「為什麼趕不出來？」
專案錯過死線的時候，管理者總覺得就是開發團隊的錯。不過真的是開發者動作太慢嗎？
專案管理服務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 ，也在部落格中提到切換工作的傷害：
“從這些事件中你會學到，別讓人同時處理兩件工作，並確定他們清楚工作內容。優秀的管理者會承擔責任，替人移除障礙，讓他們專心於一件工作並完成它。若有緊急事態，在打擾全心沉浸於專案的工程師前，先看看你能不能自己處理。”
擔起責任
管理者的工作就是提供一個環境，讓開發者能成功完成專案。在指責開發人員，要他們為延遲行程負責前，應該先檢驗你自己。
這裡提供一些簡單的步驟，可以檢檢視看你有沒有拖累團隊：
- 讓你的團隊瞭解目標：和你的團隊一起定義，如何讓使用者的生活更好，搞清楚使用者需要的結果。讓開發者接受與否很重要，對功能的熱情程度，會大大影響開發速度。
- 設計使用者情境要有明確規範。每項工作都使用同一個模板創造，除非充分敘述工作細節，否則開發者都有不接這項工作的權利。
- 減少切換工作成本，不要打擾你的開發者！寄email 或提出任何要求前，先衡量一下對生產力造成的影響。
重點是，怪罪開發人員「太慢」前請三思，很有可能是你的工作流程拖累了他們。