「為什么趕不出來？」

　　項目錯過死線的時候，管理者總覺得就是開發(fā)團隊的錯。不過真的是開發(fā)者動作太慢嗎？

　　項目管理服務 Sprintly 的產(chǎn)品行銷經(jīng)理， Justin Jackson 在部落格內(nèi)說，他們利用 Sprintly ，追蹤開發(fā)人員執(zhí)行各項工作的時間，并依種類和大小細分，得到了以下結(jié)論。

　　有什么共通點？

　　第一點就是，開發(fā)人員表現(xiàn)非常平均。根據(jù)軟件搜集的資料，75% 的開發(fā)周期都在 175 小時左右。

　　第二，在 ticket 開始前變數(shù)最大，這就是廠商開出規(guī)格和安排工作的時間，也就是當 ticket 從出現(xiàn)到安排作業(yè)所需的時間。這個階段浪費了很多時間。

　　第三，從「完成」轉(zhuǎn)換到「測試完并準備好分配」對團隊而言也很困難。

　　進度落后的原因？

　　如果不是你的開發(fā)人員特別慢，那為什么開發(fā)會逾期？答案可能是：你的流程有問題。

　　需求不明

　　確定技術規(guī)格很重要。如果開發(fā)者不懂一項功能的目的，那他要怎么開發(fā)這功能？

絕大多數(shù)的技術規(guī)格開出來時，沒經(jīng)過審慎思考，通常等到我們開始設計或開發(fā)，就會碰到一堆麻煩，因為很多規(guī)格都有漏洞。

— eagerMoose on Stack Exchange

　　廠商太常開出自己沒仔細想過的功能，所以開發(fā)者一定要去了解，為什么使用者需要這個功能、這個功能是做什么的、要怎么用。你可以用固定的格式來描述使用者情境。

使用 Sprintly 時，你得用這個格式來寫：我是一個 ＿＿＿，我想要 ＿＿＿，所以 ＿＿＿。（要把事情做對）一定得這樣。

— Darren Rogan， the Hack and Heckle podcast

　　這個形式為特定功能設定了方向，也維持小規(guī)模的情境設定，不會過度展開。

　　不斷變更需求

　　開發(fā)者第二大抱怨主因就是，項目開始后，不停變動的技術規(guī)格。Hacker News 的一位使用者形容得很貼切：

開發(fā)者：「我們把屋頂和墻都裝好了！」

廠商：「我們現(xiàn)在想要把所有的墻都移開?！?/p>

　　這大部分是安排工作前沒有好好規(guī)劃功能，所產(chǎn)生的債務。

　　避免在流程中途變更需求的方法之一，就是在真正開始開發(fā)前，先做互動模擬。我們用靈活的方式工作，不代表我們可以隨時變更規(guī)模。

　　最理想的情形是，你在過程中得到的點子，都該立刻紀錄下來，并考慮日后放進更新。

[[154207]]

　　另一個防止變更需求及規(guī)模的方法就是盡可能預測進度。Sprintly 內(nèi)有項功能，就是根據(jù)進度，預測完成一項功能還須多少天。

　　切換工作

　　Justin Jackson 提到，流程中最后一塊絆腳石，大概就是工作的切換，而這可能有以下幾種常見形式：

1. 開發(fā)者已經(jīng)完成 A 工作的一半，此時你走到他的辦公桌旁，要求他切換到 B 工作。
2. 開發(fā)者已經(jīng)完成 A 工作的一半，此時你走到他的辦公桌旁，要求他同時處理 B 工作。

　　舉例來說，Sprintly 的開發(fā)主管時常需要檢查代碼、幫員工分組、開會、緊急狀況出來救火。

　　開發(fā)主管不斷分心做其他事，導致他完成一項工作的時間要比其他人來得長。

　　當管理者讓開發(fā)人員中途切換到新工作，就會產(chǎn)生問題，而如果工作時程一直在變，將讓團隊付出重大代價。

　　Stack Overflow 的 CEO，Trello 共同創(chuàng)辦人 Joel Spolsky ，也在部落格中提到切換工作的傷害：

從這些事件中你會學到，別讓人同時處理兩件工作，并確定他們清楚工作內(nèi)容。

優(yōu)秀的管理者會承擔責任，替人移除障礙，讓他們專心于一件工作并完成它。若有緊急事態(tài)，在打擾全心沉浸于項目的工程師前，先看看你能不能自己處理。

　　擔起責任

　　管理者的工作就是提供一個環(huán)境，讓開發(fā)者能成功完成項目。在指責開發(fā)人員，要他們?yōu)檠舆t行程負責前，應該先檢驗你自己。

　　這里提供一些簡單的步驟，可以檢查看看你有沒有拖累團隊：

　　1、讓你的團隊了解目標：和你的團隊一起定義，如何讓使用者的生活更好，搞清楚使用者需要的結(jié)果。讓開發(fā)者接受與否很重要，對功能的熱情程度，會大大影響開發(fā)速度。

　　2、設計使用者情境要有明確規(guī)范。每項工作都使用同一個模板創(chuàng)造，除非充分敘述工作細節(jié)，否則開發(fā)者都有不接這項工作的權(quán)利。

　　3、減少切換工作成本，不要打擾你的開發(fā)者！寄 email 或提出任何要求前，先衡量一下對生產(chǎn)力造成的影響。

　　重點是，怪罪開發(fā)人員「太慢」前請三思，很有可能是你的工作流程拖累了他們。