光有技术怎么够？为什么说每位开发者都要懂点项目管理？

引言 项目管理是『把事情做对』的重要能力之一，具体表现为通过与他人协助把事做成的能力，是我们都应具备的通用能力，我们做的每一项事情都可以是广义的项目，如买房、婚礼筹办等；同时项目能力还非常有助于提升个人影响力，建立个人品牌。本文将重点讲述从开发视角，如何把项目管理做好。

作者：owen、chairlen、kane、yama（合作编辑）

（本文内容由公众号“腾讯云开发者”提供，转载请征得同意。文章仅为作者观点，不代表GWB立场）

“动机”有时比“行动”更重要，了解一个事物的价值，能帮助做的更好。学习项目管理能带来什么好处呢？

《项目管理精华》一书将项目管理视为“21世纪独有的工作"，作者认为“每一名知识型工作者都在工作中不知不觉中扮演着’非职业项目经理’的角色”。作为开发工程师的我们，其实就是典型的知识型工作者。

实际上，具备项目管理能力，可以让你在专业之外，获得更大的成长空间。它对职业发展和个人生活均有着很大的价值：

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

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

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

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

而项目管理正是协同他人做成一件事情，达成目标的能力。试想一下，拥有这种能力的人，在哪个团队会不受欢迎。

而且这样的能力并不会随着年龄而贬值，反而越老越吃香。

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

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

《微权力下的项目管理》一书讲到项目经理往往需要个人的“魅力”去影响他人做事，进而达成目标。

项目管理能提升与各类干系人打交道的能力，进而提升你在组织的个人影响力。

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

我们的生活很多事情都符合宽泛的“项目”的定义。

房屋装修就是生活中非常典型的项目：

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

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

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

2.1 你有什么痛点？

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

• 工作量评估问题：工作量评估不准确

• 进度问题：日常杂事或者临时问题打乱排期

• 外部依赖问题：设计/后台等外部资源延期/需求变更，怎么推动解决？

• 沟通问题：如何让大家对需求的理解保持一致？

• 效率和质量平衡问题：怎么既保证开发效率又保证质量？

• ....

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

我们也许都做过项目管理，但是我们怎么知道我们做的好不好？

为了回答这个问题，我们也咨询了好几位项目经理的同学，大家都提了不少要素，综合来看，以下三个要素是大家都有提到的：进度、质量以及成本，三要素而最终影响的是项目的目标

进度是否符合预期？

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

质量是否达标？

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

成本是否可控？

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

2.3 我们需要哪些能力？

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

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

3.1 如何做好进度管理

如何合理地利用资源，按时完成项目是做好项目管理最基本的要求。大多数失败的项目是由于不合理的进度规划所导致的。所以做好进度管理是做好项目管理的关键。接下来将详细地介绍进度管理中最基本的概念和内容，以及做好项目管理的基本流程和思路，剖析在做进度管理中的重难点，主要从评估工作量，依赖管理，意外事项的处理三个方面进行分析

3.1.1 如何做好工作量的评估

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

3.1.1.1 需求详细方案设计

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

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

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

3.1.1.2 合理拆解，明确职责

在完成需求详细方案设计之后，接下来对任务进行合理的拆解，什么样的拆解才是合理的？

1、拆解的原则

1) 两天原则

拆解之后的单个任务不能太长，太长的话，就会存在着工作量评估不准确，整体项目难以把控，同时也不利于工作的合理分配，不能更好地利用人力资源，如果时间太短，就会导致工作交付的频率较快，工作之间也会存在着一定的耦合，拆解的粒度太小，会增加一定的沟通成本，得不偿失。最好工作拆解的粒度为一至两天

2）成果作为导向原则

任务拆解应该以可交互的成果作为导向，并且要有一定要有输出，这个输出应该是完整的，否则这个拆解就拆解得不够透彻，或者说不算一个任务

3) 责任到人原则

拆解之后的任务项，有且只有一个负责人，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。

4) 任务分层原则

