腾小云导读

程序员对工作量评估不准确？日常临时问题打乱排期？怎么让大家对需求的理解一致？如何既保证开发效率又保证质量？项目管理是「把事情做对」的重要能力之一。知识型工作者包括程序员，在工作中都不知不觉中扮演着「非职业项目经理」的角色。具备项目管理能力，对程序员职业发展、个人生活都有重大价值。本文详细分析程序员如何进行进度管理、质量管理和风险管理。

看目录

(资料图片仅供参考)

1为什么开发者需要懂项目管理

1.1项目管理是“通过别人做成事情”的能力

1.2项目管理能输出个人影响力

1.3项目管理对个人生活也有价值

2开发者在项目管理中会遇到哪些问题

2.1 开发者的痛点

2.2 怎么衡量项目管理的“好/坏”？

2.3 开发者需要哪些能力

3开发者怎么做好项目管理

3.1如何做好进度管理

3.2如何做好质量管理

3.3 如何做好风险管理

4 总结

本文由腾讯MoonWebTeam团队的赖文辉、蔡卓伦、刘冬、陈长吉协作完成

‍‍

01

为什么开发者需要懂项目管理

“动机”有时比“行动”更重要。了解一个事物的价值，能让事情做的更好。学习项目管理能带来什么好处呢？《项目管理精华》一书将项目管理视为「21 世纪独有的工作」，作者认为每一名知识型工作者都在工作中不知不觉中扮演着「非职业项目经理」的角色。开发者其实就是典型的知识型工作者。总体来说项目管理对开发者的职业发展和个人生活均有着很大的价值。

1.1 项目管理是「通过别人做成事情」的能力

古往今来，如何驱动一个人做成一件事情，一直都是一个人稀缺的能力。

汉高祖刘邦有一句经典名言：“夫运筹策帷帐之中，决胜于千里之外，吾不如子房(张良)。镇国家，抚百姓，给馈饟，不绝粮道，吾不如萧何。连百万之军，战必胜，攻必取，吾不如韩信。此三者，皆人杰也，吾能用之，此吾所以取天下也。”正是刘邦具备协调张良、萧何、韩信三人协同工作的能力，才使得其能夺取天下，建立大汉王朝。

反观刘邦的对手项羽，当初凭着个人英雄主义，势力一度增加。但势力增大、地盘扩大后，面对纷繁复杂的战争形势，他没能协调好手下的将领，没做到知人善用。最终落得“至今思项羽，不肯过江东”的下场。

而项目管理正是使他人协同做成一件事情，达成目标的能力。试想一下，拥有这样能力的人，在哪个团队会不受欢迎？而且这样的能力并不会随着年龄而降低，反而越老越吃香。

1.2 项目管理能输出个人影响力

项目管理中很多做事情的方法都很符合「为人处事」之道，例如学会及时同步信息的能力。将各类信息及时且高效的以合理的渠道同步给对应的角色，就很容易成为别人眼中「靠谱的人」。

《微权力下的项目管理》一书讲到项目经理往往需要有个人魅力去影响他人做事，进而达成目标。项目管理能提升与各类干系人打交道的能力，进而提升一个人在组织内的个人影响力。

1.3 项目管理对个人生活也有价值

其实生活中很多事情都符合宽泛的项目的定义。举个例子，房屋装修就是非常典型的项目：

装修工期长，涉及各种材料购置。一次性购置材料会阻碍工人干活，分批购置，又怕丢三落四忙不开；等师傅进场再买，又担心延误工期。除此之外，装修还需要与各类工种打交道，要合理安排各工种工作排序、工期管理。在装修中，能不能少花点钱，就看一个人“成本管理“做得怎么样；能不能快点住进新房子取决于一个人的“进度管理”；而能不能住的安心，就要看“质量管理”有没有做好。

生活中处处是项目，掌握项目管理的能力，对于个人生活大有裨益。

02

开发者在项目管理中有会遇到哪些问题

说了这么多好处，大家一定很关心开发者在工作中怎样做好项目管理。在讲怎样做好之前，我们先探讨一下在项目管理中有什么痛点，再分析下在开发项目中哪些部分涉及项目管理以及如何衡量项目管理成功与否，最终目的是提炼出开发者需要的项目管理能力。

2.1 开发者的痛点

作者在写文章之前调研了身边部分开发者同事在项目管理上的痛点，总结起来主要包括以下几类问题：

工作量评估问题：工作量评估不准确。进度问题：日常杂事或者临时问题打乱排期。外部依赖问题：设计/后台等外部资源延期/需求变更，怎么推动解决？沟通问题：如何让大家对需求的理解保持一致？效率和质量平衡问题：怎么既保证开发效率又保证质量？...

工作量评估问题：工作量评估不准确。进度问题：日常杂事或者临时问题打乱排期。外部依赖问题：设计/后台等外部资源延期/需求变更，怎么推动解决？沟通问题：如何让大家对需求的理解保持一致？效率和质量平衡问题：怎么既保证开发效率又保证质量？...

2.2 怎么衡量项目管理的好与坏

也许大家都做过项目管理，但是怎样知道做的好不好？为了回答这个问题，作者咨询了几位做项目经理的同事，他们讲述了很多要素。综合来看，以下三个要素是都有提到的：进度、质量以及成本。这三要素最终会影响到项目的目标。

进度是否符合预期？

这个很容易理解和衡量。你是不是按时完成了项目中每个里程碑阶段的任务？你是不是按照预期的时间交付了项目中所规划的功能点？延期往往也是项目中最容易出现的风险。

质量是否达标？

项目的质量是最为重要的要素。直接关系到各个利益相关者，直接影响项目目标的达成。作为开发工程师，质量是否达标也关系到个人及团队的技术口碑。

成本是否可控？

你是否设法在预算范围内交付某个项目？这个预算究竟是高还是低？和平均线偏差多少？对于开发人员而言，可以关注投入的机器资源及人力成本是否合理。

