項目經(jīng)理手冊

1、項目經(jīng)理更多的是管理的工作: l 團隊構(gòu)建l 領(lǐng)導力l 執(zhí)行力l 時間管理l 壓力管理l 結(jié)構(gòu)化思維與表達l 有效溝通l 有效的演講技巧l 六頂思考帽軟件工程項目管理是一個系統(tǒng)工程，軟件工程項目管理的主要目標是保證項目在規(guī)定時間內(nèi)高質(zhì)量地完成。項目管理包括了項目組開發(fā)各階段的人員結(jié)構(gòu)的配置，質(zhì)量控制的實施方略，內(nèi)部文檔和產(chǎn)品文檔的組織編寫等多項工作，其中質(zhì)量控制方法具有軟件開發(fā)的特點。項目開發(fā)根據(jù)進度分為需求、設計、開發(fā)、測試等各個階段，質(zhì)量保證工作始終貫穿各階段，同時又必須根據(jù)每個階段特點采取相應的措施。需求分析從系統(tǒng)分析的經(jīng)驗來看，這個過程往往是個循序漸進的過程，一次性對系統(tǒng)形成完整的認識

2、是困難的。只有不斷地和客戶領(lǐng)域?qū)＜疫M行交流確認，方能逐步明了用戶的需求。從系統(tǒng)開發(fā)的過程得知，系統(tǒng)分析時犯下的錯誤，會在接下來的階段被成倍放大，越是在開發(fā)的后期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發(fā)影響系統(tǒng)的工期和系統(tǒng)的質(zhì)量。在具體項目中，一般的做法有兩種：一是請該領(lǐng)域內(nèi)專家參與到系統(tǒng)開發(fā)的早期階段；二是開發(fā)系統(tǒng)原型，原型包括功能性的原型和用戶界面性的原型，也可以是二者混合的原型，用這些原型確認用戶的需求。監(jiān)督計劃按照監(jiān)督計劃分配相應的資源來保證某階段的開發(fā)質(zhì)量。分析階段的監(jiān)督計劃會在分析任務之前被項目經(jīng)理、項目負責人、系統(tǒng)分析員以及技術(shù)支持所了解。為保證分析工作高質(zhì)量進行，同時又

3、不被過分打擾，質(zhì)量監(jiān)督組則主要針對系統(tǒng)分析報告進行復審，并在認為確實有必要的情況下才召開質(zhì)量復審會議。質(zhì)量復審會議的主要參與者是項目經(jīng)理、項目負責人、分析人員和質(zhì)量監(jiān)督組組長。會議主要是對質(zhì)量質(zhì)疑，給出改進建議即可。具體是否存在質(zhì)量問題、是否需要改進，不在會議中進行討論，以此保證了會議參與的人數(shù)較少，會議的時間盡可能短。系統(tǒng)實現(xiàn)，實現(xiàn)也就是代碼的生產(chǎn)過程。生產(chǎn)的類別有組件的生產(chǎn)，構(gòu)件的生產(chǎn)，應用系統(tǒng)的整合，以及各種測試用例的生產(chǎn)。為了能夠提高生產(chǎn)的質(zhì)量，應將生產(chǎn)的程序人員按職能分成兩組，也就是說如果某個程序員生產(chǎn)了某個組件，則不能再由該程序員來生產(chǎn)，但他可以生產(chǎn)其他組件。這樣交叉生產(chǎn)更容易發(fā)現(xiàn)

4、組件存在的問題。測試指標測試人員按照各項指標提出測試報告。指標分別包括如下幾點：軟件的正確性，正確性測試主要是測試軟件的功能是否被正確地實現(xiàn)。測試的方式主要是按照功能的要求按照給定的輸入，看是否有給定的輸出，在非標稱輸入時，輸出是否異常等。同時也可以測試軟件的功能是否實現(xiàn)或完整實現(xiàn)。性能指標：該項目對性能的要求非同一般的軟件項目。性能測試往往包含了壓力測試、攻擊性測試等測試，軟件所能承受的極限是多少，一般來說，軟件的極限應當高出用戶要求的性能，各種指標也應當為用戶所了解。易用性：軟件的使用界面在設計時，應當設法使之與功能的實現(xiàn)相脫離。脫離的原因在于易用性是通過友好的界面實現(xiàn)的。然而讓開發(fā)人員以

