示例結構：  

項目管理方法-總結

概要

項目經理的工作包括這些方面：

需求、團隊日常、任務、文檔。

需求管理：完成“需求”是核心目標，流程化、風險可控化是手段。

團隊規(guī)范：項目經理需要整理出“團隊規(guī)范”、書面化標準，以明確要求，避免反復口頭傳達要求。

任務管理：任務可跟進，是達成“需求”、項目正常運轉的保障。

文檔管理：需要引導明確要求，組織好文件存放的層級結構，以可持續(xù)的更新。 是項目長治久安的保障。

需求各階段管理

需求溝通

評估需求是否達到可以分析的詳細程度，是否外部達到啟動條件，如果不能達到，可以拒絕花費時間分析。

細節(jié)工作可以下發(fā)，但項目經理要對需求內容整體都了解

將需求匯總到項目組的“需求跟蹤表”中。

建立該需求的臨時資料svn目錄，如：“4.55精品商務經濟座積分”，保存需求文檔及后續(xù)文檔。

立項

完成《開發(fā)方案》、wbs、流程圖、樣式設計（RP軟件），示例： 

XX方案設計v1.docx

XX開發(fā)wbs-1.mpp

業(yè)務流程圖-開發(fā)流程圖-供參考.vsdx

1.rp

后續(xù)重要溝通結論、識別的新問題，及時補充到《開發(fā)方案》或專有主題的文檔。

避免單個開發(fā)人員總攬方案，而沒有多人評審環(huán)節(jié)，這樣容易出現功能設計風險問題。

《開發(fā)方案》中包含功能設計、風險點、待溝通問題、對接項目組及負責人及時間點、性能、可用性等的考慮。

將風險點加入項目組的“風險跟蹤”中。

將開發(fā)、測試、上線時間點、對接時間點、uat測試時間等加入“需求里程碑跟蹤”表。要求產品經理也要關注與其相關的時間點。

開發(fā)

開發(fā)人員對《開發(fā)方案》中不夠詳細的詳細處理流程，使用易交流的方式補全。

完成srs，完成輸入輸出等詳細約束、定義

代碼分支開發(fā)，sql腳本、部署說明文檔，按代碼分支保存。

將分支名加入“代碼分支跟蹤表”

測試

測試人員梳理測試點，以達到理解一致。需要考慮上線后的驗證方法、過程。有需要功能開發(fā)幫助測試驗證的內容，提前提出。

使用工具記錄、處理bug

預驗收、培訓

上線前需要及時組織產品經理、業(yè)務人員，對功能做uat測試，培訓（立項時預約時間點）?？捎行p少體驗問題。

發(fā)布

準備上線發(fā)布步驟、清單等信息，準備線上驗證點、步驟、時間點計劃。

安排一人整體協調發(fā)布過程。

涉及外部聯調，提前準備接口地址、賬號等信息。

線上跟蹤

上線后，一周內需要關注相關功能的錯誤日志、服務日志。有問題優(yōu)先解決。

更新“代碼分支跟蹤表”

更新“線上服務配置信息匯總”，包括配置參數、日志關鍵字等。

將《開發(fā)方案》的功能點細則，合并到“業(yè)務規(guī)則”文檔

更新“功能日常維護人員表”

更新“依賴的接口及匯總、依賴的接口及匯總”，包括接口、數據的外部項目組負責人、接口地址等信息。

新上線的項目，要更新“線上發(fā)布記錄”

日常運維

項目上線后，可考慮加入系統的監(jiān)控系統，如“數據量變化監(jiān)控功能”

響應業(yè)務部門對功能的咨詢

響應其它項目組對接口、業(yè)務的咨詢

處理線上問題、bug

盡量及時處理舊問題，避免合并到新問題一起處理。

業(yè)務咨詢的問題，及時補充到“業(yè)務規(guī)則”或“用戶手冊（單獨空間）”。

其它注意點

某需求分拆多次上線的，要跟蹤多次對應的時間點。

一個需求中，既有新功能，又有對原功能的修改時，要考慮修改原功能產生的風險大小，如果大的話，分拆上線是否可以減小風險。

修改多個原有功能時，也要考慮產生的風險大小，是否可以分拆上線，減少風險。因為分拆后，可以及時驗證、關注該功能點的影響。