2.3 开发者需要哪些能力

在大家关注的边界里，基于衡量好坏的标准并以解决实际痛点为目标，可以提炼出我们需要的能力模型：进度管理、质量管理、风险管理。由于成本管理不是痛点，所以此处不提。下文我们展开讲述。

03

开发者怎样做好项目管理

以下将从进度管理、质量管理、风险管理三项展开阐述如何做好项目管理。

3.1 如何做好进度管理

如何合理地利用资源、按时完成项目是做好项目管理最基本的要求。大多数失败的项目是由于不合理的进度规划导致的。所以做好进度管理是做好项目管理的关键。接下来将详细地介绍进度管理基本的概念和内容，以及做好项目管理的基本流程和思路。

剖析在做进度管理中的重难点，主要从评估工作量、依赖管理、意外事项的处理三个方面进行分析。下面我们展开介绍。

3.1.1 如何做好工作量的评估

做好工作量评估是做好进度管理最关键的一步，合理地对需求进行分析和拆分，明确各个阶段具体的事项，再根据日常的工作经验，对各事项所花费的时间加以估算，才能将整个大的需求的工作量评估得更加准确。

需求详细方案设计

做好工作量评估的第一步，是做好详细需求方案的设计。一份完整的需求方案设计包括：概要设计、详细设计、监控、容灾等内容。前期有详细的方案设计，才能对项目整体上有更好的把控，同时也有助于任务拆解等工作。

在做完需求详细设计方案后，再通过有开发经验的工作人员评审。一般经验丰富的开发人员能够通过设计方案发现背后的风险，能够及时将架构设计的不合理、兼容性未考虑等问题提前暴露出来，同时也能更加明确工作量。理论上来说，在完成需求方案评审后，后续的改动很少，整体的工作时长更加可控。

这里需要重点关注的是，如果开发周期大于一个月，建议分成多个需求迭代，以降低迭代周期，小步快跑。

合理拆解，明确职责

在完成需求方案详细设计后，对任务进行合理拆解。怎样拆解才是合理的？首先我们详细介绍下4个拆解的原则。

原则	含义
两天原则	拆解之后的单个任务不能太长。太长的话，就会存在工作量评估不准确、整体项目难以把控的问题。同时也不利于工作的合理分配，不能更好地利用人力资源。如果时间太短，就会导致工作交付的频率过快，开发者的工作之间也会存在着一定的耦合。拆解的粒度太小，会增加一定的沟通成本，得不偿失。最好工作拆解的粒度为一至两天。
成果作为导向原则	任务拆解应该以可交互的结果作为导向，并且一定要有输出。这个输出应该是完整的，不然这个拆解就拆解得不够透彻，或者说不算一个任务。
责任到人原则	拆解之后的任务项，有且只能有一个负责人。即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。
任务分层原则	任务拆解的过程也是一个解耦的过程，避免多个任务之间有耦合。拆解的过程应该是自上向下的，从一个大的任务，按照其特性进行任务拆解，不断地拆解成子任务，直到拆解到一至两天的工作量，并且是一个可交付的工作项。

下面我们详细了解下如何进行任务拆解。以正常迭代一个 h5 项目的功能为例，一共有四个大的功能模块，三个开发人员。那么我们需要：

事项	解析
自顶向下，逐层拆解	通过 WBS 的工具，对项目进行拆解。为保证任务拆解之后的完整性，应将整体的项目自上向下，逐层拆解。这有利于排查项目开发的各个阶段是否有遗漏。按照项目的研发流程进行拆解任务，再将各个任务进一步细分到所需时间为两天。
落实负责人，确认拆解是否合理	将每个任务落实到该任务负责人，负责人能够从自己的角度出发，进一步思考该任务的拆解是否合理，同时也能够明确自己所负责的任务需要和谁对接，更能够了解联调的成本。
总体复盘，确认有无遗漏任务	最后大家根据开发经验，梳理整体流程有无遗漏，如单元测试，埋点开发，联调，代码的 mr 等。

估算工作，知晓预期

在对任务进行拆解后，下一步是对任务进行工作量评估。这个过程在项目管理中，也是一个非常棘手的事情。工作量评估不准确，就会直接导致该任务项出现问题。评估的时间偏多，会存在着资源浪费的问题；评估的时间偏少，将直接造成当前任务延期完成，同时阻塞后面模块的开发，损失更大。

接下来介绍两种工作量估算方式，一种是自上而下的估算方式，一种是自下而上的估算方式。

估算模式	解析
自上而下	自上而下的估算方式是以项目总体为估算对象。这对于有类似项目经验的工程师来说较容易评估。方法是将工作结构从头部向尾部依次分配、传递工作量，直到到达WBS 的最底层。其特点是：项目初期信息不足，只能初步分解工作结构，很难将最基本的工作详细内容列出来。估算的精度较差。估算的工作量小，速度快。
自下而上	自下而上的估算方式是，先估算各个工作项的工作量，再自下而上的将各个工作量进行汇总，算出总的工作量。其特点是：估算的精度高。估算的成本较大。缺少子工作项之间的工作量估算。

项目初期信息不足，只能初步分解工作结构，很难将最基本的工作详细内容列出来。估算的精度较差。估算的工作量小，速度快。

自下而上自下而上的估算方式是，先估算各个工作项的工作量，再自下而上的将各个工作量进行汇总，算出总的工作量。其特点是：

估算的精度高。估算的成本较大。缺少子工作项之间的工作量估算。

3.1.2 如何做好依赖管理

因为外部依赖而导致项目延期的情况在工作中屡见不鲜，常见的诸如：

准备开始开发了，发现设计稿还未就绪。准备联调的时候，发现我们上下游的技术团队的接口还未就绪。可以联调的时候，因为上下游的链条很长，出现推诿甩锅。

...

以下是一些针对外部依赖问题的解决方法。