5、使用者的角度，來確定軟件是否易用是件非常困難的事情，在確定使用界面時，往往需要多次反復修改，甚至只能在軟件的最后交付之前或用戶使用一段時間之后才被提出來。需求變更管理需求變更管理是web項目管理中最重要的一個環(huán)節(jié)，需求變更管理的有效性直接影響項目的成功與否。對待變更的態(tài)度：1、變更是不可避免的。2、變更必須被管理。3、積極發(fā)現(xiàn)引起變更的因素，促使變更盡可能早的出現(xiàn)，減低變更帶來的風險。需求變更管理的目標：1、相關(guān)的干系人必須清楚地了解發(fā)生的變更。2、變更處于有效的管理中。3、盡量降低變更帶來的風險。通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現(xiàn)上述的目標。需求變更流程：1、確定需

6、求的基準線。通常我們會以User Case作為需求基準線，在User Case確認之后的任何需求改變，都需要走需求變更流程。沒有走需求變更流程的需求將不被認可。2、首先項目經(jīng)理接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、客服、開發(fā)人員、測試人員等。3、項目經(jīng)理評估該需求變更。項目經(jīng)理可以召集相關(guān)人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。項目經(jīng)理作為項目的負責人，對項目的成功負有主要的責任。所以需求變更的決策者應該由項目經(jīng)理承擔。4、需求變更確認后由專人將需求變更記錄下來(格式如下)，通知給項目中所有成員。其中以下人員對需求的變更是緊密相關(guān)的,他

7、們必須知曉并認可此需求變更。包括（客戶方代表，需求分析師，測試人員，相關(guān)開發(fā)人員）。需求變更表的格式：序號變更提出時間變更描述變更類型(是對原有需求的修改還是新增需求)原因變更提出者開發(fā)人員對進度的影響（工作量）5、相關(guān)人員接收到確認的需求變更后，做以下事情。需求分析人員修改需求說明書和User Case的相關(guān)內(nèi)容。測試人員修改測試用例的相關(guān)內(nèi)容。開發(fā)人員修改代碼中的相關(guān)部分。6、需求凍結(jié)項目越到后期，需求變更對項目的影響就越大，所以在一定時候我們會進入需求凍結(jié)階段，不再接收需求的變更。1是否需要變更，做出判斷我的文章中提到：項目經(jīng)理收到變更申請后，項目經(jīng)理可以召集相關(guān)人員討論該需求變更的合理

8、性、可行性，實施的代價以及對項目的影響。2如果需要變更，會產(chǎn)生那些影響，做出相應的變更計劃，包括可能影響的項目范圍，進度，費用，質(zhì)量等計劃我的文章中提到：項目經(jīng)理可以召集相關(guān)人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。對于確認的變更，會有需求變更記錄表來描述該變更，當然你說的變更計劃應該是非常全面，但對于web項目要求的時間性考慮，我覺得一張表格也可以說明問題，簡單明了。3確定變更的負責人需求變更的決策者應該由項目經(jīng)理承擔，具體的操作者是SQA來承擔，比如基線控制，變更記錄，通知相關(guān)人員。我的文章中有遺漏，沒有明確這個人的角色。5按照變更后的計劃實施項目，并進行檢查對，變更

9、后的實施反饋沒有在我的變更流程中，這一點我是有考慮，但想到大部分需求的變更最終都要經(jīng)過測試環(huán)節(jié)，所以我就沒專門提到。變更后的實施反饋還是比較重要的，我想還是根據(jù)項目的實際情況對這塊裁剪比較好。web項目經(jīng)理手冊-項目經(jīng)理需要銘記在心的話1、項目經(jīng)理不是來管人的，而是來支持人的。        解析：不光是項目經(jīng)理，任何經(jīng)理的職位都是如此。但現(xiàn)實中很多人并不是那么做，這也是為什么他們沒能把項目做成功的原因。作為項目經(jīng)理首先要端正態(tài)度，認識到這份工作職責的本質(zhì)。2、好的開始是成功的一半。   

