隨著計算機硬件水平的不斷提高，計算機軟件的規(guī)模和復雜度也隨之增加。計算機軟件開發(fā)從“個人英雄”時代向團隊時代邁進，計算機軟件項目的管理也從“作坊式”管理向“軟件工廠式”管理邁進。這就要求軟件開發(fā)人員特別是軟件項目管理人員更深一步地理解和掌握現(xiàn)代軟件工程的理論方法，完成思想觀念上的轉(zhuǎn)變。筆者在此分析了10個在現(xiàn)代項目管理中思想觀念上容易陷入的誤區(qū)，希望能夠拋磚引玉，引發(fā)大家更多的思索和討論。

誤區(qū)1：在項目的需求分析階段，開發(fā)方與客戶方在各種的問題的基本輪廓上達成一致即可，具體細節(jié)可以在以后填充。因為無論開始時有多么細致，以后對需求的修改幾乎是必然的。分析：這是一種非常危險的思想。實際上許多軟件項目失敗的最主要的原因就是需求階段對問題的描述不夠細致，導致后來預算超出或者時間進度達不到要求。正確的做法是：在項目需求分析階段，雙方必須全面地盡可能細致地討論項目的應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。并且，在需求分析結(jié)束以后，雙方還要建立可以直接聯(lián)系的渠道，以盡早地對需求變動問題進行溝通。

誤區(qū)2：軟件項目的需求可以持續(xù)不斷的改變，而且這些改變可很容易地被實現(xiàn)。分析：的確，在具體實際中由于種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨著開發(fā)進度的推進，往往會有一些需求的改變。而現(xiàn)代軟件工程理論也利用軟件的靈活性特點通過各種方式來適應這種情況。不過，這并不表明“軟件項目的需求可以持續(xù)不斷的改變，而且這些改變可很容易地被實現(xiàn)”。實踐表明：隨著開發(fā)進度的推進，實現(xiàn)軟件需求更改所需要的代價呈指數(shù)形式增長。假定在需求分析階段實現(xiàn)需求更改需要花費1倍的代價；那么，在系統(tǒng)設計和編碼階段，需要花費1.56倍的代價；在系統(tǒng)測試階段需要花費1020倍的代價；在軟件版本發(fā)布以后，甚至可能要花費60100倍的代價。由此可見，在項目開展過程中，軟件需求的改變應當盡量早地提出。這樣才可能花費少，容易被實現(xiàn)。

誤區(qū)3：軟件程序主要由代碼組成，因此編碼階段是整個軟件項目的最重要的階段，應該給與大量的時間，并且集中主要的資源。分析：與以前相比，由于軟件的規(guī)模和復雜度的增加，以及半自動化軟件代碼開發(fā)平臺的出現(xiàn)，現(xiàn)代軟件項目管理的中心發(fā)生了轉(zhuǎn)移——不是著重編碼階段，而是著重系統(tǒng)總體/詳細設計階段。一般說來，在現(xiàn)代軟件項目管理中各種資源的合理分配比例是：項目論證、風險評估階段3%，項目需求分析階段8%，系統(tǒng)總體/詳細設計階段45%，編碼階段10%，系統(tǒng)測試階段34%。

誤區(qū)4：為了便于代碼的維護修改，在系統(tǒng)的詳細設計階段文檔工作應該做到寫出所有程序的偽碼。分析：通常偽碼的最大作用是對程序的算法流程進行描述，便于人們深入了解程序的功能和實現(xiàn)過程。可見，在一定程度上偽碼的確有利于對程序代碼的維護和修改。但是，我們知道為了保證項目文檔和程序代碼的一一對應關(guān)系，維護程序代碼的時候同時需要對項目文檔進行維護。偽碼和程序代碼是非常接近的，對偽碼進行維護的話，相當于進行了2倍的程序代碼維護。工作量是很大的。所以切合實際的方式應該是對一般的程序文檔做到程序流程圖即可，對于涉及了較復雜算法的才需要偽碼。

誤區(qū)5：既然在項目人員配置中設置了專門的測試人員，那么軟件所有的內(nèi)部測試工作全部應該由測試人員完成。分析：軟件程序測試可以分為“白盒法”和“黑盒法”兩種方式。由于使用“白盒法”對測試人員各方面素質(zhì)的種種要求，在進行程序測試時測試人員總是最優(yōu)先使用“黑盒法”。他們的工作方式往往是先對程序進行“黑盒法”測試；如果測試沒有通過，不得已這才考慮對程序代碼進行“白盒法”測試。顯然，這種對“白盒法”有意無意的“逃避”，對軟件的可靠性和穩(wěn)定性構(gòu)成了威脅。如何解決這個問題？一方面需要提高對測試人員的要求，另一方面也需要程序員完成部分的“白盒法”測試（實際上，程序員往往也是進行“白盒法”測試的最佳人選）。

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

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

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

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

誤區(qū)10：為了保證項目繼續(xù)，為了留住核心程序員，加薪吧。分析：加薪可以說是很多企業(yè)在挽留程序員時所使用的常用方法。這一招可能暫時奏效，不過往往是人留下來了，但副作用也來了——加薪的人未必見得多干活，沒有加薪的人卻開始消極怠工了。其實，項目的進行過多地依賴程序員的個人技術(shù)是“作坊”時代沿襲下來的“陋習”。既然IT行業(yè)人員的流動是無法控制的，現(xiàn)在項目的執(zhí)行應該更加注重團體的力量，應該更多的考慮公司整體技術(shù)水平和核心技術(shù)能力。例如形成公司自己的專家知識庫，類/函數(shù)庫，第三方控件庫，擁有自主版權(quán)的開發(fā)平臺等。另外，實際上程序員萌生去意的原因很大程度上不是薪水，而是缺少激勵和尊重。這需要項目經(jīng)理使用“老土”一點的辦法，找適當?shù)臅r機對程序員做一做思想工作，向其描述項目的美好未來，讓其感受關(guān)心和尊重?？傊?，要從多方面著手保證項目的順利開展，而不是簡單地加薪。

【?發(fā)表評論?0條?】