解决方法	解析
明确责任人和交付时间，避免模糊	这是第一步。当一个事情出现多个负责人的时候，责任的边界就会模糊，就容易互相推诿的情况，这就是责任分散效应。三个和尚没水喝的故事就是一个典型案例。因此对于每个依赖项，我们需要明确其责任人，并沟通明确每个人对应依赖的交付时间，把责任人和交付时间提前确定清楚，可以减少很多争议和推诿。当项目涉及很多团队的时候，可以使用资源依赖列表，当遇到问题时，可以快速查找负责人及其应当交付的时间点。例子：云游 XX 活动的资源依赖列表
形成信息对齐机制	确定了接口负责人后，如果不及时进行信息对齐，也会出现跑偏的情况。反面案例：A 项目依赖外部的 sdk的 某个升级版。在最初的对齐方案中，sdk 方承诺不会修改原有的接口调用方式。而实际联调中才发现不仅接口调用方式发生了巨大变化，还有部分被依赖的接口直接在新版本中移除，导致A方需要花费大量时间进行兼容。如果提前对齐而不是等到联调阶段才介入，就能规避上述问题。关于信息对齐方式，有以下几种：不定期的非正式沟通在里程碑等关键节点通过面对面、电话、企业微信等方式进行信息对齐。对齐内容包括：开发进度、依赖事项进展、技术方案变更等，对于一些关键性的结论，最好有文字落地以用于回溯。定期的例会机制如定期晨会机制。在会议上对齐项目进度，可以提前发现可能存在的风险。记录会议纪要并通过群消息/文档/邮件的形式通知到项目的相关干系人。项目 owner 机制应当确定一个项目 owner，对项目整体负责，把关整体节奏，负责组织会议。把相关信息进行整合，并同步给项目的相关干系人。
求同存异，达成共识‍‍	作为项目组的成员，大家的核心目标应是一致的，就是让这个项目能够如期保质上线。但在实际执行中，各个依赖方因为各自的问题，会出现一些偏差。只要能核心目标是一致的，相关的问题就可以通过沟通解决。案例：春节活动需求变更 PK作为最重要的传统节日，很多业务团队都会针对春节这个时间节点运营、上线活动，作者曾经遇到过在临近提测时，活动仍在被提需要大量变更的情况（运营人员要叠加功能，设计人员则提出更多特效的要求），开发人员如果接受了大量变更，不仅意味着不断加班，更可怕的是会由此带来很大的质量风险，一旦出现严重问题，会得不偿失。最后只能是开发人员联合测试人员，跟运营和设计进行了沟通，研发侧认可变更对于提升活动效果有作用，同时也对变更可能带来的延期，以及影响线上质量等风险进行了全面分析评估。双方基于共同的目标做出了协商和让步（既保证活动效果，同时也保证活动正常安全上线）。
情感账户，软性推动	当项目依赖某个外部团队的人员支持，而这个事情并不是对方当前工作范围内的，并不是对方第一优先级的工作，该怎么办？大部分情况，有些开发者会在沟通未果的情况下，通过上升到leader去推动事情落地，这是一种解决方案。更优的方案是建立相关依赖方的“情感账户”，借助“情感账户”去软性推动。大家都知道银行账户就是把钱存进去，作为储蓄，以备不时之需。“情感账户”里储蓄的是人际关系中不可或缺的信任。经营好「情感账户」，也是经营好一个人与合作伙伴的信任关系。在日常工作中多吃亏，让自己的「情感账户」适当“存储”。例如自己曾经抽出休息时间帮助合作伙伴解决问题，当需要对方协助的时候，相信也能得到积极的响应，这也是常说的“吃亏是福"。

不定期的非正式沟通

在里程碑等关键节点通过面对面、电话、企业微信等方式进行信息对齐。对齐内容包括：开发进度、依赖事项进展、技术方案变更等，对于一些关键性的结论，最好有文字落地以用于回溯。

定期的例会机制

如定期晨会机制。在会议上对齐项目进度，可以提前发现可能存在的风险。记录会议纪要并通过群消息/文档/邮件的形式通知到项目的相关干系人。

项目 owner 机制

应当确定一个项目 owner，对项目整体负责，把关整体节奏，负责组织会议。把相关信息进行整合，并同步给项目的相关干系人。求同存异，达成共识‍‍作为项目组的成员，大家的核心目标应是一致的，就是让这个项目能够如期保质上线。但在实际执行中，各个依赖方因为各自的问题，会出现一些偏差。只要能核心目标是一致的，相关的问题就可以通过沟通解决。案例：春节活动需求变更 PK作为最重要的传统节日，很多业务团队都会针对春节这个时间节点运营、上线活动，作者曾经遇到过在临近提测时，活动仍在被提需要大量变更的情况（运营人员要叠加功能，设计人员则提出更多特效的要求），开发人员如果接受了大量变更，不仅意味着不断加班，更可怕的是会由此带来很大的质量风险，一旦出现严重问题，会得不偿失。最后只能是开发人员联合测试人员，跟运营和设计进行了沟通，研发侧认可变更对于提升活动效果有作用，同时也对变更可能带来的延期，以及影响线上质量等风险进行了全面分析评估。双方基于共同的目标做出了协商和让步（既保证活动效果，同时也保证活动正常安全上线）。情感账户，软性推动当项目依赖某个外部团队的人员支持，而这个事情并不是对方当前工作范围内的，并不是对方第一优先级的工作，该怎么办？大部分情况，有些开发者会在沟通未果的情况下，通过上升到leader去推动事情落地，这是一种解决方案。更优的方案是建立相关依赖方的“情感账户”，借助“情感账户”去软性推动。大家都知道银行账户就是把钱存进去，作为储蓄，以备不时之需。“情感账户”里储蓄的是人际关系中不可或缺的信任。经营好「情感账户」，也是经营好一个人与合作伙伴的信任关系。在日常工作中多吃亏，让自己的「情感账户」适当“存储”。例如自己曾经抽出休息时间帮助合作伙伴解决问题，当需要对方协助的时候，相信也能得到积极的响应，这也是常说的“吃亏是福"。

