把灰掃到地毯下面——專案經理應該小心的遊戲之四

 

 

幾年前，我接到一個項目的求助電話。等我參與的時候，項目正處於發布周期的中期。我跟團隊成員一起識別出他們可以交付什麼、應該交付什麼、還有哪些應該延遲。項目團隊後來也按可交付物列表完成了交付。

發布之後，我建議團隊召開回顧會議，看看有哪些工作是在下一次可以改進的。副總裁卻認為沒有人能從回顧中學到東西。

他忘了我為什麼要來幫忙，光注意到了大家的成功。他說：“不過大家這次幹得很不錯。他們滿足了我們對這個版本的所有要求。”

他的話把所有的問題一掃而光——特別是優先順序的變更——灰都被掃到地毯下面了。團隊裡可沒人覺得自己做得有多好。副總裁的話不再可靠了。項目團隊成員感到疲憊不堪。這個版本一開始要求的有些功能不做也是可以的，如果項目團隊一開始就能知道這一點，開發人員就可以集中開發最需要的功能了。

下面這些主意可以避免這個遊戲。

• 把某個版本需要的功能先按優先順序進行排序，再實現。（排序意味著1、2、3、4、5、6，諸如此類。）參見8.3節。
• 逐個實現各功能。如果按照架構進行開發，就會形成很多部分完成的功能，沒有哪個是完全開發完成的。而且架構會隨著項目進展演化，很多管理層也認識不到這一點。參見9.3
• 制訂發布條件，專案經理在項目開始時就可以討論目前的版本需要的東西。參見2.3節。

如果總是遇到“把灰掃到地毯下面”的問題，可以試試下面的方法。

• 使用產品待辦事項清單，功能按業務價值進行排序。這樣，你就總是在完成最有價值（也就是最重要）的工作。
• 使用有時間盒限制的迭代，並逐個實現各功能。專案經理和團隊成員可以看到進展，並且總是最先提供最有價值的功能。

要想利用上述規避策略，就得在項目開始時與項目干係人對話，而且這些對話很難進行。不過其有益之處在於：如果沒有交付任何東西，沒人會假裝項目是成功的。相反，團隊可以把精力放在為了成功交付必須要做的事情上，而且只做這些。