1、項目經理在售前階段的任務一、引言軟件行業從20世紀60年月開頭操作系統的研發，到20世紀90年月中期行業快速進展。從原有的作坊式開發到目前團隊協作完成，從早期的技術力氣競爭到現有的項目成本掌握競爭，從面對結構到面對對象再到面對服務架構，項目管理被提到肯定的高度，如何有效的經營項目來降低風險、掌握成本，確保項目進度流暢，在有效的時間內保質、保量的完成驗收。成為不少項目管理人士的追求目標。結合個人項目管理實踐，本人有幾點管理留意事項與大家一起共享。二、項目管理留意事項開發模型確定一個項目的好壞，開發模型優良是項目勝利重要保障，有了好的開發模型我們可以很好的掌握項目進度、降低風險。所以我們在項目開頭

2、前首先需要確定項目的開發模型。這里我們建議采納迭代式的開發模型。我們知道原有早期傳統的開發模型是一個文檔驅動的流程，它將整個軟件開發過程劃分為挨次相接的幾個階段，每個階段都必需完成全部規定的任務后才能夠進入下一個階段。項目開頭首先完成系統需求規格說明書，之后才能夠進入概要設計階段，編碼則在系統設計完成之后進行。這就意味著只有當全部的系統模塊全部開發完成之后，我們才進行系統集成，對于一個由許多個模塊組的簡單系統來說，這是一個特別艱難而漫長的工作，且存在著潛在的風險。如：需求或者設計中的錯誤無法在項目早期發覺，只有在系統交付客戶之后才能發覺原先對于需求的理解是錯誤的，系統設計的錯誤也只有在測試階段

3、才能被發覺。對于項目風險的掌握力量較弱，往往項目風險只能隨著項目結束才能逐步降低，同時也只有經過系統測試之后，才能確定設計是否能夠真正滿意系統需求。軟件項目經常延期完成或開發費用超出預算項目開發進度往往會被意外發生的問題所打亂，需要進行返工或其他一些額外的開發周期，造成項目延期或費用超支。項目管理人員專注于文檔的完成和審核來估量項目的進展狀況所以項目經理對于項目狀態的估量往往是不精確的，當他回答系統已完成了80%的開發任務時，剩下20%的開發任務實際上消耗的是整個項目80%的開發資源。在傳統的瀑布模型中，早期是無法發覺，需求和設計中的問題，只有當系統第一次集成后，這些設計缺陷才會在測試中暴露出

4、來，需求缺陷則需要等到系統與用戶見面后，方可暴露。從而導致一系列的返工：重新設計、編碼、測試，進而導致項目的延期和開發成本的上升。為了解決傳統軟件開發流程中的問題，我們建議采納迭代化的開發方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個軟件系統開發這個大目標。在迭代化的方法中，我們將整個項目的開發目標劃分成為一些更易于完成和達到的階段性小目標，這些小目標都有一個明確的階段性評估標準。迭代就是為了完成肯定的階段性目標而所從事的一系列開發活動，在每個迭代開頭前都要依據項目當前的狀態和所要達到的階段性目標制定迭代方案，整個迭代過程包含了需求調研、軟件設計、軟件實現、版本集成、軟件測試、軟件發布和

5、產品交付等各種類型的開發活動，迭代完成之后需要對迭代完成的結果進行評估，并以此為依據來制定下一次迭代的目標。開發方案制定確定好項目的開發模型，一整套配套可行的項目開發方案是開發過程中進度掌握的標準，同樣是用戶、公司管理層了解項目進展的依據。通常項目管理人員、需求人員和用戶依據用戶原始需求(可以是項目方案書或者是建議書)，一起定義整個項目過程中的項目迭代過程個數以及每個迭代過程的開發目標和范圍。如何進行迭代過程的劃分和范圍有效定義呢?是我們迭代開發方案制定的首要任務，我們這里推舉兩種劃分原則，一、用戶需求至上原則，也就是依據用戶需求的優先級，進行逐個模塊擊破，每一個迭代是用戶需求一個的模塊，當然

6、模塊小時或者人員充分時，也是在一個迭代中完成兩個或者三個模塊。二、當用戶需求沒有鮮亮優先級時，我們可以采納功能逐步求精開發法，類似于我們早期采納快速原型開發，劃分多個迭代，確定每個迭代需要達到的功能的完善層次，例如，首先第一個迭代僅完成系統的原型開發，其次迭代則緊接著完成各業務基本功能，然后逐步完善直至滿意用戶需求。無論怎樣劃分我們的迭代過程，總之需要把握一個原則，框架盡早規劃，版本快速集成。項目只要進入軟件實現過程早期,建議實現周版本的概念，確保一周一個版本，一來便利項目管理人員了解項目進度、質量，從而依據前期項目完成狀況和近期的用戶需求變動準時調整 方案。二來可以盡早將系統與用戶見面，準時

