技術專案走向失敗的五條“捷徑”

　　技術專案的失敗，屢見不鮮。不論你運營的是一個持續跟進一些專案的軟體公司，還是一個需要顧問來為你提供系統整合的非技術公司，你都有可能遭遇這個問題。進度延期、預算瘋漲、直至最後完全失敗，這在軟體世界非常普遍。事實上，一個專案延期數年，超支數百萬，已經不是新鮮事了。

　　例如，在2003年，我飛去洛杉磯出席微軟為軟體開發者舉辦的其中一個會議。活動中，微軟發表了激動人心的訊息：下一個版本的windows將會帶來一些革命性的新功能。回顧我的筆記，其中有一個新功能叫做WinFS。具體細節不講，簡單來說，WinFS建議將作業系統的檔案系統功能（檔案和資料夾的位置資訊）和資料庫功能（個人對檔案的描述資訊）合而為一，放進一個又大又邪惡的“檔案資料庫混合體”。

　　這是一個挺有野心的動作。從技術上來說，WinFS約等於重新安排一個國家的交通系統，以適應會飛的汽車。是的，這樣會使航空公司停業。同樣，所有車庫也要變寬來適應帶翼的車子。但先別想太遠，還是讓這功能在一年或最多兩年內面世再說吧。

　　三年過去了。一個叫Quentin Clark的微軟經理在部落格裡說道，WinFS根本不能準時面世，並且它阻礙了微軟推出其最新的作業系統。因此這個功能要延期，或者放到以後版本的資料庫上，這意味著沒有了“將檔案系統與資料庫系統合而為一”這唯一的亮點。有鑑於此，你怎麼知道你某個技術專案哪一天會註定成為另一個WinFS？這裡我有五步指引來確證一個軟體的失敗：

　　錯誤一：採用平庸的開發團隊

　　軟體設計是有難度的，而且不幸的是，很多自稱程式設計師的人確實不能勝任軟體設計。儘管這是專案失敗的首要原因，你也不曾從官方的失敗報告中得知。在所有的行業，軟體業，物流業，或者客服業，人們對同事的無能都太過寬容。你從來都不會聽到有人說“我們團隊沒有足夠的智慧來完成這件事”。為什麼要這樣傷人的心呢？顯而易見的，如果這隊分得了任務的人員並不擅長這份工作，他們的工作會日復一日，日復一日……等等……但軟體卻沒有做出來。你也不用太擔心HR會阻撓你招聘一班廢物。在大多數的案例裡，我向你保證，HR對此毫無建樹。

　　錯誤二：按周來定目標

　　假設你想改造你的廚房。你請來的師傅已經搞過很多廚房，而且不作詳細藍圖就能估算出這項工作的成本。但軟體開發者是在製造前所未有的東西。如果前所已有，他賣張拷貝的光碟給你就行了。因此，粗略的估計是不可能的。他們需要在寫程式碼之前做好詳盡的計劃。無論你是客戶還是開發經理，你的責任就是確保開發人員帶著詳盡計劃來開展工作。當你向開發人員詢問計劃時，他們大多數人可能只會給你一份把進度按周來劃分的時間表。這看似非常合理，但其實不然。如果你讓軟體團隊提交一份大粒度的時間表（大是指需要兩天以上的工作），那麼你可以認定他們沒有考慮到所有需要實現的細節，而這些細節將會積累，導致延期。

　　錯誤三：為截止時間而談判

　　還有什麼比按周劃分軟體專案更糟糕？就是要求團隊承諾大大地提早完成工作。根據我的經驗，大多數開發者都會樂觀地接受你的暗示並參與討價還價。然後你會得到一份友好的協定時間表，但卻無法按時執行。

