6 如何保障项目按期完工？ 人人都是项目经理系列（第6/13篇）

1.1帕金森定律（PMP中的定义）：只要还有时间，人们就会有意无意地多做不必要的工作（范围蔓延），直到用完所有的时间。（没错，说的就是那些只要有时间就改需求的策划。）

• 学生综合症：工作范围通常不变，人们在较早时间完全不做事或者很少做事，总要等到截止日期快到时才着急做。（这个也很好理解，比如发布版本定的是周五，那基本上在周五下班之前，你的项目是不可能完成内容封包的，总有一些人卡在最后的出包时间去提交内容。）

1.2、墨菲定律 有可能出错的事情，就会出错。 其原文是“如果有两种或两种以上的选择，而如果其中一种会导致灾难，则必定有人会作出这种选择。”为什么这个定律这么出名呢？因为它在技术界非常的灵验！“技术风险能够由可能性变为突发性的事实。” 换句话说，游戏上线的时候，那些无法复现的BUG一定就会出现，影响你项目的发布。 1.3、彼得定律 工作岗位总是被不能胜任的人占据的。这句话不是为了嘲讽而说的。 其原文是“在一个等级制度中，每个员工趋向于上升到他所不能胜任的地位”。彼得指出，每一个员工由于在原有职位上工作成绩表现好（胜任），就将被提升到更高一级职位；其后，如果继续胜任则将进一步被提升，直至到达他所不能胜任的职位。由此彼得推论出，“每一个职位最终都将被一个不能胜任其工作的职工所占据。层级组织的工作任务多半是由尚未达到不胜任阶层的员工完成的。”每一个员工最终都将达到彼得高地，在该处他的提升商数（PQ）为零。 知己知彼方能百战百胜。之所以要学习这些管理定律，就是要想办法去解决这些问题。 比如应对帕金森定律和彼得定律，我们可以建立学习型的组织，让所有人在现有的岗位都能保持学习和进步，以便能够胜任当前岗位。建立人才培养机制，以防止相关的管理人员任用自己“无能”的下属，同时在招聘的时候，公开公正透明，防止管理岗位的人员自己“提拔”下属。 应对拖延症，可以使用倒推的手段，最晚期限是周五，但是对成员宣布的时候说周三就得完成，留下足够的缓冲时间等等。 应对墨菲定律需要重视小概率事件，建立健全的风险（后面有风险管理计划）应对措施，以积极的心态去做事，失败后总结经验，以防止下次再次发生。 我们是项目经理，你知道某些事情可能会发生，并且很难改变，那就不要去试图改变它，而是从自身想办法看看如何才能去应对和改善它。为什么我们要在这个章节讲管理学定律呢？因为它们对于维护项目进度至关重要。 2 项目进度管理的概念 项目进度管理需要说明项目如何以及何时交付项目范围中定义的产品、服务和成果，是一种用于沟通和管理相关方期望的工具，为绩效报告提供了依据。它需要将项目的特定数据（如活动、计划日期、持续时间、资源、依赖关系、制约因素等）输入进度计划编制工具中，创建出项目进度模型。 游戏开发常用的就是用禅道、TAPD等DEVOPS导出甘特图。 下面是张老图， 我们可以看看进度管理章节主要涵盖的内容。 进度管理主要涵盖了定义活动、排列活动、估算活动持续时间、制定进度计划、控制进度等几个维度。而近年来由于敏捷概念的崛起，进度管理开始有了不同的分支。 比如未完项的迭代性进度计划： 这个适合创意性的独立游戏，每天或者每个阶段都有新鲜的想法，然后把想法丢进创意池中，每个阶段完成当前的开发周期，就去创意池中排列优先级最高的几个需求拿出来开开发。 按需进度计划： 这个适应于大型的，跨版本夸迭代的内容，一个周期做不完或者人力不够的情况下，分成多个周期去做。每当有人力释放出来的时候就去未完成的需求池里挑一个。 3 敏捷看板 不管是瀑布还是敏捷，在需求上都没有太多花哨，区别最大的还是进度的执行。而敏捷的进度最重要的工具就是看板。 左边是需求池，右边是看板，一目了然。 比如，我们以敏捷的方式开发微信软件，确定范围之后，得到了一下故事点： 假如，我们每个迭代只能消化300个故事点的话，那么每次，我们都从池中挑选300个故事点来做，以此类推。 是不是有点熟悉？需求、设计、开发、测试、发布。一个环节也少不了！而这些环节合在一起是什么呢？对，就是瀑布模型！ 所以是否还记得我们先前讨论的敏捷的几个理解误区？敏捷不是没章法，没原则的乱做，只是一种项目进度的管理模式！它是正规的，可追寻的，有特别设计过的，只是看起来比较随便。我目前遇到过的，自称是敏捷的项目100%是“中华田园式敏捷”。 敏捷还要注意几个重要的概念：

