我們必須擁有這個功能，否則就完蛋了——專案經理應該小心的遊戲之十一

 

老闆給專案經理曼尼打電話說道：“曼尼，我們得聊聊你的項目了。”曼尼答道：“當然，有什麼問題？”“嗯，如果這次不加入這個功能，我們就完蛋了。大客戶們不會買這個版本的。”曼尼歎了口氣，說道：“我跟大家說一下吧，回頭告訴你結果。”

曼尼轉頭跟項目團隊解釋了這個情況，大家同意在目前的版本中加入這個額外的新功能。不過大家已經對按議程及時交付不抱希望了，順便說一句，項目議程從來都沒有改過。

在這個例子中，每個人都希望項目成功：老闆、專案經理、項目團隊。可他們沒有權衡這樣做給項目帶來的影響，從而使得項目完全失去了按議程交付的希望。整個項目（和團隊）就這麼完蛋了。

圖 我們必須擁有這個功能，否則就完蛋了

如果管理層和項目團隊都是出於好意，專案經理可以嘗試下面這些方法。

• 要求改變功能集合。你可以問這樣的問題：“有哪些功能是在這個版本裡面不需要的？我看能不能想辦法把你說的這個功能加進去。”
• 要求更多的時間。“如果你願意延遲交付時間，我們可以加入這個功能。”
• 要求更多資金。“我知道你為什麼需要這個功能，可與其他功能相比，要多花兩周才能做完它。我們不能隨便拿出來一個功能，再把這個功能放進去；還得再考慮下整個版本。你想讓我現在動手做嗎？團隊做估算、重新規劃版本，要佔用一些時間。咱們還是搞清楚這到底是不是你想要的吧。”

要想阻止“我們必須擁有這個功能”，有個辦法。如果是按照功能逐個實現，而且按期提供可供發布的產品，專案經理就可以和管理層重新安排下個版本要實現功能的優先順序。使用不超過四周的迭代，是阻止該遊戲的最佳方法。用四周的時間盒，人們最久只需等待八周就可以得到新功能。

要是每季度發布一次，比如使用“發布列車”（release train）方式，要是想得到新功能，最長的等待時間是6個月。這對很多管理層人士來說都太長了。而且，如果每隔6到9個月才發布一次，那別人就要等上一年甚至更久了。

如果你曾在組織內部遇見過“我們必須擁有這個功能”，使用帶有時間盒限制的迭代吧，這樣你就可以管控這些要求了。或者考慮使用“發布列車”（見14.3.2節）。參見16.6.1節，以瞭解如何使用待辦事項清單來管理對更多功能的要求，以避免這個遊戲。

我們假設你已經有了一個還算靠譜的項目議程。可是總會有出乎意料之外的事情發生，不是每個人都能完成之前承諾的工作。在前一節中，你已經見到了出資人和管理層會玩的遊戲。而我見過有些團隊成員會玩這個議程遊戲。再次強調，專案經理的職責是要讓團隊成員認識現實。

請參見：http://www.stickyminds.com/s.asp?F=S11829_COL_2。

假如新功能在一個為期四周迭代的剛開始階段提出，那麼這些功能只有在下個迭代中才能被安排開發，因為一個迭代開始之後，其中要開發的功能是不能發生變化的。這樣，要得到完成的新功能就需要兩個迭代，也就是8周。——譯者注