任务拆解的过程也是一个解耦的过程，避免多个任务之间有耦合，拆解的过程应该是自顶向下的，从一个大的任务，按照其特性进行任务拆解，不断地拆解成子任务，直到拆解到一至两天的工作量，并且是一个可交付的工作项

2、怎样做好任务拆解

案例：

以正常迭代一个h5的项目功能为例，一共有四个大的功能模块，三个开发人员

1) 自顶向下，逐层拆解

通过WBS的工具，对项目进行拆解，为保证任务拆解之后的完整性，应将整体的项目自顶向下，逐层拆解，有利于排查项目开发的各个阶段是否有遗漏，按照项目的研发流程进行拆解成任务，再将各个任务进一步细分到两人天为止

2) 落实负责人，确认拆解是否合理

将每个任务落实到负责人，负责人能够从自己的角度出发，进一步思考该任务的拆解是否合理，同时也能够明确自己所负责的任务需要和谁对接，更能够了解联调的成本

3) 总体复盘，确认有无遗漏任务

最后根据开发经验，梳理整体流程有无遗漏，如单元测试，埋点开发，联调，代码的mr等

3.1.1.3 估算工作，知晓预期

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

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

1、自上而下

自上而下的估算方式是以项目总体为估算对象，一般对于有类似项目经验的工程师较容易评估，其方法是从工作分解结构的头部向尾部依次分配，传递工作量，直到WBS的最底层，其特点是：

• 项目初期信息不足，只能初步分解工作结构，很难将最基本的工作详细列出来

• 估算的精度较差

• 估算的工作量小，速度快

2、自下而上

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

• 估算的精度高

• 估算的成本较大

• 缺少子工作项之间的工作量的估算

3.1.2 如何做好依赖管理

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

• 准备开始开发了，发现设计稿还未就绪；

• 准备联调的时候，发现我们上下游的技术团队的接口还未就绪；

• 可以联调的时候，因为上下游的链条很长，出现推诿甩锅

...

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

3.1.2.1 明确责任人和交付时间，避免模糊

这是第一步。当一个事情有出现多个负责人的时候，责任的边界就会模糊，就容易互相推诿的情况，这就是责任分散效应。

三个和尚没水喝的故事就是一个典型案例

因此对于每个依赖项，我们需要明确其责任人，并沟通明确对应依赖的交付时间，把责任人和交付时间提前确定清楚，可以减少很多沟通和扯皮，

当项目涉及的团队很多的时候，可以维护资源依赖列表，这样当遇到问题时，可以快速查找负责人及应当交付的时间点

例子：某活动的资源依赖列表

3.1.2.2 形成信息对齐机制

确定了接口人之后，如果不进行及时信息对齐，可能也会出现跑偏的情况。

反面案例：

A项目依赖外部的sdk某个升级版，在最初的对齐的方案中，sdk方承诺不会修改原有的接口调用方式，而实际联调中才发现中不仅接口调用方式发生巨大变化，而且部分依赖的接口直接在新版本中被移除，导致我方进行花费大量时间进行兼容。

如果提前对齐而不是等到联调阶段才介入，就可能规避上述问题。

关于信息对齐形式，有以下两种方式：

• 不定期的非正式的沟通

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

• 定期的例会机制

如定期晨会机制机制，在会议上对齐进度、风险，可以提前发现可能存在的风险

记录会议纪要并通过群消息/文档/邮件的形式通知到项目的相关干系人。

• 项目owner机制

应当确定一个项目owner，对项目整体负责，把关整体节奏，负责组织会议，把相关信息进行整合，并同步给项目干系人。

3.1.2.3 求同存异，达成共识

作为项目组的成员，大家核心的目标是一致的，就是让这个项目能够如期保质上线。

但在实际执行过程中，各个依赖方因为各自的原因，出现一些偏差，只要能明确核心目标是一致的，相关的问题是可以沟通解决的。

案例：春节活动需求变更PK

作为最为重要的传统节日，很多业务团队都会针对春节这个时间节点上线运营活动，我们曾经遇到过在临近提测仍在提大量的变更（运营同学在叠加功能，设计同学则提出更多特效的要求），开发同学如果接受了大量变更，不仅意味着不断加班，更可怕是可能带来很大的质量风险，一旦出现严重问题，会得不偿失。