需求分期模板

 投入產出分析、結項

項目的目的是產出效益。在可能的情況下，接收需求前分析投入產出，是否值得做。

在新項目上線初步穩(wěn)定后，結項、評估實際投入產出效益。之后轉為維護與優(yōu)化項目。

大的版本變更需求，作為獨立項目開啟，評估投入產出效益。之后重新變?yōu)椤熬S護與優(yōu)化項目”。

團隊管理

目標：團隊高效高質完成任務，提升團隊成員能力。

“需求跟蹤表”

需求跟蹤表

工作量跟蹤表

   基于任務的分配記錄，匯總每個成員未來幾個月所負責的任務。

工作量跟蹤表

日常記要、臨時任務

臨時任務跟蹤

臨時任務、日常記錄-20年

人員請假、加班記錄

請假、加班記錄

臨時績效記錄

臨時績效記錄

技術分享、學習

技術分享（單獨空間，多項目組共享，按標簽導航）

技術分享記錄

環(huán)境賬號管理

測試環(huán)境的服務器、數據庫賬號等，可考慮不同人不同賬號權限、不對部分人公開賬號。

測試環(huán)境資源賬號管理（受限）

線上資源賬號管理（受限）

團隊動員、鼓舞、團建，等團隊協作提高

尋找適當自己的方式，提高團隊協作。

晨會、周會等溝通方式

使用晨會、周會、每天任務檢查等方式，保持有效溝通和跟蹤。

團隊規(guī)范

項目經理需要整理出“團隊規(guī)范”、書面化標準，以明確要求，避免反復口頭傳達要求。

詳見目錄：項目組規(guī)范

代碼管理

“代碼分支跟蹤表”

分支管理，避免分支、需求 被遺漏發(fā)布，所以需要分支命名規(guī)范、分支信息做記錄。

分支命名：f_需求編號(4.58)_功能名

代碼分支管理

數據庫架構版本管理

數據庫架構的版本變更，可以導出生成數據庫的腳本，在git中跟蹤變更。

測試數據庫定時備份

測試、開發(fā)數據庫，還可以考慮定時備份，避免人為誤刪除。

git子項目管理

不同子項目互相引用時，為了單個項目的代碼量可控，宜對git項目進行拆分到相對獨立的模塊大小。

git子項目管理SubModule

公共類、分層管理

多人合作開發(fā)，不可避免各有各的風格、溝通不及時。公共類、項目代碼分層，需要指定一兩個資深開發(fā)人員負責，其他人需要與他們溝通后，按要求放置。

負責人要把“公共類、分層管理”的邏輯形成文檔。

項目拆分、公共類管理信息

代碼規(guī)范，代碼走查，規(guī)范完善

基礎的代碼規(guī)范要求

日常代碼走查的制度，檢查結果記錄文檔。

將走查到的突出問題，整理到規(guī)范要求并提供示例。

代碼走查-范例收集

提交測試要求

提交測試前，要求開發(fā)自測、單元測試（視項目組制度）、代碼走查，方可提交測試。

系統組成、應用列表

00系統組成

發(fā)布包版本

單應用的發(fā)布包（測試環(huán)境），也可以放單個git項目中，以方便提取發(fā)布包到線上。

任務管理

任務分類

包括：

需求任務拆分

臨時任務、問題處理

總結、周期任務、日常任務

任務管理原則

任務責任制，被指派任務人，承擔完成任務的主要責任。需要尋求他人支持時要講明背景、詳細信息、需要的支持內容，帶著可選方案提出問題。

任務分配，要有記錄可查，任務要求提前在項目組規(guī)范中說明。避免大家對任務的范圍、質量要求理解不一致。

每天需要及時在redmine中登記工時在相應任務下。如同時做多個任務，可分別登記工時（注釋中寫工作內容）。同時更新完成百分比、狀態(tài)。

需要拆分任務到一個個可以標記是否完成的“交付物任務包”，而不是都標記完成百分比，卻沒有一個可以完結的任務。

例如：拆分一個功能的任務為：開發(fā)完成（可提測）、文檔、bug修復、部署

項目信息中，可查看所有工時登記

