示例結構：  

項目管理方法-總結

概要

項目經(jīng)理的工作包括這些方面：

需求、團隊日常、任務(wù)、文檔。

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

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

任務(wù)管理：任務(wù)可跟進(jìn)，是達成“需求”、項目正常運轉的保障。

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

需求各階段管理

需求溝通

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

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

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

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

立項

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

XX方案設計v1.docx

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

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

1.rp

后續重要溝通結論、識別的新問(wèn)題，及時(shí)補充到《開(kāi)發(fā)方案》或專(zhuān)有主題的文檔。

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

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

將風(fēng)險點(diǎn)加入項目組的“風(fēng)險跟蹤”中。

將開(kāi)發(fā)、測試、上線(xiàn)時(shí)間點(diǎn)、對接時(shí)間點(diǎn)、uat測試時(shí)間等加入“需求里程碑跟蹤”表。要求產(chǎn)品經(jīng)理也要關(guān)注與其相關(guān)的時(shí)間點(diǎn)。

開(kāi)發(fā)

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

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

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

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

測試

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

使用工具記錄、處理bug

預驗收、培訓

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

發(fā)布

準備上線(xiàn)發(fā)布步驟、清單等信息，準備線(xiàn)上驗證點(diǎn)、步驟、時(shí)間點(diǎn)計劃。

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

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

線(xiàn)上跟蹤

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

更新“代碼分支跟蹤表”

更新“線(xiàn)上服務(wù)配置信息匯總”，包括配置參數、日志關(guān)鍵字等。

將《開(kāi)發(fā)方案》的功能點(diǎn)細則，合并到“業(yè)務(wù)規則”文檔

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

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

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

日常運維

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

響應業(yè)務(wù)部門(mén)對功能的咨詢(xún)

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

處理線(xiàn)上問(wèn)題、bug

盡量及時(shí)處理舊問(wèn)題，避免合并到新問(wèn)題一起處理。

業(yè)務(wù)咨詢(xún)的問(wèn)題，及時(shí)補充到“業(yè)務(wù)規則”或“用戶(hù)手冊（單獨空間）”。

其它注意點(diǎn)

某需求分拆多次上線(xiàn)的，要跟蹤多次對應的時(shí)間點(diǎn)。

一個(gè)需求中，既有新功能，又有對原功能的修改時(shí)，要考慮修改原功能產(chǎn)生的風(fēng)險大小，如果大的話(huà)，分拆上線(xiàn)是否可以減小風(fēng)險。

修改多個(gè)原有功能時(shí)，也要考慮產(chǎn)生的風(fēng)險大小，是否可以分拆上線(xiàn)，減少風(fēng)險。因為分拆后，可以及時(shí)驗證、關(guān)注該功能點(diǎn)的影響。

需求分期模板

 投入產(chǎn)出分析、結項

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

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

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

團隊管理

目標：團隊高效高質(zhì)完成任務(wù)，提升團隊成員能力。

“需求跟蹤表”

需求跟蹤表

工作量跟蹤表

   基于任務(wù)的分配記錄，匯總每個(gè)成員未來(lái)幾個(gè)月所負責的任務(wù)。

工作量跟蹤表

日常記要、臨時(shí)任務(wù)

臨時(shí)任務(wù)跟蹤

臨時(shí)任務(wù)、日常記錄-20年

人員請假、加班記錄

請假、加班記錄

臨時(shí)績(jì)效記錄

臨時(shí)績(jì)效記錄

技術(shù)分享、學(xué)習

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

技術(shù)分享記錄

環(huán)境賬號管理

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

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

線(xiàn)上資源賬號管理（受限）

團隊動(dòng)員、鼓舞、團建，等團隊協(xié)作提高

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

晨會(huì )、周會(huì )等溝通方式

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

團隊規范

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

詳見(jiàn)目錄：項目組規范

代碼管理

“代碼分支跟蹤表”

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

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

代碼分支管理

數據庫架構版本管理

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

測試數據庫定時(shí)備份

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

git子項目管理

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

git子項目管理SubModule

公共類(lèi)、分層管理

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

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

項目拆分、公共類(lèi)管理信息

代碼規范，代碼走查，規范完善

基礎的代碼規范要求

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

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

代碼走查-范例收集

提交測試要求

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

系統組成、應用列表

00系統組成

發(fā)布包版本

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

任務(wù)管理

任務(wù)分類(lèi)

包括：

需求任務(wù)拆分

臨時(shí)任務(wù)、問(wèn)題處理

總結、周期任務(wù)、日常任務(wù)

任務(wù)管理原則

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

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

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

需要拆分任務(wù)到一個(gè)個(gè)可以標記是否完成的“交付物任務(wù)包”，而不是都標記完成百分比，卻沒(méi)有一個(gè)可以完結的任務(wù)。

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

項目信息中，可查看所有工時(shí)登記

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

項目經(jīng)理每天關(guān)注“進(jìn)行中的大任務(wù)的進(jìn)度”、每個(gè)成員的工時(shí)填寫(xiě)情況。

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

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

記錄方式 

redmine需求關(guān)聯(lián)體系方案

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

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

業(yè)務(wù)需求、IT產(chǎn)品需求、項目組版本任務(wù)，彼此關(guān)聯(lián)。

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

redmine項目組任務(wù)管理

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

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

使用“跟蹤任務(wù)”列（或“跟蹤”=“任務(wù)跟蹤”，推薦前一種方式），識別每個(gè)人在處理哪些任務(wù)。每個(gè)人同時(shí)在處理的任務(wù)數應在3~5個(gè)以?xún)取?span style="color:red">“跟蹤任務(wù)”另可加自定義屬性“質(zhì)量打分”（1~5分，用于績(jì)效計算=計劃工時(shí)*“質(zhì)量打分”）

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

或配置不隨子任務(wù)變化。

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

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

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

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

confluence任務(wù)跟蹤方式

效果：  

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

文檔管理

推薦方式：

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

svn里按需求分文件夾，命名類(lèi)似如下：

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

開(kāi)發(fā)方案 分為兩個(gè)：一個(gè)概要（功能點(diǎn)與規則，上線(xiàn)后合并到 業(yè)務(wù)規則）、另一個(gè)是詳細設計（補充細節規則、實(shí)現邏輯，上線(xiàn)后合并到開(kāi)發(fā)方案）

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

備選方案：某功能的”開(kāi)發(fā)方案“，做為該功能的“業(yè)務(wù)規則”的子節點(diǎn)。

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

各類(lèi)工具的比較

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

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

wiki中文檔結構

部門(mén)級技術(shù)分享管理

示例：0使用說(shuō)明

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

2.為技術(shù)文檔添加技術(shù)名詞標簽

3.在”技術(shù)分享“頁(yè)面，可以按標簽搜索文檔