3.1.3 如何处理意外事项

排期后进入开发，还是会存在各种事情影响项目的进展。例如：插入一些高优的需求，或者说发生一些不可控的因素如疫情等等导致人力不足，从而影响项目的进展。下面我们详细介绍几种情况及其处理方式。

1. 需求的变更

在设计详细需求方案中，如果考虑得不够周全，开发过程中就会产生需求变更。

处理方式：

‍判断需求变更的大小，如果是样式修改等简单变更，半小时能解决的小问题，可以协助快速调整；如果工作量在 0.5 天以上，并且需要依赖第三方接口，则需要将整体的需求重新评估，重新梳理排期，并同步给干系人。先保证核心的业务流程不变，高收益的工作量优先处理，保证正常的上线时间，后续有余力再对其它功能点进行迭代优化。‍

‍判断需求变更的大小，如果是样式修改等简单变更，半小时能解决的小问题，可以协助快速调整；如果工作量在 0.5 天以上，并且需要依赖第三方接口，则需要将整体的需求重新评估，重新梳理排期，并同步给干系人。先保证核心的业务流程不变，高收益的工作量优先处理，保证正常的上线时间，后续有余力再对其它功能点进行迭代优化。‍

2. 高优需求插入

在业务的开发过程中，可能存在被高优需求插入的情况，如果被高优需求插入，直接带来的影响是延后当前的工作完成时间。

处理方式：

评估高优需求的工作量，以及影响当前项目的程度。如果在 0.5 天以内，没有被依赖的下游时，再评估对排期影响不大的情况下是否可以快速响应。并第一时间反馈风险，确保各干系人都有一个心理预期；如果大于 0.5 天的需求，则建议反馈给项目干系人来安排其他人来解决。

3. 不可抗力的因素

不可抗力在项目的开发过程中也是不可避免的。如开发人员有急事需要请假，又或者因为疫情导致办公效率低下，从而影响项目的进展。

处理方式：

如果是一些身体原因导致办公效率低下。在不影响整体项目交付的情况下，适当的延长完成项目的时间；若影响到整体项目交付的时间，则应该暴露该风险，进行项目计划调整。如果完全不能投入开发，应该尽早的将此事向上级报备，由上级进行统一的人力调整，交由其他人投入开发。‍

如果是一些身体原因导致办公效率低下。在不影响整体项目交付的情况下，适当的延长完成项目的时间；若影响到整体项目交付的时间，则应该暴露该风险，进行项目计划调整。如果完全不能投入开发，应该尽早的将此事向上级报备，由上级进行统一的人力调整，交由其他人投入开发。‍

4. 内部依赖延后

内部依赖延后影响到项目的进展也是项目开发中经常发生的事情。最好的做法是依赖前置。如果在规定的时间，没办法进行交付产物，则会给项目带来延期风险。

处理方式：

将自身的业务流程做好，依赖部分通过模拟的方式解决。将联调的时间后移，先开发其他的功能模块。如果已经是最后联调阶段，则需要再次调整交付的时间，同时将该风险同步给相关的干系人。

将自身的业务流程做好，依赖部分通过模拟的方式解决。将联调的时间后移，先开发其他的功能模块。如果已经是最后联调阶段，则需要再次调整交付的时间，同时将该风险同步给相关的干系人。

3.2 如何做好质量管理

质量管理的价值就是保证项目质量以达成项目目标，降低因为产品质量问题带来的损失。

3.2.1 通过流程规范提高质量

研发流程是一个精细的过程。需要通过建立执行规范来实现工作标准化和程序化，确保产出质量稳定和高团队工作效率，降低人为因素导致的质量问题。

1. 制定研发流程规范

制定流程有时会让人反感，觉得降低了研发效率。但规范的流程可以大大提升项目的质量，好的流程都是在实践中不断总结出来的，是项目的最佳实践。

当然流程也不是一成不变的，它需要根据我们的具体情况不断调整优化，才能适应当下的需要。另外应当尽量将流程变成 CICD 的约束，通过系统来约束、控制，减少其对人的依赖。

具体到研发团队介入一般可分为需求评审、方案设计、需求开发、测试验收、发布上线、项目复盘六个步骤。这里提供之前所在前端研发团队的研发流程图用以参考：

2. 严格执行Code Review

code review 的好处不仅仅是能够大大提高代码质量，减少代码 bug，还能从心理上（自己写的代码要给别人审核）让自己更认真严谨些。另外 CR 交流也非常有利于提升团队的工程素养，可以针对性补强开发者的知识盲区，纠正不良习惯。

3. 制定发布checklist

每次发版上线都应当是如履薄冰。为了保证上线顺利，发布完善的 checklist可大大规避低级错误，减少不必要的事故。

发布 checklist 一般可以分为服务、机器、流程三部分，通过日常工作中累计容易出错的地方，将其整理收集起来，持续完善。

这里提供一份参考案例：

阶段	事项	是否通过
提测前	根据前期编写的测试用例进行整体自测
	根据埋点文档验证埋点，确保埋点中的事件和维度不多报、不漏报、不错报、不重复报、报的时机正确
	根据设计稿叠图并截图（2+测试机），确保无视觉问题
	确保分支的代码CR通过
	确保代码已发布到测试环境，并确认页面能够正常访问
	确保创建了提测单，提测单包含测试用例地址、测试范围、测试入口和二维码、终端环境、埋点文档地址
	确保需求单状态扭转到增量测试中
bug修复后	涉及到功能、逻辑、埋点、样式和交互变更：重新走本次需求逻辑部分的自测、涉及样式的叠图、CR 和发布测试环境流程，确保全流程无误
	确保bug单状态扭转到已处理，并通知测试同学验证，保证在 1D 之内扭转到已关闭
	确保需求单状态扭转到待发布
