项目管理实战 20 讲

找到“核心关注点”

用数据和事实来作“论点”

给出一个小小的“行动点”

在合作前，你要跟对方建立合约，明确合作目标、合作事项、双方各自的需求和责任、时间
进度要求、风险及责任人。建立合约时，要由双方负责人进行邮件确认，公开做出正式的承诺。

需要注意的是，在刚开始合作时，建立稳定的预期是关键，双方责任及进度要求，必须要得
到公开确认。否则，这些问题如果不明不白的话，就会给后续工作带来极大的隐患。

为什么很多公司级的战略合作，都会举办一个签字仪式呢？其实，这就是因为承诺越公开，
越正式，日后对双方的约束效力就越大。

合作建立之后，需要建立常规的沟通机制来持续推动。比如，项目信息开放共享，每周在固
定的时间开碰头会，双方相关人员交流工作进展及风险情况。更进一步的话，你还可以借助
标准的任务管理和文档管理工具，对项目任务和文档做到统一的流程化管理，在过程中确保
及时地跟进检查。

如果你发现了模糊地带的存在，要及时明确需要共同协作的内容是什么，该由哪个部门、哪
个人负责，做到权责分明和分工合理，避免后期出现相互推诿、扯皮的情况。

在找领导之前，建议你先自己摸清楚状况，尽快启动风险应对机制，确定问题处理方案，比
如改变方案、调整时间、增加资源、减少范围等。

你要把问题和相应的决议结果抄送给双方的负责人，让双方清楚问题对整体项目的影
响及调整方案。同时，你还要明确的是，今后要采取哪些预防措施，以避免问题的再次发
生。

重新设定节奏之后，如果跨部门协调的问题明显变少，那么当前这个节奏就是更合适的

如果更多是单方面依赖、单方面受益，且是一次性的合作，第一种方式会更加适合

如果是互相依赖，而且是长期合作的共生关系，那么就不能只考虑短期利益了

一个有始有终的闭环，意味着你要对自己的每一个行为负责，清楚地了解为什么做，目标是什么，做完之后效果是怎样的，还有什么问题，以后要做哪些改进；如果中途有变化，也要及时跟相关方明确说明调整或取消的原因是什么

确保至少完整地经历过两到三个项目周期

避开工作高峰期，选择自己相对空闲的季度

并不一定需要有明确的项目经理岗位，只要有相应的项目经验，并且达到足够的时长积累，就可以报名了

英文申请全年都可以提交，没有时间限制，但是有 5～7 天的审核时间，审核成功后，账户有一年的有效期

如果英文申请没有通过，是不能完成中文报名的

报名考生需要具备 PMI 授权的培训机构所颁发的 35PDU 培训证书

《PMBOK 指南》三步学习法

从外部引入相应的人才，是最直接有效的方式。除此之外，你还可以去积极争取短期借调、内部转岗等。从长期来看，你还需要有意识地发现和投资那些团队中最有潜力的人，给他们安排相应的工作辅导，开展有针对性的培训等，帮助项目组成员发展相应能力，让事情真正落地。

项目经理要带大家一起开启动会，清晰愿景目标，定义阶段里程碑和完成标准，接着制定分段执行的计划，把事情的所有环节从头到尾捋顺了；项目经理要建立上下游协同的流程规则，明确各个角色在整个过程中的职责，获得大家的认同和共识：项目经理还要建立站会、周会等制度和模版，让进展和风险通过这些良好设计的信息渠道汇聚，借助规则和工具来达到监控的目的。

当成熟的秩序在团队中形成之后，从日常琐事中解放出来的项目经理，就可以集中精力去做愿景驱动、激励团队等更高层面的工作，真正做到变“赶〞为"引。

在你的项目组中，时间、成本、质量、范围这几个因素，到底哪个更重要？哪些是允许有一定调整空间的？

各个角色目前的痛点在哪儿？哪些是最先需要解决的？这些问题背后潜在的原因是什么？

团队对于这个痛点的改进是否有真实需要？需求的迫切程度如何？

你的老板或项目发起人对于项目管理以及你本人的定位是怎样的？关于这些问题与可能的改进，你是否与其沟通过并达成了一致？

