六問禪道1：為什麼任務的剩餘工時不自動更新？

來自專欄 半山的絮叨

我自己從2010年8月開始接觸和使用禪道項目管理軟體，由剛開始的只使用測試--Bug管理模塊，到現在的所有模塊均有在使用。

在不斷的使用過程中，加上長期混跡在禪道QQ技術交流群，對禪道的使用，項目管理也有了深入的理解。

在QQ群里，同樣的問題經常被問起，看起來是個小問題，其實裡面卻蘊含了項目管理的一些大道理。

因此，我以禪道使用為背景，再加上自己的拙見，整理了「六問禪道項目」系列使用分享，希望能達到拋磚引玉的效果。

歡迎吐槽指正。

今天來說說任務工時更新問題。

不少童鞋都有在問：禪道里記錄任務工時，輸入日期和工時後，為什麼還要輸入剩餘，這麼簡單的加減系統不會自動計算嗎？

也就是說很多童鞋對任務工時有誤讀，單純的認為任務預計剩餘工時 = 最初預計工時 — 已經消耗工時。

具體解答問題之前，我們先來了解一下禪道里的工時概念：

最初預計：創建任務時的最初預計工時。

預計剩餘：完成這個任務還需要的工時。

套用一句老話「計劃沒有變化快」，以我的個人經歷來說比較常見的任務開發狀況：

1、某個任務最初預計工時是10，coding了5小時後，重新估算還要9小時才能完成，系統自動計算剩餘工時的話是3小時。

2、某個任務最初預計工時是10，coding了5小時後，任務完成了，剩餘工時為0，系統自動計算剩餘工時的話還是3小時。

3、某個任務最初預計工時是10，coding了5小時後，重新估算還要1小時就可完成。系統自動計算剩餘工時的話依舊是3小時。

或許你會反駁我，難道就不存在任務很完美的按預期開發並完成，最初預計與總消耗工時一致的情況嗎？有，這種理想狀況出現的頻率足以讓我們忽略掉它的存在。

還有個類似的問題：關於任務已消耗工時的自動更新。有不少童鞋說這個任務我coding了1天，已消耗工時就應該自動記為8小時呀。

錯！鬼才知道這一天你都coding了些什麼。

讓系統自動更新任務已消耗和剩餘工時，不僅是錯誤的認識，而且還會引發一些問題：

• 不能反映出任務的真實開發狀況，導致任務剩餘工時統計有誤。
• 項目進度和燃盡圖不能真實反映當前項目進展。禪道里項目進度（進度=項目任務總消耗工時/（項目任務總消耗工時+項目任務總剩餘工時））和燃盡圖都是通過統計任務的剩餘工時來繪製的。
• 錯誤的數據讓項目經理對項目全局的掌控有偏差，對項目的調整和決策出現失誤。進而會導致出現項目延期，人員分工不合理，沒有測試就匆忙發布，交付的產品Bug頻出等一系列問題。

所以嚴格按照任務開發實際狀況記錄工時是很有必要的，而不能簡單的讓系統自動計算掩蓋掉真實的數據。

關於任務工時更新，我比較推薦的做法：

• 最初預計工時在任務開始後，就不要再做修改。
• 開發人員每天及時更新任務狀態和工時。
• 更新任務工時，結合實際開發狀況重新估算剩餘工時並記錄。
• 允許任務的最初預計工時和總消耗工時存在偏差。任務完成後，二者對比以糾正自己的工時估算。

總結下來就是：及時更新，重新估算，真實填寫。

最後，簡短粗暴的回答：禪道里任務最初預計工時 ≠ 已經消耗工時 + 預計剩餘工時。