技术人核心竞争力：被忽视的项目管理能力

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

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

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

 1）如何做好工作量的评估

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

需求详细方案设计

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

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

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

合理拆解，明确职责

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

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

估算工作，知晓预期

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

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

2）如何做好依赖管理

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

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

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

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

• ...

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

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

3）如何处理意外事项

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

• 需求的变更

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

处理方式：

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

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

• 高优需求插入

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

处理方式：

评估高优需求的工作量，以及影响当前项目的程度。

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

• 不可抗力的因素

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

处理方式：

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

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

• 内部依赖延后

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

处理方式：

将自身的业务流程做好，依赖部分通过模拟的方式解决。

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

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

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

1）通过流程规范提高质量

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

• 制定研发流程规范

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

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

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

• 严格执行 Code Review

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

• 制定发布 checklist

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

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

这里提供一份参考案例：

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

2）管理变更影响

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

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

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

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

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

通过架构设计上隔离变更

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

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

3）功能回归的能力

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

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

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

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

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

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

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

4）发现问题和定位问题的能力

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

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

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

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

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

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

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

日志记录的时机如下：

• 第三，智能化监控平台。

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

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

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

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

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

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

1）风险管理管的是啥

• 风险的本质

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

• 风险的特征和构成要素

风险具备以下特征：

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

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

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

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

风险管理怎么做

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

风险识别：

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

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

风险评估：

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

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

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

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

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

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

风险应对：

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

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

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

风险沟通：

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

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

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

• 最常出现的风险

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

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

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

• 性能风险

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

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

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

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

• 安全风险

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

合规化风险

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

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

系统实现漏洞风险

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

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

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

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

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

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

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

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

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

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

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

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

还存在哪些安全隐患？是否考虑防安全扫描。

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

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

• 容灾性风险

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

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

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

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

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

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

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

...

逻辑实现相关的核对表：

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

边界条件是否。

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

....

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

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

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