　　試想以下情況：海象媽媽會在懷孕15到16個月後，生出小海象。你可能會叫海象媽媽保證在15個月內做到，而她也說沒問題。或者你說，“15個月？瘋了吧？我們要在8個月內生出”。當然，這樣談判是無法促進事成的，而且即使得到一份8個月的進度表，我還是告訴你一個小祕密：這是不可能實現的。你可以取得一份11個月的時間表，但你還是要等15個月，因為小海象就是要15個月才能出產，有時甚至16個月。

　　錯誤四：均分任務

　　這裡有一個破壞專案的好方法。列出人們需要做的所有工作，然後給重新均分給各人。如果Mary有太多的工作，就分一些給John。這聽起來完全合理，使得你不會被質疑。但我向你保證，時間一長肯定會出現問題。那是因為當一個開發者去替代另一個時，我們有理由假設效率降為十分之一。John將會花費無數小時去搞清楚Mary其實已經熟悉的那部分程式碼。而且John改bug也不及Mary快，因為Mary才瞭解所有的陷阱在哪裡。

　　錯誤五：工作到深夜

　　讓我們假設有個專案要每週工作40小時，連續六個月才能完成。如果你讓所有人每週工作60小時，那麼持續四個月就能完全搞定。軟體團隊可能甚至會接受這個挑戰，因為這使他們看上去像英雄（那個海象隊有多厲害？他們每個週末都來工作！）這能行的，是吧？再想想吧。有一部完整的文獻論述了“加班不會使軟體更快產出”。Edward Yourdon，作為軟體企業家和該文獻的作者，稱這種專案為“死亡行軍”。

　　軟體開發者花費大量的腦力勞動。即使是最好的程式設計師，也很少有能堅持幾小時以上的高強度腦力勞動。另外，他們還需要休息一下大腦。這就是為什麼你好像總能撞到他們在上網或玩遊戲。

　　強迫他們投入更長時間坐在電腦前，並不會轉化為更多的產出——即使會，那都將是劣質的產品。當軟體開發者的大腦完全發燒，他們幾乎做錯多過做對，寫出無法使用的程式碼，或者引入大量的bug。而如果你真的禁止他們上網，玩多人遊戲，強迫他們在正常的睡眠時間繼續寫程式碼，好吧，他們可能會開始離你而去。死亡行軍不是造成專案延期和預算爆炸的唯一條件，但絕對是充分條件。

　　如果以上是使你專案失敗的方法彙總，那麼怎樣做到萬無一失呢？首先，你要招聘一個巨星級人馬。在Fog Creek，對於一個全職崗位，我們傾向於稽核大約400個候選人。因為最優秀的開發者擁有十倍於“一般優秀”的創造力。

　　其次，讓開發者給出細粒度的時間預算。是的，讓開發者去預估製作一個新應用需要花多長時間，是不容易的（文章1、文章2）。這就是為什麼他們要在每個專案之前作出可靠的藍圖。

　　一旦你有時間表在手，不要嘗試提前截止日期。如果專案不能在你能諒解的時間內完成，解決方法不應是去交涉一個“好聽的”時間表，而應該是爭取更多資源，或者推遲上線，或者拿掉一些功能。

　　當專案正在進行時，你會多次被誘導而想重新分配工作。但你要謹慎地重分配。所換的新人需要花不少時間去駕馭原作者的程式碼。我覺得讓人員在不同崗位上輪換有助於消除不可替代性，但我是謹慎地安排這事，並且在時間表里加入額外的三週給新人以學習新程式碼，和額外的一週給舊人去教新人。

　　最後，鼓勵你的員工按合理的工時，一週幹40小時。我是說真的。除了偶爾為截止日期而衝刺，我們在Fog Creek都是一天8小時工作制。在技術的世界裡，應該將一個大專案看成是一次馬拉松，而非一次短跑。

　　注：Joel Spolsky是紐約市Fog Creek的聯合創始人兼CEO，並且是熱門部落格“Joel on software”的主人。英文原文最後更新於 2007 年 11 月 1 日。

　　原文連結： Joel Spolsky   翻譯： 伯樂線上 - unblock