如果你打算引入新方法或工具，更适合用怎样的路径进行，是自上而下地全面推广，还是自下而上地一步步优化呢？最有可能从哪个问题切入？

分析那些是活动组织者的干系人？

项目发起人对活动的预期效果是什么？

是否存在更多潜在的干系方，可以助力活动的成功？

如何更好地管理干系人的期望和影响？

活动过程中的各类决定，都需要谁来拍版？

干系人要以什么样的方式参与？

确保围绕着预期目标来设计相应的活动方案

范围管理的过程中主要是搞清楚到底要做到那些事情，达到各方的期望值

要规划好阶段性步骤，同时明确每个里程碑的目标成果和时间安排

第一阶段，启动项目并确认概要方案设计

第二阶段，规划并落实人力和各项资源的投入

第三阶段，确定具体的活动流程和详细分工，完成活动前的各项准备工作

第四阶段，做好活动当天现场的统筹和运作

从全局视角去思考，如何更有效地管理项目的各项投入，以达到更加匹配目标的预期效果

以终为始，从结果出发，思考引入那些流程可以有效保证活动效果

公司内有哪些核心资源是可以使用的？

哪些是需要外部采购？

有哪些工作需要外部人员支持？

如果经费受限，是否可以通过交换资源的方式，来获取更多的外部支持？

从这个角度出发，需要考虑的是，活动策划团队、执行团队分别通过什么方式来进行项目沟通？

与发起人和赞助方的沟通方式和频率是怎样的？

你如何保持团队内外项目信息的高效传递，使用什么方式来同步进展？

需要提前做好系统性的风险识别，分等级制定应对策略

整合管理是要告诉你，作为这个活动的大内总管，你该如何去统筹全局，整合并协调各个环节利益冲突和工作安排

在不断变化的情境下，根据活动的目标"裁剪”出合适的过程、方法和工具，进行有效管理，从而达到全局的最优效果

意味着正式开始一个项目，或者是开始一个项目中的新阶段，包括识别干系人和制定项目章程两个子过程

正式宣告一个新项目或新阶段的开始，公开确认项目章程，包括明晰各方干系人的期望和诉求，设定愿景目标和重要里程碑，确定责任分工和沟通机制等

启动过程组是最容易被忽略的过程组之一，越是持有结果导向的人，就越容易马上直奔主题去做，根本不管什么项目章程

规划就是要把愿景目标转化为可落地的行动方案和工作路线

需要根据预期目标，明确项目范围，确定项目的里程碑阶段目标，为项目的执行做好各项准备

确保项目一直在正确的轨道上，确保各个环节按照规划进行，并且能够真正做到位

规划做好之后，就是考验执行力的时候了。这个阶段重在整合资源，推进项目落地，完成项目管理计划中确定的工作以实现项目目标

对项目的进展、范围、质量等进行跟踪和监控，识别目前的进度与计划之间的偏差，从而快速准确地采取办法进行纠正和调整

执行并不意味着在任何情况下都要一成不变。当外界环境或内部要求发生变化时，项目管理者也要审时度势，沉着应变，适时地调整各方，以更地实现目标

不管项目成功与否，“趁热”复盘都是极为重要的一步

复盘通常会带给我们很多有价值的信息和启示，比如哪些致命风险需要在一开始就被很好地管理和应对，再来一次的话，我们该怎么做

反对者是最难处理的一类，管理这类人的重点在于建立信任，化解敌意。如果你实在无法争取他们的支持，至少要让他们
保持中立，以免对其他成员造成负面影响。

支持者是项目获得成功非常需要依赖的力量。管理这类人的重点
是，首先你要明确地知道，他们各自对项目不同的期望和诉求，然后有意识地创造更多
的空间和机会，让他们能够深度参与到这个项目的决策或创意环节。这样可以增强他们
的主人翁意识，也会给整个项目组带来最大的收益。

对待这类人，总体原则就是，在条件合适时，进一步将其转化为支持力量。但如果你精力有限，可以先不管。

好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦

WBS 工作分解（Work Breakdown Structure），这是我们做计划的第一个标准动作

简单来说，在做计划的时候，我们要把项目，也就是我们要做的这件事情真正拆解开，明确要分成多少块工作内容，涉及哪些角色和哪些
环节的工作项，你需要将工作项拆解到 3 个工作日以内，每项任务都对应到个人。

