作者：CppExplore 網址：http://www.shnenglu.com/CppExplore/
一 項目管理流程
1 項目定義
在有限的時間、有限的人力、有限的資源內，完成即定的功能，并保證項目的質量。
項目具有時效性/資源受限，功能邊界明確等特點。
項目失敗，并不僅僅是指項目的功能沒有完成。超時/超支都算做項目失敗。
2 項目管理目標
可重復：項目的成功性可復制。一個項目成功，另一個項目也可以成功。成功不是偶然性。
可管理：項目本身可管理，成功過程可控。
3 項目生命周期
項目具有固有的生命周期規律，項目管理需要遵循該規律，不要過分重視產出（壓縮時間），否則影響長期的穩定的產出（同樣體現項目管理的可重復、可管理）。
項目生命周期分：需求意向 需求階段 開發階段 測試階段 維護階段。下圖給出一個模擬示例：
其中需求結束、開發結束、版本正式發布（測試結束）均為里程碑。
4 參與項目的角色
參與項目的主要角色有：項目管理人員/需求人員/研發人員/測試人員/配置人員/實施人員。他們分階段進入項目，分階段離開項目。下圖為人力投入示例： 其中需求來源發生在立項之前，不予考慮，另產品人員需要參加需求文檔review，屬項目外，不考慮。
項目管理人員需要全程跟蹤項目，尤其是立項點、需求文檔review、需求結束、設計文檔review、設計結束、測試期間以后進入維護期后。
需求人員除需求階段，還需要參與設計文檔review、測試文檔review。
開發人員除開發階段，還需要參與需求文檔review，以及測試期間bug修復、維護期保留部分人力。
測試人員除開發階段，還需要參與需求文檔review。
二 項目階段
1 立項
立項初期，更多的是資源申請、人力安排計劃等。盡量減少以后的溝通成本，比如確定項目編號、階段編號、功能編號、模塊名（如果能夠確定）、各模板版本號格式、系統部署的軟硬件平臺等。
2 需求階段
該階段是項目最重要的階段，代表了項目的使命。該階段的產出需求文檔則是項目最重要最核心的一片文檔，是設計文檔、測試用例以及后期維護的依據。
需求文檔的用語應該是明確的、無歧義的。比如 “包含...但不限于這些...”、“這些功能請研發人員靈活掌握”“請參考某某網站/請參照某某項目的樣子”都屬于不合格的用語。
需求文檔整體內容應該是封閉的，不依賴于任何未知的內容，引用的外部文檔需要嵌在需求文檔中，或者給出文檔號，可以在團隊的文檔庫中查詢到。為更好的理解需求文檔的封閉性，舉例說明，比如要實現sip棧， 需求文檔應該給出sip協議的介紹以及做到什么程度，研發不需要自己去看rfc文檔， 只需要參照需求文檔去開發即可。另任何業務上的知識盲點， 需求人員都要給開發人員解決，開發人員在任何時候(需求文檔review中或者設計文檔中或者開發中)發現業務知識盲點，都可以反饋給需求人員，要求給予支持或解決。
需求文檔需要明確定義系統的功能邊界、系統的網元劃分、各個網元的外部特性。這里給出一個大體的提綱：要實現的功能點、網元劃分以及最后的部署方式、每個網元的功能點、復雜網元的內部模塊圖建議（可選）、網元間通訊接口、各網元間的交互時序圖、各個網元如何和其他網元交互完成前面的功能點。
其中各網元的交互時序圖需要能涵蓋網元間所有的交互，簡單的重復的交互也可用文字描述補充；網元間的通訊接口是明確的，每個命令中的字段名、類型、取值范圍都需要明確。
其他方面，比如性能要求、其他非功能性要求等，如果外部需求方有明確要求，可寫入文檔，否則可象征性寫一個一定可以滿足的值或者省略這部分（性能本身依賴于團隊的積累）。
在需求文檔review階段，產品人員可以審核考量是否已經滿足了預期的功能；開發人員可以審核考量是否已經明確了自己負責的模塊特性，是否不再需要和其他模塊的開發人員溝通確認某些接口上的問題；測試人員審核考量是否可以依據此寫出測試用例，不需要再向開發人員確認。

