一 專案管理流程
1 專案定義
在有限的時間、有限的人力、有限的資源內，完成即定的功能，並保證專案的質量。
專案具有時效性/資源受限，功能邊界明確等特點。
專案失敗，並不僅僅是指專案的功能沒有完成。超時/超支都算做專案失敗。
2 專案管理目標
可重複：專案的成功性可複製。乙個專案成功，另乙個專案也可以成功。成功不是偶然性。
可管理：專案本身可管理，成功過程可控。
3 專案生命週期
專案具有固有的生命週期規律，專案管理需要遵循該規律，不要過分重視產出（壓縮時間），否則影響長期的穩定的產出（同樣體現專案管理的可重複、可管理）。
專案生命週期分：需求意向 需求階段 開發階段 測試階段 維護階段。下圖給出乙個模擬示例：
其中需求結束、開發結束、版本正式發布（測試結束）均為里程碑。
4 參與專案的角色
參與專案的主要角色有：專案管理人員/需求人員/研發人員/測試人員/配置人員/實施人員。他們分階段進入專案，分階段離開專案。下圖為人力投入示例：其中需求**發生在立項之前，不予考慮，另產品人員需要參加需求文件review，屬專案外，不考慮。
專案管理人員需要全程跟蹤專案，尤其是立項點、需求文件review、需求結束、設計文件review、設計結束、測試期間以後進入維護期後。
需求人員除需求階段，還需要參與設計文件review、測試文件review。
開發人員除開發階段，還需要參與需求文件review，以及測試期間bug修復、維護期保留部分人力。
測試人員除開發階段，還需要參與需求文件review。
二 專案階段
1 立項
立項初期，更多的是資源申請、人力安排計畫等。儘量減少以後的溝通成本，比如確定專案編號、階段編號、功能編號、模組名（如果能夠確定）、各模板版本號格式、系統部署的軟硬體平台等。
2 需求階段
該階段是專案最重要的階段，代表了專案的使命。該階段的產出需求文件則是專案最重要最核心的一片文件，是設計文件、測試用例以及後期維護的依據。
需求文件的用語應該是明確的、無歧義的。比如 「包含...但不限於這些...」、「這些功能請研發人員靈活掌握」「請參考某某**/請參照某某專案的樣子」都屬於不合格的用語。
需求文件整體內容應該是封閉的，不依賴於任何未知的內容，引用的外部文件需要嵌在需求文件中，或者給出文件號，可以在團隊的文件庫中查詢到。為更好的理解需求文件的封閉性，舉例說明，比如要實現sip棧， 需求文件應該給出sip協議的介紹以及做到什麼程度，研發不需要自己去看rfc文件， 只需要參照需求文件去開發即可。另任何業務上的知識盲點， 需求人員都要給開發人員解決，開發人員在任何時候(需求文件review中或者設計文件中或者開發中)發現知識盲點，都可以反饋給需求人員，要求給予支援或解決。
需求文件需要明確定義系統的功能邊界
開發階段可以細分為設計文件階段、編碼階段、測試階段。其中重要的是前期設計和後期的測試階段。
設計文件中，開發人員要從各個角度向別人展示自己的系統，包括部署圖（在網路中的位置）、模組圖、資料流向圖、靜態類圖、互動圖、狀態圖 關鍵資料結構等，最終需要能體現需求文件要求的功能。
研發測試階段請參見測試系列之 c++ server測試全攻略
，其中白盒測試、記憶體測試、壓力測試必做，同時陪測程式需要和原始碼一併提交在版本管理工具中。完善的log資訊和必要的陪測工具是系統質量的保障。
開發階段結束後，原始碼/二進位製包上傳、**行統計、各種文件入庫、defect入庫。
4 測試階段
測試人員的測試用例、結果必須文件化。專項測試需要包含以下部分：測試目的、測試方法、測試環境、附測試指令碼、測試結果。
測試人員不僅需要測試系統，在實施和維護期間更要回答現場人員的諮詢。
測試結束，各種文件入庫、defect入庫，使用者文件產生、版本打標記或者打基線，作為以後開發的基礎。
5 實施階段
專案管理理論容易給人以錯覺，好象只要有了規範的專案管理流程，就可以保證專案的成功可重複/成功過程可控制。但事實往往並不是這麼如意。
專案管理的順利進行依賴於團隊的基礎建設：團隊人員組成、基礎**庫、基礎模組庫等。沒有完備的團隊和一定的基礎積累，談不上專案得可重複與可管理性。
成熟的團隊中，專案的主角是需求人員、開發人員、測試人員。需求是個迭代的過程，是在已有系統或模組上持續擴充的過程。開發是充實基礎庫與模組庫，在已有基礎**庫和基礎協議棧之上實現業務的過程。測試是乙個測試工具積累的過程。完備的積累是專案成功的可靠保證。
總體來說，專案管理和團隊建設相輔相成，共同發展，公司在不同的時期，偏重不同，初期重團隊建設，成熟期重專案管理。
五 具體問題具體分析
專案管理流程並非一層不變。針對專案的規模和複雜性，可分大專案、小專案、mini專案。有的專案很小，不需要寫需求文件，可能只需要增加乙個changerequest，也可能不需要寫設計文件。以保證小專案的靈活性和響應及時性。後期的補充正確區分defect和changerequest。需求一定要遞交到需求人員，以便其把握整個系統以及後續架構的走向。
（首次發表於http://www.cppblog.com/cppexplore/archive/2009/09/18/96668.html）
係分專案 個人小結
負責擔當需求分析 互動設計部分。psp2.1 小時 nikkariaoe 計畫5 估計這個任務需要多少時間 5開發78 需求分析 包括學習新技術 24 生成設計文件 20 設計複審 和同事審核設計文件 10 規範 為目前的開發制定合適的規範 0 具體設計 24 具體編碼 0 複審 0 測試 自我測試...
個人小結 測試
結束了在測試的工作，一直想寫點東西 1.測試首先是為個讓使用者能用，不會報錯，然後才能談到其他比如易用性，解析度等不會常用的功能,所以測試就要有重點 2.自動化測試在版本測試中用處也不大,前期投入太大,收益太小,自動化一般用於回歸測試,執行一輪測試中錄製好的指令碼,檢查修改bug時是否導致其他功能點...
2013個人小結
昨天開了年會，明天就放假了。想寫點東西記錄下2013年的得失，就算是對自己內心的一點交代。在這一年裡，對我來說，發生了很多改變。有收穫，也有失去 有歡樂，也有傷悲。一 關於工作。不僅僅是換了新公司，在新公司裡工作崗位也換過一次。從專案經理轉變成產品經理，對個人來說是個不小的挑戰，一直充滿激情的對待，...