項目經理，可以視情況將任務細分到大小不同的粒度。成員可以對任務繼續(xù)做細分，但不能新添同級任務。識別出新的任務時，應由項目經理創(chuàng)建同級任務。

項目經理每天關注“進行中的大任務的進度”、每個成員的工時填寫情況。

 團隊協作：
項目團隊作為一個整體，必須團結一致、同心協力，為實現項目目標而共同努力。在項目中，項目的成功是團隊成功的基礎，團隊的成功又是個人成功的前提。因此每一位項目成員都必須以項目目標為重，以團隊業(yè)績?yōu)橹?，并為之付出努力?br>當某些項目成員遇到困難時，應該充分發(fā)揮團隊的力量，發(fā)揚互幫互助的精神共同解決問題。在項目團隊中，每一位項目成員都有義務在力所能及的方位內，為其他項目成員提供幫助。

任務安排與服從：
在項目建設過程中，項目成員可以對項目經理的任務安排提出異議，但項目經理仍有最終決定權。對于項目經理最終決定的任務安排，項目成員應無條件地服從。

記錄方式 

redmine需求關聯體系方案

IT現有redmine體系 沒有很好講解設計原則，項目組可操作性差。

redmine項目，應以部門、項目組為管理主體，方便他們集中管理。

業(yè)務需求、IT產品需求、項目組版本任務，彼此關聯。

年度計劃，需要提前錄入“IT需求”項目做跟蹤管理 。

redmine項目組任務管理

項目組任務包括：需求工時、臨時任務（線上bug、問題分析、待處理bug或優(yōu)化、支持外部工時）、日常任務（日常任務、周期任務）。

某類臨時任務，能提前識別并指派的，就歸為日常任務。
如果使用redmine替代qc記錄bug，則一個redmine項目記新需求工時、臨時任務，另一個記bug跟蹤。

使用“跟蹤任務”列（或“跟蹤”=“任務跟蹤”，推薦前一種方式），識別每個人在處理哪些任務。每個人同時在處理的任務數應在3~5個以內。“跟蹤任務”另可加自定義屬性“質量打分”（1~5分，用于績效計算=計劃工時*“質量打分”）

redmine任務管理有一個問題：添加子任務時，會把父任務的計劃日期、計劃工時覆蓋掉，所以需要3個新屬性來記錄（當子任務尚未全創(chuàng)建完時）。

或配置不隨子任務變化。

需求的里程碑，也可以創(chuàng)建一條redmine任務（“跟蹤”=“里程碑”），跟蹤時間點。 相比不如在wiki里直觀。

開發(fā)階段bug修復的任務如何編排

方式一（推薦）：排在“測試”期間，按人建bug修復任務。發(fā)布也是一樣，按人建任務。

方式二：開發(fā)任務工時包含bug修復工時，但計劃完成時間僅指編碼實現。

confluence任務跟蹤方式

效果：  

 使用方法： 創(chuàng)建任務跟蹤

文檔管理

推薦方式：

wiki為主，svn為輔的方式管理文檔。

svn里按需求分文件夾，命名類似如下：

上線時，將svn目錄中的文檔拆分、合并到wiki中（開發(fā)方案、數據字典、線上服務信息、配置賬號等）。

開發(fā)方案 分為兩個：一個概要（功能點與規(guī)則，上線后合并到 業(yè)務規(guī)則）、另一個是詳細設計（補充細節(jié)規(guī)則、實現邏輯，上線后合并到開發(fā)方案）

測試整理的文檔，存在 測試文檔

備選方案：某功能的”開發(fā)方案“，做為該功能的“業(yè)務規(guī)則”的子節(jié)點。

關于“業(yè)務規(guī)則”的書寫，建議項目經理先做幾次示范，以后的再分配給成員做，并自己檢查修正后使用。

各類工具的比較

使用svn的話，操作繁瑣，不方便頻繁變更、高效交流。不建議組織一個很大的文件，在svn里頻率更新。

使用wiki的話，部分文檔類型不夠強大，還是需要線下再處理一些文檔（excel、word、project、思維導圖、流程圖等）。

wiki中文檔結構

部門級技術分享管理

示例：0使用說明

1.在”技術分享“下創(chuàng)建文檔

2.為技術文檔添加技術名詞標簽

3.在”技術分享“頁面，可以按標簽搜索文檔