有一些低效率的管理實 踐操作仍被許多人采用，造成了完全可以預期的不好的結果，這些實踐操作被稱為“經典錯誤”。大多數“經典錯誤”都有一個具有誘惑力的外表。你需要拯救一 個落后于進度的項目嗎？那增加人手吧。你想減少日程安排嗎？那把日程安排得更緊一些吧。團隊中的一個關鍵人物激怒了其余隊員？那在項目結束后炒他魷 魚吧。你有一個很緊急的項目要完成？那把目前所有可用的人力資源召集起來開始工作吧，越快越好！
開發者、管理人員和顧客通常會有很好的理由來解釋自己的所作所為，所以這些“經典錯誤”的具有誘惑力的外表也是解釋為什么會再三犯下這類錯誤的原因。但是，由于“經典錯誤”已經發生過很多次了，因此它的結果是可以預期的，這些結果顯然會和人們原來希望得到的結果不一致。
本章列舉了36個“經典錯誤”，每個錯誤我本人至少見過一次，而且有許多是我自己也犯過的。你會從案例分析3-1中識別出這些錯誤。
這些錯誤的共性在于，如果你想避免它們，那么你的軟件項目肯定不能開發得很快。但如果你不去避免他們，你注定會開發得很慢。
如果有些錯誤看起來很熟悉，好像自己也犯過，不用擔心，振作起來。因為有許多人犯過相同的錯誤，而且一旦你了解了這些錯誤給你的開發速度所帶來的影響，你可以在制訂計劃的時候進行風險控制。
有些錯誤會在本書的相應章節中進行討論，有些則不會進一步討論。為了便于查閱，這些“經典錯誤”被分類成了人員、過程、產品、技術等四個方面。
人員
這里是一些與人員有關的經典錯誤。
#1：不確定的激勵措施
無數的調查研究表明，激勵很可能是提高產品產量和質量的有效的措施（Boehm 1981）。在案例分析3-1中，在管理的實施中充斥著不確定的激勵措施。開頭是一番虛情假意的激勵性談話，中間是要求員加班加點地工作，后管理者去享受了一個長假，而員工卻要在假期中繼續工作，為的只是那些少得可憐的額外獎勵。
#2：糟糕的人事管理
在激勵之后，對產品產量有巨大影響的不是由團隊隊員個人的能力決定是由隊員之間的關系所決定（Boehm 1981， Lakhanpal 1993）。招募那些資歷差的員工將會威脅到企業為快速發展所付出的努力。在那個案例分析中，人事選拔的標準是誰能快被找到，誰被錄取，而不是根據 誰的能力強來作為標準。這種做法雖然使項目迅速地開展，但不能快速地完成。
#3：不受控制的問題員工
不處理好問題員工同樣會影響工作速度。這類錯誤在Geral Weinberg于1971年出版了《計算機編程心理學》一書后被管理者 普遍理解。不處理好問題員工往往是團隊隊員抱怨他們的領導的普遍的原因（Larson and LaFasto 1989）。在案例分析3-1中，整個團隊都知道Chip這個人不是什么好東西，但團隊領導卻視而不見。其結果——重新完成Chip的工作——可以預見 了。
#4：英雄主義
有些軟件開發者認為，在項目開發中強調英雄主義是非常重要的，認為英雄主義是非常有益的（Bach 1995）。但是我認為，以任何一種形式來強調英雄主義，其壞處往往要比好處多。在案例分析中，中層管理者 對那些認為只要能做能做成功的人給予了更高的獎勵，而那些講究穩定、長效的工作人員卻得到了較低的獎勵。其結果是工作中實行的邊緣政策直到后一分鐘 才發現、認識了組織所面臨的緊急的問題，并向上級報告。一個小的開發團隊掌握了公司的生殺大權，因為他們不愿意承認不能按期完成任務。對英雄主義的強調促 進了冒極大風險的趨勢，而削弱了在軟件開發的過程中，利益相關者之間的合作。
當有些管理者 過分強調“能做能成功”的態度時會產生強調英雄主義的行為。當項目管理者視這種態度高于的狀態報告時，他們會不完全發揮自己的能力地去采取正確 措施。他們甚至不認為自己需要采取正確措施，直到損失已經造成了。正如Tom Demarco所說，“能做能成功”的態度將原本只是很小的障礙放大成一場真真正正的災難。
#5：向即將到期的項目追加人手
這也許是常見的“經典錯誤”了。當一個項目落后與進度時，不在現有隊員中下功夫，而是以增加人手的方式來提高產量。Fred Brooks把這種行為比做“火上澆油”（Brooks 1975）。
#6：吵鬧、擁擠的辦公室
多數開發者對自己的工作環境是不滿意的。約60%的人認為他們的工作環境不是不夠安靜是不夠私人化（DeMarco and Lister 1987）。擁有安靜、私人的工作場所的工作人員會比那些處在吵鬧、擁擠的地方的人要表現得更為出色。吵鬧、擁擠的環境會拖延工作日程。
#7：開發者與顧客之間的沖突
這種沖突可以是來自多方面的。當開發者不愿意簽定顧客制定的項目進度表時，或者開發者沒有履行好他們的承諾時，顧客可能會認為開發者不夠合作。而開發者可能會認為顧客過于無理地堅持不現實的項目進度或修改明明已經確定下來的要求。于是這兩撥人之間可能發生人身攻擊或誹謗。
這種沖突的主要的影響是使交流和溝通變得匱乏，其中又包含了對需求的缺乏理解，用戶界面設計不夠理想，更糟糕的情況則是顧客拒絕接受已經完成的產品。平均地來說，顧客和軟件開發者之間的沖突往往會嚴重到雙方要撕毀合同取消項目的開發（Jones 1994）。這種沖突是非常耗時的，而且會把雙方的精力從真正的工作中吸引出來。
