评估所需的工时

8.7.2　步骤2：评估所需的工时

找出可执行的工作项目之后，焦点就转变成评估完成这些工作所需的工时。请不要把它和工期评估搞混了，工期是执行某项工作的时间（将会在步骤5说明），评估工时是根据既定的技能基线来推算某人完成某些工作所需的时间。其重点在于，你应该要了解为什么工时的评估必须以某个技能基线作为校准。如果某人根据他所拥有的技能来评估某项工作，可是却指定由另一个拥有不同技能的人来负责完成这项工作，那么这项评估就没有什么意义了。一般而言，团队会先规定一组技能基线，以作为评估工作的依据。

目前已经发展出很多不错的评估方法，多到无法在这里逐一介绍，因此以下只列出一些常用的方法。

项目计划评审技术（PERT）--利用数学方法来产生乐观的、预期的以及悲观的三种评估。

德费尔（Delphi）法--基于专家意见的评估方法。

参数估算法--以其他项目中类似活动的实际工时来评估。

原型法--先完成预先评估的工作范围的一部分，并依此来推算剩余工作所需要的工时。

这些预估方法可以由上而下或由下而上的方式进行，一般而言，"产品管理"和"日程管理"团队会采取由上而下的方式，以反映出项目的各种约束条件，而团队成员则通常会采用由下而上的方式。比较或对照这两种方法对团队而言是有益处的，因为这样通常可以发现需求的偏差、技能落差、利益关系人的期待落差、与现实不符的项目约束条件等。

让团队成员评估自己的工作时间是团队授权的一项重要理念。这样的话，就能让实际执行工作的人来承诺完成的时间。所有的团队成员将因此都支持这份时间表计划，因为他们相信自己评估的结果。MSF团队成员会很有自信，任何进度落后的情况，都会被及时提出来，因此团队领导可以专心扮演协助的角色，只在最重要的时刻提供指导和帮助就可以了。进度的监控已经分散于团队成员之间，并且成为相互支持的活动，而不是由领导监督的活动。

经验谈　依照经验法则，工作应该分解成预估能够在四个小时以上、一周以内完成。如果预估工作低于4个小时，就表示工作分得太细了；如果超过一个星期，就应该再进一步分解成为更小的工作，即使只是借由增加检查点或者发布一项交付成果的初稿的方式来分解工作。理想的情况下，工作应该在一两天内完成。

经验谈　不要用项目管理术语和团队成员沟通，例如要求他们使用PERT来预估工时，这样只会增加他们的困扰。你只要请他们针对每一项工作提供以下三项评估即可：合理的最佳状况（即乐观的预估）、预期的状况、合理的最差状况（即悲观的预估）。这些预估除了用来安排时间表，它们还能呈现出评估者对执行某些工作的信心水平。具体来说，如果最佳状况和最差状况之间的评估值差异很小，就表示评估者很有自信（即最低的不确定性）；如果差异很大，就表示信心不足，而且可能成为一项风险。造成信心不足的原因可能很多（例如：技术的挑战、欠缺相关技能、需求不明等），应该进一步查明。

缓冲时间

每个项目都会碰到一个典型的问题，就是在安排项目时间表时如何将缓冲时间也一并考虑在内。这通常会造成团队与赞助人之间的尴尬场面，因为项目团队很少能够提出加入缓冲时间的充分正当理由。因此，赞助人通常会拒绝在预估时间表中加入缓冲时间，因为他们认为那都是多余的。

要打破这个僵局，双方应该就缓冲时间的议题，开诚布公地讨论。经验显示，不论团队的经验多丰富，一些会对项目造成影响的意外事件、风险和问题还是会发生--太过突然以至于来不及纳入变更管理，但是又很严重，使团队必须在时间安排计划里面考虑它们。为项目加入缓冲时间可以让团队有足够的时间处理这些意外的问题。缓冲时间不该拿来当作增加功能或变更资源的补偿时间，这些改变还是应该通过变更管理流程来处理。

项目团队与赞助人必须针对如何将缓冲时间整合到项目时间表里这一问题达成协议。缓冲时间不应该分配给一些单个的工作，因为这样的话，它必然会被吸收成为评估工时的一部分，致使计划的工时增加，以填满它所分配到的时间（帕金森定律），而不是把多分配到的缓冲时间拿去处理意外事件，那才是缓冲时间的真正用意。正确的做法是将缓冲时间分配给比较高层的工作集合，例如工作流。

与其为主要交付成果预设固定的20%缓冲时间，不如采用另一种比较好的方法来了解项目所需的缓冲时间，就是利用PERT的分析结果（即预期的评估与悲观的评估之间的差异）。这种方法就可靠多了，因为有工作层级的数据来支持它。

——《微软软件研发的奥秘：MSF精髓》