10、60;    解析：一個好項目的失敗，往往是由于前期的準備不足、計劃不周密。所以在項目初期要舍得花時間做前期的需求收集、討論、技術(shù)準備等工作。盡管前期的工作看起來并沒有直接產(chǎn)生效益，但這塊工作做好了，后面的工作往往會事半功倍。否則前期準備不足，很可能導致項目出現(xiàn)各種各樣的問題（比如大量的需求變更等）。3、什么樣的項目最可能成功？答案是：項目越小成功的可能性越大。       解析：項目經(jīng)理和相關(guān)人員要仔細評估項目中feature的成本/價值比，盡可能縮小產(chǎn)品的規(guī)模。   &#

11、160;  有時候項目經(jīng)理可能改變不了整個項目規(guī)模，但是項目經(jīng)理可以采用各種手段來“縮小”項目，比如分期進行、迭代開發(fā)等。4、任何對項目的改善無關(guān)的工作都是浪費時間。       解析：在項目過程中項目經(jīng)理不要做表面工作，或者對項目本身無意義的工作。比如無休止的會議；要求編寫詳細而最終沒有用處的文檔。5、使用者的參與是項目成功的重要保證。      解析：使用者可以是：產(chǎn)品經(jīng)理、需求方代表、或者客戶。      在項目的各個階

12、段，項目經(jīng)理要積極要求使用者參與到項目過程中。通過這種與使用者不斷的溝通、反饋，使得最終做出來的產(chǎn)品是客戶真正想要的。6、不要認為把任務交給團隊成員，期間你可以不聞不問，到了完成的時間他自然會把任務交上來。這種想法是非常錯誤。       解析：這樣做無疑會增加項目的風險，很容易出現(xiàn)該完成的任務沒有按時完成，有些延誤，這樣項目后續(xù)的工作都會收到牽制。      正確的做法是：當把任務安排下去后，你要定期和成員溝通完成的情況，詢問是否需要支持，這樣我們才能保證任務能按時保質(zhì)的完成。7、溝

13、通要訣：項目過程中與相關(guān)人員溝通時，不要總認為對方的出發(fā)點都是從項目利益考慮，他/她一定先考慮個人利益或部門利益，所以項目經(jīng)理要做的是：如何把對方的個人利益(部門利益)引導到和項目利益一致。8、“加班”是一個危險的信號，表明一定是某個地方出現(xiàn)了問題，要找出進度落后的原因。9、項目開始前，項目經(jīng)理一定要找出項目的決策者是誰，誰對項目的產(chǎn)品有最終的發(fā)言權(quán)。10、我們交付的不是程序，而是產(chǎn)品和服務。web項目經(jīng)理手冊-風險管理     風險管理是web項目中項目經(jīng)理最重要的工作之一。風險管理是一個持續(xù)的過程，貫穿于整個項目過程中，風險管理包括風險識別、風險估計

14、、風險解決以及風險管理策略。           在實際web項目中，項目風險主要表現(xiàn)為以下情況。了解這些有助于項目經(jīng)理在項目初期就識別出這些風險，并采取措施避免或者減少它們的發(fā)生。一、web項目風險列表：1：需求變更風險：需求已經(jīng)打上了基線，但此后仍然有變更發(fā)生，對項目造成影響。       如何減少此類風險的發(fā)生？(1) 前期的需求討論要詳細、充分。需求文檔中需求的范圍要明確、功能描述要清楚。(2) 需求文檔中要有demo。對于we

15、b項目，圖片比文字更能說明問題。(3) 找出項目中需求的決策者(通常會是產(chǎn)品經(jīng)理、相關(guān)職能主管、客服)，所有的需求要經(jīng)過他們的認可。(4) 客戶在項目過程中的全程參與有助于降低此類風險。需求討論、需求確認、User Case確認、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參與。(5) 發(fā)生需求變更時，嚴格按照需求變更流程執(zhí)行。2、技術(shù)風險：開發(fā)過程中遇到技術(shù)難題，導致開發(fā)時間延遲或者需求不得不發(fā)生變更。     如何減少此類風險的發(fā)生？     在項目開始前的技術(shù)評估階段，明確技術(shù)難點，提前安排人員進行攻克。如果在可預