• 迭代规划会议：用来确定下一个迭代要完成哪些故事，整理下个迭代的待办清单。
• 每日站会：团队每天进行短暂沟通的内部会议。一般不能超过15分钟。团队成员只需要讲三点内容：昨天做了什么、今天计划要做什么、 遇到了什么问题。
• 迭代评审会议：在当前迭代结束之后，演示成果并接受评价。
• 回顾总结会议：哪些做得好，哪些可以做的更好，下次迭代需要做哪些改进。

这里需要全员同步一个理念：DOD（Definition of Done）。也就是“完成的定义”，意思就是，大家应该对“完成”有一致的认可，不能A觉得做完了，B觉得没做完。 最后，无论是采用那种管理模型，项目经理的角色都不变。 4 规划进度管理 和前面的范围管理一样，项目进度管理也需要指定进度管理计划。最直接的就是里程碑和版本节点。比如4月部署版署版本，它需要包含哪些内容，8月开始α版本需要包含哪些内容，10月开始β版本等等。 它的PMP官方定义为：为规划、编制、管理、执行和控制项目进度而制定政策、程序和文档的过程。其作用是：为如何在整个项目期间管理项目进度提供 指南和方向 。 不过和范围管理不一样的是，范围要求尽可能的确定不要修改，而进度计划则应该在整个项目期间保持灵活性，使其可以随着知识的获取，对风险理解的加深，以及各种增值活动的设计而随时调整。同样的进度管理计划也是流程性、规范性的文件，里面不包含任何进度。 进度管理计划应该包含几个方面：

• 进度计划的发布和迭代长度：使用适应型生命周期时，应指定 固定时间 的发布时段、阶段和迭代。固定时间段有助于尽可能 减少范围蔓延 。意思就是，我们一周发一个版本，这个版本的内容是上周确定的，这周内你新增的想法和故事，请放入下次版本中。
• 准确度：活动持续时间估算的可接受区间及允许的应急储备数量。应急储备的概念我们在风险章节会详细讲，这里可以理解为缓冲时间。正如前面所说的，如果你打算周五发版本，那就应该周三验收全部内容，留下两天给那些拖延症的同事或者应对突发情况。
• 计量单位：每种资源的计量单位。注意项目管理里所提到的资源，如果没有特殊标明，基本都是指人力资源。那么资源的计量单位一般是指工时，比如每人每天的资源计数为1。
• 控制临界值：项目执行中，采取某种措施前，允 许出现的最大进度偏差 。通常用偏离基准计划中的参数的某个百分数来表示。这个非常重要，进度管理最重要的就是进度基准。比如你约定8月1号游戏上线，那么游戏在上线之前的全公司配合，宣传、爆点、软文、商务位置等等都是针对这个点进行宣传的。所以，如果没有把握的话，宁愿把它排在8月10号，即使我提前完成了，要做的也只是等待。

另外记得前面的帕金森定律吗？只要还有时间，总想修改东西，这里项目经理就要确保已经定下的内容不能再出现范围蔓延或者镀金！

• 绩效测量规则：需要规定用于绩效测量的挣值管理(EVM)规则或其他测量规则。后面会提到一些进度评估的专有名词，并且还有计算方法（哈哈，没想到项目经理也要做题吧），这里先不细说。另外游戏开发，对于这些专有名词较少涉及，我们在后面的成本章节介绍一个非常重要的名词叫做“挣值”！基本上知道挣值就可以了。挣值简单说就是实际进度和预期进度的偏差。

