隨著計算機硬體水平的不斷提高，計算機軟體的規模和複雜度也隨之增加。計算機軟體開發從“個人英雄”時代向團隊時代邁進，計算機軟體專案的管理也從“作坊式”管理向“軟體工廠式”管理邁進。這就要求軟體開發人員特別是軟體專案管理人員更深一步地理解和掌握現代軟體工程的理論方法，完成思想觀念上的轉變。以下列舉了10個在現代專案管理中思想觀念上容易陷入的誤區，希望能夠拋磚引玉，引發大家更多的思索和討論。

　　誤區1：軟體專案的需求可以持續不斷的改變，而且這些改變可很容易地被實現。的確，在具體實際中由於種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨著開發進度的推進，往往會有一些需求的改變。而現代軟體工程理論也利用軟體的靈活性特點通過各種方式來適應這種情況。不過，這並不表明“軟體專案的需求可以持續不斷的改變 ，而且這些改變可很容易地被實現”。實踐表明：隨著開發進度的推進，實現軟體需求更改所需要的代價呈指數形式增長。假定在需求分析階 段實現需求更改需要花費1倍的代價；那麼，在系統設計和編碼階段，需要花費1.5-6倍的代價；在系統測試階段需要花費10-20倍的代價；在軟 件版本釋出以後，甚至可能要花費60-100倍的代價。由此可見，在專案開展過程中，軟體需求的改變應當儘量早地提出。這樣才可能花費少，容易被實現。

　　誤區2：既然在專案人員配置中設定了專門的測試人員，那麼軟體所有的內部測試工作全部應該由測試人員完成。分析：軟體程式測試可以分為“白盒法”和“黑盒法”兩種方式。由於使用“白盒法”對測試人員各方面素質的種種要求，在進行程式測試時 測試人員總是最優先使用“黑盒法”。他們的工作方式往往是先對程式進行“黑盒法”測試；如果測試沒有通過，不得已這才考慮對程式程式碼 進行“白盒法”測試。顯然，這種對“白盒法”有意無意的“逃避”，對軟體的可靠性和穩定性構成了威脅。如何解決這個問題？一方面需要 提高對測試人員的要求，另一方面也需要程式設計師完成部分的“白盒法”測試（實際上，程式設計師往往也是進行“白盒法”測試的最佳人選）。

　　誤區3：軟體專案管理只是相關技術部門的事情，與公司其他部門無關。在競爭日益激烈的今天，軟體專案規模大、複雜度高而且時間要求緊迫。要想提高公司的軟體專案管理水平，這就需要提高公司的整體參與意識，需要公司各個部門協同作戰。例如需要會計部門協助進行專案預算，財務管理和費用控制；需要研究部門（技術委員會）指派專家 協助進行各種風險評估，提供技術指導；需要後勤部門提供各種保障。

　　誤區4：在開發進度滯後的情況下，可以聘請更多的程式設計師加入到開發團隊中，通過增加人力資源來趕上進度。分析：在注重團隊開發的時代，開發方應該根據目前的軟體專案管理水平慎重考慮這個做法。如果新加入的程式設計師對目前軟體專案的應用行業 有一定了解，並且可以很快適應了開發方的專案管理方式、軟體開發風格、團隊協作氛圍；那麼“新人”的加入是有益的。否則，可能會“好心好意做壞事”。因為儘管其個人能力很高，但是為了使其與大家一起協同工作，開發團隊不得不分出人手對其進行與專案有關的技術/業務培訓，更重要的（也是難度最大的）是還要引導其融入團隊。這可能需要花費開發團隊許多時間和精力，很有可能使專案進度更慢。

