如何进行项目管理？

这篇文章是软件工程系列知识总结的第三篇，前面的两篇文章聊了软件工程的重要性以及相关的基础知识。这篇文章，我会将软件工程中关于项目规划和管理的重点知识进行总结梳理，并以自己理解的方式进行阐述。

可行性研究

可行性研究的本质：基于问题和解决方案进行分析，评估投入产出，以供决策。

可行性研究的考虑点：

• 经济可行性：即成本问题，包含人力成本、时间成本、软硬件资源成本、引流拉新成本等；

• 技术可行性：技术方案的实现难易程度、开发速度、结束难题如何解决规避、以及后期的维护成本等；

• 社会可行性：可以理解为业务可行性，即项目投产后能否带来预期的收益，市场和竞品分析以及可能涉及到的法律道德和社会影响等因素；

当然，由于软件项目很多时候前期是没有特别明确的需求时，可以考虑小范围做一个 mvp（最小化可行产品）进行验证，等需求比较明确，可行性较高时再逐步加大投入。

如何管理技术项目

以我自身的职场成长经历来看，从技术转型为管理岗的过渡过程，管理项目是必不可少的一个经历。

这里的管理项目不是说单纯的 PMO（项目经理）角色及职能，而是你既要做项目主要的技术决策者，又要关注过程，协调团队里不同的人解决不同的问题，最终保障项目的保质按期交付，拿到好的结果。

项目管理最重要的一点是大局观，要脱离具体的技术细节，从整个项目和团队维度去考虑。具体可分为下面几个部分：

• 确定方向：明确团队和项目的发展方向，目标是什么，达到目标需要做哪些事情；

• 识别风险：项目的整个生命周期中哪里可能出现问题，出现问题有哪些应对方案（事前预防大于事后解决）；

• 创造环境：为项目能按照计划交付尽可能创造好的条件，解决资源问题、沟通问题，让专业的人做专业的事情；

• 调整能力：项目研发过程中遇到问题或业务规划变更，要及时评估并对接下来的动作进行调整，平衡投入产出比；

项目管理也有自己的“道法术器”，而项目管理的道就是管好人，管好事。想明白本质，掌握好方法就能做到较好的项目管理。具体的如何管好人管好事，可以看下面这张图：

PS：图来自极客时间，侵删。

项目计划的重要性

我们日常工作中最熟悉的项目计划，应该都是从需求评审到线上发布这一套了，当然，大家更愿意称之为版本迭代。

项目计划的本质是明确什么时间由什么人做什么事达到什么效果。如果没有计划，软件研发可能会陷入混乱，问题不知道找谁解决，无法按时交付。就像开车上路的导航地图一样，在每段道路行驶中都提醒我们该走哪条车道，做哪些动作。如果不按照导航提醒驾车，就很可能走错路甚至违反交通规则。

制定项目计划，一般主要分为如下几个步骤：

• 任务拆解：将项目完成所需做的事情按照层级逐层拆解，一直拆解到最小单元（具体的可量化可交付的事项）；

• 估算时间：这个大家都很熟悉，需求评审完，研发测试都会进行工时评估，哪些环节大概需要多少时间，多少人力；

• 任务路径：根据任务之间的依赖关系和预期的资源占用，排出合适的顺序。比如：

• 研发编码阶段测试可以编写测试计划、测试 case 并评审（这是并行的任务路径）；

• 做接口测试的前提是研发已经写好了 API 并自测通过，否则接口测试无法开展（这是串行的任务路径）；

当然，有了项目计划后，还要设置不同阶段的里程碑。比如我们日常的版本迭代中，会规定什么时间提测，什么时候验收，什么时候线上发布，这些环节的交付产出物需要满足哪些条件。

还有一点比较重要的是制定好计划之后，需要时时的跟进整体进度，并且要根据具体情况进行及时的调整。常见的有研发同学生病请长假、临时插入了很多紧急需求等，这种时候资源不足又需求变多，就需要调整整体的研发交付进度。要么砍需求，要么加人，或者项目延期上线。

流程和规范的目的

关于流程规范的目的，我在前面的文章介绍过很多次，这里再次重申下我的观点：

流程是什么？

流程是保障团队目标达成的最佳实践，因人/团队/业务类型/迭代速度/资源紧张程度而异。

为什么要有流程？

没有流程会导致团队中的个体各自为战，目标不统一，进度不协调，资源配给失衡而导致交付质量下降。

流程能解决什么问题？

流程能保障团队或者群体在大方向上保持协调一致，尽可能降低由于团队人员能力、认知水平、资源不足、意外情况导致的项目延期或者质量下降。

流程能带来什么保障？

风险可识别+问题可追踪+结果可验证+数据可量化！

其实制定流程规范的目的主要是如下几点：

• 提升团队整体效率（原因参见上文）；

• 流程是解决问题最佳实践的标准化产物，起到经验共享的作用（可以理解为赋能）；

• 流程规范让项目管理从人治到“法治”（人会成为人治的瓶颈，人也有其自身的局限性）；

工具：管理提效利器

软件项目的研发过程中，跟进计划和任务的进度是最繁琐的事情。

任务要拆解成可具体的可量化可交付的单元，但衡量任务的完成度和状态变更是最大的难点。

因此借助工具或技术手段来解决任务追踪和量化，是提高项目管理效率很好的手段。

这就是上一篇文章中提到的研发过程管理部分，各种管理模型的迭代和进化目的。

业务、市场、技术在不断变化，大家追求的永远是质量和效率，而工具发明出来的目的就是为了提高效率。

有句话叫做“流程工具化，工具自动化”，意思就是好的流程规范要尽可能转变为工具，脱离人治，升华“法治”，不断寻找新的更好的可以提高效率的工具和技术。

近几年敏捷的火爆，一部分原因也是由于传统的软件研发管理方法效率太低，而敏捷所包含的的 Sprint、Ticket 跟踪和看板可视化任务管理，就是为了解决效率问题。

风险管理的本质

软件研发过程中或多或少会遇到一些预料之外的事情，比如工时评估太乐观导致后期交付延期、关键岗位的人员离职导致项目进度停滞、采用了新框架新技术导致上下游兼容出了问题等等。这些都是软件项目研发过程中的风险。

风险是不可逆的，但提前评估风险，做好应对准备，可以有效的降低风险造成的损失和影响。

风险管理一般分为如下四步来进行：

• 识别风险：在项目开展前期就尽可能评估可能出现的风险，比如核心员工离职；

• 风险量化：评估不同的风险会造成的影响和损失，主要考虑损失大小和发生几率；

• 制定策略：针对风险发生的概率和损失大小制定优先级，并制定对应的备份方案；

• 风险监控：对风险进行监控，设定监控告警机制和风险处理流程（类似 SRE 中提到的 noc 团队所做的事情）；