軟體開發專案管理中的“經典錯誤”

有一些低效率的管理實 踐操作仍被許多人採用，造成了完全可以預期的不好的結果，這些實踐操作就被稱為“經典錯誤”。大多數“經典錯誤”都有一個具有誘惑力的外表。你需要拯救一 個落後於進度的項目嗎?那就增加人手吧。你想減少排程嗎?那就把排程得更緊一些吧。團隊中的一個關鍵人物激怒了其餘隊員?那就在項目結束後炒他魷 魚吧。你有一個很緊急的項目要完成?那就把目前所有可用的人力資源召集起來開始工作吧，越快越好!

　　開發人員、管理員和顧客通常會有很好的理由來解釋自己的所作所為，所以這些“經典錯誤”的具有誘惑力的外表也是解釋為什麼會再三犯下這類錯誤的原因。但是，由於“經典錯誤”已經發生過很多次了，因此它的結果是可以預期的，這些結果顯然會和人們原來希望得到的結果不一致。

　　本章列舉了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)。但是我認為，以任何一種形式來強調英雄主義，其壞處往往要比好處多。在案例分析中，中層管理者 對那些認為只要能做就能做成功的人給予了更高的獎勵，而那些講究穩定、長效的工作人員卻得到了較低的獎勵。其結果就是工作中實行的邊緣政策直到最後一分鐘 才發現、認識了組織所面臨的緊急的問題，並向上級報告。一個小的Team Dev掌握了公司的生殺大權，因為他們不願意承認不能按期完成任務。對英雄主義的強調促 進了冒極大風險的趨勢，而削弱了在軟體開發的過程中，利益相關者之間的合作。

　　當有些管理者 過分強調“能做就能成功”的態度時就會產生強調英雄主義的行為。當專案管理者視這種態度高於精準的狀態報表時，他們就會不完全發揮自己的能力地去採取正確 措施。他們甚至不認為自己需要採取正確措施，直到損失已經造成了。正如Tom Demarco所說，“能做就能成功”的態度將原本只是很小的障礙放大成一場真真正正的災難。

　　#5：向即將到期的項目追加人手

　　這也許是最常見的“經典錯誤”了。當一個項目落後與進度時，不在現有隊員中下功夫，而是以增加人手的方式來提高產量。Fred Brooks把這種行為比做“火上澆油”(Brooks 1975)。

　　#6：吵鬧、擁擠的辦公室

　　多數開發人員對自己的工作環境是不滿意的。約60%的人認為他們的工作環境不是不夠安靜就是不夠私人化(DeMarco and Lister 1987)。擁有安靜、私人的工作場所的工作人員會比那些處在吵鬧、擁擠的地方的人要表現得更為出色。吵鬧、擁擠的環境會拖延工作議程。

　　#7：開發人員與顧客之間的衝突

　　這種衝突可以是來自多方面的。當開發人員不願意簽定顧客制定的項目進度表時，或者開發人員沒有履行好他們的承諾時，顧客就可能會認為開發人員不夠合作。而開發人員可能會認為顧客過於無理地堅持不現實的項目進度或修改明明已經確定下來的要求。於是這兩撥人之間就可能發生人身攻擊或誹謗。

　　這種衝突的最主要的影響是使交流和溝通變得匱乏，其中又包含了對需求的缺乏理解，使用者介面設計不夠理想，更糟糕的情況則是顧客拒絕接受已經完成的產品。平均地來說，顧客和軟體開發人員之間的衝突往往會嚴重到雙方要撕毀合約取消項目的開發(Jones 1994)。這種衝突是非常耗時的，而且會把雙方的精力從真正的工作中吸引出來。

　　#8：不現實的期望

　　最可能引起開發人員和消費者或管理者 之間衝突的原因之一是不現實的期望。在案例分析3-1中，如果不是公司需要那麼多時間，Bill沒有理由相信Giga-Quote項目可能在6個月內開發 完畢。Mike沒有糾正這個不現實的期望是問題的主要來源。在其他情況下，專案管理者或開發人員會根據過於樂觀的項目議程估計來申請項目資金。有時候他們會 作出不能保證實現的承諾。雖然不現實的期望並沒有自發地造成項目議程的增長，但它仍會形成開發時間過長的假象，這會使事情變得非常糟糕。Standish Group的一個調查表明，貼近現實的期望是保證商業軟體開發項目成功的五大要素之一(Standish Group 1994)。

　　#9：缺乏有效項目贊助

　　進階別的項目贊助可以在許多方面保證項目的高效開發，包括現實的計劃、權變控制，以及新的開發實現操作。如果沒有這樣一種有效項目贊助，那麼其他更進階別的人事管理就會在組織裡迫使你去接受不現實的期限，或被迫接受一些削減項目的變化。澳大利亞諮詢師Rob Thomsett說，缺少有效項目贊助事實上註定了項目的失敗(Thomsett 1995)。

　　#10：缺乏利益相關者的入夥

　　軟體開發中所有的主要成員都要入夥該項目，其中包括執行贊助、團隊領導、團隊成員、市場部、終端使用者、消費者以及其他所有利益相關方。密切的合作只在所有的利益相關者入夥時才會發生，從而保證了項目的順利進行。

　　#11：缺乏使用者的參與

　　Standish Group的調查表明IS項目獲得成功的最主要的原因是其使用者積极參与了項目的開發(Standish Group 1994)。

　　#12：將權術置於本質之上 www.myp

　　Larry Constantine就四個團隊進行了報道，並稱他們分別具有四種權術中心(Constantine 1995a)。“政治型”團隊傾向於“向上管理”， 即更關注與其上層領導之間的關係。“研究型”團隊專註於偵察和收集資訊。“隔離型”團隊以自我為中心，他們會與非團隊成員劃清界線。而“通用型”團隊則每 件事都做一些：他們和上級搞好關係，進行研究和收集資訊的工作，並在工作流程中和其他團隊進行協調。Constantine報道稱，一開始是“政治型”和 “通用型”團隊能夠被上級領導重視，但在一年半以後“政治型”團隊被打入冷宮。所以說將權術置於成果之上對高效開發來說是致命的。

　　#13：一廂情願的想法 專案管理論壇

　　我很驚訝，為什麼在軟體開發中有許多問題最後都歸結為一廂情願的想法。你聽過幾次類似下面的說法：

　　“團隊中沒有一個成員認為他們可以按期完成任務，但他們卻想如果每個人都努力功能，沒有一件事會出錯，再加上幾次幸運的休假，相信他們就能順利完成任務。”

　　“我們團隊還沒有將產品的幾個部分進行融合，但我們會在其他發麵進行有效溝通，而且這些部分之間的介面是比較簡單的，所以應該只要一兩天的時候來修複其中存在的問題。”

　　“我們以謊報低價的方式和他們簽訂了資料庫子系統的承包合約，而要完成這些任務就需要相當的人力資源，這對他們來說是很困難的，因為他們並沒有這方面的資曆，但也許他們可以用更多的精力來彌補經驗上的不足。也許他們可以按時完成任務。”

　　“我們不需要想顧客展示程式的最終原型，我很確定這就是他們想要的。”

　　“這個團隊稱他們會非常努力地按期完成任務，雖然他們在第一個關鍵時間點上延誤了幾天，但我相信他們可以按時完成的。”

　　一廂情願的想法不是樂觀，而是閉上了你的眼睛去期望一些根本沒有理由相信其存在的東西。這種想法會在項目的最後階段帶來巨大的麻煩。它不僅削弱了有意義的計劃，而且很有可能這項軟體工程有著更多更複雜的問題。