項目延期是不曾變緩的滑坡

　　2010年我受邀參與一個團隊的交付過程，看看是否能夠幫上忙，做出一些改進。進入的時候大概是2月，當時團隊士氣還不錯，在長達6個月以上的開發之后，3月份很快團隊就面臨第一次上線了。然而技術上仍然存在若干問題，客戶方的IT技術設施似乎也沒有準備好。第一次上線毫無疑問的延期了。夏天到了，計劃中的第二次發布由于技術上遇到難以想象的挑戰，又延期了。秋天到了，情況沒有變得更好一些，由于發現技術上的挑戰，測試遇到了傳說中Bug不收斂的情況，QA完全沒有信心發布版本。冬天的時候似乎看見了曙光，技術負責人也放了狠話，說如果發布不了我就不干了。第二年春天，終于上線了;技術負責人也不干了，先后還有五六個團隊成員也離開了。

　　作為軟件項目而言，出現延期的原因可能千變萬化。計劃不合理固然是其中一方面，但一旦發布日期固定，那么剩下的事情就應該是全力以赴面對這個目標。一鼓作氣，再而衰，三而竭。戰場尚且如此，極端依賴智力勞動者全心投入的軟件開發行業更是如此。雖然團隊中有許多的方式能夠增加凝聚力，但最能夠激勵的，莫過于自己寫的代碼能夠被使用。處于某種原因延期，帶來的不僅僅后推的日程，還有開始懈怠的斗志。

　　如同病毒一樣，延期會傳染。一旦接受了延期的理由，同樣的理由可能不被繼續使用，但其他的理由會突然冒出來，目的只有一個，無法在目標日期完成。09年我參與了一個超級復雜的電信電子商務網站，也經歷了延期。第一次是因為服務器通過海運需要28天……第二次是單點登錄集成花費了遠超想象的時候。到第三次的時候，無論如何都應該上線了，結果商務上出現了別的問題沒有上線。

　　這些真的是阻止上線的原因嗎?除了服務器原因之外，現在想來，單點登錄真的并非是非要不可的特性。通過改善之后的網站吸引流量，重拾用戶信心，似乎更重要一些。然而，真實情況是，一旦延期成為一個可以接受的理由——也許所有人并不承認這一點——那么其他的原因，會被以各種合理的方式加進來，造成一次又一次的延期。于是，延期就像不曾變緩的滑坡，交付就像輪子，越來越快的，滑向無法交付的深淵。

　　在開發行易產品的時候，我設定了一個時間：7月15日，也就是下周一。越靠近這個日子，想要在這個日子發布越發顯得越艱難。我們甚至在本周一，也就是上線的前一周決定將整個網站設計全部改掉。設計師在嘀咕，程序員們也在嘀咕，我自己也在嘀咕：7月15號上線，可能嗎?

　　然而卻看到了設定明確日期的情況下，做決策顯得更加的注重實效。我們清楚的知道上線并非意味著結束，只是開始。那么哪些特性應該包含在這個發布中，哪些可在稍后調整?當你只有幾天時間剩下的時候，答案往往是不言而喻的。

　　離7月15日還有兩天。我們真的能發布嗎?我自己也想知道答案。

原文轉自：http://www.kjueaiud.com