項目中應當引以為戒的錯誤

一、前期與客戶需求調研階段： 

　　1）  抓住主要的人物

　　這個項目的實際使用者，提出項目需求具有決定權的人。這一點比較難做到。主要是看對方是屬于什麼機關，如果是政府部門就麻煩很多，因為政府部門等級制度觀念很明确，他們是很讨厭越級之類的需求提出。在一個需要找準找對能提出具體需求的人。即使提出了具體需求如果他不能确認需求這樣也是一大危險。必須找準可以給你在具體需求書上簽字确認的那位上司。不然一旦沒有這個環節，那日後的工作量就要成倍的付出，才能挽回。（重點） 

　　2）  不能輕易将需求分析看成是客戶提出的要求

　　有些項目客戶方面可以抽調一些人協助調研需求。但是這些協助的人員隻能是大概的說清楚具體使用者的要求。不能詳細的說明具體的重點放在什麼功能上面所實作的表示。而且他們一般給的需求僅僅是他們能了解到的，還不能完全具體到使用者的上面。項目經理或是需求調研人員需要自己在重新分析作出相應的需求報告，不然一味的拿過來讓開發人員去了解，去吃透這些那簡直是一種折磨。因為“你”是整個項目的調研人員不是真正的開發人員去了解需求，而是你來吃透需求徹徹底底的将需求轉化成你所了解的程式流程，程式中所要涉及到的某些關鍵點。如果人人都可以拿别人寫的需求分析來做為你的需求交給開發人員的話，那麼人人都可以做項目經理作調研人員了。（次重點） 

　　3）  分析需求要透徹必須具體到某個點，把握住關鍵點的控制，不可擴大需求

　　經過前面兩點後可能這一點相對來說不時非常重要了。但是如果前面兩點都不注意的話後面談和控制？假設一個項目中也有需求分析了，但是最重要的控制關鍵點沒有名确。那如果别人在已有的需求上面加多幾個功能都不為過，主要原因是沒有明白的告訴别人在什麼時間此類的需求已經明了的确認。并且除了以前提出的需求，其他的需求不能在次提出。是以别人突然想到了什麼就是可以提出來讓你修改，這是最可怕的。如果明确了關鍵點的确認，那就算是提出也沒有關系，可以做為二次開發來再次簽訂相應的開發合同。俗話說得好“空口無憑，立字為證”嘛。這是需要建立在需求調研階段最難最不好控制的地方。（必需做的工作） 

　　二、中期示範工程的編寫

　　1）一旦确認了所有的需求，就需要具體來設計一個示範的模型确認開發效果。 

　　（經過了上面的需求調研，具體的需求分析已經徹底明确後，這一步的工作就比較輕松一些）這裡就需要公司中一些部門的具體配合協同完成了。完成後又要開始前面第一部分相同的工作了此時将需求更換成了示範工程。這個時候應該是需要客戶确認書的，因為一旦确認後以後的開發工作相對就輕松多了，即便是更改某些細節上的需求也是控制在前期。

　　2）開發文檔整理

　　經過了這兩個階段，相應的需求全面了，界面明确了。剩下的就是将一些文檔性的東西拼補齊全，這是項目經理應該做的大事情，當然如果之前的需求文檔都明确簽字，這裡的工作可以說是複制粘貼了（首先确認你縮寫的東西你帶領的開發團隊（Team）能看的明白）。 

　　三、項目後期開發工程 

　　1）初期階段的開發

　　進入初期階段的時候就已經不需要再重複的進行相關需求的調研階段了，還是那句話前期的工作要充分作盡。具體的開發工作就應該是項目經理集合團隊（Team）配置設定工作，将前期自己所做的具體需求分析分發下去，根據需求文檔來編寫項目了。這時候項目經理所做的就是将自己調研階段了解透徹的需求分析講解給每一個開發人員。大家共同協作推進項目進度。此時這個團隊裡面需要進行必要的溝通，保證每個環節不出現不必要的差錯。這時候項目經理就是這個環節的協調者（謹慎行事，這裡如果控制不好将對以後的驗收帶來困難）。這個階段應該是加快速度開發完成。完成具體子產品的功能，經過測試部門測試通過。

　　2）中期階段開發 

　　進入中期，将初期開發的成果傳遞客戶試用，讓客戶提出應用界面的修改意見（注意：這裡是界面的修改意見。如果功能需要修改這時候你就可以拿出以前确認的文檔去說事了。是以前期的需求調研客戶确認需求開發文檔是非常重要的。這時候就是拿來力争的憑據。）如果需要加功能在改動不打得情況下可以做為一種服務性質來更改。如果需要改動項目的底層背景可就要嚴格控制了。 

　　4）  後期開發收尾 

　　到了這個階段經過前兩個階段不斷的修改，這裡應該是離終點線不遠的地方了。也應該是準備臨門一腳的時刻。這裡經過修改後基本上達到了客戶的滿意是時候可以讓客戶進行相關的上線測試使用階段了。這裡要堅決杜絕客戶的需求提出，能做的僅僅是調試工作。項目組成員開始整理整個項目的開發文檔傳遞項目經理整合，以備驗收階段。 

　　四、項目驗收 

　　項目的驗收主要的就是看整個開發過程中是否能嚴格的按照“代碼+注釋+文檔”的過程來了。如果到項目完成後再去補齊項目文檔也是可以的，當然如果可以提前做的工作盡量的提前作好。以免突擊出來的文檔被打回。 

　　五、項目的經驗總結 

　　這個就看個人了，看你是否在這個項目當中得到經驗的積累，知識技巧的提升了。 

　　六、整個項目中項目經理擔當的角色

　　在整個項目中，項目經理的位置要擺正，你是一個技術型的經理，還是溝通型的經理。這裡的技術型和溝通型是相對而說的。技術型的經理往往自己獨裁比較嚴重，不能有效地聽取采納他人意見（這裡注意：畢竟你是經理，是一位協調人不是總裁，不能一味的獨斷專行。這種做法容易讓你很難接受一些新的理念）。溝通型的相對來說容易聽取别人提出的建議，但是不能絕對聽取，因為你才是最後的決定者。可以通過一些方式和實際的結果來證明你所采用的方案優于别人。