概述
上一篇讲解了项目管理常识的基础知识，下面讲解一些项目管理中比较重要的技能，分别从启动、规划、执行这三个阶段来说明。
启动:识别项目中的四类关系人
如果按照在项目上的权力和利益相关度对干系人进行划分，可以把项目干系人分成四类：高利益 - 高权力，高利益 - 低权力，低利益 - 高权力，低利益 - 低权力。为了方便你更直观地理解干系人的类别，我给你分享一张干系人的四象限分类图。接下来，我会结合这四类干系人，为你讲解各个象限的应对之道。
“高利益 - 高权力”代表：项目发起人
《项目管理知识体系指南》把项目发起人称为 Sponsor，即项目资助人。项目发起人会定义组织对项目的需求，为项目提供资金支持，并进行人员配备。一般来说，项目发起人天然会成为你强有力的支持者，你需要重点管理。实际上，了解发起人对项目的真正诉求，对项目的成功至关重要。有很多项目经理只知道保质保量地完成项目是最重要的，却从来没问过发起人，这个项目真正要的是什么。我曾见过很多看上去执行得还挺顺利的项目，中途却突然被撤消，大多是因为没有搞清楚这个项目会为组织带来什么，以及组织对项目成功的定义是什么。你要知道，发起人所掌握的项目背景信息量肯定比你要大，所以，对发起人做一轮全面而深入的了解，是非常有必要的。我为你精心准备了一个问题列表，你可以找发起人好好聊一聊这些问题。
在这个列表里，有一些问题你需要重点跟项目发起人进行沟通。比如，他发起这个项目的背景和初衷是什么？如何才能知道我们做到了？哪些资源是项目获得成功的关键？他最看重项目的哪些要素？是进度、质量、成本还是范围？在极端情况下，我们该如何对这些要素进行排序呢？即便你的项目已经开始了，你也可以参照这个列表，问问自己是否知道这些问题的答案。需要注意的是，对于你不太确定的地方，特别是我用红色标注的这些问题，不要自认为发起人的想法和你的想法是一致的，你不妨找他当面确认下。同时，为了管理好之后的沟通，你还需要约定好你们之间的沟通频率和方式，以便在项目进行的过程中做好实时同步。比如，可以是每周用邮件同步项目的进展及风险问题、建立核心微信群实时交流、每个月至少进行一次深入面谈等。或者，你们只是简单地达成约定：在你需要支持的时候，随时发起，当日问题当日解决，这也是可以的。
“低利益 - 高权力”代表：职能经理
在矩阵式组织结构中，职能经理是资源池的所有者，他们所管辖的团队通常覆盖多个项目或项目群，这也使得他们与单个项目的利益相关度通常比较低，介入程度往往也很有限。但是，因为他们对资源的把控力很强，如果管理不好这类干系人，你的项目资源就很容易受到影响。我曾经就碰到过这样的情况。有段时间，团队一再跟我抱怨，这个项目中的设计资源成了最大的瓶颈，于是我决定去拜访一下那位传说中性格乖张、超难合作的设计经理。见面后的前半个小时，他一直在跟我抱怨：“项目进度压得太紧，我的很多设计师都累病了；产品和开发对设计师们太不友好了，产品没有经验，连需求都说不清楚；开发实现得还原度太低，问题一箩筐……”我没有反驳他，而是把他的话一条条地记录了下来。半个小时之后，我给他看我记的内容，耐心地跟他一一确认，他想要表达的是不是我所记录的意思。看到我认真的笔记，他的态度明显缓和了。经过一番梳理，我发现，他之所以排斥这个项目，是因为他觉得在这个项目中，设计师没有太多发挥的空间。于是，我问他：“咱们设计团队今年最想做的事是什么？这个项目怎样才能更好地支持你和你的团队呢？”这个问题瞬间打开了他的话匣子，他兴致高昂地跟我描绘了他的期望。这次交流，让我们找到了更多深度契合的合作点。随着合作的深入，这位经理从一个抵制者慢慢变成了项目的坚定支持者。他调动了资深的设计师来支持这个项目，并且主动发起了 Logo 和界面主风格改版的创意评选活动，把项目的设计品质提升了一大截，这给项目组带来了非常正向的影响。所有你看，要想让干系人的态度发生转变，最重要的就是弄清楚他抵制的原因。强烈的态度背后，一定反映了干系人对现状的某种认知，比如，这位设计经理抱怨的“这个项目没有太多设计师可以发挥的空间”，这种认知未必是事实，但你一定不要急于反驳，而是不带评判地去了解他的内心想法，通过积极聆听去建立信任。只有真正地理解了对方的逻辑，才有可能进一步对其施加影响。
总体来看，根据对项目的认知态度，我们还可以把“低利益 - 高权力”的干系人再细分成以下 3 类，进行差异化管理。
反对者（红色部分）：反对者是最难处理的一类，就像刚刚案例中展示的那样，管理这类人的重点在于建立信任，化解敌意。如果你实在无法争取他们的支持，至少要让他们保持中立，以免对其他成员造成负面影响。
支持者（绿色部分）：支持者是项目获得成功非常需要依赖的力量。管理这类人的重点是，首先你要明确地知道，他们各自对项目不同的期望和诉求，然后有意识地创造更多的空间和机会，让他们能够深度参与到这个项目的决策或创意环节。这样可以增强他们的主人翁意识，也会给整个项目组带来最大的收益。
中立者（灰色部分）：对待这类人，总体原则就是，在条件合适时，进一步将其转化为支持力量。但如果你精力有限，可以先不管。
如果你想对这类干系人有进一步的了解，我再给你分享一个问题列表，你要重点关注一下我标为红色的部分。
“高利益 - 低权力”代表：项目组成员
这是与项目结果直接相关、但对决策影响不大的一类人，广大的项目组成员就属于这个象限的典型代表。你可以借助三类问题，了解流程的基本情况和成员的信息诉求。
这些问题可以帮你了解项目的规划和实施过程，找出那些没有做到位的地方，弄清楚项目组成员当前最希望通过项目管理看到的变化。这些痛点和渴望，会成为你在团队中促发改变的有力抓手，帮助你找准突破点，集中发力。有位创业团队的同学给我留言说，他认为，现在团队扩大之后，最大的痛点就是开发流程不规范，但是却得不到老板的重视。那么在这种情况下，对项目组成员的访谈或集体复盘，就是很有效的方法。你可以让更多完善改进的声音和力量汇聚起来，这样一来，就能争取到更多的关注和资源支持。管理这类干系人的核心，就是要做到项目事项的随时告知，及时通报项目的进展和困难。在专栏的第 7 讲中，我会分享给你进展同步的方法，教你学会用数据说话。
“低利益 - 低权力”代表：外围支持人员
我们通常会把一些复杂度低而且非核心的工作，转交给外围支持人员，比如，设计外包、技术外包人员等。在不影响项目的前提下，你可以花最小的力气对他们进行监督。比如，你可以跟他们提前约定好，每天或者每周进展汇报的格式和内容，确保他们的工作职责和任务明确，进展符合预期就可以了。
总结
项目干系人的有效沟通可能直接关系到资源的调配，进度的监控，成本的控制等监控过程中的一些指标。在一定程度上是为我们的规划和执行在保驾护航。每个象限人群的关注点不一致，作为项目经理沟通的方式也得有所变化，“高权利-高利益”人群我们沟通更多是以倾听和解惑的方式来沟通，并适时的表达出自己的诉求；“高权利—低利益”我们需要以平等、透明的姿态，把项目的诉求和愿景，以及协作空间沟通清楚，尽量能保证他们得自主控制权；“低权利-高利益”人群可以说是直接干系人，我们需要描述清楚项目的背景，共同指定项目章程，项目规范等；“低权利-低利益”人群更多的是把规矩和范围制定清楚，进度计划沟通明白。
1. 项目的干系人管理，需要与各种干系人不断沟通。
2. 最重要的是与项目发起人的沟通。因为这个涉及到项目的立身之本，项目的方向，资源，目标等等需要及时同步。
3. 定时和项目发起人沟通项目的进度，方向，以及遇到的问题。项目发起人希望多快好省的完成项目，但有时候我发现在如何取舍上他也不清楚，做选择太难，所以还是要自己把握取舍。
4. 高权力-低利益的代表，比如研发主管，设计主管等，因为他们在多个项目中，最理想的情况还是能够通过满足他们的诉求和期望达到激励作用，让他们能自己将资源倾斜过来。但很多情况下，真的很难做到。实际情况有时候是这样的，哪个项目经理去跟进、催促的多，他们就会把那个项目多投入一些。当然他们也还要分项目优先级，优先级高的优先做。项目管理部门要自己在部门内部确定好项目优先级，谁都说自己的优先级最高，各个职能经理会很迷惑。
5. 对于高利益-低权利的项目组成员，就是要及时沟通项目的相关事项，包括项目的大方向、进度、遇到的困难等。如果有的项目经理是直接对接的不是职能经理，比如研发主管，而是直接对接执行人员，比如研发人员，这些研发人员就是项目组成员。我们需要及时跟他们沟通项目的基本情况，主要可能包括项目目标、目的，项目进度，未来的走向，以及及时帮他们处理过程中遇到的问题，比如可以遇到技术难关，提供资源帮助攻克，以及攻克后的复盘和内部分享，帮助项目组成员和项目一起成长。
规划:排除计划中的延期地雷
在项目管理中，计划是贯穿始终的重要课题，是各个角色协同工作的基准。程序员在做项目管理的时候，会有个特别明显的优势，就是对项目中涉及到的架构设计、技术难点等问题，有着非常深刻的理解，因此，你对技术类风险会有更高的把控力。但是，你还需要学习的是，从全局的视角出发，去推进项目整体目标的落地，优化各个角色的协同过程。作为项目经理，你要利用一切可以利用的资源、尽自己最大的努力达成项目目标，而计划是你可以借助的重要工具。
实际上，计划是“市场需求或发起人的期望”和“团队生产力”之间平衡的结果。从本质上来讲，计划是用来对焦的！做计划，是个集体对焦的过程。如果我们省去对焦的步骤，就会给后续的执行工作埋下很多“地雷”。在执行过程中，这些“地雷”一旦被引爆，就会把我们的项目拖向失控的深渊。下面我们就介绍一下我们在规划项目中遇到的地雷。
雷区 1：不够具体
好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦。这里需要引入一个概念，叫作 WBS 工作分解（Work Breakdown Structure），这是我们做计划的第一个标准动作。作为一个描述思路的规划和设计工具，WBS 可以清晰地表示各项目工作之间的相互联系，帮助团队更高效地管理项目。WBS 是项目管理领域非常重要的方法。创建 WBS 的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程。
简单来说，WBS 就是“把大象放进冰箱”的过程，在做计划的时候，我们要把“大象”，也就是我们要做的这件事情真正拆解开，明确要分成多少块工作内容，涉及哪些角色和哪些环节的工作项，你需要将工作项拆解到 3 个工作日以内，每项任务都对应到个人。
但是有的计划，看似很详细，实际上仍然是个任务的集合，没有办法指引我们有效地达到目标。做计划的方式的转变，背后其实是思维方式的根本转变。
雷区 2：不够全面
我刚刚说过，项目管理是运用当前一切可用的资源，去完成整个项目目标。这份计划的最大问题就是，只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节。这样的计划，无法让我们明确实现目标的关键路径，也无法明确是否可以完成目标以及如何完成。识别依赖并画出关键路径，就是我要讲的做计划的第二个标准动作，这一步意味着我们开始从目标的角度对资源进行统筹思考。关键路径是决定项目工期的进度活动序列。它是项目中最长的路径，关键路径的工期决定了整个项目的工期。所以，任何关键路径上的延迟都将直接影响项目的预期完成时间。
除此之外，在核心部分计划出炉以后，我们还要对项目涉及到的其他合作环节，进行全面地规划和安排，为各个阶段设定合理的里程碑节点，确保考虑周全。明确了和其他合作环节的时间节点之后，我建议你使用 Visio 工具，把整个过程可视化出来，让计划更加直观。
雷区 3：不够准确
让节点的定义形成共同的标准。这就要引出做计划的第三个标准动作了，就是定义完成标准。简单来讲，完成标准就是某时间点需要完成的事项列表，或者是应该达到的某项指标（特定水平的 Bug 数量 / 性能指标等）。进度计划中的任何重要时间节点，都应该有一组完成标准。越早定义完成标准，计划按照期望完成的概率就越大。以最关键的几个常见时间节点为例，完成标准如下：
需求 / 设计确认：执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。值得一提的是，有些团队还会对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。
功能完成 / 提测：所有定义的功能都已经完成（比如冒烟测试通过率高于 90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪。一些质量基础比较好的团队，也可以把 CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准。
里程碑完成：质量已经达到适当水平（如不存在 P0 及 P1 优先级的 Bug），可以上线发布，或者可以开始下一个里程碑。
雷区 4：没有共识
事先定义完成标准，就好比提前约法三章，会让计划有更准确的指向作用。如果只是只是“做”了一份计划，而不是在“做计划”。这真是个惊人的发现。其实，做计划本身并不是最难的，真正难的是什么？对焦！没有达成共识的计划，是不具备任何效力的。事实上，PM 在召开规划会之前，排期的内容已经准备得差不多了。在全员规划会上，除了对齐信息之外，更重要的是当面达成共识，这其实也是仪式感和承诺的象征，对计划后续的有效执行，是至关重要的。因此，达成共识并公开透明，就是做计划的第四个标准动作。对于一些小项目，即便没有全员规划会，我也强烈建议你至少要在确认计划之后，向所有项目组成员，包括项目的所有干系人，发送计划邮件，正式周知，这可以尽早地发现共识的偏差。
雷区 5：不够即时
计划就像冰箱里的酸奶，即时的，才是有效的。虽然定计划是个谨慎的过程，但我们也需要看到，计划绝不是固定不变的。在整个项目周期中，由于随时会可能出现变更，加上对估算的不断细化，做计划永远是个反复修正、渐进明晰的过程，我们要对计划进行持续地跟进与调整。重要的是，每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。而及时调整变更，就是做计划的第五个标准动作。你需要注意的是，与进度计划有关的任何变更，都需要提交给项目管理人员，最好由团队中对应功能小组的成员（该功能模块涉及的策划、设计、开发、测试）及其他相关干系方共同讨论，明确计划变动可能对各方造成的影响，最终做出决策，并公开告知所有项目组成员。
执行:打造品质，要从头开始闭环
很多时候，我们确实没有办法一步到位，但合理试错，减少不必要的浪费，仍然是可以做到的。在项目执行的过程中，想要降低偏差、减少返工，你就需要构建系统能力，在产品研发的整个过程中，建立起真正闭环反馈的产品验证机制。说到这里，我想先提一下，到底什么才是真正的闭环。我是学控制工程出身的，大学教科书里的一张展示开环和闭环系统的经典图片让我印象非常深刻。看了这张图，你就会明白，其实，开环与闭环之间的关键差异，就在于有没有反馈环节，以及系统是否会根据反馈自动调节。
那么，既然闭环如此重要，在产品研发的整个过程中，到底有哪些实用的闭环验证方法呢？我来给你介绍三种最实用的方法。
方案评审（OARP 决策机制）
其实，需求评审、交互评审、视觉评审都是非常基本的闭环验证方法。我在留言区了解到，有些项目是从来不做需求评审和设计评审的，产品人员找某位开发单方面讨论一下，需求就算定下来了，可以直接往下走了，这就是典型的开环系统。还记得我在刚开始举的“黑五购物节”的例子吗？那次返工，不仅让团队一个多月的辛苦打了水漂，还错过了最黄金的购物节时间。不得不说，这样的开环系统，在上线后出现偏差是很正常的，因为在这个过程中，根本没有任何矫正的机会。要想执行中不走样，你就必须把方案评审做到位。而一说到评审，很多人会说，不就是组织一个会吗？大家就是坐在一起看一看，流于形式。No！你需要理解的是，评审的精髓不在会，而在于背后的决策机制。只有决策机制清晰，职责分工明确，方案评审才会有好的闭环效果。我来给你介绍一个典型的决策机制，叫作 OARP。OARP 是 Owner、Approver、Reviewer、Participant 的缩写，分别对应四个关键角色：
负责人（Owner）：负责给出方案，组织各方讨论并推进做出最终的决定；
批准者 （Approver)：最终批准者；
审核者（Reviewer）：负责人和批准者挑选出的审核人。审核者有责任对文档进行讨论分析，并提出反馈意见，负责人必须重视并给予回复；
参与者 （Participant）：其他提供意见的人。参与者会收到文档的相关信息，可以对相关问题做出反馈。
这张流程图清晰地展示了一个典型的方案评审流程。OARP 是一套决策机制，你需要为项目中每一类方案的评审，确定明确的角色和职责，让各角色应享有的权利、应履行的职责，都得到规则上的保障，这样才能更好地确保方案质量，把后期的返工降到最低。我把项目中常见文档所对应的 OARP 角色汇总在了下面这张表格里，你可以参考一下。
Bug Bash（Bug 大扫除）
Bug Bash，也叫 Bug 大扫除，最初来自微软，是指在项目开发里程碑的末期（比如 Beta 版发布前），划出一个专门的时间段，在这期间，所有参与项目的人员，集中全部精力一起来给项目找 Bug，目的是从各个维度衡量和体验产品。这是一个非常有意思的活动，在网易也很受欢迎，在反复的实战应用中，我们对 Bug Bash 做了很多的改良，产生了很多有趣的变种。除了应用于测试阶段，我们发现，Bug Bash 还是进行产品闭环验证的一个非常有效的方法。通常，在版本的需求稿和交互稿完成之后，我会专门安排一段时间，组织团队成员一起，集中精力给需求稿和设计稿找问题。记得我第一次组织这样的活动时，程序员们开心坏了！因为，他们终于可以让策划和设计们，也尝尝修 Bug 的滋味了！曾经，在一次活动的需求设计 Bug Bash 上，运营同学发现了现有产品的逻辑错误，避免了上线后优惠券发放的漏洞，为我们提前规避了很大的损失。通过这些 Bug Bash 活动，我们把产品验证环节大大地提前了, 不仅达到了更好的体验效果，还有效地保障了上线质量。那么，想要组织一场 Bug Bash 活动，该从哪些方面入手呢？
时间：测试类的 Bug Bash，你可以选择在全面功能测试结束后，Bug 趋于收敛的时间段开展；需求设计类的 Bug Bash，一般会放在需求稿或设计稿完成后举行。这个活动需要一到两个小时的时间，你一定要提前排除所有干扰；
地点：你需要设立一个单独的作战室，鼓励参与者自带笔记本，让他们尽可能集中精力做这一件事。同时，作战室可以提供一些零食和饮料，让活动更有氛围；
参与者：除了研发和测试，产品、设计、市场、运营、销售等项目组不同角色的人群，都需要参与到这场活动中，这样你就可以获得更加丰富多维的视角；
现场安排：你可以把现场反馈的问题直接贴在白板上，或者通过电子白板，来滚动更新 Bug 或建议的排名情况。需要注意的是，营造互动的氛围非常关键，如果因为空间受限，参与者做不到在同一个地点进行，你至少也要在通信群中实时更新排名情况的变化。
活动结束：在活动结束后，要直接公示 Bug 或建议数，现场给奖品，并发邮件通报全组。最后，在对 Bug 进行去重后，还要分类定级，确定哪些 Bug 是必须修的，哪些 Bug 是改了会更好的。另外，千万不要忘记公示结果，明确修复计划。
关于活动的组织方式，你可以加入更多游戏化的玩法，这些都是为了最大程度地调动团队成员的参与热情，让问题在早期得到更好地暴露。你可以在一些重要版本中尝试这样的方法，与很多低效冗长的评审会相比，这个活动在避免返工方面，会有非常好的实战效果。实际上，有时候，视觉稿我们也会拿出来这么做。曾经，某个已经运营了三四年的重量级产品，要在一个月之内完成全网的视觉改版，工作量巨大到难以想象，寻常做法很容易出问题，影响最终的用户体验。但时间非常紧张，我们根本来不及全部定稿，就必须开始并行开发，怎么办呢？当时我就想到了 Bug Bash，不过这回不是做一次，而是每天都做！我们把计划拆分到按天交付的颗粒度，每天晚饭后的半个小时，大家会聚在一起，给刚刚做好的视觉稿找 Bug。开发和测试人员的早期参与，让很多遗漏的视觉问题在早期就得以发现，避免了后期的很多返工。后来，这个视觉改版非常顺利地上线了！让我没想到的是，在项目组的回顾会上，每天晚上的 Bug Bash 活动，竟然高票当选最受欢迎的团队活动。仔细想想，Bug Bash 也是非常好的团建活动，我至今都很怀念那段虽然无比辛苦，但有吃有喝、充满欢笑的“革命岁月”。
冒烟用例评审
有同学留言问我说，当程序员说完成了某个模块的开发工作时，项目管理人员怎么知道 100% 完成了呢？其实，项目经理最怕听到的一个词，就是“差不多”。比如，差不多写完了，差不多测好了，差不多可以发布了……每项工作都是差不多，可是一到测试环节，就会发现，其实还差得很远呢。在上一讲中，我提到，做计划时要明确定义完成标准，而冒烟测试用例，可以说是开发和测试之间最基础的合约。虽然“冒烟测试”这个概念很普遍，但是很多团队只是把它作为提测后的测试用例组，并没有真正发挥其合约的作用。要想避免掉进“差不多”的陷阱，在进入开发环节后，你需要安排专门的测试用例评审，让开发和测试对标准的冒烟用例集达成约定，这个约定就会成为进入测试的准入标准。开发发起提测以后，测试人员就会依照这个标准用例集进行冒烟，并记录冒烟测试通过率，如果通过率不达标，就打回修正并再次提测。如果你是在完全没有基础的团队中推行这个做法，可以先从测试人员记录冒烟测试通过率开始。接着，你要收集相关数据，和你的团队在回顾会上一起看看冒烟用例失败所导致的后期返工成本，讨论出一种更好的确保质量的做法。在我直接管理的项目中，冒烟通过率的要求通常是 100%，你可以选择从一个合适的起点开始，比如 80%，然后再一步步地逼近更好的提测质量。
总结
以后关于数据中台系列的总结大部分来自Geek Time的课件，大家可以自行关键字搜索。