后面是开发同学联合测试同学，跟运营和设计进行了沟通，研发侧表示认可变更对于提升活动效果的作用，同时对变更可能带来延期，以及影响线上质量等风险进行全面分析评估，双方基于共同的目标最后做了协商和让步（既保证活动效果，同时也保证活动正常安全上线）

3.1.2.4 情感账户，软性推动

当你的项目依赖某个外部团队的小伙伴支持，而这个事情并不是对方当前工作范围的，并不是他第一优先级的工作，你会怎么办？

大部分情况，可能有些同学会在沟通未果的情况下，通过上升leader去推动事情落地，这是一种解决方案。

更优的方案是建立相关依赖方的“情感账户”，借助“情感账户”去软性推动。

我们都知道银行账户就是把钱存进去，作为储蓄，以备不时之需。“情感账户”里储蓄的是人际关系中不可或缺的信任。

经营好“情感账户”，也是经营好你与合作伙伴的信任关系。

在日常工作中，多吃亏一些，让你的“情感账户”适当“存储”，比如你曾经抽出休息时间帮助你的合作伙伴解决问题，当你需要他协助的时候，相信也能得到积极得响应，这也是我们为什么说『吃亏是福』。

3.1.3 如何处理意外事项

在排完期进入开发后，还是会存在这个各种事情会影响项目的进展，比如插入一些高优的需求，或者说一些不可控的因素，如疫情等等，导致人力不足，从而影响项目的进展

3.1.3.1 需求的变更

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

处理方式：

1. 判断需求变更的大小，如果是简单的样式修改等半小时能解决的小问题，可以协助快速调整；如果工作量在0.5天以上，并且还需要依赖于第三方接口，则需要将整体的需求进行重新评估，重新梳理排期，并同步给干系人

2. 先保证核心的业务流程不变，高收益的工作量优先，先保证正常的上线时间，后续有余力再对此功能点进行迭代优化

3.1.3.2 高优需求插入

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

处理方式：

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

3.1.3.3 不可抗力的因素

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

处理方式：

1. 如果是一些身体原因，导致办公效率低下，在不影响整体项目交付的情况下，适当的延长完成的时间，若影响到整体项目交付的时间，则应该暴露该风险，进行调整项目计划

2. 如果是完全不能投入开发，应该尽早的将此事情向上级报备，由上级进行统一的人力调整，交由其他人投入开发

3.1.3.4 内部依赖延后

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

处理方式：

1. 将自身的业务流程跑通，依赖部分通过模拟的方式解决

2. 将联调的时间后移，先开发其他的功能模块

3. 如果已经是最后联调阶段，则需要再次调整交付的时间，同时将该风险同步给相关的干系人

3.2 如何做好质量管理

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

3.2.1 通过流程规范提高质量

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

3.2.1.1 制定研发流程规范

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

当然流程也不是一成不变的，它需要根据我们的具体情况不断调整优化，才能适应当下的需要。

另外应当尽量将流程变成CICD的约束，通过系统来约束、控制，减少对人的依赖。

具体到我们研发团队介入开始一般可分为需求评审、方案设计、需求开发、测试验收、发布上线、项目复盘六个步骤。

3.2.1.2 严格执行Code Review

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

具体参考文章：google cr 指南

3.2.1.3 制定发布checklist

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

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

这里提供一份参考案例：

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

不起眼的清单很多时候发挥着非常重要的作用，比如飞机起飞前的检查清单、手术前后的检查清单，拯救了无数的生命，具体推荐看一本书叫『清单革命』，

3.2.2 管理变更影响

变更是导致程序异常的主要原因，通过在需求设计阶段提前对变更进行评估、规划，从而确保能够在对程序最小负面影响的情况下实施这些变更，同时通过在团队内进行有效的协商和沟通，确保所有的变更都具有可追溯性。

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

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

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

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

3.2.2.2 通过架构设计上隔离变更