16、期的時間內(nèi)無法解決，可以要求需求方變更需求。3、質(zhì)量風險：對于web項目而言，質(zhì)量風險主要指開發(fā)代碼的質(zhì)量。       如何提高開發(fā)人員開發(fā)的質(zhì)量？(1)、制定項目計劃時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質(zhì)量的影響很大。開發(fā)時間評估可參考【web項目經(jīng)理手冊-開發(fā)時間估算】。(2)、有一套嚴格可行的代碼規(guī)范，編碼時嚴格遵守，code review時嚴格考核。(3)、在編碼前，開發(fā)人員要對框架熟練掌握。(4)、一份好的系統(tǒng)設計文檔對指導開發(fā)非常重要。4、資源風險：項目所需人力資源無法按時到位，導致資源風險。如何減少

17、此類風險的發(fā)生？這個就需要在項目計劃制定的時候提前申請確認資源，并在項目過程中不斷溝通協(xié)調(diào)。二、項目風險管理的要點：1、上述我們所說的風險管理都是指可以預期將要發(fā)生的風險，那些不可預期將要發(fā)生的風險不屬于風險管理的范疇。這也說明項目經(jīng)理的經(jīng)驗和知識對能否管理好風險至關(guān)重要。2、詳細明確的項目計劃、以及項目執(zhí)行過程中每個要點的質(zhì)量保證是降低項目風險的必要條件。3、風險報告是項目團隊以及領(lǐng)導了解項目風險的一個有效手段。風險報告的格式通常是：   web項目中有很多項目涉及到跨部門、跨公司的合作。這類項目往往比其他項目更有挑戰(zhàn)。對于項目經(jīng)理如何做好這些項目呢？ 

18、0;     首先讓我們看看這類項目都有哪些共同的特點。1、合作雙方工作在不同地方，對項目溝通造成一定影響。2、合作雙方隸屬于不同的公司或者部門，雙方的項目開發(fā)流程可能完全不同，在項目執(zhí)行過程中需要考慮到這個因素。2、合作項目需要雙方共同完成，如果一方的工作進度出現(xiàn)延誤，那么整個項目的進度都會收到影響。      本人根據(jù)平時這類項目的實施經(jīng)驗，總結(jié)一下這類項目要想成功，需要把握的原則。1、合作雙方的領(lǐng)導層必須都非常重視這個項目。剃頭挑子一頭熱的項目成功的可能性不會高。只有這樣，項目的優(yōu)先級才有保證，這樣

19、在以后項目過程中一些資源（包括人力、硬件、時間投入）更有保證，配合起來也會更加順暢。2、合作雙方確定好各自的接口人。雙方的溝通都通過接口人進行，這樣可以降低成本，提高溝通的效率。接口人可以分為兩類：一類是商業(yè)上的接口人，一類是技術(shù)上的接口人。3、完備的文檔(接口文檔、數(shù)據(jù)庫文檔)必不可少。web項目雙方的合作在技術(shù)方面通常采用API接口方式交互。所以項目前期詳細準確的接口說明文檔非常重要，雙方開發(fā)人員之后的開發(fā)都是嚴格按照接口進行。同時接口的相對穩(wěn)定也是非常重要的，所以需要前期設計的時候認真全面地考慮接口規(guī)范。4、便利的溝通工具。對于跨地區(qū)的合作，便利的溝通工具是非常重要的。當然工具最好是免費

