背景案例
在刚刚结束的项目中，从开始到发布上线，全程伴随着多个高风险，每个模块的技术方案，都涉及到多个团队的沟通协调。在项目管理成本极高的情况下，如何推进并完成项目的如期上线，成为一个棘手的问题。
本文不再累述项目管理各阶段任务和经典管理方法，更多地是从成本管理与协调沟通的角度，总结一些软技能的落地方法。
deadline反推里程碑
在资源充足的情况下，我们看一下deadline与项目发布风险的关系：
项目时间越短，发布风险越高；但项目时间拉的很长，发布风险也同样极高，因为在这个过程中，业务的变化、需求的变化、相关系统的改造与升级、大促的风险都会接踵而至。
在deadline确认之后，PM需要根据需求内容，反推项目的核心里程碑，确认每个核心里程碑的deadline。无奈的是，越是紧急的需求，里程碑的设定越没有弹性，项目的风险越大，下图是某个高风险多角色项目deadline反推的里程碑，完全没有任何弹性：
为了保证核心里程碑的推进，高风险的项目还需要拆解出重要里程碑，让各方都能感知到项目进度与里程碑的推进成本。
举个简单的例子，在技术方案评审里程碑下面，我们至少需要圈定资源与产出技术方案，那么资源圈定里程碑与技术方案设计里程碑就必须明确给出deadline。
里程碑细化的好处不仅仅是将项目进度透明、风险及时更近，而且是动态推算成本的好工具，是PM管理项目的金钥匙。
收敛不确定性
很多高风险的项目在初期可能风险很低，但是需求的不确定性、业务决策的摇摆，往往导致项目预期很差，甚至发生大面积的不可用。
为了避免这种情况出现，就需要PM在项目整个过程中强控并收敛不确定性，下图是需求收敛情况与项目完成质量之间的关系图：
需求越发散，发布质量越低；需求越收敛，发布质量越高。但是，绝大部分项目很难在项目伊始做到绝对收敛，细微的需求变更总是在所难免，尤其是互联网公司的项目。因此会有一个需求收敛的【拐点】，当收敛到一定地步的时候，发布质量的提高与需求收敛程度已经没有关系，且需求本身也很难进一步收敛，我个人喜欢称之为【收敛疲惫】。
作为PM，应该尽可能保证让所有不确定性都收敛在技术方案评审结束之前，且高风险项目尤其需要注意3次收敛：
1.PRD阶段，保证子需求粒度下的需求收敛；
2.技术方案阶段，保证子模块粒度下的方案收敛；
3.日常测试阶段，保证所有开发实现细节的需求收敛。
技术主动推动项目
一般情况下，是需求驱动项目、项目反哺业务，但很多高风险高优先级的需求，往往需要技术主动推动项目，以更大的责任感更多的精力投入到项目管理中。
这里不得不提到另一个问题：技术何时投入一个项目？
在业务型开发团队中，PM需要在MRD阶段开始介入并了解整个项目，尽可能把控每个业务细节，协助运营同学做业务决策，帮助产品同学梳理产品规则与项目规划。
下图是PM投入时间与项目可控程度的关系图：
在实际管理的过程中，PM将精力过多地投入到管理中，会容易陷入需求细节而忽略全局考虑，对项目可控力度反而不利。
抛开一般的推动列表，高风险项目中还额外需要特别推动几点：
- 业务架构与方向不清晰的时候，需要协助业务决策并推动输出；
- 产品框架不清晰，产品模块化较为模糊；
- 需求投入产出比较低，业务方案被挑战；
- 技术方案出入较大，多方协同难以达成一致；
- 领域边界不清晰，各个模块的业务边界模糊。
对于以上问题，PM可能不是最合适的问题解决者，但一定是最合适的推动协调者。
透明与协同
高风险项目的一个典型特征是所有人所有角色之间都不可或缺地参与到项目中，且彼此之间风险共担。
让所有人知道你在做什么，有什么风险，应对策略是什么，推进到怎样的进度了，是高风险项目必须做到的。我们来看下面几张图：
- 项目透明度与风险的关系
我们发现项目透明度越高，风险就越低，直到最后维持一个不为零的基本线上。这说明，透明是多么地重要！
很多人虽然很清楚这一点，却往往在沟通的时候，忽略一些关键角色。有几个典型的小例子：
- 技术方案沟通清楚后，仅通知方案涉及人员，并没有通知项目组其他模块的核心技术同学、测试同学、系统联调同学，导致后期重复沟通，并遗漏实现细节；
- 产品同学与合作伙伴沟通产品方案后，仅通知产品与业务方，并没有与技术同学沟通也没有同步最新进展，导致后期产品对接不匹配，临时调整产品方案；
- 技术同学将产品发布上线之后，仅内部通知，并没有通知业务方发布内容，导致运营同学对线上功能模糊不清，业务需求容易断层。
- 项目协同情况与风险的关系
高风险的项目往往需要投入大量的精力协调沟通，协同情况越好，项目风险越低，最终会维持在一个不为零的基本线上。这说明，协同是多么地重要！协同除了需要具备“不要脸”的特质，还需要良好的沟通能力，对PM的软技能绝对是一个挑战。
- 项目透明度与项目协同成本的关系
过犹不及。过渡地追求各方透明，会极大地增加协同成本，导致项目整体成本增加，甚至威胁到发布上线。优秀的PM，会适度地将项目信息输出透明，使协同成本控制在一个适当的范围内，不至于疲于开会、失去里程碑。
设定核心里程碑的底线
协同的过程中，必然会遇到需求不收敛的情况，这就需要我们依据底线进行判断与决策。不同于里程碑内容，项目的底线并不是用于推进项目，而是为了说不，从而控制风险。
一般情况下，核心里程碑的底线包括时间底线、内容范围的底线、资源底线等。在项目成本可控的前提下，合理利用底线，能够最大力度帮助PM控制风险，保障项目上线。
事实上，我们经常使用这个原则，举个简单的例子：不完成冒烟用例，绝不接受需求提测；在某个时间点之前不完成PRD评审，不保障需求内容发布上线。
承担更多
与项目组其他成员不同，PM必须主动承担更多，并时刻保持清醒的头脑，避免被发布时间冲昏头脑。
在高风险的项目中，存在较多的非技术困难，比如好的技术方案因为时间成本而不适合自己的项目、严苛的测试流程可能需要多通路并行提测、非常多的沟通会议且与会人员涉及多团队多角色。好的PM会适当控制非技术困难的问题，尽可能通过协调的方式将结论透明给各方，而不是全员出动、全员面对。
高风险项目中，PM与组员一起面对核心困难并解决困难，能够极大提高团队士气与整体激情。这在项目的开发、提测阶段是有利的，但需要特别注意的是，激情太高反而会降低整体质量，尤其是在测试阶段，容易遗漏细节。
写在最后的
从立项开始到整体交付之前，在整个项目的生命周期内，PM是唯一全知全能的接口人，因此作为高风险项目的PM：
项目的任何环节的任何问题，PM都必须主动承担、面对、解决，不论它是技术问题、产品问题、业务问题还是其他问题；
项目的任何方案与产出，PM都必须清楚知晓，不论它是产品方案、技术方案、测试方案还是相关的其他项目的方案；
项目的任何协同透明，PM都必须一站到底、责无旁贷，不论是沟通、协调、计划还是配合共建开发。