在开发生涯中最害怕的莫过于修改”老代码“，有些”老代码“读起来云山雾罩，各种痛苦，完全搞不懂业务逻辑和代码的关系，也闹不明白这块代码为什么这么写那块代码是几个意思。使得我们战战兢兢如履薄冰思前想后寸步难行。

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

分层架构：分层架构的一个重要原则是每层只能与位于其下方的层发生依赖。由于层间松散的耦合关系，使得我们可以专注于本层的设计，而不必关心其他层的设计或本次变更应影响到其它层，只要本层的接口保持稳定。大型系统中推荐使用DDD(领域驱动设计)，拆分成展现层、应用层、领域层、基础设施层；

组件化设计：组件化可以比喻为积木，其工作方式信奉独立、完整、自由组合。目标就是尽可能把设计与开发中的元素独立化，使它具备完整的局部功能，通过自由组合来构成整个产品。

特性开关：目前最为常用的隔离手段还是特性开关的方式。这种方式隔离较为彻底，如果某种场景不需要该特性，直接关闭开关即可，缺点之于代码中可能会存在许多开关逻辑。

资源隔离：从物理上隔离变更导致的影响，通常我们将可以以服务、静态资源、网络、内存、进程等方式进行隔离，通过限制变更带来的影响在可控范围内，隔离对其他资源的影响。

3.2.3 功能回归的能力

功能回归能力是通过自动化的回归测试寻找原始设计中没有预料到的错误。

3.2.3.1 有效的测试是设计出来的

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

设计阶段做详尽的需求分析和测试用例设计，好尽早地发现不合理的地方，尽早地暴露问题，促使团队更早地在需求评审阶段识别修复缺陷。

编码阶段研发可以依照测试用例自行编写单元测试、接口测试来验证核心逻辑是否正确，尽可能确保所有代码被测试到，所有的业务流程都能被测试用例覆盖到。

这里非常重要的是需要反过来想：很多人设计用来只考虑了正常逻辑，异常逻辑覆盖的分支较少，导致测试遗漏。

3.2.3.2 接入自动化测试平台

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

我们团队近期在研发一个自动化测试平台Hertz，目前还在开发初级阶段，可以尽请期待。

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

研发阶段我们尽量保证质量，不出现BUG；上线后我们需要确保一旦出现问题，能快速通过告警发现，并快速定位找到原因，从而最大限度降低对现网的影响。

3.2.4.1 利用监控告警发现问题

在我们需要监控告警之前，我们需要先定义我们需要关注哪些问题？笔者团队是前端团队一般需要关注以下问题进行分类：

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

然后我们跟进对应指标配置对应的告警策略

3.2.4.2 规范日志快速定位问题

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

如何让程序能够”说话“，并准确的说出有价值的信息，这就是日志的核心价值。日志要解决的问题是：程序是否按期执行？用户在系统上做了什么操作？程序有没有执行错误？问题是怎么造成的？

合理日志的要素：

日志时间：日志是记录程序运行过程中的事件，日志时间就是记事件行为发生的时间。

日志级别：日志级别是设置日志告警的关键条件，应该根据日志的重要性或严重程度划分等级，常用的日志级别有：DEBUG、INFO、WARN、ERROR。

业务标识：用来区分当前日志所属哪块业务，通过业务标识可以将日志进行归类聚合，方便分析和定位问题。

日志内容：日志内容作为事件的描述，应准确描述程序在什么场景做了发生了什么行为、事件，如关键行为描述、程序错误原因等。

异常堆栈：堆栈异常信息有助于排查程序异常，通常可以从异常堆栈中得到程序运行的顺序和定位到具体代码执行错误位置。但异常堆栈通常文本量比较大，且对系统性能有一定的影响，应该酌情考虑，通常仅在ERROR级别日志中记录堆栈信息。但对于业务捕获到的异常且日志内容能够准确描述问题，则建议不用记录堆栈信息，避免不必要的开销。

追踪ID：对于单次用户行为需要一个唯一ID贯穿全链路日志，方便对用户行为进行追踪，错误信息也能够查询到用户行为的上下文，方便定位日志。

日志记录的时机：