7、發覺對于用戶需求理解不正確之處，同時還可以激發用戶潛在需求，細化需求。在軟件實現過程后期，則可以依據需要調整集成版本頻率。所以，雖然每個迭代開發過程中的開發活動是可以選擇性的裁減，但通常軟件實現、版本集成和軟件測試是每個迭代不行缺少的活動，否則迭代過程將失去它的含義。迭代過程個數和范圍確定后，則需要與每個迭代過程中的開發活動相關者協商爭論進度支配，先明確各開發活動的起始、截至時間，然后在依據開發活動的詳細需求進行任務細化。假如盼望能將項目進度掌握在方案之中，任務越細越好，每個任務跨度不要太大，一天一個任務最好。當然這種狀況是很能實現的。的確，我這里說的是一種比較抱負的狀況，但并不是不行能。在這

8、里我們就可以了解到迭代開發方案給我們帶來的好處。項目開頭了需求通常都是很泛，不太明確。與用戶溝通，可能他認為自己已經表達了全部需要。實際或許他的確已經充分描述了他所知道的需求(業務需求)，但完善我們的系統，除了基本業務需求外還有許多非功能性需求，比如：系統性能需求、界面顯示需求、系統操作流程需求等等，尤其是目前B/S架構的開發模式，界面需求已經越顯示出它的重要性。而這些需求在項目早期，在沒有任何可見事務的狀況下，用戶很難意識到它的重要性。我們只有逐個迭代的細化，每一個迭代過程完成既是需求進一步細化的依據又是一個新系統的開頭，每個迭代開頭前都要依據上個迭代的成果和所要達到的階段性目標細化定制。組

9、內成員配置項目啟動之前除項目管理者著手方案制定外，同時也需要對其項目組那成員配置進行規劃，界定其職責。通常我們需要幾種角色：技術組長：負責技術難題攻關，組間溝通協調。需求人員：負責將用戶需求轉換成項目內的功能需求和非功能需求，編制項目需求規格說明書，針對每個迭代集成版本與用戶溝通獵取需求的細化。設計人員：負責對需求規格說明書，進行系統設計。開發人員：實現設計，完成用戶功能。集成人員：負責整套系統的編譯集成，督促小組系統功能提交，準時發覺各模塊集成問題，起到各小組之間的溝通的紐帶。測試人員：對于集成人員集成的版本進行測試，盡可能的發覺程序缺陷，以及未滿意需求的設計。文檔整理人員：負責對小組內產生

10、文檔的整合，統一。系統環境人員：負責系統編譯環境、運行環境規劃。編制系統環境說明書。維護人員：系統驗收后，維護人員，建議維護人員早期進入項目參加項目測試以便順當擔當起項目維護職責。項目組啟動初期需求人員首先依據迭代方案第一個迭代方案進行需求調研編制功能需求規格說明書，通過項目下到工序人員評審后進入軟件設計、編碼。留意，這里需求確認并不是指項目中的整體需求，僅僅是指該迭代過程中體現的需求。整個過程類似如項目開發流程，這里只是細小流程，逐步完善，漸進提交。三、項目中溝通通常項目中口頭溝通是最為常見的，包括項目組內部、外部溝通，這種溝通快捷、便利。一般的小問題或者是簡潔問題的理解特別有效，但問題簡單

11、或是此次溝通需要后續使用，那么該種溝通則存在問題，則需要以書面方式加口頭相結合最為有效。即可在本次溝通中便利、快捷的領悟，也可以為后續工作供應依據。通常用戶對于項目進度卻是有要求，不僅需要提交周方案和總結，還需要定期匯報項目的完成狀況，對于即將延時的里程碑，需要提前至少三天時間提出項目延時申請。那么從這里我們可以吸取，與用戶的溝通間隔除每周進行項目方案和總結外，對于用戶認可的項目開發方案，需要在里程碑需要向用戶匯報，對于即將延時的開發進度，盡可能早的通知用戶方的項目負責人知道，便利用戶方的項目負責人有預備的與其領導溝通，可以有效預防工作被動狀態消失。項目組內部溝通不是越多越好，你會發覺當內部的溝通時間沒有規律或是溝通時間過長，這樣其實也會嚴峻影響項目成員的開發進度，但溝通又是必不行少，何種間隔最為相宜了?這是不好定的，我們通常以評審作為溝通的基礎，平日的溝通建議項目組成員在每天工作過程遇到問題，將其記錄下來，然