第一章 项目管理失当

    激励：不能光靠比萨和啤酒

    总的来说，你的观点用在项目早期的计划上还行，但对于产品发布前的最后一个里程碑就不那么合适了。时间表怎样提供最后期限和时间约束，让团队遵照执行，使得它能作为一种日常管理工具去激励团队的执行力？你必须要解决诸如此类的问题。

    ——一个找不到（汽车）油门的人

    首先我要重申：如果你坚持让开发人员遵从“功能交付日期”，那他们为了准时交付可能会撒谎。他们会隐瞒自己的工作状态，会在质量和完成度上给你虚假信息。如果你不想你的开发团队这么对你的话，你必须建立起一个更好的激励机制。我用过3种不同的方法，这些方法能使大家互相协调工作并产生良好效果。

    第一种，也是最基本的方法，就是应用里氏震级估计。我的开发人员知道，我期望的是每个功能在大致那么多的时间内完成。如果一个原先估计需要2周的任务实际上花了2周半，可能关系不大。但如果花的时间比原先估计的要长得多，那么通常是有实实在在的原因的，那个开发人员必然会让我知道这个原因。如果缺乏充分的理由去延期交付，则足以对开发人员形成一种鞭策。然而，因为没有卡得很死的日期，大家几乎不会去想到隐瞒和欺骗。

    第二种激励工具是瞄准里程碑日期。这有招致大家走捷径的危险，但总体的效果是鼓励开发人员从一开始就努力工作，并且让他们对自己是否落后于进度做到心里有数。“功能交付日期”和里程碑日期关键的不同在于，后者是给整个团队设置的日期，需要整个团队一起努力去达到它。因此，个人抄近路的压力就会小很多。然而，这种危险性仍然无法杜绝，逼得我使出最后也是最有效的一招。

    作者注：一个自我导向的团队向着一个清晰的共同目标一起努力，这是很多敏捷方法的核心概念，尽管在2001年我还不知道有敏捷方法。

    最后一种激励工具是迄今为止我使用起来最有效的。我向团队解释清楚哪些功能是必须要有的，必须优先完成。我告诉他们，必要时任何其他的功能都可能被放弃不做。遗憾的是，这些必须要有的功能常常做起来比较乏味，没有意思，甚至不值得一提。因此我告诉我的团队，如果他们想要做那些很酷的功能，必须首先保质保量地完成之前的这些关键功能。之后，再去做那些不那么关键却要炫得多的东西。这种激励是积极的，有建设性的，并且非常有效。屡试不爽！

    在日期上沉沦

    继续前面的讨论：时间表在不同的功能单位之间（不只是开发，还有项目管理、测试、用户体验、市场推广、外部合作）同步工作时，绝对是必要的；你还必须要解决这个问题。

    ——一个出格的人

    如果你确实需要具体的“功能交付日期”来同步各个方面和依赖方的工作，那么你的软件永远也没法发布。当然，我们的软件一直在发布——我们甚至准时发布了庞大的Office XP。要知道，它的发布日期是在两年之前计划的。因此，肯定存在其他的一些关键因素。

    其实真正起决定作用的，是要在顺序、成本和方法上达成一致，并且提供及时的状态报告。各个方面之间要协商达成协议，定义好状态汇报的流程，并且避免工作的相互牵制。

    顺序：讨论协商各个功能实现的先后顺序已经不是什么新鲜事了，尽管有些部门从来都不能对优先顺序达成一致。

    成本：成本的协商通常发生在开发人员和项目经理之间（例如一个开发人员说：“如果我们使用标准控件，可以帮你节省2周的时间。”）但有时候就只是开发人员做决定。其实，成本的协商也应该让测试和实施人员参与进来。

    方法：讨论协商使用哪种方法通常在项目管理规范书中做，但很少在开发和测试的规范书中做——这对他们不利。

    状态汇报：至于状态的及时汇报，你务必要把邮件和测试发布文档（Test Release Document，TRD）登记起来，或者两者任选其一，以便让项目经理、测试和实施人员了解项目的进展情况。测试部门需要对阻碍工作继续进行的Bug使用警报。项目经理采用类似于“规范书变更请求”（Spec Change Request，SCR）的方式来汇报规范书的更改。（了解更多关于SCR的内容，可阅读第3章的“迟到的规范书：现实生活还是先天不足”栏目。）

    如果各个不同的部门能够对他们的工作顺序进行合理的安排，知道各自的工作需要花费多少时间，对他们使用的方法也很有信心，并且保持着最新的状态报告，那么项目就上轨道了！问题找到了，风险降低了，意外也很少发生。更重要的是，没人顶着因为人为的交付日期而犯错的压力。相反，每个人都朝着同一个目标在努力——为我们的客户交付一个令人愉快的体验。