程序流程：在流转分支，每个关键代码逻辑的执行前后记录进行相应的日志输出，有助于代码调试。流程日志一般数量较多，建议通过白名单或开关能力决定是否上报。

系统初始化：系统初始化是通常依赖服务配置参数，这些参数决定系统的启动后的运行状态。

远程调用：远程调用是程序正常运行的关键步骤，一般程序中对远程调用函数都会进行封装，可以在这里统一记录调用请求的入参和响应信息。

核心业务操作：系统用户进行核心业务操作的行为，也应该进行记录，便于进行操作审计。

可预期的异常：这类异常通常被是被代码逻辑捕获到或者主动抛出的，经过了人为筛选过的异常应引起较高的重视，需要配套的监控警告。

预期外的错误：这类异常通常使用全局错误捕获的方式收集，应尽详细记录程序错误描述和异常堆栈，并通过告警策略通知开发人员，及时做出相应，避免影响系统的正常使用。

3.2.4.2 智能化监控平台

每次排查告警问题对程序员而言都是体力活，都想能够轻松，快速的查看日志，更进一步监控平台能够直接告诉我问题是什么，怎么解决。

近年来就产生出一些智能机器数据分析平台，利用大数据技术及机器学习技术对 IT 基础架构及应用系统的所产生的海量日志进行实时分析。

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

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

3.3 如何做好风险管理

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

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

3.3.1 风险管理管的是啥？

3.3.1.1 风险的本质

风险的本质是一种不确定性带来的损失

项目风险实质上是我们项目的三要素：进度、成本、质量中，一个或多个出现受到了影响，最终影响我们的项目目标的达成

3.3.1.2 风险的特征和构成要素

风险具备以下特征：

• 客观性：风险是客观存在的，不以人的意志为转移，项目中存在风险是常态

• 不确定性：风险是否造成损失，以及损失的程度，是不确定的

• 可观测：单一风险存在不确定性，但是总体来讲是有规律的，有办法预测的

• 可变性：风险会随着应对措施的进行而消失，不会一层不变

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

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

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

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

3.3.1.3 风险管理怎么做？

风险管理从流程上主要做四件事：

• 1、风险识别：

核心是找出可能产生风险的“风险因素”，识别分析这些“风险因素”究竟有哪些特征，可能会影响项目的哪些方面。

比如上述小A的例子，“风险因素”就是疫情的放开带来的感染风险，其特征就是会导致成员患病无法工作，影响就是项目的延期。

风险识别有以下几种方法：

• 头脑风暴法：

一些人聚集起来，进行头脑风暴，通过彼此的沟通交流、想法、建议、意见进行碰撞，一起发现问题

• 专家调查法：

由相关领域的专家组成风险小组，通过征求专家的意见，然后综合汇总整理，再反馈给专家，再次征求专家的意见，反复进行4～5轮，最终专家们的意见会趋于一致，达成共识

• 情景分析法：

识别关键影响因素，基于该因素可能发生的场景，进行场景内容的分析，进而发现风险可能造成的后果

• 核对表法：

将项目范围、目标、成本、质量要求、进度、类似项目成功或失败的原因等列在一张表上，进行一一核对。这种方法可以识别到进度风险、成本风险、质量风险等

• 流程图法：

需要建立项目的全链路流程图以及各子域流程图，这些流程图可以涵盖项目的整体流程以及分支细节。通过将实际情况与流程图一一对比，便可识别风险

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

• 2、风险评估：

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

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

• 定性分析：根据风险的重要程度和发生概率等指标对风险因素进行排序

• 定量分析：将体现风险特征的指标量化，以强化对风险因素的认知

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

如上述小A的例子，如果不采取措施，疫情防控带来的延期风险随着时间推移几乎达到100%

• 3、风险应对：

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

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

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

如上述小A的例子

• 从“规避风险”的角度，我们可以投入更多的备份人力，或者调整项目目标（如调整上线时间点）；

• 从减轻风险的角度，我们可以实施分散办公（居家办公），减少项目组成员被“一锅端”的风险

