老板给项目经理曼尼打电话说道:“曼尼,我们得聊聊你的项目了。”曼尼答道:“当然,有什么问题?”“嗯,如果这次不加入这个功能,我们就完蛋了。大客户们不会买这个版本的。”曼尼叹了口气,说道:“我跟大家说一下吧,回头告诉你结果。”
曼尼转头跟项目团队解释了这个情况,大家同意在当前版本中加入这个额外的新功能。不过大家已经对按日程及时交付不抱希望了,顺便说一句,项目日程从来都没有改过。
在这个例子中,每个人都希望项目成功:老板、项目经理、项目团队。可他们没有权衡这样做给项目带来的影响,从而使得项目完全失去了按日程交付的希望。整个项目(和团队)就这么完蛋了。[1]
图 我们必须拥有这个功能,否则就完蛋了
如果管理层和项目团队都是出于好意,项目经理可以尝试下面这些方法。
- 要求改变功能集合。你可以问这样的问题:“有哪些功能是在这个版本里面不需要的?我看能不能想办法把你说的这个功能加进去。”
- 要求更多的时间。“如果你愿意推迟交付时间,我们可以加入这个功能。”
- 要 求更多资金。“我知道你为什么需要这个功能,可与其他功能相比,要多花两周才能做完它。我们不能随便拿出来一个功能,再把这个功能放进去;还得再考虑下整 个版本。你想让我现在动手做吗?团队做估算、重新规划版本,要占用一些时间。咱们还是搞清楚这到底是不是你想要的吧。”
要想阻止“我们必须拥有这个功能”,有个办法。如果是按照功能逐个实现,而且按期提供可供发布的产品,项目经理就可以和管理层重新安排下个版本要实现功能的优先级。使用不超过四周的迭代,是阻止该游戏的最佳方法。用四周的时间盒,人们最久只需等待八周就可以得到新功能[2]。
要是每季度发布一次,比如使用“发布列车”(release train)方式,要是想得到新功能,最长的等待时间是6个月。这对很多管理层人士来说都太长了。而且,如果每隔6到9个月才发布一次,那别人就要等上一年甚至更久了。
如果你曾在组织内部遇见过“我们必须拥有这个功能”,使用带有时间盒限制的迭代吧,这样你就可以管控这些要求了。或者考虑使用“发布列车”(见14.3.2节)。参见16.6.1节,以了解如何使用待办事项列表来管理对更多功能的要求,以避免这个游戏。
我们假设你已经有了一个还算靠谱的项目日程。可是总会有出乎意料之外的事情发生,不是每个人都能完成之前承诺的工作。在前一节中,你已经见到了出资人和管理层会玩的游戏。而我见过有些团队成员会玩这个日程游戏。再次强调,项目经理的职责是要让团队成员认识现实。
[1] 请参见:http://www.stickyminds.com/s.asp?F=S11829_COL_2。
[2]假如新功能在一个为期四周迭代的刚开始阶段提出,那么这些功能只有在下个迭代中才能被安排开发,因为一个迭代开始之后,其中要开发的功能是不能发生变化的。这样,要得到完成的新功能就需要两个迭代,也就是8周。——译者注