这里稍微提一下几个挣值（EV）的估算方法。 5 定义活动 活动的官方定义：识别和记录为完成项目可交付成果而需采取的 具体行动 的过程。主要是将 工作包 （WBS）分解为活动，作为对项目工作进行估算、进度规划、执行、监督和控制的基础。 也就是说在前面策划的需求已经全部拆分完毕了，现在有很多个子需求（工作包），接下来要把这些需求再按照开发人员的理解，或者实现方式去拆分成任务，看看要完成这个需求需要实际上干哪些活。 这里我们拿TAPD举个例子： 活动是这个版本要做的大功能（需求），下面的实力里程碑、神殿集结等属于子需求（工作包），它们始于策划需求层面的内容（范围）。然后每个子需求下面都评定了一个任务（活动）表示这个任务需要怎么干那些，谁来干，要多久。 当然一个工作包不一定是只分解出一个活动，比如下面这个就很多： 如何分解是属于工具和技术范畴，分解完毕之后我们会得到一个活动清单（任务统计），它包含项目所需的全部进度活动（任务）的综合清单，还包括每个活动（任务）的标识及工作范围详述。如果你是使用敏捷管理的话，这个活动清单需要定期更新。 比如我们使用TAPD进行项目管理的话，可以看到如下展示： 你还可以将这些任务导出成各种报表格式，以支持总体的预览。同样，也可以把这些任务打印成任务卡，来派发给相关人员。 可以导出活动清单： 可以导出甘特图，了解进度总览： 活动清单只是这个过程的输出之一，其他输出的还有变更请求和项目管理计划的更新。 先说变更请求，因为范围和活动总是 渐进明细 的，记住这个词，后面很多方法和过程都要基于这个理念。渐进明细的概念就是，越到跟前才越能确定我们要什么。 举个例子，我们制作版署版本，版署版本的要求是 内容完成度90%，需要实名认证，防沉迷，屏蔽词。那么在你刚立项的时候，你需要考虑版署版本的活动怎么定义吗？完全不需要，因为你的项目可能连防沉迷的策划都还没写。这个时候你只能放一个里程碑清单，说这个时间点，要能满足版署版本的这些要求。 随着研发进度推进，项目大功能系统全部做完了，估了一下，内容完成差不多80%了，好了，我们开始写防沉迷的策划案吧。写策划按的过程中，发现尼玛版署送审还需要软著，怎么办？只能走变更请求，增加项目范围。也就是说在活动渐进明细的过程中，可能会 发现原本不属于项目基准的工作。通过前面说过的实施整体变更控制的子过程。 因为新增的需求导致范围基准变化了，同时，进度和成本基准也会受到影响，那么这些基准变化就会影响到项目管理计划。所以这个过程会输出变更请求和项目管理计划的更新。 6 排列活动顺序 排列活动顺序这个过程理解很简单，但是实施起来是非常复杂的缓解。先说下它的概念：识别和记录项目活动之间的关系的过程。 也就是说，所有活动（任务）都准备好之后，我们要看看这些活动之间的关联关系。比如，你要做版署实名认证，就需要先接入公安部或者第三方的实名认证接口。要做一个皮肤，必须要先把这个英雄先做出来。 这里介绍一种工具，叫做紧前关系绘图法（PDM）。 每一个活动，理解为1个任务，排列活动顺序，就是要梳理好这些任务的前后关系。图示的关系比较简单，实际上的关系要复杂很多。（这个部分很不想介绍，好麻烦啊……） 紧前关系又包含四种逻辑关系： 这些关系又可以分为四种：强制性外部关系、强制性内部关系、选择性外部关系、选择性内部关系。 先软著再版署始于强制性外部关系，先做跨服支持，再做跨服活动属于强制性内部关系。 先接实名认证SDK还是先接入屏蔽词库属于选择性外部关系 先做邮件系统还是先做背包系统，属于选择性内部关系。 在排列活动路径的时候，应该先把强制性的关系排出来，然后再排非强制性的。 这里还要再介绍一个提前量和滞后量的概念：

• 提前量：相对于紧前活动，紧后活动 可以 提前的时间量。（往往表示为负滞后量，如FS-3）
• 滞后量：相对于紧前活动，紧后活动 必须 推迟的时间量。（如FS+2）