发布前	确保产品体验、设计走查、测试都通过
	确保所有代码（功能+bug修复）都已经通过CR，合入 master
	确保正式环境配置文件中的配置都是正式环境的配置
	如图片有新增和修改，确保图片已经进行过压缩
	确认接口监控的数据正常，业务错误码屏蔽正常，不误报
	上线前和产品运营确认线上配置是否正确，涉及运营资源是否到位
	和后台、终端确认好发布顺序，并确保按照约定顺序发布
	确保在群里进行发布周知，提交的发布审批通过才能进行发布
发布后	待 CDN 生效后，用非公司 wifi访问页面，确保页面正常，同时确保所有的资源都是正式的 CDN 地址
	关注告警群消息，关注告警监控平台流量监控是否有较大波动，JS 报错、接口错误率是否有上涨，关注是否有告警
	发布出现问题，及时在群里周知并回滚，通知leader，并寻求团队成员协助定位排查
	发布外网后需要留守至少 30 分钟
	确保需求单状态扭转到已交付和已接受

很多时候不起眼的清单发挥着非常重要的作用。例如飞机起飞前的检查清单、手术前后的检查清单，都守护了无数的生命。更多清单相关内容推荐一本书叫作《清单革命》。

3.2.2 管理变更影响

变更是程序异常的主要原因。在需求设计阶段提前对变更进行评估、规划，可以确保在对程序最小负面影响的情况下实施这些变更。同时在团队内进行有效的协商和沟通，可以确保所有的变更都具有可追溯性。下面分别介绍下如何通过详细设计评审技术方案和通过架构设计上隔离变更。

通过详细设计评审技术方案

编写技术文档对部分工程师来说是反感的事情，但好的项目质量一定是设计出来的，而不是测试出来的。

所以在正式编码前，详细思考、设计整体方案并编写成技术文档在组内评审，是规避质量风险非常好用的方法，也是非常好的开发习惯。它可大大减少编码阶段的质量风险。

以之前笔者团队为例，我们还整理了团队详细文档模板，把大家做详细设计需要考虑的点都囊括了进去，避免大家遗漏。如性能设计、监控日志设计、安全风险设计、用例设计、容灾设计等，既是模板也是详细设计的 checkList。

通过架构设计上隔离变更

许多开发者在职业生涯中最害怕的莫过于修改老代码，有些老代码读起来云山雾罩，完全搞不懂业务逻辑和代码关系、也不明白这块代码为什么这么写、那块代码是什么意思。使得大家战战兢兢、寸步难行。

与之相反的「好代码」一般都遵循软件工程概念中的高内聚低耦合原则，模块之间相互隔离。常见的隔离方式如下：

隔离方式	解析
分层架构	分层架构的一个重要原则是每层只能与其下方的层发生依赖。由于各层间松散的耦合关系，使得开发者可以专注于本层的设计，而不必关心其他层的设计或本次变更会影响到其它层，只需保持本层的接口稳定。大型系统中推荐使用 DDD (领域驱动设计)，将系统拆分成展现层、应用层、领域层、基础设施层。
组件化设计	组件化可以比喻为积木。其工作方式信奉独立、完整、自由组合。目标就是尽可能把设计与开发中的元素独立化，使它具备完整的局部功能，再通过自由组合来构成整个产品。
特性开关	目前最为常用的隔离方式还是特性开关。这种方式隔离较为彻底，如果某种场景不需要该特性，直接关闭开关即可，缺点在于代码中可能会存在许多开关逻辑。
资源隔离	从物理上隔离变更导致的影响，通常使将其以服务、静态资源、网络、内存、进程等方式进行隔离，通过使变更带来的影响在可控范围内，隔离其对其他资源的影响。

3.2.3 功能回归的能力

功能回归能力是指：通过自动化的回归测试，寻找原始设计中没有预料到的错误。这里需要考虑到2件事：

第一，有效的测试是设计出来的。

测试左移的意思就是说尽可能地在前期规避质量问题，以提高效率。大家都知道越早发现问题，修复 bug 的成本越低。例如在设计阶段发现 bug 只需要改写流程图，编码阶段只需要修改代码，测试阶段需要重新走 git 合并 mr 流程，要是到了上线后才发现问题将直接影响是线上用户，那么其修复成本和前面的这些相比可能会没有上限。

设计阶段：做详尽的需求分析和测试用例设计，好尽早发现不合理的地方，尽早暴露问题，以便团队能更早的在需求评审阶段识别并修复缺陷。编码阶段：研发可以依照测试用例自行编写单元测试、接口测试来验证核心逻辑是否正确。尽可能确保所有代码被测试到，所有的业务流程都能被测试用例覆盖到。

设计阶段：做详尽的需求分析和测试用例设计，好尽早发现不合理的地方，尽早暴露问题，以便团队能更早的在需求评审阶段识别并修复缺陷。编码阶段：研发可以依照测试用例自行编写单元测试、接口测试来验证核心逻辑是否正确。尽可能确保所有代码被测试到，所有的业务流程都能被测试用例覆盖到。

第二， 接入自动化测试平台。

DevOps 工具是目前最适合做测试的集成管理平台，从需求提交到产品迭代，从产品设计到代码构建、测试管理、持续集成，整个流程贯穿软件行业生命周期。在平台的基础上将各环节的数据收集、沉淀成量化指标。如在代码构建阶段的流水线集成代码规范检测、代码质量检测、单元测试、安全性校验等工具，能够产出代码重复率、单测覆盖率、安全问题数、页面性能等有效衡量项目代码质量的数据指标。

3.2.4 发现问题和定位问题的能力

研发阶段要尽量保证质量，不出现 BUG。上线后需要确保一旦出现问题，能快速通过告警发现，并快速定位找到原因，从而最大限度降低对现网的影响。下面我们将介绍如何利用监控告警发现问题、规范日志快速定位问题和利用智能化监控平台。