做计划的方式的转变，背后其实是思维方式的根本转变

只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节。
这样的计划，无法让我们明确实现目标的关键路径，也无法明确是否可以完成目标以及如何完成

识别依赖并画出关键路径，这一步意味着我们开始从目标的角度对资源进行统筹思考

做计划的第三个标准动作就是定义完成标准

完成标准就是某时间点需要完成的事项列表，或者是应该达到的某项指标（特定水平的 Bug 数量/ 性能指标等）。进度计划中的任何重要时间节点，都应该有一组完成标准。越早定义完成标准，计划按照期望完成的概率就越大。

越早定义完成标准，计划按照期望完成的概率就越大

没有达成共识的计划，是不具备任何效力的

达成共识并公开透明，就是做计划的第四个标准动作

每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策

及时调整变更，就是做计划的第五个标准动作

负责人（Owner）：负责给出方案，组织各方讨论并推进做出最终的决定；

申核者(Reviewer)：负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论
分析，并提出反馈意见，负责人必须重视并给予回复；

参与者 (Participant)：其他提供意见的人。参与者会收到文档的相关信息，可以对相
关问题做出反馈。

事件描述

影响后果

跟进分析

响应措施

所需支持

首先，我们自己要先进入反思区

奠定基调：复盘不是来挑问题的，而是为了找到问题的根源并改进的

包括项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等

现场回顾总结项目 / 里程碑的整体概况

与会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点

在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论

对大家总结出的好和不好的点，进行集体投票

由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案

事后不如事中控制，事中不如事前控制

关于执行中的风险，群众永远是最有发言权的。如果这个系统是健康
的，一定是可以自行去呈现和反馈风险的。而建立系统性保障机制的关键就在于，你要致力
于持续改善人与人之间的互动品质，提升项目团队的健康度。

经常做匿名问卷收集或访谈，定期做一场坦诚布公的复盘会，都是系统性保健的好方法

做调查问卷，是项目经理了解团队的重要方式之一

你要坚持在多个版本中反复使用，积累数据。这样一来，你就可以通过各个版本的数据变
化，看到团队状态的起伏和健康度的走势。当团队对产品的发展方向产生疑虑或不认可，抑
或是对过程中的管理方式或协作状态不满的时候，你要允许团队各抒己见，充分沟通表达。
事先预防永远胜过事后纠正，如果你有意识地在团队中构建这样的常规反馈渠道，系统性风
险提示和保健的作用就会逐渐发挥出来。

项目经理不是只要管理好常规执行风险就可以了，真正会导致项目失败的致命风险，
往往在项目一开始就埋下了。比如，公司高层对于项目的态度和预期、项目目标与组织战略
目标的一致性、项目所依赖的重要资源方的合作关系、竞争对手及行业市场状况的变化、政
策变化、监管风险等。

第 1 步：挖掘出这些致命风险，把它们变为可见的、可谈的

第 2 步：正视风险，不存侥幸心理

第 3 步：在项目的核心团队中，周期性地梳理和同步风险状态

新功能适当放慢：在基本功能已经成型的情况下，进一步控制新功能开发在迭代中的占
比与优先级。当时我们定义的是不超过 70%，在一定时期内，核心功能不再做大的变
动

回顾总结：将线上 Bug 分析作为周会的一项固定内容，集体讨论出整体层面上的改进措
饰并立即实施到位

查漏补缺：对已有的测试用例进行全面梳理，与相关的开发、测试、运维一起集体
review，花大力气补充测试代码（增加异常、并发、稳定性测试等）。考虑到这是一项
长期工作，要确保将其分解到各个迭代中，分批实施。

走到前面：紧密跟进社区 Bug，分析重现并评估影响，定期总结梳理，并组织讨论应对
措施，主动引入必要的补丁。

以终为始：新功能需求确定后，测试用例同步设计并进行 review，然后开放冒烟测试标
准，让开发人员在明确”什么是完成”的前提下，进行开发。

1. 每月坚持开线上 Bug 分析会。你可以召集产品、研发、测试，一起对过去一个月的线上
问题，进行深入的根因分析，制定策略并推进落实。