它们对应了前面的强制关系和非强制关系。 最后，会输出一张项目进度网络图： 需要注意的是，这张图里面，多个路径汇聚或者多个路径分支的活动（任务）是风险任务，它们需要被重点关注，因为要么是收到多个其他活动影响，要么就是影响多个其他活动。 （额，游戏开发过程中，偷懒的时候都是直接抓对应开发人员来问，你这个往后挪两天能不能自己私下协调下，囧） 7 估算活动持续时间 估算活动时间：源自计划评审技术（PERT）。考虑估算中的不确定性和风险，来提高估算的准确性。这里介绍的东西对游戏来说不太实用，我大概贴一下，不细讲，游戏开发基本都是让相关的开发人员自己估时间，然后由高一级的技术管理人员核对工时，有出入较大的需要一起核对原因，最终算出比较合理的工时。 非游戏行业，可能需要使用到这些实用方法来估算工期了。 来几道题，闲来无事，可以自己算算看： 8 制定进度计划 现在好了，活动顺序也有了，工时也评定出来了，接下来就要制定进度计划了。和前面说的规划进度管理计划不一样，这个制定的进度计划里面是包含进度的。 制定进度计划：分析活动顺序、持续时间、资源需求和进度制约因素，创建进度模型，从而落实项目执行和监控的过程。主要作用：为完成项目活动而制定具有计划日期的进度模型。 第一个方法就是分析进度网络，寻找关键路径： 其中关键路径的工时时长就是该版本的进度时长。 第二个方法，使用7格图顺推、逆推来计算活动日期的属性。 下面做道题（反正我不想再做一遍，学习考试的时候我已经做过了，贴出来你们也痛苦下，答案也给你们）： 1、ABCD四个活动的活动持续时间 2、顺推除所有活动的ES、EF。 3、逆推出所有活动的LS、LF、TF。 4、分析结论。 5、最后做几个总结： 现在我们已经能够找到关键路径，和初步制定进度计划了，但有没有优化进度的方式呢？当然有： 1、资源优化（资源指人力资源）：

• 资源平衡 ：需要平衡主要是因为：1 资源只在特定时间能用，比如专家就过来2天；2 资源数量有限，你们组里就2个人；3资源被过渡分配，一核有难，7核围观的现代CPU工作方式；4保持资源使用量的均衡，呃，这个方式是最人性的。

但是资源平衡，往往会导致关键路径发生变化，也就是说通常是延长工期的，囧。所以在使用资源平衡的时候，多看看非关键路径。

• 资源平滑 ：前面的活动定义关系里，有一些活动是有自由浮动时间的，对这些自由浮动时间内的工作进行平滑调整。它一般不会改变关键路径，也不会影响进度计划。

2、进度计划压缩：

• 进度压缩：缩短或加快进度 工期（进度压缩之后要进行关键路径分析，防止出现新的关键路径）。
• 赶工。通过增加资源，以最小成本增加来压缩工期。（可能导致成本和/或风险的增加。）
• 快速跟进。按顺序进行的活动或阶段改为至少是部分并行开展。可能造成返工和风险增加。

总结来说，就是加人、加班、加钱。 通过一些列的手段，我们最终开始输出，第一个是 项目里程碑 。 第二个是 项目日历 。 第三个也是最重要的， 进度基准 。 9 控制进度 控制进度：监督项目状态，更新项目进展，管理进度基准变更的过程。主要作用是，整个项目期间保持对进度基准的维护。 方法一：挣值分析，将进度绩效测量指标与进度基准比较。 方法二：迭代燃尽图，用于追踪迭代未完项中尚待完成的工作。可使用预测趋势线来预测迭代结束时可能出现的偏差，以及在迭代期间应该采取的合理行动。 方法三：绩效审查，根据进度基准，测量、对比和分析进度绩效，如实际开始和完成日期、已完成百分比及当前工作的剩余持续时间。 方法四：偏差分析，关注实际开始和完成日期与计划的偏离，实际持续时间与计划的差异，浮动时间的偏差。 方法五：假设情景分析，基于项目风险管理过程的输出，对各种不同的情景进行评估，促进符合基准。 最后，关联一下需求和进度两个章节，用一个流程图表示： 下一章，我们介绍成本管理。