第一，利用监控告警发现问题。

在需要监控告警前，开发者需要先定义需要关注哪些问题？笔者主要涉及前端工作，这里提下前端团队一般需要关注的问题：

类型	指标	案例
脚本问题	页面js错误、接口错误、页面白屏、资源加载错误 等	页面 JS 错误 xx isnot defined
性能问题	首屏耗时、首屏可见耗时、接口平均耗时、接口成功率 等	检测到近 5 分钟领取礼包接口接口成功率下降触发告警
业务问题	流量下跌、核心链路转化率下跌、特定业务错误上升	云游戏用户排队耗时提高导致用户流失，需要额外开启设备

然后再跟进对应指标配置所对应的告警策略。

第二，规范日志快速定位问题。

线上项目的程序出问题，程序本身不会说话只会安安静静的挂机。但导致这一现象出现一般就是业务代码写得有问题。

如何让程序能够「说话」，并准确的说出有价值的信息，这就是日志的核心价值。日志要解决的问题是：程序是不是按预期执行？用户在系统上干了什么？程序有没有执行错误？问题是谁造成的？合理日志的要素如下：

合理日志的要素	解析
日志时间	日志作为事件的表述，事件发生的时间是一定要具备的。
日志级别	应该根据日志的重要性或严重程度划分等级，常用的日志级别有：DEBUG、INFO、WARN、ERROR，只有合理定义日志级别，才能避免日志混乱。日志级别也是日志告警的关键条件。
业务标识	用来区分日志属于哪块业务，因为日志都是跟业务相关联的，通过该部分内容便于按业务进行日志归类聚合。
日志内容	根据不同的日志等级，在日志内容上会有不同的侧重点，尽量描述清楚。
异常堆栈	堆栈异常信息有助于程序异常的排查定位，但这部分信息的记录输出，对系统性能有一定的影响，应该酌情考虑，如果记录异常信息足够定位异常，就不要打印整个堆栈。一般是 ERROR 打印异常堆栈，WARN 不打印，还有就是通过日志框架打印，避免用 printStackTrace 方法打印。
追踪 ID	对于单次用户行为需要一个唯一的ID 贯穿全链路日志，方便对用户行为进行追踪，错误信息也能够查询到用户行为的上下文，方便定位日志。

日志记录的时机如下：

日志记录的时机	解析
程序流程	记录程序的流转分支，在关键代码逻辑的执行前后进行相应的日志输出，有助于代码调试。但要避免不必要的日志输出，比如一般只在循环体前后记录日志，而不在循环体内重复记录，过多的日志反而会影响阅读。
远程调用	远程调用也属于程序流程的一部分，但第三方远程调用的日志信息级别，应该与一般的调试日志区别对待，因为涉及到外部系统的交互，在出入口处记录请求响应的信息，这相当重要。
系统初始化	系统初始化需要依赖一些关键配置参数，这些参数决定系统的启动状态，应该把这些系统初始化信息记录起来。
核心业务操作	系统用户进行核心业务操作的行为，也应该进行记录，便于进行操作审计。
可预期的异常	这类异常应该有效记录起来，通过警告方式反馈给相关人员加以关注，避免频繁发生，最终演化为不可控的错误。
预期外的错误	这类异常发生时，要有详尽记录，并通知相关人员介入处理，并预留时间作出响应，因为这种错误已经影响系统的正常使用。

第三，智能化监控平台。

每次排查告警问题对程序员而言都是体力活，都想能够轻松，快速的查看日志，更进一步还有监控平台能够直接告诉问题是什么、怎么解决。近年来就产生出一些智能数据分析平台，利用大数据技术及机器学习技术对 IT 基础架构及应用系统所产生的海量日志进行实时分析。

能实现大量的日志模式发现并进行聚类，将大量的日志原文转化为少量的日志模式，并反应相应模式在日志原文中的占比，这大大减少了人工筛选时间，帮助运维人员更快的定位到故障原因。

如果更进一步，那就是在发生告警的时候其可以提供一张监控大盘、影响范围、触发异常用户的全链路日志。信息密度的提高能够协助我们快速感知服务的整体状况、评估风险等级，全链路日志也能辅助开发者更快捷的定位问题，提高告警信息触达的效率和质量。

3.3 如何做好风险管理

如果用一句话来形容风险，应该是这样的：

风险如鬼魅在深渊潜藏，它可能出现在项目中任何一个环节，在未来的某个时刻出现，对开发者负责的项目产生破坏性的影响。

下面我们分别聊一聊风险管理管的是什么，以及在实际项目中我们要注意哪些。

3.3.1风险管理管的是啥

风险的本质

风险的本质是一种不确定性带来的损失。项目风险实质上是项目的三要素：进度、成本、质量中，一个或多个受到了影响，最终影响了整体项目目标的达成。

风险的特征和构成要素

风险具备以下特征：

日志记录的时机	解析
客观性	风险是客观存在的，不以人的意志为转移，项目中存在风险是常态
不确定性	风险是否造成损失，以及损失的程度，是不确定的
可观测	单一风险存在不确定性，但是总体来讲是有规律的，有办法预测的
可变性	风险会随着应对措施的进行而消失，不会一层不变

而风险的构成则包含三要素：风险因素、风险事故、损失。

风险因素会引发风险事故，风险事故会进一步带来损失。

例如：小 A 是某个紧急项目的研发负责人之一，项目既定的时间是 2022 年 1 月 1 日上线，此时正值解除疫情防控，身边越来越多的同事感染，小A所在项目组的研发成员也陆续感染，最后项目不得不延期。

可以想想：对于小 A 所在的项目组，风险因素，风险事故，损失是什么？

风险管理怎么做

风险管理从流程上主要做四件事：风险识别、评估、应对和沟通。下面展开介绍。