• 从接受风险的角度，如果项目因为疫情带来的延期是可以接受的，也可以不采纳任何措施；

4、风险沟通

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

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

以上是项目管理中，针对风险管理基本的手段，而作为开发人员，我们日常支持的项目中，又有哪些会遇到的风险呢，以及如何更好的应对呢

3.3.2.1 最常出现的风险

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

• 进度方面的风险：

因为外部依赖，需求变更，或者高优需求插入，带来项目延期风险，这里在进度管理章节，我们已经重点介绍了如何管理依赖，如何跟产品沟通需求变更，以及如何管理好自身的排期

• 质量方面的风险：

主要是在项目研发环节中产生质量问题，如自测不充分导致提测期间bug数过多，在质量管理一节中也介绍了相应的解决方案

• 成本方面的风险：

大家对成本关注越来越多，成本也是一项重要风险，特别是大项目，但因为不是开发疼点，本文不展开。

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

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

3.3.2.2 性能风险

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

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

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

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

3.3.2.3 安全风险

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

1、“合规化风险“是因为未按照相关的法律法规导致政策风险，如app因为实现疏忽导致某些场景未满足个保法。

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

2、“系统实现漏洞风险”则是因为技术实现的漏洞导致的风险，比如：活动没有做好防刷，导致奖品被刷；页面没有做好脚本过滤被xss注入攻击了

从风险识别的角度，我们也可以采用“流程法”，对每个环节可能带来的安全风险进行梳理，如：

• 在“开发测试阶段”，确认工程是否在流水线中接入“代码扫描工具”；

• 在“上线阶段”，确认服务是否接入”安全扫描“工具进行扫描；

• 在“运营配置阶段”，确认相关运营系统的配置是否经过审查测试

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

• 涉及数据查询修改，必须有登录态校验

• 涉及数据修改，必须要有token校验，避免CSRF攻击

• 所有输入都需要白名单校验，包括从URL获取数据、从cookie获取数据、从表单获取数据等，避免SQL注入、XSS攻击等

• 涉及福利相关，必须有黑产打击策略

• 是否有严格的用户权限校验

• 涉及外部对接时，必须包含加密或验签环节

• 还存在哪些安全隐患？

• 是否考虑防安全扫描

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

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

3.3.2.4 容灾性风险

缺失针对系统运行异常情况的处理，也是一种潜在风险因素。

从风险识别的角度，我们同样也可以识别“核对表法”来核对潜在的异常情况是否都有对应的处理措施：

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

• 系统即将面临的最大流量是多少

• 需要提前多久跟运维沟通扩容？

• 系统各个环节能承受的流量压力，哪些环节需要扩容？

• 如果流量陡增、服务过载时，系统有没有做兜底降级方案?

• 有没有做多地部署，规避单点风险？

• ...

逻辑实现相关的核对表：

• 数据结构是否变更，如果变更是否考虑老数据兼容？

• 边界条件是否

• 运行环境可能存在的兼容性问题？（前端经常遇到）

• ....

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

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

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

本文从为什么程序员也要懂项目管理入手，介绍懂项目管理对我们在职业发展和生活中的价值，接着从项目管理中会遇到的问题为入手点，整体介绍了与我们实际相关管理息息相关的三大能力——进度管理、质量管理、风险管理。

最后感谢您抽出宝贵的时间阅读，期望本文能帮助您提升工作中项目管理能力，也欢迎大家留言交流。

参考资料

《项目管理精华》：https://book.douban.com/subject/26986573/

《极简项目管理：让目标落地、把事办成并使成功可复制的方法论》：https://book.douban.com/subject/35219808/

《微权力下的项目管理》：https://book.douban.com/subject/26997081/

PMP项目管理知识（上）：https://www.yuque.com/kanding/knote/zol8ep

PMP项目管理知识（下）：https://www.yuque.com/kanding/knote/rrm2zz

PMP知识体系：http://pmp6.chn.ai/chapter/70

如何做好项目管理工作？：https://cloud.tencent.com/developer/article/1629446

你需要知道的项目管理知识：https://juejin.cn/post/6997536906967777316