鬆弛讓你更敏捷（3）：不好的進度表

June 04 12:42~14:00

 

當年老蔣總統提出「一年準備，兩年反攻，三年掃蕩，五年成功」的反攻大陸進度表（schedule），很不幸的最後事與願違，計畫沒能如期實行。請問，時程延誤或專案失敗這是訂定計畫者的責任，還是實施計畫者（軍人）的責任？

嗯…感覺起來應該是 聖上 專案經理 訂定計畫者的責任吧…是吧，不是嗎？

***

為什麼工程師普遍都很不爽專案經理，因為進度表是專案經理規劃的，但是只要進度落後，專案經理便把責任推給基層的工程師，質疑工程師辦事不力或是能力不足。

工程師：進度落後的原因，會不會是schedule訂定錯誤呢？

專案經理：天下沒有不好的schedule，只有趕不上進度的工程師。

工程師：你贏了，我走。

***

《別讓員工瞎忙（Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency）》書中第八章有兩段話Teddy覺得非常有道理：

天下的確有不好的進度表，如果進度表訂下的完成日期沒有做到，它就是不好的進度表。這是判斷進度表好壞的唯一標準，就是這麼簡單。不管做不到的原因是什麼，如果完成日期沒有達到，進度表就是不好。進度表的目的是做計畫，不是設定目標。工作沒有按照計畫來進行，計畫自動無效。

做不到的進度表是計畫者的錯誤，不是執行者的錯誤。如果工作人員極無能，好的計畫會考慮到他們的不足，使其影響減到最低。一個不考慮實際狀況的計畫，不僅無用，而且危險。

讀完上面這兩段話，鄉民們有沒有覺得這個精神跟Scrum好像啊。在Scrum的框架中，release date是固定的，可以調整的是功能項目的多寡。所以從這個角度來看，時間到了之後就算是原本規劃的某些功能無法完成（理論上未完成的功能是價值較低的功能），團隊總是可以釋出某些對使用者有價值的東西。

在Scrum框架中計畫者是Product Owner，當作案失敗時，由Product Owner負責，而不是開發人員的錯誤。這一點也符合slack書中的看法。

***

進度表原本就是一種估算，有估算就會有錯誤。承認錯誤，面對問題，才有機會可以解決問題。如果把進度表當成聖旨，堅持「千錯萬錯皇上不可能錯」的心態，那就只好…請參考《對症下藥》。

***

友藏內心獨白：難不成schedule跟政見一樣，都是喊爽的，不需要落實。