风险识别：

核心是找出可能产生风险的“风险因素”，识别分析这些“风险因素”究竟有哪些特征，可能会影响项目的哪些方面。例如上述小 A 的例子，风险因素就是疫情的放开带来的感染风险，其特征就是会导致成员患病无法工作，影响就是项目的延期。

风险识别方法	解析
头脑风暴法	一些人聚集起来，进行头脑风暴，通过彼此的沟通交流，想法、建议、意见进行碰撞，一起发现问题。
专家调查法	由相关领域的专家组成风险小组，通过征求专家的意见，然后开发团队综合汇总整理，再反馈给专家，再次征求专家的意见，反复进行 4～5 轮，最终专家们的意见会趋于一致，达成共识。
情景分析法	识别关键影响因素，基于该因素可能发生的场景，进行场景内容的分析，进而发现风险可能造成的后果。
核对表法	将项目范围、目标、成本、质量要求、进度、类似项目成功或失败的原因等列在一张表上，进行一一核对。这种方法可以识别到进度风险、成本风险、质量风险等。
流程图法	需要建立项目的全链路流程图以及各子域流程图，这些流程图可以涵盖项目的整体流程以及分支细节。通过将实际情况与流程图一一对比，便可识别风险。

上述小 A 的例子属于进度风险，通过「核对表法」是比较容易识别到疫情防控开放这个风险因素的。

风险评估：

对已识别出来的风险因素，进行系统分析和研究，评估其带来风险的概率，造成损失的范围和程度。

风险评估一般有“定性分析”和“定量分析”两种：

定性分析：根据风险的重要程度和发生概率等指标对风险因素进行排序。定量分析：将体现风险特征的指标量化，以强化对风险因素的认知。

定性分析：根据风险的重要程度和发生概率等指标对风险因素进行排序。定量分析：将体现风险特征的指标量化，以强化对风险因素的认知。

定量分析包括“蒙特卡洛法”、“敏感分析法”、“决策树”、“影响图”等，都是非常专业的分析方法。实际上，作为非专业项目经理的技术人员，一般通过定性分析就可以对风险进行评估了。

如上述小A的例子如果不采取措施，疫情防控的解除带来的延期风险会随着时间推移不断接近严重度100%。

风险应对：

在评估完风险的概率和损失范围之后，就可以为风险应对提供参考依据了。

风险应对主要以下几种方法：

方法	说明	例子
规避风险	消除风险因素进而规避风险的产生	1、改变项目目标包含的范围2、投入更多的成本（人力、资金）
转移风险	将风险转移给第三方	购买保险
减轻风险	降低风险发生的概率或受影响程度	1、将鸡蛋放在不同篮子2、兜底策略
接受风险	对即将发生的风险，不采取措施	/

如上述小A的例子，从“规避风险”的角度，我们可以投入更多的备份人力，或者调整项目目标（如调整上线时间）。从减轻风险的角度，我们可以实施分散办公（居家办公），减少项目组成员被“一锅端”的风险。从接受风险的角度，如果项目因为疫情带来的延期是可以接受的，也可以不采纳任何措施。

风险沟通：

这也是最重要的，当风险出现时，及时的跟项目干系人做好沟通，以调整项目干系人的预期。

3.3.2 实际项目我们要关注哪些风险

以上是项目管理中，针对风险管理的基本手段。作为开发人员，大家日常参与的项目，又有哪些会遇到的风险呢？如何更好的应对呢？接下来我们介绍完几个最长出现的风险后，分别为各位分享性能风险、安全风险和容灾性风险的应对措施。

1、最常出现的风险

从风险的本质出发，最常遇到的风险：

风险	解析
进度方面的风险	因为外部依赖、需求变更或者高优需求插入，带来项目延期风险。这里在进度管理章节，已经重点介绍了如何管理依赖，如何跟产品人员沟通需求变更，以及如何管理好自身的排期。
质量方面的风险	主要是在项目研发环节中会产生质量问题，如自测不充分导致提测期间 bug 数过多，在质量管理一节中也介绍了对应的解决方案。
成本方面的风险	降本增效是最近两年的主题，大家对成本的关注越来越多。成本也是一项重要风险，特别是大项目，但因为不是开发通点，本文不展开讨论。

除了“进度管理”、“质量管理”中提到的解决方法。“进度风险”、“质量风险”，通过前文提到“风险识别”=>"风险评估"=>"风险规避"=>"风险沟通"这些通用的方法论也是可以解决的。

除了“进度风险”和“质量风险”，研发人员，还有一些特定的风险因素需要关注。

2.性能风险

性能是非常容易被忽视的风险。研发人员可能忙碌于功能的实现，保障项目正常上线，往往非常容易忽视项目中可能存在的性能问题。

从风险发现的角度，开发者可以通过「性能检查清单」，梳理出可能带来性能风险的因素，并在项目开发过程中规避化解。

从风险评估的角度出发，项目性能低下可能会直接带来项目转化率的下跌。例如一个支付页面如果没有做好弱网支持，在弱网打开慢，就会带来的支付转化率不高的问题，进而影响收入。

从风险应对的角度来说，针对核心页面（例如上述提到的支付页面），需要采取措施规避风险。非核心页面（例如一个不重要的介绍页），可以采取一定措施减轻风险或者是接受风险（从成本角度出发，针对性能做优化可能需要花费更多时间）。

3.安全风险

安全是互联网永恒的话题。在当下互联网环境中，安全风险可以分为“合规化”带来的法务风险，以及系统实现漏洞带来的风险。

合规化风险

是因为不符合相关的法律法规导致的政策风险，如 app 因为实现疏忽使某些场景未满足某个保法。

从风险识别的角度出发，可以通过“专家调查法”来发现，通过请求公司的法务，对相关项目规划进行法务风险评估，并根据法务人员提供的建议进行调整。

系统实现漏洞风险

