最近有個 Tweet，說項目延誤時，如果同時又有很多人插手會使事情變得更糟糕。大多數(shù)團隊碰上截止期限都會干三件蠢事兒：1、雇傭更多開發(fā)人員。2、抄近路。3、工作更長時間——— jasongorman

這自然就產(chǎn)生了個問題：如何拯救即將延誤的項目？

其實，首先，最困難的問題，就是我們也許無法拯救即將延誤的項目。所以，我不得不重新考慮策略，只有兩種方式我們可以考慮：

1. 延期到一切準備妥當(dāng)
2. 先把做好的展示出來

現(xiàn)在不是討論團隊如何和自己的消費者周旋，當(dāng)我說 “少提供點兒”，我指的是少做些 “程序”——程序多不代表有價值，多關(guān)注用戶核心需求才是正事兒，其實就是別把一開始準備的那成堆功能遞出來。

這個過程差不多就是：“房子無法按期完成，但是你能如期入住。”

如果你做的是?敏捷軟件開發(fā)，估計現(xiàn)在已經(jīng)發(fā)生了。如果還沒發(fā)生，說明你恐怕做的不是?敏捷軟件開發(fā)。

解決方法就是要求我們知道最終目標(biāo)也許跟程序無關(guān)。你得把關(guān)注重點從展示功能轉(zhuǎn)移到解決問題。然后你就能給自己帶來設(shè)計的空間。在有限時間里更多選擇能夠成為解決問題的有效方式。

當(dāng)我臨危受任時，我首先做的就是停下手頭一切，退一步問自己：“我們走到這兒到底想要什么？有沒有更簡單的方式？” 所以準備隨時去掉設(shè)計和計劃。在我個人拯救瀕死項目的經(jīng)歷中，這是關(guān)鍵。面對客戶，準備些充分又坦率的對話。

但是，從 Tweet 的那三項注意事項里，我們能得到什么啟發(fā)？甚至讓項目時間延期。

雇傭開發(fā)人員早已被證明只會讓事情變得更糟

在 Fred Brook 在圖書 The Mythical Man-Month 中對雇傭過多開發(fā)人員會加劇問題做了細致的原因闡述。我相信任何軟件開發(fā)者和軟件開發(fā)項目經(jīng)理都該讀讀。

做著糟糕產(chǎn)品的開發(fā)人員現(xiàn)在轉(zhuǎn)變?nèi)ゴ叽僦碌拈_發(fā)人員。這就像讓最有效的銷售人員充當(dāng)管理角色，結(jié)果就是看著銷售量直線下降!

想要指標(biāo)數(shù)值激增，最重要的就是團隊內(nèi)部都知曉每個人正在做什么，可悲的是，這在軟件開發(fā)中是必要的，因為聯(lián)系是普遍存在的——最需要進行斗爭的就是失去最具生產(chǎn)力身居要職的開發(fā)者和大體量團隊效益的迅速遞減。

因此，最簡單的建議是別去做。不管你如何想要，或者承受上級多大的壓力，千萬不要這樣做。

但如果隊伍已經(jīng)很龐大了呢?如果未完成任務(wù)的原因是因為團隊開銷拖你的后腿?在這里，你可能不得不做出非常困難的決定，把相關(guān)人員轉(zhuǎn)移到其他項目——或把擋在路中間的無關(guān)人等放一邊，再不行最后只能辭退一些員工。

如果你有點兒頭重腳輕，或有太多實習(xí)生，有可能能承受這種打擊。另一方面，假設(shè)有 3 個建筑師、 2 個項目經(jīng)理、 6 個技術(shù)大神、4 個業(yè)務(wù)分析師、 30 名開發(fā)者和 10 名測試人員——就我個人而言，很多的人正在享受實際工作福利。他們抱著酬勞，很多人很高的酬勞，但只是不為團隊帶來一點兒價值。你付錢去讓他們拖累你。我們都知道，但很少有人敢說出來。

在團隊顯然太臃腫的情況下，當(dāng)你想要提供客戶需要的有價值的東西，只有精簡團隊，否則幾乎不可能。

雇傭、重新分配或解雇這類有風(fēng)險的決定通常不是我們這些人能夠決定的，不過這種情況還是得有人先打頭哨。在這些情況下，默認行為是完全知情還選擇失敗。其實，這也是為團隊好。