　　誤區5：技術骨幹應該成為專案的專案經理，專案經理一定是所有專案成員中薪水最高的。分析：在“軟體作坊”時代，這是一種普遍使用而且效果不錯的方法；而在“軟體工廠”時代，這種方法卻帶來各種問題，有時甚至直接導致 專案失敗。究其原因這主要是因為隨著現代軟體開發分工的細化，對專案經理的要求也發生了根本的改變--最注重的不是其對某項專業技術 的掌握程度，而是其組織、領導、協調開發團隊的能力（當然，可以兩者均突出最好）。至於專案經理的薪水問題，這和定薪制度有很大關係。通常，專案經理執行的是管理人員的薪酬體系，而其他人員執行的是技術人員的薪酬體系。專案經理的薪水在專案成員中是比較高的，但不一定是最高的。有時候，為了激勵技術人員，專案中的技術骨幹得到的酬勞比專案經理要高。

　　誤區6：只有專案經理以及部門主管才會關心專案整體進度，程式設計師只關心自己的開發進度。其實這是一種“官僚”的想法。實際上程式設計師作為團隊中的一員，他不僅僅是在打一份工，更重要的是在參與一件“作品”的創作。在體味工作的辛苦的同時，程式設計師更重要的是要享受創作的快感。專案經理不應該漠視程式設計師對“成就感”的追求，應該向每一個人詳細描述最終“作品”將會如何美妙和令人興奮，並且在到達最終目標的路上設立一系列的里程碑。每當專案整體推進到一個里程碑的時候，專案經理應該把 這個訊息告訴每一位專案成員，這不僅僅可以讓所有的專案成員享受到階段勝利的喜悅，還可以激發大家更大的工作熱情，提高工作效率。

　　誤區7：更大的壓力可以帶來工作效率的提高。軟體公司的員工加班情況是時常發生的，對員工增加工作壓力、要求加班趕進度，這種方式在初期可以略微提高生產力，因為員工喜歡壓力，並且集中精力於專案任務，全力投入。中等壓力或許可以將生產力提高25％，甚至使總的交付時間縮短25％。但是隻有在壓力處在適當的範圍時，情況才是這樣。壓力再大點，增加的壓力將不會產生作用，畢竟人的能力是有限的，當員工面對巨大的壓力而習以為常時，會將普通的工作量佔滿整個工作時間，導致實際的生產力下降。如果壓力再大一些，員工開始疲憊，直到筋疲力盡，甚至灰心喪氣，他們對專案不抱有什麼積極的態度，此時的專案結局可想而知。

　　誤區8：使用高階語言可以大大提高專案進度，縮短交付期。高階語言相對於他們的前輩確實效率大大提高，程式設計師使用之可以提升編碼速度，從而使整個專案的開發週期縮短；但是在完整的軟體生命週期中，編碼活動一般僅佔總時間的20％左右，而需求蒐集和分析、高層設計、測試等活動卻無法從高階語言的使用中獲益，所以不要認為運用了高階語言就可以制定一個“激進而且安全”的專案進度計劃。

　　誤區9：小型專案不需要嚴格的流程控制。小型專案由於涉及的人員較少，便很草率地制定一個開發日程表，沒有認真地估計專案難度，結果實際完成時間與估計完成時間往往有較大差別；開發人員少，意味著不同人員的程式之間互動、介面相對少一些。開發週期短意味著往往是同樣的幾個人從頭到尾負責一個專案。這兩者都讓人容易犯些錯誤。往往是幾個人碰一下頭，討論一下最基本的資料結構、函式介面便分頭去做自己的工作了，沒有一份較正式的文件。往往覺得“把這些事情（流程管理、專案文件）都做完的話，專案就永遠做不完了！”事實是如果專案中不做這些事，就得花更久時間才完成得了。

　　誤區10：軟體產品的質量完全取決於過程。事實上產品的質量受到人員、技術和過程三個要素制約，片面強調過程決定質量就好像認為只有明星程式設計師才能開發出合格的軟體一樣片面。而且低劣設計和良好設計之間的區別可能在於設計方法中的完善性，而良好設計和卓越設計之間的區別肯定不是如此。卓越設計來自卓越的設計人員。軟體開發是一個創造性的過程。完備的方法學可以培養和釋放創造性的思維，但它無法孕育或激發創造性的過程。

本文轉自：http://www.51testing.com/html/04/n-842004.html