20、，比如使用IM。從溝通方式的效果來看，我覺得面對面的溝通>電話溝通>EMAIL(or IM)。5、接口變更的及時通知。這一點很重要，接口變更應該有流程來保證，特別是對于這種成員分散在不同地方的團隊尤為重要。6、前期技術(shù)方案的溝通。前期技術(shù)方案的討論以及接口的定義，最好能當面溝通，這樣效果最好。所以前期最好去一趟對方公司商談這些要點。7、各自開發(fā)環(huán)境的可訪問問題。解決雙方開發(fā)環(huán)境的相互調(diào)用問題。合作雙方聯(lián)調(diào)的時候通常需要訪問對方的接口。由于雙方都在各自環(huán)境進行開發(fā)，所以需要解決這種問題。最好的情況是：可以訪問對方的環(huán)境(外網(wǎng))。最大的風險是：沒有可以聯(lián)調(diào)的環(huán)境，等到發(fā)布到正式環(huán)境上再

21、測試，這時候時間上就有點晚了，可能會遇到一些之前預想不到的問題。所以聯(lián)調(diào)的時間越提前,問題就能越快暴露出來，整個項目的風險就越小。聯(lián)調(diào)環(huán)境的穩(wěn)定也非常重要。有一次我們發(fā)現(xiàn)我們的功能有問題，代碼跟蹤調(diào)試，結(jié)果發(fā)現(xiàn)原來對方的環(huán)境有問題，浪費了我們很多時間。8、由于項目的各個點是互相依賴的，所以在一些關(guān)鍵點上要能按時提交，否則會影響對方的進度。在項目計劃中要詳細定義各個重要的里程碑，并嚴格控制執(zhí)行。9、項目進度報告。定時相互通告項目進度，重點關(guān)注項目風險。10、熟悉對方項目開發(fā)的流程。不同公司項目的流程、角色分工不一定相同。只有熟悉了對方項目的流程，在與對方溝通時候才能做正確的事情。所謂知己知彼，才

22、能百戰(zhàn)百勝。千萬不要自己悶頭開發(fā)，完全不顧對方的做事方式，然后自己想當然他們應該和我們一樣。       我們常說做好項目的關(guān)鍵之一就是做好“溝通”，但很多人只知道“溝通”的重要性，卻不知道怎么做好“溝通”，所以仍然會有很多項目由于溝通未做好而導致項目失敗或者有些遺憾。       “溝通”不僅僅是說話，不是說的越多溝通就越好。要做好“溝通”關(guān)鍵是清楚以下兩點：我們要和誰溝通，和他(她)溝通什么，怎么和他(她)溝通。溝通的最終目標是：讓被溝通的人明白你要傳遞的內(nèi)容，并自覺執(zhí)行

23、好你希望他做的事情。要解決好溝通問題，我們需要把握以下兩個原則：一、 利益原則利益原則解決的是“和誰溝通”的問題。項目開始階段我們要識別出與項目有利益的人(即項目干系人)，確定他們需求和期望，然后采用合適的溝通策略。項目的干系人是指參與項目，或其利益在項目執(zhí)行中或成功后受到積極或消極影響的個人和組織。這些人是項目過程中需要著重關(guān)注的人群，很多項目出了問題都是由于忽視了(或者是忘了)其中某些人。   項目干系人通常包括：Ø       項目發(fā)起人、出資方。（項目決策者）Ø  &

24、#160;    部門職能經(jīng)理。(資源提供方)Ø       項目團隊成員。(項目執(zhí)行者)Ø       產(chǎn)品運營。(產(chǎn)品的運營者、使用者)Ø       客服人員。(客戶接口)為了更好地把握這一原則，我推薦項目經(jīng)理在項目開始階段使用以下表格。序號 項目干系人 其對項目的主要期望 在本項目中的利益程度(H, M, L) 對項目的影響程度(H, M, L) 與

25、其溝通的策略 1           2           3           4           5   &

26、#160;      二、閉環(huán)原則很多項目經(jīng)理在實際溝通中常常會是這樣的：某某某這個事情你做一下，或者發(fā)個郵件給某某，期間也不聞不問，期望到時候那個人就會按時提交任務。這種情況往往會發(fā)生問題。正確的溝通環(huán)節(jié)應該是一個閉環(huán)。具體的過程應該是這樣的：1、項目經(jīng)理和項目干系人溝通事情，征詢他們的意見。(雙向溝通)2、達成一致意見，確認action列表。(責任、任務落實到具體的人)。3、執(zhí)行過程中要跟蹤執(zhí)行情況，確認執(zhí)行人是否需要協(xié)助，同時有助于識別是否存在潛在的風險發(fā)生。4、執(zhí)行結(jié)果的檢查。    溝通結(jié)束前要

