技術(shù)項目的失敗，屢見不鮮，不論你運營的是一個持續(xù)跟進(jìn)一些項目的軟件公司，還是一個需要顧問來為你提供系統(tǒng)集成的非技術(shù)公司，你都有可能遭遇這個問題。一個項目延期數(shù)年，超支數(shù)百萬，已經(jīng)不是新鮮事了。進(jìn)度延期、預(yù)算瘋漲、直至最后完全失敗，這在軟件世界非常普遍。
例如，在2003年，我飛去洛杉磯出席微軟為軟件開發(fā)者舉辦的其中一個會議?；顒又校④洶l(fā)表了激動人心的消息：下一個版本的windows將會帶 來一些革命性的新功能。回顧我的筆記，其中有一個新功能叫做WinFS。具體細(xì)節(jié)不講，簡單來說，WinFS建議將操作系統(tǒng)的文件系統(tǒng)功能(文件和文件夾 的位置信息)和數(shù)據(jù)庫功能(個人對文件的描述信息)合而為一，放進(jìn)一個又大又邪惡的“文件數(shù)據(jù)庫混合體”。
這是一個挺有野心的動作。從技術(shù)上來說，WinFS約等于重新安排一個國家的交通系統(tǒng)，以適應(yīng)會飛的汽車。是的，這樣會使航空公司停業(yè)。同樣，所有車庫也要變寬來適應(yīng)帶翼的車子。但先別想太遠(yuǎn)，還是讓這功能在一年或最多兩年內(nèi)面世再說吧。
三年過去了。一個叫Quentin Clark的微軟經(jīng)理在博客里說道，WinFS根本不能準(zhǔn)時面世，并且它阻礙了微軟推出其最新的操作系統(tǒng)。因此這個功能要延期，或者放到以后版本的數(shù)據(jù)庫 上，這意味著沒有了“將文件系統(tǒng)與數(shù)據(jù)庫系統(tǒng)合而為一”這唯一的亮點。有鑒于此，你怎么知道你某個技術(shù)項目哪一天會注定成為另一個WinFS?這里我有五 步指引來確證一個軟件的失?。?/span>
錯誤一：采用平庸的開發(fā)團(tuán)隊
軟件設(shè)計是有難度的，而且不幸的是，很多自稱程序員的人確實不能勝任軟件設(shè)計。盡管這是項目失敗的首要原因，你也不曾從官方的失敗報告中得知。在所 有的行業(yè)，軟件業(yè)，物流業(yè)，或者客服業(yè)，人們對同事的無能都太過寬容。你從來都不會聽到有人說“我們團(tuán)隊沒有足夠的智慧來完成這件事”。為什么要這樣傷人 的心呢?顯而易見的，如果這隊分得了任務(wù)的人員并不擅長這份工作，他們的工作會日復(fù)一日，日復(fù)一日……等等……但軟件卻沒有做出來。你也不用太擔(dān)心HR會 阻撓你招聘一班廢物。在大多數(shù)的案例里，我向你保證，HR對此毫無建樹。
錯誤二：按周來定目標(biāo)
假設(shè)你想改造你的廚房。你請來的師傅已經(jīng)搞過很多廚房，而且不作詳細(xì)藍(lán)圖就能估算出這項工作的成本。但軟件開發(fā)者是在制造前所未有的東西。如果前所 已有，他賣張拷貝的光盤給你就行了。因此，粗略的估計是不可能的。他們需要在寫代碼之前做好詳盡的計劃。無論你是客戶還是開發(fā)經(jīng)理，你的責(zé)任就是確保開發(fā) 人員帶著詳盡計劃來開展工作。當(dāng)你向開發(fā)人員詢問計劃時，他們大多數(shù)人可能只會給你一份把進(jìn)度按周來劃分的時間表。這看似非常合理，但其實不然。如果你讓 軟件團(tuán)隊提交一份大粒度的時間表(大是指需要兩天以上的工作)，那么你可以認(rèn)定他們沒有考慮到所有需要實現(xiàn)的細(xì)節(jié)，而這些細(xì)節(jié)將會積累，導(dǎo)致延期。
錯誤三：為截止時間而談判
還有什么比按周劃分軟件項目更糟糕?就是要求團(tuán)隊承諾大大地提早完成工作。根據(jù)我的經(jīng)驗，大多數(shù)開發(fā)者都會樂觀地接受你的暗示并參與討價還價。然后你會得到一份友好的協(xié)定時間表，但卻無法按時執(zhí)行。
試想以下情況：海象媽媽會在懷孕15到16個月后，生出小海象。你可能會叫海象媽媽保證在15個月內(nèi)做到，而她也說沒問題。或者你說，“15個月? 瘋了吧?我們要在8個月內(nèi)生出”。當(dāng)然，這樣談判是無法促進(jìn)事成的，而且即使得到一份8個月的進(jìn)度表，我還是告訴你一個小秘密：這是不可能實現(xiàn)的。你可以 取得
一份11個月的時間表，但你還是要等15個月，因為小海象就是要15個月才能出產(chǎn)，有時甚至16個月。
錯誤四：均分任務(wù)
這里有一個破壞項目的好方法。列出人們需要做的所有工作，然后給重新均分給各人。如果Mary有太多的工作，就分一些給John。這聽起來完全合 理，使得你不會被質(zhì)疑。但我向你保證，時間一長肯定會出現(xiàn)問題。那是因為當(dāng)一個開發(fā)者去替代另一個時，我們有理由假設(shè)效率降為十分之一。John將會花費 無數(shù)小時去搞清楚Mary其實已經(jīng)熟悉的那部分代碼。而且John改bug也不及Mary快，因為Mary才了解所有的陷阱在哪里。