進度落后不是開發者的錯，工作流程可能才是兇手！
「為什么趕不出來？」
項目錯過死線的時候，管理者總覺得就是開發團隊的錯。不過真的是開發者動作太慢嗎？
項目管理服務 Sprintly 的產品行銷經理， Justin Jackson 在部落格內說，他們利用 Sprintly ，追蹤開發人員執行各項工作的時間，并依種類和大小細分，得到了以下結論。
有什么共通點？
第一點就是，開發人員表現非常平均。根據軟件搜集的資料，75% 的開發周期都在 175 小時左右。
第二，在 ticket 開始前變數最大，這就是廠商開出規格和安排工作的時間，也就是當 ticket 從出現到安排作業所需的時間。這個階段浪費了很多時間。
第三，從「完成」轉換到「測試完并準備好分配」對團隊而言也很困難。
進度落后的原因？
如果不是你的開發人員特別慢，那為什么開發會逾期？答案可能是：你的流程有問題。
需求不明
確定技術規格很重要。如果開發者不懂一項功能的目的，那他要怎么開發這功能？
絕大多數的技術規格開出來時，沒經過審慎思考，通常等到我們開始設計或開發，就會碰到一堆麻煩，因為很多規格都有漏洞。
— eagerMoose on Stack Exchange
廠商太常開出自己沒仔細想過的功能，所以開發者一定要去了解，為什么使用者需要這個功能、這個功能是做什么的、要怎么用。你可以用固定的格式來描述使用者情境。
使用 Sprintly 時，你得用這個格式來寫：我是一個 ＿＿＿，我想要 ＿＿＿，所以 ＿＿＿。（要把事情做對）一定得這樣。
— Darren Rogan， the Hack and Heckle podcast
這個形式為特定功能設定了方向，也維持小規模的情境設定，不會過度展開。
不斷變更需求
開發者第二大抱怨主因就是，項目開始后，不停變動的技術規格。Hacker News 的一位使用者形容得很貼切：
開發者：「我們把屋頂和墻都裝好了！」
廠商：「我們現在想要把所有的墻都移開。」
這大部分是安排工作前沒有好好規劃功能，所產生的債務。
避免在流程中途變更需求的方法之一，就是在真正開始開發前，先做互動模擬。我們用靈活的方式工作，不代表我們可以隨時變更規模。
最理想的情形是，你在過程中得到的點子，都該立刻紀錄下來，并考慮日后放進更新。
另一個防止變更需求及規模的方法就是盡可能預測進度。Sprintly 內有項功能，就是根據進度，預測完成一項功能還須多少天。
切換工作
Justin Jackson 提到，流程中最后一塊絆腳石，大概就是工作的切換，而這可能有以下幾種常見形式：
- 開發者已經完成 A 工作的一半，此時你走到他的辦公桌旁，要求他切換到 B 工作。
- 開發者已經完成 A 工作的一半，此時你走到他的辦公桌旁，要求他同時處理 B 工作。
舉例來說，Sprintly 的開發主管時常需要檢查代碼、幫員工分組、開會、緊急狀況出來救火。
開發主管不斷分心做其他事，導致他完成一項工作的時間要比其他人來得長。
當管理者讓開發人員中途切換到新工作，就會產生問題，而如果工作時程一直在變，將讓團隊付出重大代價。
Stack Overflow 的 CEO，Trello 共同創辦人 Joel Spolsky ，也在部落格中提到切換工作的傷害：
從這些事件中你會學到，別讓人同時處理兩件工作，并確定他們清楚工作內容。
優秀的管理者會承擔責任，替人移除障礙，讓他們專心于一件工作并完成它。若有緊急事態，在打擾全心沉浸于項目的工程師前，先看看你能不能自己處理。
擔起責任
管理者的工作就是提供一個環境，讓開發者能成功完成項目。在指責開發人員，要他們為延遲行程負責前，應該先檢驗你自己。
這里提供一些簡單的步驟，可以檢查看看你有沒有拖累團隊：
1、讓你的團隊了解目標：和你的團隊一起定義，如何讓使用者的生活更好，搞清楚使用者需要的結果。讓開發者接受與否很重要，對功能的熱情程度，會大大影響開發速度。
2、設計使用者情境要有明確規范。每項工作都使用同一個模板創造，除非充分敘述工作細節，否則開發者都有不接這項工作的權利。
3、減少切換工作成本，不要打擾你的開發者！寄 email 或提出任何要求前，先衡量一下對生產力造成的影響。
重點是，怪罪開發人員「太慢」前請三思，很有可能是你的工作流程拖累了他們。