27、注意總結(jié)、回顧，以及action，以確保溝通的效果。三、 良好的溝通技巧會有助于溝通。1、當你不知道怎么給出建議，或者如何回答的時候，建議你采用提問式的回答，比如“你覺得怎么做會好呢？”等等開放式的問題，這樣有助于發(fā)揮大家的積極性，創(chuàng)造性，最終獲得良好的效果。2、溝通過程中盡可能少的打斷，不要匆忙下結(jié)論，不要立刻針鋒相對地駁斥對方。3、要適當使用幽默。3、積極地給予反饋。4、了解溝通者的風格，以便更有效的溝通。四、溝通的表現(xiàn)形式實際上是很多的，絕不要局限在面對面對話，像會議、email等都是溝通的具體表現(xiàn)。所以上面所說的原則和技巧都可以這些環(huán)節(jié)中采用。   

28、60;   在項目中如果把握好上面所說的原則，再加上自身溝通的技巧，一定會對項目的成功起到非常大的幫助。記住和正確的人正確地做正確的事情。1.不要喪失激情人們在啟動一個新項目時往往很容易躊躇滿志。但是要想在長期內(nèi)都保持這種充沛的精力及激情卻很難得。要知道，想有好的結(jié)尾，光有一個好的開頭是不夠的。2.不草率記住，您開始得越早，您完成得就越晚。在一個項目周期里，不適當?shù)挠媱澗幹茣屇馁M過多的成本。不要因為壓力的關(guān)系就匆匆開始，從而忽略了遵循基本的項目管理方法。3.不要總說是企圖預先就羅列好項目所具有的所有功能就好比是列好“烹飪”一個項目的菜譜，這個項目必定會超過預算并且有一個

29、負的投資回報率。要學會有所選擇。這也算是一門藝術(shù)，而且隨著時間的磨礪，您在這門藝術(shù)上的造詣會越來越高。向項目贊助人展示必須的重要因素，并且讓他們知道您為什么想拋棄那些不必要的因素。通常表面上看起來小而不重要的因素往往會耗費您大量的時間和資金。4.在政治沖突中不要偏袒任何人保持中立。5.不要忘了溝通如果溝通不是您的強項，就在您的項目小組中找一個擅長這個的人。如果您總是忙于這個項目的技術(shù)方面，那就很容易會忽視溝通這件事了。確保您或您信任的某個人能與關(guān)鍵人物保持溝通。6.不要把錯誤的人安排在錯誤的崗位上一個蘋果就是一個蘋果，即使您把它描成橙色或是在它上面裹上七彩紙。7.不要讓小組中的任何人透支體力我

30、們都必須在這或在那加班加點，但是千萬別讓任何一個人持續(xù)加班而沒有休息。這樣會讓人不健康。8.不要找借口如果您犯了一個錯誤（每個人都會犯錯誤），承認錯誤并及時改正。9.不要眼高手低10.不要忽視問題警惕小問題發(fā)展成大問題。一旦忽視了它們，您可能回頭就陷入困境。11.不要忘記心中的藍圖我們必須在過程和資源之間保持一個微妙的平衡點。確保項目中所有的工作能在合適的時刻匯合，并且達到項目所希望的最大目標，這是我們的職責。12.別遺忘您的小組成員記住讓他們充滿斗志，并且及時給他們充電。13.不要把所有功勞據(jù)為己有正如哈瑞.杜魯門曾經(jīng)說過的，如果您得不到別人的付出，您還妄想成功，這就如同癡人說夢。誤區(qū)1：在

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

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

33、程中，軟件需求的改變應當盡量早地提出。這樣才可能花費少，容易被實現(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)的詳細設計階段文檔工作應該做到寫出所有程序

