#30：開發(fā)者畫蛇添足

開發(fā)者會被新科技所吸引，有時會想要在項目開發(fā)中嘗試一些新的特性，或者參照別的程序里的組件，自己寫出它的實現(xiàn)，即使項目沒有這樣要求。這些設計、實現(xiàn)、測試、撰寫文檔的經(jīng)歷都是不需要的，且會增長項目進度。

#31：來回推搡的談判

有一種奇怪的談判策略，管理者在確認了進度上的失誤后，即沒有按時完成任務，在進度更改后又加上新的任務。這樣做的理由耐人尋味，因為確認了進度上失誤的這個管理者也表示承認了項目進度是有錯誤的。但是當項目進度重新調(diào)整正確后，同一個人又用明顯的舉動將其再一次搞錯。這無疑將拖延開發(fā)進度。

#32：以研究為中心的項目開發(fā)

Cray超級計算的設計師Seymour Cray說，他從來沒有試圖過同時跨越兩個領域進行開發(fā)，因為那樣做風險太高了（Gilb 1988）。許多軟件項目開發(fā)人員可以從Cray那里好好學一學。如果你的項目著眼于研究出新的算法或?qū)嵺`方式，那你不是在進行軟件開發(fā)，你是在做軟件研究。軟件開發(fā)進度是可預測的，而軟件研究的進度即使從理論上講也是不可測的。

如果你的產(chǎn)品目標中包括了研究出新的算法、提高速度、內(nèi)存使用等，那你得預見項目進度是非常不確定的。如果你的項目中還有其他弱點，如人員的短缺，人員資歷不足，模糊的需求，于承包人之間不穩(wěn)定的接洽，那把項目進度扔到窗外去吧。如果你真的想要完成那些研究，那不要期望進度會很快！

技術

剩下的經(jīng)典錯誤是和現(xiàn)代技術的使用和誤用有關的。

#33：銀彈綜合癥

在案例分析中，人們把太多的期望寄托在所謂的新技術中（報告生成器，面向?qū)ο缶幊�，C++），而它們是否能在此項目中發(fā)揮效用還不得而知。當項目開發(fā)團隊決定使用一種新的方法或技術，其他它能解決目前所面臨的問題時，他們一定會非常失望（Jones 1994）。

#34：對新工具和方法太過猶豫

在技術革新時，組織很少會大幅度提高他們的產(chǎn)能，不管他們引進了多少先進的技術。先進的技術所帶來的好處基本上不在他們的學習范圍之內(nèi)，而要學 習這些新的技術以發(fā)揮其大效能是需要花費時間的。新的技術同時會包含新的風險，只有使用后才會發(fā)現(xiàn)。人們寧愿使用慢速的穩(wěn)定的提高，而不是經(jīng)歷起伏過大 的收獲。案例分析3-1中的開發(fā)團隊應該已經(jīng)計劃到使用了新技術后會使產(chǎn)能提高10%，而不是樂觀的相信這會使開發(fā)速度提高一倍。

有一個特例，當在使用過去項目的代碼時，這種猶豫會更加明顯，但時間的節(jié)省并沒有想像中的多。

#35：在項目開發(fā)過程中更換工具

這是一種慣常的備用手段但很少奏效。有時這對于相同產(chǎn)品線內(nèi)的升級會有效，如3.0版、3.1版甚至4.0版。但其中的因為使用新工具而產(chǎn)生的學習時間、重復勞動和不可避免的錯誤往往會抵消掉在項目中途更換工具的好處。

#36：缺少自動化的源代碼控制

不進行自動化的源代碼控制會使關鍵項目遭 受不必要的風險。如果沒有它，當兩個程序員在開發(fā)同一個部件時，他們需要進行手工整合。他們也許會達成約定，把修改好的文件存入一個主文件夾，并在修改 時注意查看文件時間信息。但是有些人總是會覆蓋他人的工作。當人們用過時的結構來編寫程序，在發(fā)現(xiàn)之后又必須進行重寫。當用戶舉報程序的錯誤時間，你不 能重新編譯項目。源代碼平均每個月要更改10%，而手工的源代碼控制是跟不上的。