掰掰项目管理-如何制定交付计划
前言
2020年2月20日，晚8点 —— 今天聊点什么呢？很多从传统的瀑布出来的项目经理经常会问这样一个问题：项目要做敏捷交付了，该不该制定一个交付计划，以及怎么制定这个交付计划呢？
乍一听觉得很诧异，项目经理为啥会问这个问题？但是深究原因，之所以有这样的困惑，更多还是因为：
- 首先，在传统服务外包公司践行瀑布方式做交付管理，往往分工是很明确的，而且传统的外包类的项目交付往往无法让项目经理接触端到端从项目立项到最终上线运行的整个生命周期。
- 其次，项目交付计划本身在所谓敏捷的语境下似乎也成为了一种“负担”——因为敏捷宣言 [1]里那么一句“响应变化高于遵循计划” …… 于是乎，很多项目经理心里就有了上述的疑问。
该有还是要有
就我个人的经验来讲在固定价值合同 [2]敏捷方式 [3]的项目交付还是需要一个交付计划的，为什么呢？
首先，目标是相对清楚的。在我看来，之所以能签订固定价值合同的交付合同，就是因为在项目立项的阶段客户已经有了相对清晰的业务诉求或者需要解决的业务痛点，团队也基于这些业务诉求提出了理论上可行的解决方案，并与客户达成了一致。
其次，基于目标要做什么，要花多少时间做，谁来做，怎么做，总得介绍介绍。客户花了钱，买了你的服务，这些钱怎么花，谁花，花多久，花了预计能得到什么结果…… 这些事情，还是需要通过一个计划跟客户有个“交代”的。这也是一个很好的展示团队能力，建立信任的方式。理论上说，没有哪个客户会平白无故给你钱，随便团队发挥，也不问问准备搞什么，怎么搞的问题的。
最后，如果遇到意料之外，怎么办？说的直白一些，遇到问题了，遇到变更，遇到风险，团队和客户通过什么样的机制和规则来应对和处理。所谓“约法三章，丑话说在前面……”，其实也是这个道理。也只有这样才不至于真遇到问题了（问题总会有的 ：D），相互推诿，互相指责，然后大家能在问题应对和处理节奏上，形成步调的一致。
交付计划应该有什么
简单讨论完该不该有交付计划的问题，下面跟大家讨论一下交付计划里面该有什么的问题。就我个人的经验来讲，面对一个业务诉求相对清晰的固定价值合同敏捷方式的项目交付，通常情况下交付计划中应该包含以下四个维度的内容：
范围: 项目交付的范围——各个阶段交付范围和交付工作。关注：对内对外，项目交付的目标是什么？价值点（预期的好处）有哪些？最终验收的交付物有哪些？
通常情况，在项目进入交付阶段，交付团队会有一个故事列表作为交付计划制定的重要依据——包含所有功能需求的故事项。因此，交付计划从范围的角度来讲，就应该依据故事列表，在项目不同的生命周期罗列出项目交付阶段所有可能的功能与非功能交付工作来明确项目交付范围并且与客户和团队达成一致。
从可视化的角度，会是一个功能与非功能故事的全景图，在项目交付启动阶段大致确立了本期项目交付的范围和范围内的工作。
当然，它也可以通过电子看板的形式，例如：Jira，Trello等，进行工作的罗列和呈现——故事，任务。
最终，我们想要达到的目的是帮助客户了解和明确，为了真正意义上的实现交付目标，作为一个团队（包括客户、交付团队、第三方依赖）需要完成哪些工作，这些工作不仅包含了传统意义与功能相关的需求分析、研发、测试，更加包含了一些列非研发类，与交付质量和交付目标息息相关的工作，例如：各类研发与非研发实践、项目管理、技术对接、联调测试……
于此同时对于交付团队，我们需要帮助团队了解和明确，为了达成交付目标，团队在各个阶段需要完成的工作有哪些？特别是涉及最终交付物和验收标准的相关工作，例如：用户验收测试、各类测试报告、各类研发设计的源文件，等等。这些内容需要在对内对外的交付启动会议中都进行有效澄清。
排期: 项目交付的时间规划——各个范围交付工作的时间节点，里程碑的时间点节点，依赖的时间节点。关注：对内对外，依赖和里程碑的节点逾期带来的影响、以及风险应对计划。
在项目正式进入交付阶段前，或者在需求分析阶段，客户方是会针对项目交付的具体时间周期提出相关诉求的，例如：给到一个客户方期许的关于里程碑事件和时间节点的列表，或者是对于某些核心功能的诉求提出相关的时间点诉求。
原则上讲，在排期的过程中应该在合理范围内尽可能的配合客户方所期望的关键事件时间节点诉求的，例如：路演、汇报会议、推荐会…… 但是，与此同时，在很多情况下，时间点的诉求又往往是可以调整的。所以，在项目启动阶段，也可以通过对于进度排期的合理评估，帮助客户优化和调整相关依赖事件的时间点预期。同时，也要考虑节假日的情况。
简单来讲，在排期中，我们需要向客户和团队澄清，按照达成一致的本期交付范围，我需要多少时间来完成这些工作，在各个时间周期内，计划完成的交付相关工作有哪些，里程碑，依赖事件的时间节点…… 以及整体呈现项目整体在交付阶段的生命周期是怎样的。
在项目正式进入交付阶段前，排期可以利用前述的表格来排列，从可视化角度可以相对细化，呈现阶段性功能和非功能工作。但是，粗粒度的甘特图排期也是可行的方式。
团队: 项目团队成员规划——不同阶段，团队角色的配置，团队成员进场与出场的规划。关注：根据项目具体需要，人员培养等因素，调节团队能力和经验的配比（Leverage）
团队成员角色的介绍与人员规划，是一个交付计划中必不可少的环节。一方面，我们需要跟客户呈现团队每一位成员的工作内容和职责，以及不同阶段人员配比和团队规模，同时，因为是Fix-bid 项目，每位团队成员的任期属性也是需要说明的，例如：Full Time 或者 Part Time。特别是没有相应研发经历的客户，在呈现团队成员在项目上的工作时间时，需要澄清我们基于工作量的评估和客户给到的时间诉求、质量、成本考虑，已经尽最大可能合理安排团队人员和规模。
另一方面，对于团队侧，应该跟每一位团队成员澄清对齐项目整体的交付周期，各个阶段时间周期，团队规模，人员配比，以及每位团队成员上下项目的时间点安排和相关安排的原因。对于重要的客户侧和团队侧的里程碑事件的时间节点，也需要进行必要的澄清和说明，例如：客户侧的路演、推荐会、发布会，等等。
最后，各种公共假期，个人假期安排、不同国家、地域、公司或者供应商的节假日因素，也是需要在人员工作周期的安排上有所体现，并加以说明。遇到因私休假可能会比较长时间的情况，需要考虑后备人选的问题。
机制: 项目交付的运作机制——项目交付相关工作如何实施，如何管理，以及团队如何管理等等。关注：针对项目范围、进度、质量、成本如何进行管理，跟踪和调整的计划。
团队运行的机制的建立，更多基于项目管理四个基本维度，进度、范围、质量、成本来建立契合的交付运行机制和管理标准。通常需要思考问题会是：项目的进度、范围、质量、成本会如何管理？重要的运作和管理机制，例如：需求变更管理，风险管理，信息安全管理，沟通管理，Scrum或者Kanban 敏捷交付机制，验收机制条件，等等。
另外，也会需要考虑和定义在项目交付过程中，各类敏捷的实践（关于敏捷实践推荐大家可以读一下这篇博文“我在 ThoughtWorks 中的敏捷实践” [4]）如何因地制宜的裁剪和执行的问题。例如：IPM中是否重新估点，是否建立物理看板，正向或者反向开卡关卡，是否结对编程，等等。
再比如故事卡的生命周期节点有哪些，交付中使用怎样的敏捷交付管理工具来支持相关的管理工作，Jira、Trello、及时沟通工具、邮件组，等等。
再比如，交付中的变更需求，如何评估工作量，优先级，如何处理。项目如何验收，有没有相应的流程。整体项目交付如何过渡到下一个阶段——由交付周期进入维保周期或者产品演进周期。如果可以，所有这些都可以在启动阶段的交付计划当中进行必要的阐述和澄清。
更重要的是，需要在客户侧和团队侧对于上述团队的运行和管理机制做充分的对齐，力求团队内部与外部在运行机制和管理上理解是一致的。
交付计划怎么制定
聊到现在，我们讨论了为什么，也讨论了是什么，现在就来说说怎么做的问题 —— 也就是怎么制定一个交付计划。
参考四步工作法 [5]和PDCA [6]工作法，我把我制定项目交付计划的过程总结为上图中的几个步骤，它们分别是：
- 了解 - 收集和了解项目相关的各类信息、上下文、以及前序阶段的产出物
- 分析 - 分析评估项目各个维度管理的优先级，依赖、潜在风险、干系人对于项目交付的影响
- 计划 - 基于前述了解的项目上下文，以及相关的分析和评估，制定项目交付整体计划
- 对齐 - 通过会议、私人沟通、邮件等形式对内对外分享交付计划所包含的内容，达成理解上的一致
- 调整 - 在内外部对齐过程中，基于客户与团队侧的反馈，对交付计划进行调整
- 执行 - 基于已经达成内外部一致的项目交付整体计划执行项目交付
由于内容比较冗长，下面我会以一种内容清单的形式，跟大家分享在各个环节当中，应该去关注的内容和事项，方便大家在后续制定交付计划的过程中可以有一个类似于检查清单的工具，帮助大家更高效的制定交付计划。
了解什么？
- 项目交付的目标和价值 - 对客户侧与TW侧项目愿景、目标、价值与发展规划
- 项目商务的信息 - 合同类型、商务状态
- 项目事业环境因素 - 组织架构、干系人信息、交付场所
- 需求分析阶段的业务和技术侧功能与非功能诉求
- 故事列表&对应优先级
- 非功能需求列表&对应优先级
- 需求分析阶段功能与非功能需求
- 页面设计
- 估点排期
- 团队配置
- 技术选型
- 技术架构
- 项目的验收条件和交付物 - SOW或者合同当中写明的验收条件和交付物
- RAIDs - 风险、假设、问题、依赖
分析什么？
- 项目交付进度、范围、质量、成本在客户侧优先级
- 项目交付相关干系人重要性、支持程度
- 项目中各方依赖对于项目交付的优先级和影响
- 项目中潜在风险的优先级，发生可能性与影响程度
- 项目中需要验证的假设的优先级，以及对于项目交付的影响程度
- 项目中已经发生或者识别的问题的优先级，导致问题的原因，以及对于项目交付的影响程度
计划什么？
- 范围管理 - 基于故事列表、非功能需求，划定明确项目交付启动、实施、收尾阶段团队工作范围和职责
- 进度管理 - 基根据交付范围内工作和相关工作量评估，考虑团队规模，排列迭代计划
- 团队管理 - 根据交付业务及技术栈要求，客户侧交付节点要求，安排团队人员配置和规模。同时需要考虑：能力发展，后备建设，远程或者现场人员安排等因素
- 资源管理 - 建立目录或者清单管理项目相关软硬件资源，例如：显示器、主机、测试机、云服务、电子墙服务等
- 成本管理 - 范围、进度、团队、资源等相关计划相对清晰的状态下，整体交付工作量相对明确，这时可以利用公司的一些财务工具（如果有 ：D）计算毛利，建立成本基线与收益目标
- 风险管理 - 制定项目风险管理计划和列表（周报中应该呈现）
- 变更管理 - 制定项目变更管理计划和列表（特别是需求变更，及其处理方式和处理结果，应该在周报中实时呈现）
- 安全管理 - 交付安全与应用安全计划的制定，例如：- Onboard/Offboard 流程&资料&清单，紧急事件响应计划，基础信息安全期望确立，法律法规合规性检查跟踪列表，安全培训资料准备（公司侧&客户侧），设备防火墙&杀毒软件，代码库、资料库、邮件组、账户密码管理方式，应用安全管理计划制定（ Build Security In - BSI [7]- 推荐阅读 zlmessage：掰掰项目管理-安全管理），BSI-威胁建模，等等
- 质量管理 - QA主导定义软件测试中 [8]的质量管理策略和计划（例如：测试体系定义 - UT、FT、ST、SIT、UAT，测试时间和频率定义等等）；定义自动化测试覆盖率要求、各类质量管理实践执行时间点和频率、Bug的管理方式，等等
- 沟通管理 - 制定项目对内对外沟通计划和模版，例如：启动会、例会、站会、IPM、周报，等等
- 干系人管理 - 建立干系人管理列表与干系人管理策略
对齐什么？
- 对项目交付的目标、范围、周期、时间节点、团队配置与客户和团队侧进行沟通，并达成一致
- 对项目的运行和管理机制与客户和团队侧进行沟通，并达成一致，例如：范围、进度、团队、资源、成本、风险、变更、安全、质量、沟通、干系人等将在项目交付期间如何进行管理和跟踪
- 收集对齐期间，内外部关于交付计划的反馈，便于及时协商和调整
调整什么？
- 基于收集的反馈，对项目交付的目标、范围、周期、时间节点、团队配置等进行调整和再计划
- 基于收集的反馈，对项目的运行和管理机制进行调整和再计划，例如：范围、进度、团队、资源、成本、风险、变更、安全、质量、沟通、干系人等的管理和跟踪机制
注意：计划的调整和变动，应该基于交付价值最大化的原则，同时也要考虑范围、进度、质量、成本维度的合理性。
开始执行。。。
- 密切跟踪项目交付目标和事业环境变化对交付带来的影响，及时合理调整交付计划
- 密切跟踪识别项目需求变更，潜在风险等因素在交付过程中带来的影响，及时合理调整交付计划
- 密切跟踪项目交付执行过程中范围、进度、质量、成本等实际状况与计划间的差异，了解上下文，分析原因，及时合理调整交付计划
- 另外对项目的运行和管理机制的调整和再计划，尽量对内对外都通过会议、邮件、私下沟通等形式保持意见一致和上下文对齐——调整和保持对齐需要考虑的维度包含（不限于）范围、进度、团队、资源、成本、风险、变更、安全、质量、沟通、干系人等的管理和跟踪机制等
一些建议
- 交付计划的信息呈现对内对外会有所不同，例如：干系人管理信息和策略
- 不是每个项目都需要涉及 PMBok 中的九大知识领域，应该针对项目的具体情况做必要的裁剪，
- 例如：有的项目不涉及资产采购，有的项目在客户现场交付，安全管理更多由客户方负责
- 根据项目的不同量级和复杂度，调整项目交付计划的颗粒度和覆盖的维度
- 如果可以，最好利用公司的财务工具进行交付成本计划和跟踪管理，如果没有此类工具，那么最简单的规划固定价格合同成本的方式就是（不考虑软硬件采购，折旧等因素的情况下）：
- 团队研发成本+差旅成本+云服务成本+管理工具使用成本
- 利用各类敏捷实践实施、电子看板和物理看板的不同卡的类型和生命周期的设置等，就可以跟踪和管理项目交付整体质量。如果有必要可以适当在交付计划中对于实践的执行和意义进行诠释
- 实践：IPM、Poker Plan、开卡、关卡、Showcase、Retro、结对编程、Code Review、TDD、CI/CD...
- 类型：故事卡、任务卡、缺陷卡、安全卡
- 生命周期：Backlog、In Analysis、Ready for Dev、In Dev、Ready for QA、In QA、Done
写在最后
依循前面叙述的交付计划内容，按照上面的步骤，大体上应该可以制定一个还算不错的交付计划了。也许有的小伙伴在制定交付计划的过程中，还是会对各个部分的轻重缓急，内容的想尽程度产生疑惑。从我个人来讲，我一般遵循的原则就是：
- 把我觉得重要的内容，也就是资源需要投入最多的部分给客户说清楚讲明白，与客户达成一致。
- 再就回到最初的那句话：遇到问题了，遇到变更，遇到风险，团队和客户通过什么样的机制和规则来应对和处理——把这一块跟客户达成一致，大家一起朝着解决问题的方向努力，形成互信互助和互相理解的协作氛围。
好了，就写到这里，感谢阅读～
点赞是一种积极的生活态度，赞一个吧!
附录-掰掰项目管理系列：
- zlmessage：掰掰项目管理-项目交付目标
- zlmessage：掰掰项目管理-项目交付总结
- zlmessage：掰掰项目管理-需求变更管理
- zlmessage：掰掰项目管理-风险管理
- zlmessage：掰掰项目管理-安全管理
- zlmessage：掰掰项目管理-如何制定交付计划
- zlmessage：掰掰项目管理-敏捷交付下的项目运行机制
参考
- ^敏捷宣言，也叫做敏捷軟體開發宣言，正式宣佈了對四種核心價值和十二條原則，可以指導迭代的以人為中心的軟體開發方法 https://wiki.mbalib.com/zh-tw/%E6%95%8F%E6%8D%B7%E5%AE%A3%E8%A8%80
- ^固定总价合同是为供货方提供一个完成任务的固定价格的合同。履行合同的承包商必须承担完成工作的责任而不管完成工作的成本是多少。 https://baike.baidu.com/item/%E5%9B%BA%E5%AE%9A%E6%80%BB%E4%BB%B7%E5%90%88%E5%90%8C
- ^敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。 https://zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91
- ^推荐阅读 https://www.infoq.cn/article/my-agile-practice-in-thoughtworks
- ^四步工作法是指將整個公共關係工作過程劃分為四個基本階段的方法。這四個基本階段是公關調查分析、公關策劃、公關實施、公關評價。這四個步驟相互銜接、迴圈往複，形成一個動態的環狀模式。 https://wiki.mbalib.com/zh-tw/%E5%9B%9B%E6%AD%A5%E5%B7%A5%E4%BD%9C%E6%B3%95
- ^PDCA循环是美国质量管理专家休哈特博士首先提出的，由戴明采纳、宣传，获得普及，所以又称戴明环。全面质量管理的思想基础和方法依据就是PDCA循环。PDCA循环的含义是将质量管理分为四个阶段，即计划（Plan）、执行（Do）、检查（Check）、处理（Act/Adjust） https://baike.baidu.com/item/PDCA%E5%BE%AA%E7%8E%AF
- ^安全内建 https://www.buildsecurityin.net/zh/
- ^软件测试（英语：Software Testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程 https://baike.baidu.com/item/%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95/327953
文章被以下专栏收录