抄近路是經(jīng)典錯誤，只要我們知道雇傭更多開發(fā)人員只會讓事情變得更糟，我們更得知道犧牲質(zhì)量只會拖慢我們未來的發(fā)展。

原因很簡單，證據(jù)確鑿如就像活生生的喜馬拉雅山脈。解決 Bugs 的時間越長，就會花費成倍的時間和金錢。前期不注重測試和實驗，未來修復(fù) bug 就需要 10-100 倍的時間，不如早些解決，免得下游海嘯發(fā)生為時已晚。

你可以讓團隊專注”code-and-fix”發(fā)展進程，不用在意 bug 列表的大小，而把大量時間和精力用于”穩(wěn)定”應(yīng)用軟件，做好投放市場的準備。我目睹過圈子里幾個月周而復(fù)始寫代碼，只為使其足夠好到可以應(yīng)用。

所以內(nèi)行都知道當(dāng)團隊或計劃延誤了，就需要更嚴格地做更多測試。是的，現(xiàn)在才剛剛開始，但之后你會節(jié)省 10-100 倍的精力。

當(dāng)然，軟件開發(fā)中沒有銀彈。但當(dāng)你想讓團隊走上正軌時，我見過最管用的方式是創(chuàng)建快速自動運行的測試機制。它可以完全改變前景。

同樣討論到Specification By Example ，我們認為用戶需求會產(chǎn)生革命性的影響。你會驚訝當(dāng)你向別人詢問具體例子來闡明他們需求的這種行為會產(chǎn)生多少誤解。用可執(zhí)行驗收測試認清用戶需求花費幾個小時可以防止你接下來一周內(nèi)不必要的返工。

代碼的可維護性也是一樣。因為對代碼的簡易性和容易改變 (不可攻破) 思慮 不周或少了關(guān)心，其未來的護理成本比想象中來得快，來得讓人心疼。我發(fā)現(xiàn)自己早上寫的代碼阻礙了我下午的進程。

打高爾夫球時，要想更快獲取高分關(guān)鍵是不要太在意進了多少桿。

這對團隊工作人員和管理人員都是很難的。眾所周知的神話定律——用更多時間來做更高質(zhì)量的應(yīng)用軟件，還是存在的。最需要學(xué)習(xí)的新技能是學(xué)會如何預(yù)防缺陷和做”干凈代碼”。如果團隊沒有在規(guī)則和演習(xí)中準備好 “向上加速”，那么，說真的，你可能覺得別扭，因為你已經(jīng)有幾個月 (可能幾年) 都不知道如何學(xué)習(xí)了。

想要知道一個團隊是否具備基本技能，捫心自問，為什么這些還沒有做？如果答案是”老板不讓我們做”,那么另一個隱患的種子就埋下了。我的個人經(jīng)驗，也是從別人的遭遇得到的忠告，最好不要出現(xiàn)上述對話。否則，那意味著團隊已經(jīng)迷失了。想要事事順心可不容易。然而，如果讓管理者和消費者在功能和質(zhì)量間選擇，他們中間 99%的人都會投”功能”否決票。除此之外，選擇犧牲質(zhì)量也會降低功能性。事實上讓團隊在這兩種感知沖突中做出選擇本身就意味著失敗。

所以當(dāng)程序發(fā)布時間臨近，切不可在質(zhì)量上讓步。最好的方式就是不要在團隊以外討論這個問題。舉個例子，要是你做驅(qū)動開發(fā)測試 (TDD)，這就是能起作用的方式。就像用文本編輯器一樣。上次你向老大要求使用文本編輯器是什么時候？

當(dāng)計劃出現(xiàn)紕漏時，你更應(yīng)該在質(zhì)量上下狠功夫。如果你在初期階段，尤其是初次嘗試；如果你每天都在建設(shè)和測試，甚至每小時；如果你平均投入?20 分鐘與客戶討論一個用戶故事，花一個小時和同意可執(zhí)行的測試，包括所有您能想到的邊緣情況；如果你為了集中做單元測試，10 行代碼平均一個單元測試；如果你平均在每個迭代中進行團隊代碼審查，做每次提交之前進行同行代碼審查，等等。