34、的偽碼。分析：通常偽碼的最大作用是對程序的算法流程進行描述，便于人們深入了解程序的功能和實現(xiàn)過程?？梢?，在一定程度上偽碼的確有利于對程序代碼的維護和修改。但是，我們知道為了保證項目文檔和程序代碼的一一對應關(guān)系，維護程序代碼的時候同時需要對項目文檔進行維護。偽碼和程序代碼是非常接近的，對偽碼進行維護的話，相當于進行了2倍的程序代碼維護。工作量是很大的。所以切合實際的方式應該是對一般的程序文檔做到程序流程圖即可，對于涉及了較復雜算法的才需要偽碼。誤區(qū)5：既然在項目人員配置中設置了專門的測試人員，那么軟件所有的內(nèi)部測試工作全部應該由測試人員完成。分析：軟件程序測試可以分為“白盒法”和“黑盒法”兩種方

35、式。由于使用“白盒法”對測試人員各方面素質(zhì)的種種要求，在進行程序測試時測試人員總是最優(yōu)先使用“黑盒法”。他們的工作方式往往是先對程序進行“黑盒法”測試;如果測試沒有通過，不得已這才考慮對程序代碼進行“白盒法”測試。顯然，這種對“白盒法”有意無意的“逃避”，對軟件的可靠性和穩(wěn)定性構(gòu)成了威脅。如何解決這個問題?一方面需要提高對測試人員的要求，另一方面也需要程序員完成部分的“白盒法”測試(實際上，程序員往往也是進行“白盒法”測試的最佳人選)。誤區(qū)6：軟件項目管理只是相關(guān)技術(shù)部門的事情，與公司其他部門無關(guān)。分析：在競爭日益激烈的今天，軟件項目規(guī)模大、復雜度高而且時間要求緊迫。要想提高公司的軟件項目管理

36、水平，這就需要提高公司的整體參與意識，需要公司各個部門協(xié)同作戰(zhàn)。例如需要會計部門協(xié)助進行項目預算，財務管理和費用控制;需要研究部門(技術(shù)委員會)指派專家協(xié)助進行各種風險評估，提供技術(shù)指導;需要后勤部門提供各種保障。誤區(qū)7：在開發(fā)進度滯后的情況下，可以聘請更多的程序員加入到開發(fā)團隊中，通過增加人力資源來趕上進度。分析：在注重團隊開發(fā)的時代，開發(fā)方應該根據(jù)目前的軟件項目管理水平慎重考慮這個做法。如果新加入的程序員對目前軟件項目的應用行業(yè)有一定了解，并且可以很快適應了開發(fā)方的項目管理方式、軟件開發(fā)風格、團隊協(xié)作氛圍;那么“新人”的加入是有益的。否則，可能會“好心好意做壞事”。因為盡管其個人能力很高，

37、但是為了使其與大家一起協(xié)同工作，開發(fā)團隊不得不分出人手對其進行與項目有關(guān)的技術(shù)/業(yè)務培訓，更重要的(也是難度最大的)是還要引導其融入團隊。這可能需要花費開發(fā)團隊許多時間和精力，很有可能使項目進度更慢。誤區(qū)8：技術(shù)骨干應該成為項目的項目經(jīng)理，項目經(jīng)理一定是所有項目成員中薪水最高的。分析：在“軟件作坊”時代，這是一種普遍使用而且效果不錯的方法;而在“軟件工廠”時代，這種方法卻帶來各種問題，有時甚至直接導致項目失敗。究其原因這主要是因為隨著現(xiàn)代軟件開發(fā)分工的細化，對項目經(jīng)理的要求也發(fā)生了根本的改變最注重的不是其對某項專業(yè)技術(shù)的掌握程度，而是其組織、領(lǐng)導、協(xié)調(diào)開發(fā)團隊的能力(當然，可以兩者均突出最好)

38、。至于項目經(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è)在挽留程序員時所使用的常用方法。這一招可能暫時奏效，不過往往是人留下來了，但副作用也來了加薪的人未必見得多干活，沒有加薪的人卻開始消極怠工了。其實，項目的進行過多地依賴程