最后需求文檔defect入庫、文檔本身入庫。
3 開發階段
開發階段可以細分為設計文檔階段、編碼階段、測試階段。其中重要的是前期設計和后期的測試階段。
 設計文檔中，開發人員要從各個角度向別人展示自己的系統，包括部署圖（在網絡中的位置）、模塊圖、數據流向圖、靜態類圖、交互圖、狀態圖 關鍵數據結構等，最終需要能體現需求文檔要求的功能。
研發測試階段請參見測試系列之 c++ server測試全攻略，其中白盒測試、內存測試、壓力測試必做，同時陪測程序需要和源碼一并提交在版本管理工具中。完善的log信息和必要的陪測工具是系統質量的保障。
開發階段結束后，源碼/二進制包上傳、代碼行統計、各種文檔入庫、defect入庫。
4 測試階段
測試人員的測試用例、結果必須文檔化。專項測試需要包含以下部分：測試目的、測試方法、測試環境、附測試腳本、測試結果。
測試人員不僅需要測試系統，在實施和維護期間更要回答現場人員的咨詢。
測試結束，各種文檔入庫、defect入庫，用戶文檔產生、版本打標記或者打基線，作為以后開發的基礎。
5 實施階段
版本正式發布，基本標志項目結束。實施人員將作為以后現場支持的Level1級，測試人員為Level2級，研發人員為Level3級，屬于未實現的功能，轉需求人員。

說下bug數量，一般c/c++代碼每千行16-20個bug左右，研發和測試階段按一定比例劃分。bug過少，從某個角度可以看作測試力度不夠，過多可以看作代碼質量較差。任何時候，bug數量都不應當作為績效考核的標準。
以上階段中最重要的是需求階段，其次是研發階段的測試。
三 追求更好的項目管理流程
從某種程度上說，項目管理是一個團隊的習慣。
一個好的項目管理習慣，可以讓一個團隊的運作如行云流水，又如微風拂面。團隊成員各司其責，既是在工作 又何嘗不是一種享受。整個項目管理，就象... （就象...最近裝修，團購網上的標語：就象）喝茶那樣輕松。即便是這個團隊從公司脫離，在新的環境里也會保留以前的項目管理制度，從通訊企業里出走的團隊很多這種例子。
而一個差的項目管理習慣，則是一個團隊的噩夢。所謂的管理，可能流于形式，可能成為項目管理者的令箭牌，可能成為研發人員的催命符。
習慣的力量強大而可怕。不管是好的團隊還是差的團隊，遇到不符合自己習慣的改變，都會做出一致的決定：抵制。抵制的理由可能不同 ，有的是 我們現在已經運作的很好了，不需要做出改變，有的則是我們沒有那個能力去實施這個流程/我們人員有限/我們控制不住。改變后也不見的運作比現在差，改變后也不見得會浪費更多的人力，反而會有序，更節省人力，更利于控制。
養成習慣需要3個前提：知識（知道這么做是好的）、意愿（愿意這樣做）、可實施性（有明確的實施方法）。之后加上堅持，一定時間（21天）后就可以形成習慣。
看培養好的項目管理習慣就是這么簡單，真的就象喝茶那樣輕松。
四 團隊技術積累
項目管理理論容易給人以錯覺，好象只要有了規范的項目管理流程，就可以保證項目的成功可重復/成功過程可控制。但事實往往并不是這么如意。
項目管理的順利進行依賴于團隊的基礎建設：團隊人員組成、基礎代碼庫、基礎模塊庫等。沒有完備的團隊和一定的基礎積累，談不上項目得可重復與可管理性。
成熟的團隊中，項目的主角是需求人員、開發人員、測試人員。需求是個迭代的過程，是在已有系統或模塊上持續擴充的過程。開發是充實基礎庫與模塊庫，在已有基礎代碼庫和基礎協議棧之上實現業務的過程。測試是一個測試工具積累的過程。完備的積累是項目成功的可靠保證。
總體來說，項目管理和團隊建設相輔相成，共同發展，公司在不同的時期，偏重不同，初期重團隊建設，成熟期重項目管理。
五 具體問題具體分析
項目管理流程并非一層不變。針對項目的規模和復雜性，可分大項目、小項目、mini項目。有的項目很小，不需要寫需求文檔，可能只需要增加一個ChangeRequest，也可能不需要寫設計文檔。以保證小項目的靈活性和響應及時性。后期的補充正確區分defect和ChangeRequest。需求一定要遞交到需求人員，以便其把握整個系統以及后續架構的走向。