最后，工作更長時間——就我們在上世紀進行的調(diào)查顯示，這是不穩(wěn)固的，還會傷害團隊和計劃，一個錯誤的經(jīng)濟體?；氐胶嗬Ｌ啬莻€時代，就是他把工廠工人工時從一周 50 個小時降至 40 小時的那時候。我們有更多需要做，我們得讓工作有效率，產(chǎn)生有用的輸出。

程序開發(fā)尤其易受影響，當(dāng)我們把團隊置于”危機模式”。程序開發(fā)需要注意力和清晰度，而注意力、清晰度是需要經(jīng)常補充的易腐貨物。從我自己的團隊實驗中，發(fā)現(xiàn)開發(fā)人員平均一天 4 小時就是極致，8 小時算多的，要是比 12 小時還多會怎樣？

有些人會說”在短期內(nèi)是可行的”,但我至今沒發(fā)現(xiàn)任何有力證據(jù)可以證明這是可行的。也許裝配線工人可以為了多輪幾班，但軟件開發(fā)不是這樣的。

我們非常容易被生產(chǎn)力的錯覺影響，我覺得這解釋了 “短期內(nèi)是有用的” 的說法。當(dāng)然，感覺好像什么都沒完成。那時我們不知道在前進道路上犯下的錯誤產(chǎn)生了多么嚴重的下游后果。一天八小時工作時我才意識到，越是客觀地管控，越是犯更多錯。所以，我提前學(xué)到一招能給同樣境遇團隊帶來好處的方法。在你從 “流動區(qū)” 去往 “責(zé)任” 區(qū)的路上，學(xué)會認知。

所以，我對團隊超時工作處于零容忍，甚至短期之計也不行。

是的，對管理層來說這是很難的。并且許多開發(fā)者還因為自己生產(chǎn)力的錯覺眉飛色舞呢?，F(xiàn)在真是箭在弦上，每個人都瘋狂地火力全開，晚上 5、6 點安靜地從工作桌前站起來，回家。確實，這是目前我發(fā)現(xiàn)唯一你能做的。

同樣，最重要的是更加集中注意力，并隨時保持最近更新狀態(tài)。學(xué)會休息，學(xué)會來頓輕食午餐（最好不要有太多讓你昏昏欲睡的碳水化合物）。要把格外勤奮放在合理的時間，找到工作與生活的平衡點。

然后在別人才會注意到你在辦公桌前的成績而不是花費多少時間在公司。有件事一直很討厭，就是很多組織都在倡導(dǎo)長時間的工時。然后在會議和非正常工作環(huán)境，如開放的辦公室等無意義干擾下歡快地燃燒。我企圖在兩者之間發(fā)現(xiàn)強烈的關(guān)聯(lián)性。想做更多？注重工作環(huán)境而不是工作時長。

所以接下來給了你一個總結(jié)，用來提升你在發(fā)布日期推出產(chǎn)品的成功率：

1. 管理好你的產(chǎn)品預(yù)期和什么時候推出。簡化產(chǎn)品，簡化方案。專注最終目標(biāo)，而不是賺多少。
2. 抵制住雇傭更多開發(fā)者的誘惑。如果你的團隊已經(jīng)很龐大了，這將是個艱難的轉(zhuǎn)變。
3. 撥通質(zhì)量專線，專注不可攻破的質(zhì)量。
4. 工作時間少些，多休息。不要把注意力放在花費多少時間，而要注重效率，把前進路上的障礙都移除，比如不利的工作氛圍。當(dāng)然，為了安全起見，大多數(shù)團隊不敢去嘗試。說起來容易，做起來難?，F(xiàn)實中，要想實現(xiàn)這一切需要有股堅定的領(lǐng)導(dǎo)力形成具有凝聚力的團隊來促成這一切發(fā)生。
5. 有力且有技巧的領(lǐng)導(dǎo)力

這并不一定意味著其他人都跟我一樣有自信這樣與團隊斗爭（雖然我已經(jīng)做了很多次）。但不知何故，從內(nèi)部深處，團隊需要在關(guān)鍵問題上找到這個實力和自信，如范圍、期限、團隊規(guī)模、工作時間、辦公環(huán)境等。這讓你對發(fā)布產(chǎn)品產(chǎn)生責(zé)任感：如果這必須奏效，想要成為巨擘就必須謹記伴隨而來的責(zé)任。

祝你好運！

作者@孫應(yīng)然 ? ?文章來源@36氪

本文編譯自：codemanship.co.uk