👉腾小云导读
程序员对工作量评估不精确？日常长期问题打乱排期？怎么让大家对需要的了解统一？如何既保证开发效率又保证质量？项目管理是「把事件做对」的重要能力之一。知识型工作者包含程序员，在工作中都人不知; 鬼不觉中扮演着「非职业项目经理」的角色。具备项目管理能力，对程序员职业倒退、集体生存都有重大价值。本文详细分析程序员如何进行进度治理、品质治理和风险管理。
👉 看目 录
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 去推动事件落地，这是一种解决方案。更优的计划是建设相干依赖方的“情感账户”，借助“情感账户”去软性推动。大家都晓得银行账户就是把钱存进去，作为储蓄，以备不时之需。“情感账户”里储蓄的是人际关系中不可或缺的信赖。经营好「情感账户」，也是经营好一个人与合作伙伴的信赖关系。在日常工作中多吃亏，让本人的「情感账户」适当“存储”。例如本人已经抽出休息时间帮忙合作伙伴解决问题，当须要对方帮助的时候，置信也能失去踊跃的响应，这也是常说的“吃亏是福 ”。 |
3.1.3 如何解决意外事项
排期后进入开发，还是会存在各种事件影响我的项目的停顿。例如：插入一些高优的需要，或者说产生一些不可控的因素如疫情等等导致人力不足，从而影响我的项目的停顿。上面咱们具体介绍几种状况及其解决形式。
1. 需要的变更
在设计具体需要计划中，如果思考得不够周全，开发过程中就会产生需要变更。
解决形式：
- 判断需要变更的大小，如果是款式批改等简略变更，半小时能解决的小问题，能够帮助疾速调整；如果工作量在 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 is not 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 攻打等。
- 波及福利相干，必须有黑产打击策略。
- 是否有严格的用户权限校验。
- 波及内部对接时，必须蕴含加密或验签环节。
- 还存在哪些安全隐患？
- 是否思考防平安扫描。
针对一些重点项目（比方量级宏大的春节流动），也能够采纳「专家考察法」，提交相干的技术计划给到业务平安的人员进行审查，以发现零碎设计存在的潜在安全漏洞。
从危险评估的角度登程，与平安相干的危险往往是无奈漠视的，是第一优先级须要解决的，因而危险应答伎俩，往往是须要采取对应措施来躲避危险。
4. 容灾性危险
缺失针对零碎运行异常情况的解决，也是一种潜在危险。从危险辨认的角度，同样也能够应用「核对表法」来核查潜在的异常情况是否都有对应的解决措施：
服务可用性相干的核对表：
- 零碎行将面临的最大流量是多少？
- 须要提前多久跟运维沟通扩容？
- 零碎各个环节能接受的流量压力，哪些环节须要扩容？
- 如果流量陡增、服务过载时，零碎有没有做兜底降级计划?
- 有没有做多地部署，躲避单点危险？
- …
逻辑实现相干的核对表：
- 数据结构是否变更，如果变更是否思考老数据兼容？
- 边界条件是否。
- 运行环境可能存在的兼容性问题？（前端常常遇到）
- …. |
从危险评估的角度登程，须要依据服务 / 页面的重要性，采取对应的危险应答措施：
一些外围场景（如领取场景），相干服务 / 页面一旦呈现问题就是间接的经济损失，因而就须要采取措施躲避危险。
一些对用户感知不是很显著的场景，则能够驳回兜底降级的计划。例如信息流场景下，在面对突增流量冲击时，举荐零碎所能接受的流量压力要远远低于接入服务的接受范畴，这个时候，接入服务就须要爱护举荐服务，通过返回兜底数据，缩小流量对举荐零碎冲击。
04、总结
为什么开发也要懂项目管理？开发如何做好项目管理？置信各位读者已有肯定感知。本文首先介绍了项目管理对大家在职业和生存中的价值，接着以项目管理中的痛点为切入点，整体介绍了项目管理中须要把握的三大能力——进度治理、品质治理、风险管理。
其中进度治理蕴含工作量评估、依赖治理、解决意外事项等；品质治理蕴含流程标准建设、治理变更影响、晋升性能回归能力、晋升问题发现和定位效率等；风险管理蕴含风险管理的根底方法论，以及理论我的项目中容易漠视的性能危险、平安危险、容灾性危险等。
最初冀望本文能帮忙开发者晋升项目管理技能，晋升「把事做成」的能力，成为合作伙伴眼中「靠谱」的人。以上是本次分享的全部内容，欢送各位开发者在评论区交换。如果你感觉内容有用，欢送分享、点赞、在看。感激反对。
-End-
原创作者|赖文辉、蔡卓伦、刘冬、陈长吉
技术责编|赖文辉、蔡卓伦、刘冬、陈长吉
「变动」对程序员而言是个极大的挑战，这是万年老话题了。客户需要在变，老板要求在变，产品经理的需要也在变。有程序员示意，当我埋怨变动带来的加倍工作量，兴许还会受到吐槽：“你程序不怎么样啊，不能适应我的变动。”🤒 面对变动，你有怎么的教训和办法呢？你有什么评估工作量的妙计？当变动产生，日常杂事和长期问题呈现打乱排期，你怎么解决？能够做些什么来缩小「变动」？
欢送在评论区聊一聊你的认识。在 3 月 24 日前将你的评论记录截图，发送给腾讯云开发者公众号后盾，可支付腾讯云「开发者秋季限定红包封面」一个，数量无限先到先得😄。咱们还将选取点赞量最高的 1 位敌人，送出腾讯 QQ 公仔 1 个。3 月 25 日中午 12 点开奖。快邀请你的开发者敌人们一起来参加吧！
最近微信改版啦
很多开发者敌人反馈收不到咱们更新的文章
大家能够关注并点亮星标
不再错过小云的常识速递