「為什么趕不出來(lái)？」

　　項(xiàng)目錯(cuò)過(guò)死線的時(shí)候，管理者總覺(jué)得就是開發(fā)團(tuán)隊(duì)的錯(cuò)。不過(guò)真的是開發(fā)者動(dòng)作太慢嗎？

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

　　有什么共通點(diǎn)？

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

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

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

　　進(jìn)度落后的原因？

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

　　需求不明

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

絕大多數(shù)的技術(shù)規(guī)格開出來(lái)時(shí)，沒(méi)經(jīng)過(guò)審慎思考，通常等到我們開始設(shè)計(jì)或開發(fā)，就會(huì)碰到一堆麻煩，因?yàn)楹芏嘁?guī)格都有漏洞。

— eagerMoose on Stack Exchange

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

使用 Sprintly 時(shí)，你得用這個(gè)格式來(lái)寫：我是一個(gè) ＿＿＿，我想要 ＿＿＿，所以 ＿＿＿。（要把事情做對(duì)）一定得這樣。

— Darren Rogan， the Hack and Heckle podcast

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

　　不斷變更需求

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

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

廠商：「我們現(xiàn)在想要把所有的墻都移開。」

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

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

　　最理想的情形是，你在過(guò)程中得到的點(diǎn)子，都該立刻紀(jì)錄下來(lái)，并考慮日后放進(jìn)更新。

[[154207]]

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

　　切換工作

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

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

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

　　開發(fā)主管不斷分心做其他事，導(dǎo)致他完成一項(xiàng)工作的時(shí)間要比其他人來(lái)得長(zhǎng)。

　　當(dāng)管理者讓開發(fā)人員中途切換到新工作，就會(huì)產(chǎn)生問(wèn)題，而如果工作時(shí)程一直在變，將讓團(tuán)隊(duì)付出重大代價(jià)。

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

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

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

　　擔(dān)起責(zé)任

　　管理者的工作就是提供一個(gè)環(huán)境，讓開發(fā)者能成功完成項(xiàng)目。在指責(zé)開發(fā)人員，要他們?yōu)檠舆t行程負(fù)責(zé)前，應(yīng)該先檢驗(yàn)?zāi)阕约骸?/p>

　　這里提供一些簡(jiǎn)單的步驟，可以檢查看看你有沒(méi)有拖累團(tuán)隊(duì)：

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

　　2、設(shè)計(jì)使用者情境要有明確規(guī)范。每項(xiàng)工作都使用同一個(gè)模板創(chuàng)造，除非充分?jǐn)⑹龉ぷ骷?xì)節(jié)，否則開發(fā)者都有不接這項(xiàng)工作的權(quán)利。

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

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