2. 持续进行内部 Bug 分类。从不同维度分析 Bug 原因，你可以按照具体引入阶段给 Bug
分类，比如需求不清、设计缺陷、逻辑错误、测试遗漏、变更引发的覆盖升级、历史遗
留等，也可以按照 Bug 类别分为功能问题、性能问题、界面问题、兼容性问题等。从数
据统计上，你就可以准确地知道，自己项目的质量问题主要出在哪个环节，下一步是要
先规范代码准入标准，还是加强需求评审，以及哪些保障措施会更有效。

3. 建立质量大盘，拉通不同业务线或模块的每月 Bug 趋势，对齐干行代码 Bug 率、Bug
数/需求数的比率、Reopen Bug 率等，对低于平均线下的业务线或模块进行有针对性
的原因分析。

那个项目的启动会，可以邀请到大老板亲自上阵跟大家讲述项目背景。他从公司战略赛
道的选择性聚焦，讲到自己对这个事业的追求，话语中所传达出的重视、关注和热爱，是让
这个 why 真正打动人的核心要素。

对于一些新组建的团队来说，也可以加入一些破冰的环节，让大家打破边界，尽快建立新的 协作模式。你还可以留一些时间给重要的角色代表发言，大家的热情相互感染，会让士气空 前高涨。这时，启动会的效果就达成了。

举“红牌〞：表示叫停谈话，避免过度的讨论和无结果的时间浪费，提高站会效率；

举“黄牌〞：表示打断讨论，进行提问，向发言者了解协同及依赖的信息；

举"绿牌〞：这是一个 token 牌，代表每个人的发言权。每次只有1 个人发言，按顺序
来，将此牌归还给主持人表示同步完毕。

这样简单的游戏规则，既可以帮助主持人有效地把握节奏，同时还把会议控制的权力和责任
交给了与会的每一个人，任何人都可以对过度的讨论随时喊停，从而让站会在“有用”的同
时又能保持"高效〞。

每个会议都有特定的主题和目的，并有明确的参会人员范围，这个就叫会议的边界

项目经理要做好两个确保

相关问题的主要决策人，对这个问题有责任的相关人员、负责执行决议的人员是必须参与的

会后所有跟进事项，直接进任务系统，确保跟进到底

去观察那些花他时间和精力最多、他反复强调却又没很好解决的问题，那些才是他真正的痛点

在变革的早期，最重要的就是寻找到早期支持者；围绕着你想要引入的变化，击中几个重要干系人的痛点之后，这个时机就到了

每个人都等着上一环节的人把东西弄好送到自己面前来，才能开始工作。这些空耗的时间，并不能给产品带来直接
的价值。

在传统的项目管理中，项目经理的很大一部分工作就是要厘清各方责任，界定权利与义务，
疏通对抗情绪，并解决随之而来的突发问题。但在敏捷的情境中，更加快速的交付压力，使
得这种等待和界限变得越来越不可接受，我们不得不改变思路。

开发做完了工作以后，如果发现测试进度被卡，就会跟着一起着急，一起想办法解决问题， 因为这影响到了整体的进度。

在敏捷团队中，开发干得热火朝天的时候，测试也没闲着，测试代码与开发代码几乎是同时 在写的。往往代码刚”出炉” 就测上了，而且只有在测试结束并确认没有 Bug 的时候，开 发的工作才算结束。

1. 产品负责人向团队和用户代表，面对面地讲解收集来的各方需求，最终明确需求的优先 级及验证条件，也就是说，在迭代结束的 Demo 演示会上，我们要给用户呈现什么。 2. 团队估算。我们采用敏捷估算扑克的形式，由团队成员共同给出估算结果，最后综合得 出这个迭代要交付哪些内容.

团队估算的过程，其实是个双向互动的环节，可以帮助团队和产品负责人共同加深对条目的 理解。同时，产品负责人也会根据大家的反馈，及时修改条目，完善条目。

需求探索更深入

估算结果更加全面、细致

找到了更优的整体解决方案

更低的延误率

阶段性可见的产出

更快的反馈、适应与调整

团队自主运行，管理更轻松

变“赶”为”引，为共同目标奋斗

更高的生产力

更强的责任感、主人翁意识