项目管理实战案例：深入理解大厂项目经理的“敏捷交付”
2024-11-29本文为学员投稿的原创作品，现在才聚正面向专业项目管理者征集“项目管理实战案例”原创文章，被采纳即可获得丰厚稿酬，欢迎大家关注公众号踊跃投稿。
如您有意向投稿，可点击查看投稿要求和方法，按文中方法将稿件投递给我们。
在软件开发行业中，对于研发型的项目经理一直存在“供不应求”的状态，其中一个很重要的原因是，大部分企业要求研发项目经理有开发经验或技术背景。
然而，以笔者自身的从业经验来看，即便没有技术背景和开发经验，只要明白软件交付的全流程和敏捷开发的过程，依然可以进入大厂从事软件项目经理的岗位（我本人即是如此）。
因此，本文尝试为诸多想从事软件行业的项目经理提供简单的软件项目实战化经验，来了解这个行业是如何运作的，以及项目经理能在其中发挥什么作用。
想进入一个行业，就需要了解一个行业及岗位为什么诞生。
在软件行业，由于业务或客户面临的问题和环境复杂多变，甲方没有办法在一开始就想明白“需要什么产品”，因此行业引入了“敏捷开发”的概念，用于解决随时面临客户需求变更的问题。
在行业上，这种方法的集合来引入团队内部，称之为“软件工程”，即解决“如何稳定高效地准时交付所需功能的软件项目”的问题。
因此，项目经理在软件领域的作用和企业对项目经理的要求，并不局限于交付一个软件项目本身，更多也在于如何持续性的建设和提高团队的研发效率和质量。
图源：作者
从PMP的定义上看，项目成功有两个关键因素：一是达成项目目标，二是满足干系人期望。
如果把软件工程能力本身也当成一个项目去交付，对项目经理来说回答的问题即“如何衡量并提高团队研发的效率和质量”，而要回答这个问题，就需要对当前软件工程的“敏捷”和代码从诞生到交付软件产品的全流程有一定了解。
在软件工程的发展趋势中，最典型的是从“瀑布式开发”到“敏捷式开发”，其核心差异在于团队怎么应对需求变更，为方便理解，其实可以简要类别为前者是“计划式”的“计划经济”，后者是“灵活式”的“市场经济”。
从这个类比相信你已经可以看出，前者需要充分的信息以支撑制定需求交付计划，后者仅需要了解简单的目标和原型，就可以在开发的过程中不断调整需求，以接近交付客户要求的产品型态。此处在PMP理论和考试中有详细的解释，这里不再一一赘述。
从互联网行业软件工程的趋势来看，腾讯、华为、阿里等大厂已然陆续在内部推广或已经完成敏捷交付方法的推广，在我司的项目经理招聘中，也已经将懂得“持续交付”或“DevOps”等敏捷方法作为项目经理招聘的基本要求之一。
某大厂互联网项目经理招聘要求（图源：作者）
如上文所述，持续交付作为敏捷方法之一，回答的是如何以持续安全高效的方式把代码部署到正式环境，即关注“从代码提交到产品发布”的全过程，其概念最早由Jez Humble在2010年出版的《持续交付》一书中提出，业内称为“持续交付1.0”。
而持续交付2.0由腾讯软件工程负责人乔梁老师提出，将精益创业与持续交付结合，更强调快速验证和交付业务价值。
精益创业的核心思想是先在市场中投入一个极简的原型产品，然后通过不断的学习和有价值的用户反馈，对产品进行快速迭代优化，以期适应市场。这个过程主要涉及三个主要工具：“最小可用品”、“客户反馈”和“快速迭代”。
“最小可用品”是指将创业者或者新产品的创意用最简洁的方式开发出来，可能是产品界面，也可以是能够交互操作的胚胎原型。
它的好处是能够直观地被客户感知到，有助于激发客户的意见。通常最小可用品有四个特点：体现了项目创意、能够测试和演示、功能极简、开发成本最低甚至是零成本。
对于精益创业者而言，一切活动都是围绕客户而进行，产品开发中的所有决策权都交给用户，因此，如果没有足够多的客户反馈，就不能称为精益创业。
“快速迭代”是针对客户反馈意见以最快的速度进行调整，融合到新的版本中。
一言以蔽之，持续交付就是研究如何加快一个需求从产生到最终交付的过程，以尽可能快速交付最小产品的方式验证市场价值，并保障质量和持续改善度量指标，即解决“如何稳定高效地准时交付所需功能的软件项目”的问题。
图源：作者
作为一个优秀的项目经理基础要求（我个人认为），项目经理在开展项目过程中，除了满足项目成功的2个要素外，更重要的是要跳出项目经理的身份，以更高的视角去理解公司为什么发起一个项目，从而帮助项目经理理解不同领域的目标，更好地把控全局。
持续交付在我司落地过程中，最困难的其实不是如何落地和执行，而是如何让技术Leader、敏捷教练和项目经理理解“持续交付”，并应用在开发、测试和产品的日常迭代中。
在落地持续交付过程中，会分为多个阶段，例如一阶段统一标准度量体系、二阶段统一流水线和环境构建等等，这里不再展开讨论。
下面以一个业务准备按照持续交付的理念开展版本迭代，项目经理应该怎么做为例介绍如何实战落地持续交付的敏捷方法。
首先，项目经理要规划版本节奏，所谓“版本”即一个需求从进入到最终完成发布的窗口时间，例如当业务提交一个需求过来，应该进入哪个窗口期完成，应由该需求的澄清时间而定，项目经理需要安排好每个月的窗口期也即“版本”，以便于业务及时提出自己的需求，并了解计划在什么时候交付。
这里以服务端的版本为例，通常为双周一个版本，业界内比较好的优秀实践是单周（甚至可能不存在版本概念，即主干开发主干发布），要基于业务的情况与业务一起达成共识，一个简单的迭代周期如下所示：
图源：作者
在制定版本节奏时，通常要考虑以下几个因素：
① 需求的复杂程度，一个较短的版本迭代，不可能承接需要一个月甚至更长时间交付的需求，因此需要产品经理将一个大需求拆解为诸多3~5天可验证的小需求（INVEST原则）；
②服务端or客户端，用于互联网面向用户的特性，客户端需要尽可能减少对用户的打扰，通常为4~6周一个版本，服务端通常为2~3周一个版本。
③人力的饱和度，主要是要为测试留出充裕的时间以确保质量。
④需求的依赖程度，大部分需求是否有存在依赖其他团队或版本的情况。
⑤发布是否敏捷、灵活，对于流水线的构建与发布，是否可以实现较好的自发布与代码冲突管理。
其次，项目经理要把握关键的版本节点，安排好版本的各项会议。
例如，需求澄清节点是整个版本的开始，也定义了版本的结束时间，需要与产品经理明确好需求的PRD文档标准；定义好需求阶段，例如从需求筛选-澄清-开发-测试-验收等各环节的流转时间，并且通过每日站会或周会等形式把控需求进度与风险。
最后，项目经理要基于度量安排版本复盘，从数据上呈现整个研发团队及各角色的交付速度、质量和效率，并在新的版本迭代中解决这些遗留问题。
图源：作者
以上是一个项目经理在一个简单的版本规划中所应承担的职责，而如果想要成为一个软件工程领域的项目经理，在面试中通常也需要回答对于敏捷方法的理解。
再展开而言，持续交付与Devops、持续集成等敏捷方法的区别是什么？为方便理解，区别可以用下图来表示：
图源：作者
具体区别如以下总结：
图源：作者
对持续交付有一个初步的理解和认识后，我们可以结合持续交付2.0再总结一下，如果要在实践上应用持续交付的方法，最重要的目标和原则是什么？
持续交付最重要的目标是在高质量、低成本和低风险的前提下，快速交付并验证用户反馈，并成为企业市场核心竞争力之一。
围绕这个目标，我们最重要的四个原则是：
（1）坚持少做
无论公司实力如何，想做的事情永远超过自己的交付能力，需求永远做不完。然而，做得多就一定有效吗？因此，要学会做减法，只关注真正重要的事情。
（2）持续分解问题
复杂的业务问题中一定会包含很多不确定因素，它们会影响问题解决的速度和质量。在实施解决方案之前，通过对问题的层层分解，可以让团队更了解业务，更早识别出风险。
企业应该坚信，即便是很大的课题或者大范围的变更，也可以将其分解为一系列小变更，快速解决，并得到反馈，从而尽早消除风险。
与其设计一大堆特性，再策划一个持续数月的一次性发布，不如持续不断地尝试新想法，并各自独立发布给用户。
（3）坚持快速反馈
当把问题分解以后，如果仍旧只是一味地埋头苦干，而忽视对每项已完成工作的结果反馈，那么就失去了由问题分解带来的另一半收益。
只有通过快速反馈，我们才能尽早了解所完成工作的质量和效果。
（4）持续改进并衡量
在持续交付中，我们要不断关注流程的改进和优化。通过持续改进，我们可以不断提升软件产品的质量，提高交付效率。
同时，我们还要关注度量和指标的设定，通过度量和指标来评估改进的效果和价值。
在实践中，结合以上4个核心原则，以下3点可以作为实践的指导方针，分别是目标驱动、简单问题开始和持续改善。
具体而言，在实施持续交付过程中，必须要明确每个阶段的目标，并设定具体可衡量的指标，如需求交付周期、漏测率等等，确保组织上下围绕一个目标和指标进行牵引和改进。
其次，从简单问题开始着手逐步改善，要以持久战的准备攻坚组织的工程能力，抓大放小，先从核心业务试点等不失为更好的一种企业变革方式。
最后，持续度量和改善，一切围绕指标和问题进行优化和提升，持续提高组织和团队的交付质量和能力。
图源：作者
综上，本文简单介绍了为什么要了解敏捷、敏捷与软件工程的关系、什么是持续交付，以及如何在大厂中实践敏捷交付，与其他如Devops等敏捷方法的区别是什么。
需注意的是，由于各公司的业务形态不一致，不能简单套用其中的方法来实践，需项目经理结合对业务的理解、敏捷的思考来综合制定适合团队的敏捷方法。
对于想入门这个行业的项目经理，建议从开源社区、身边做开发的朋友、相关敏捷书籍入手，先了解软件领域从代码提交、分支策略、流水线构建、持续集成、自动化测试管理、发布模式等环节了解交付全流程，结合实践提炼属于自身的方法论和理解，也欢迎大家共同交流、成长。
