增加更多的人手到一个已经延期的项目中往往不会加快项目的进度，反而可能使情况变得更糟。

项目进度的细微延迟往往难以察觉，但它们却能悄无声息地累积起来，最终对整个项目的完成时间造成重大影响。昨天，一位关键成员因突发疾病未能出席重要会议；今天，一场突如其来的雷暴导致公司供电系统受损，所有设备因此陷入瘫痪；而明天，由于供应商那边出现了预料之外的延误，原定用于磁盘例程测试的新硬盘无法按时到位。此外，还有不可预见的天气变化、紧急任务的插入、个人突发事件、与客户的紧急沟通需求以及管理层的临时审查——这些因素无一不在悄悄消耗着宝贵的时间资源。尽管每次看起来只是半天或一天的小耽误，但日积月累之下，整个项目的推进速度开始逐渐放缓，直到落后于最初的计划安排。

里程碑还是沉重的负担？

精心设计的里程碑实际上为团队提供了支持，使他们能够向项目经理提出合理请求；而模糊的里程碑则成为负担。

在计划中，每个关键节点被称为“里程碑”，并配有明确的时间点。选择这些时间点需要基于技术评估，并且通常依赖于过往的经验。里程碑的选择原则是：它们必须是具体、特定且可度量的事件，能够被清晰地定义。

例如，避免使用模糊表述如“编码完成90%”或“调试接近尾声”，因为这样的描述缺乏精确性。相反，应采用诸如“架构师与实现人员已签署规格说明书”、“100%源代码开发完毕并已录入磁盘库”、“所有测试用例均通过验证”等具体指标作为里程碑。这些明确的里程碑有助于区分那些界限不甚分明的阶段，比如规划、编程和调试。

清晰界定的里程碑不仅便于上级审核，更重要的是它们减少了团队成员自我欺骗的可能性。当里程碑的具体要求无法被轻易篡改时，人们更倾向于诚实报告进展状况。反之，如果里程碑含糊不清，则容易导致报告失真，因为没有人愿意主动传递坏消息。

针对大型项目的估计工作，政府承包商的研究揭示了以下几点：

• 在活动开始前就进行初步估计，并定期（每两周）更新调整，这样即便最终情况不佳，也能保持一定的预见性。

• 活动初期往往对所需时间过于乐观，但随着活动推进，这种乐观情绪会逐渐减少。

• 相反，低估的情况在整个过程中变化不大，直到接近截止日期前三周左右才显现出来。

“其他的部分反正会落后”

当项目进度落后一天时，我们可能会想：“这没什么大不了的，反正其他部分也落后了。”然而，这种态度忽视了一个重要事实：每一天的滞后都可能成为潜在风险的累积。在棒球运动中，队长明白进取心对于优秀队员和团队的重要性。同样，在软件开发中，进取心也是不可或缺的。它促使团队成员追求更快、更高效的工作表现，并为应对不可预见的问题提供缓冲空间。

但是，过于乐观地看待时间安排也会带来负面影响。如果团队因为预计可以轻松赶上进度而放慢脚步，那么小问题可能会演变成大麻烦。因此，我们必须对每天的滞后保持警惕，因为它们可能是导致重大延误的前兆。

并非所有的滞后都会造成灾难性后果，但准确判断哪些偏差是关键的至关重要。这时，PERT（Program Evaluation and Review Technique）或关键路径方法就显得尤为重要。这些工具可以帮助识别哪些任务处于关键路径上，以及它们的延迟将如何影响整个项目的完成日期。此外，它们还能指出一个非关键任务可以在不影响最终期限的情况下允许的最大滞后时间。

尽管PERT技术要求对每个事件进行三次估计，以考虑不同可能性下的完成时间，但这额外的工作量是为了获得更加精确的计划。实际上，准备PERT图的过程——包括展开网络结构、确定任务依赖关系、评估各个任务链——本身就是一项极具价值的工作。第一份PERT图可能会让人感到有些畏惧，但通过不断努力和完善，我们可以制作出更加实用的图表。

随着项目的推进，PERT图能够帮助我们回答诸如“其他部分反正会落后”的借口。它不仅显示了为了使某项工作远离关键路径需要提前多少时间，还提供了补偿其他部分失去时间的方法。这样，我们就能够更好地管理项目进度，避免由于个别任务的滞后而导致整体项目的延误。

地毯的下面

当一线经理发现团队的工作偏离了原定计划时，他通常不会立即向上级报告这一情况。经理们往往倾向于自己解决这些问题，避免给高层带来额外的烦恼。从某个角度来看，这似乎是一个合理的做法，因为处理这类问题是他们的职责所在。然而，这种做法却隐藏了一个潜在的问题：所有的问题都被掩盖在地毯之下，而没有得到及时的曝光。

实际上，老板需要两类信息：一类是关于需要采取行动的具体问题；另一类是用来分析项目状态的数据。为了有效地管理项目，老板必须对所有开发队伍的情况有全面的了解。但要获取这些真实的状态信息并不容易，因为一线经理和老板之间存在利益冲突。经理可能担心如果汇报了问题，会导致上级介入，从而削弱自己的权威或打乱现有的安排。因此，只要经理认为自己能够独立解决问题，他就不太愿意向老板透露问题的存在。

为了解决这个问题，有两种方法可以揭开地毯下的污垢：

1. 减少角色冲突，鼓励透明度：

   • 老板需要明确区分需要立即采取行动的信息和仅用于分析的状态信息。

   • 他们应该控制住自己不对每个问题都做出反应，尤其是在审查状态报告时不应直接干预。

   • 通过这种方式，项目经理会逐渐感到放心，开始提供更加真实的评估结果。

   • 此外，将会议明确标记为状态检查或问题-行动会议，并且保持相应的行为规范，可以帮助建立一个更健康的沟通环境。

2. 强制性的状态评审机制：

   • 即使是在合作良好的情况下，也需要有一个可靠的系统来揭示项目的实际状态。

   • PERT图和频繁设立里程碑是这种评审的基础。

   • 对于大型项目，可能需要每周对部分工作进行评审，大约每个月进行一次整体评审。

   • 关键文档如里程碑进度和实际完成情况的报告，对于识别潜在问题至关重要。

   • 例如，在一次会议上，报告指出手册批准时间与产品测试开始时间存在冲突，这就需要产品构件经理准备解释延迟原因、预计结束时间以及所需的任何支持措施。

通过这两种方法的结合使用，可以确保管理层及时获得准确的信息，从而促进更有效的决策制定和项目管理。这样的透明度不仅有助于解决问题，还能增强团队之间的信任和协作。