在從事開發時，往往思考的是具體開發問題，如何提高程式碼質量，如何加快開發過程，將採用什麼新技術等等，偶爾也會以開發的角度思考專案管理中該如何如何；等到從事專案管理時，考慮的主要問題是如何按工期、高質量、快捷、低風險的完成專案開發，圍繞此主題，結合專案情況和以前的經驗，制訂出各種專案管理的策略和計劃；下面，結合專案開發談談體會。
籌備階段
1. 召開專案誓師大會，討論形成一致共識；
在下達專案開發任務後，組織團隊成員召開討論會；通過介紹專案任務，引導大家一起討論專案改如何進行，暢所欲言，傾聽意見和建議，最終形成一致共識；這樣做的目的：一是讓團隊提前進入專案狀態；二是調動團隊對專案的積極性；三是達成專案過程中一些基本原則，比如嚴格服從開發管理、所有問題都是團隊的問題等等。
2. 對團隊成員的性格有個基本瞭解；
對成員性格瞭解後，有利於彼此交流，有利於開展工作，可減少交流中的衝突點。
3. 專案經理要向團隊闡述自己的做事方式方法；
比如，開發中遇到重大問題，要提出來大家一起商量解決。
4. 對團隊成員的技術水平有個基本的把握；
這點非常重要，專案開發過程中採用技術含量高低，就來源於這裡，比如Hibernate技術，如果團隊成員有1/2熟練運用，且專案經理包括在內，就完全可以採用此技術；另外，通過對技術水平的瞭解，在專案開發時可以有個側重點，對技術水平低的多些關注，技術高的也可以幫助解決問題。
5. 明確要求的事必須不折不扣的執行；
在專案開發過程中，會要求團隊執行各種標準、開發要求等，這些都必須得到徹底執行，才能最大限度提高軟體的質量。
需求階段
6. 開會整體介紹、討論需求，分配開發模組；
7. 各自閱讀需求文件，列出疑問點；開會討論，列出剩餘疑問，提交業主或需求人員；
以上是本人理解需求的基本思路，屢試不爽。
8. 此階段測試人員必須介入；
測試人員提前理解需求，對測試工作非常有幫助，儘快制訂測試用例，編寫測試計劃，提高測試質量；另外，如果現在不介入，等到提交功能測試時，再理解需求，就影響專案進度，而且費時費力。
9. 需求階段必須實現對需求至少60%的理解度；
通過6、7兩種方式，實現這個目標問題不大。
設計階段
10. 要求開發人員書寫部分詳細設計文件,包括程式結構圖、IPO圖(輸入、處理、輸出)、演算法、資料流程圖、操作流程圖、系統頁面設計等等；
這樣可以進一步加深對業務的理解，需求理解度達到80%以上；從開發的角度，思考軟體的實現方式，明確業務流程等等，這樣在開發階段就可以專著於具體程式碼書寫。
11. 整理準備所有的Cell報表,要求加入輸入限制、公式等；
12. 要用陌生技術的開發人員,要及時閱讀相關資料,做好技術準備；
開發過程中，有時需要用到陌生技術，這時要給予相關人員一定時間來閱讀學習。
13. 原則上統一設計資料庫模型；
這樣做目的是規範資料庫的設計，統一標準，統一模型，統一部署；如果資料庫設計量較大，可以允許開發人員單獨設計，但要嚴格遵循設計規範，設計完交資料庫工程師（或專案經理），確認方可部署到庫裡；經驗證明這樣做可以避免很多問題，比如資料庫設計混亂，資料庫版本混亂。
14. 此階段需要開發人員做許多工作，要加強監督檢查，以保質保量的完成工作；
對於工作內容安排,開發人員必須絕對的支援和執行,不能打折扣或者跳躍工作內容,讓做這個他做那個。
開發/測試階段
15. 在開發前期統一開發工具；
開發工具統一非常重要，可避免很多潛在的問題，比如由於JDK版本不同，導致整合版本後無法正常執行，Tomcat版本不同也會如此；開發工具統一如下“JDK1.4 Eclipse3.1 MyEclipse4.1 Tomcat5.0 SQL Server2000”。
16. 商討將要運用那些開發技術(如Struts、Ajax、Hibernate、Spring等);
採用技術的原則是團隊必須1/2成員會用。
17. 參考行業標準和實際要求，制訂詳細的程式碼書寫規範和程式碼結構要求；
通過規範要求可相對的提高程式碼質量，使專案更接近一個人開發出來的，增強程式碼的可讀性，最重要的是增加程式碼的可維護性，長期來看降低了專案的風險性，從公司發展上看，有利於技術的沉澱積累。
先開發部分程式,然後一起閱讀部分程式碼,檢查程式碼規範執行的情況,包括類和JSP等;同時,也看看程式碼的書寫思路是否有問題,特別是書寫的結構是否規範等,現場解釋解決問題,最終完善出一套具體的程式碼書寫規範,以及程式書寫的結構思路規範出來,列如下:
a．類及方法都要有註釋;
b．方法中的變數和程式塊,要有註釋;
c．頁面也要有註釋,比如頁面所屬、JS方法註釋等等;
d．每次頁面動作只能建立一次資料庫連線並用完及時關掉;
e．資料庫連線取得、使用、關閉的程式塊,得按照制訂的模式書寫;
f．對資料庫進行新增、修改、刪除操作時,一定要運用事務機制(系統底層已經封裝,注意呼叫就可以實現);
g. 在構架每次頁面動作的業務類時,要嚴格按照MVC的結構書寫,同時完全運用Struct思想;
h. 對於異常的報出,呼叫公共類,輸出相應”類名、方法、說明”;
i. 頁面上不允許做任何的訪問資料庫或業務操作,只可以顯示、獲取資料;
注意呼叫一些公共類,可以減少工作量,也使程式模組化,比如”專案列表” 、”標段列表” 、”編制範圍”的生成程式等等。
18. 與測試組交流,商討專案測試目標,瞭解測試報告和測試用例準備情況；
19. 部分模組開發完成，馬上提交同步測試，對測試問題及時進行修改；
20. 注意對測試問題的累加、分類，及時進行復測；
21. 定期開會一起討論測試問題，找出問題出現的原因，及時調整開發方式，加強工作細心態度，爭取類似的問題不再出現；這樣可有效的降低BUG出現率；
22. 積極協調開發進度，協調好開發與測試的關係；
在軟體開發中，開發與測試是最容易產生矛盾的雙方，但是他們協調工作的效果高低，直接影響專案軟體的質量；專案經理要營造一個良好的工作氣氛，當出現矛盾時，及時的協調化解，推動測試進度。
23. 開發人員遇到難解問題時，要及時幫助解決，困難的開會商討，千萬不能積壓問題，因為這往往是關鍵點問題，不解決會極大的影響開發進度；
24. 每週都要開會了解開發進度情況，及時把握專案進度，做到心中有數；
25. 要多協調、多商議、多交流，充分調動大家的積極性；
釋出階段
26. 書寫詳細釋出說明文件；
團隊建設
27. 考慮問題以成員為出發點,維護他們的基本利益,幫助做好輔助工作；
28. 可以不定期的組織茶話會，聊聊天，釋放工作壓力；
29. 與成員一起尋找利益的共同點，建立共同的價值觀，才能最大限度的凝聚力量，發揮主觀能動性；
30. 對成員要求不能急於求成，要循序漸進，共同進步；在不斷的歷練中，提高團隊的工作效率；
31. 採取民主集中的原則，用集體的力量解決問題；
以上就是本人在專案過程中一些體會，對於一般公司專案經理往往需要身兼數職，比如構架、設計、管理、協調等，所以專案涉及的方面比較複雜；如果簡單的從專案出發，關注點是如何保質保量、低風險的完成專案任務；但是經過數個專案後，才發現專案不是最重要的，重要的是團隊建設和公司產品技術的積澱，在專案開發過程中形成一支高效的團隊，經過幾個專案的磨合，團隊的開發效率將得到極大的提高，公司產品技術得到有效累積，這時專案只是團隊工作過程中的積澱的產物而已；不過有個問題，往往公司的開發人員是隨機組合的，對此可採取相對穩定團隊，保持團隊的基本構架不變即可。