这则是因为技术实现的漏洞导致的风险。例如：活动没有做好防刷，导致奖品被刷；页面没有做好脚本过滤被 xss 注入攻击。

以风险识别的角度来说，可以采用「流程法」，对每个环节可能带来的安全风险进行梳理，如：

在“开发测试阶段”，确认工程是否在流水线中接入“代码扫描工具”；在“上线阶段”，确认服务是否接入”安全扫描“工具进行扫描；在“运营配置阶段”，确认相关运营系统的配置是否经过审查测试

在“开发测试阶段”，确认工程是否在流水线中接入“代码扫描工具”；在“上线阶段”，确认服务是否接入”安全扫描“工具进行扫描；在“运营配置阶段”，确认相关运营系统的配置是否经过审查测试

可以采用「核对表法」，整理常见的安全措施，并在项目研发阶段对照核对：

涉及数据查询修改，必须有登录态校验。涉及数据修改，必须要有 token 校验，避免 CSRF 攻击。所有输入都需要白名单校验，包括从 URL 获取数据、从 cookie 获取数据、从表单获取数据等，避免 SQL 注入、XSS 攻击等。涉及福利相关，必须有黑产打击策略。是否有严格的用户权限校验。涉及外部对接时，必须包含加密或验签环节。还存在哪些安全隐患？是否考虑防安全扫描。

涉及数据查询修改，必须有登录态校验。涉及数据修改，必须要有 token 校验，避免 CSRF 攻击。所有输入都需要白名单校验，包括从 URL 获取数据、从 cookie 获取数据、从表单获取数据等，避免 SQL 注入、XSS 攻击等。涉及福利相关，必须有黑产打击策略。是否有严格的用户权限校验。涉及外部对接时，必须包含加密或验签环节。还存在哪些安全隐患？是否考虑防安全扫描。

针对一些重点项目（比如量级庞大的春节活动），也可以采用「专家调查法」，提交相关的技术方案给到业务安全的人员进行审查，以发现系统设计存在的潜在安全漏洞。

从风险评估的角度出发，与安全相关的风险往往是无法忽视的，是第一优先级需要解决的，因此风险应对手段，往往是需要采取对应措施来规避风险。

4. 容灾性风险

缺失针对系统运行异常情况的处理，也是一种潜在风险。从风险识别的角度，同样也可以使用「核对表法」来核对潜在的异常情况是否都有对应的处理措施：

服务可用性相关的核对表：

系统即将面临的最大流量是多少？需要提前多久跟运维沟通扩容？系统各个环节能承受的流量压力，哪些环节需要扩容？如果流量陡增、服务过载时，系统有没有做兜底降级方案?有没有做多地部署，规避单点风险？...

系统即将面临的最大流量是多少？需要提前多久跟运维沟通扩容？系统各个环节能承受的流量压力，哪些环节需要扩容？如果流量陡增、服务过载时，系统有没有做兜底降级方案?有没有做多地部署，规避单点风险？...

逻辑实现相关的核对表：

数据结构是否变更，如果变更是否考虑老数据兼容？边界条件是否。运行环境可能存在的兼容性问题？（前端经常遇到）....

数据结构是否变更，如果变更是否考虑老数据兼容？边界条件是否。运行环境可能存在的兼容性问题？（前端经常遇到）....

从风险评估的角度出发，需要根据服务/页面的重要性，采取对应的风险应对措施：

一些核心场景（如支付场景），相关服务/页面一旦出现问题就是直接的经济损失，因此就需要采取措施规避风险。

一些对用户感知不是很明显的场景，则可以采纳兜底降级的方案。例如信息流场景下，在面对突增流量冲击时，推荐系统所能承受的流量压力要远远低于接入服务的承受范围，这个时候，接入服务就需要保护推荐服务，通过返回兜底数据，减少流量对推荐系统冲击。

04

总结

为什么开发也要懂项目管理？开发如何做好项目管理？相信各位读者已有一定感知。本文首先介绍了项目管理对大家在职业和生活中的价值，接着以项目管理中的痛点为切入点，整体介绍了项目管理中需要掌握的三大能力——进度管理、质量管理、风险管理。

其中进度管理包含工作量评估、依赖管理、处理意外事项等；质量管理包含流程规范建设、管理变更影响、提升功能回归能力、提升问题发现和定位效率等；风险管理包含风险管理的基础方法论，以及实际项目中容易忽视的性能风险、安全风险、容灾性风险等。

最后期望本文能帮助开发者提升项目管理技能，提升「把事做成」的能力，成为合作伙伴眼中「靠谱」的人。以上是本次分享的全部内容，欢迎各位开发者在评论区交流。如果你觉得内容有用， 欢迎分享、点赞、在看。感谢支持。

-End-

原创作者｜赖文辉、蔡卓伦、刘冬、陈长吉

技术责编｜赖文辉、蔡卓伦、刘冬、陈长吉

「变化」对程序员而言是个极大的挑战，这是万年老话题了。客户需求在变，老板要求在变，产品经理的需求也在变。有程序员表示，当我抱怨变化带来的加倍工作量，也许还会遭到吐槽：“你程序不怎么样啊，不能顺应我的变化。” 面对变化，你有怎样的经验和方法呢？你有什么评估工作量的妙计？当变动发生，日常杂事和临时问题出现打乱排期，你怎么解决？可以做些什么来减少「变动」？

欢迎在评论区聊一聊你的看法。在3月24日前将你的评论记录截图，发送给腾讯云开发者公众号后台，可领取腾讯云「开发者春季限定红包封面」一个，数量有限先到先得。我们还将选取点赞量最高的1位朋友，送出腾讯QQ公仔1个。3月25日中午12点开奖。快邀请你的开发者朋友们一起来参与吧！

最近微信改版啦

很多开发者朋友反馈收不到我们更新的文章

大家可以关注并点亮星标

不再错过小云的知识速递

‍

‍

标签：