PM職責(zé)
項目干系人管理
|列出所有關(guān)系人：PM、PD、TC、前端、后端、其他負(fù)責(zé)人以及開發(fā)人員
l 項目動態(tài)及時通知相關(guān)責(zé)任人
l 建立項目管理群，相關(guān)文檔材料以及開發(fā)進度列入群公告中
- 透明化
l 項目價值、產(chǎn)品方案、技術(shù)方案、項目計劃、各個結(jié)論等全員共享
l 項目狀態(tài)、風(fēng)險、動態(tài)等即需要告知相關(guān)責(zé)任人，也需要同步效率平臺讓關(guān)注的人查閱
l 信息傳達(dá)要及時，相關(guān)知識要共享。
- 溝通機制
l 建立溝通機制，溝通群、郵件組
l 項目協(xié)同工具：效率平臺、jira、gitlab
l 溝通頻率、溝通反饋與同步
需要給各個角色提供什么信息，何時提供
明確在過程中需要溝通的環(huán)節(jié)以及各個環(huán)節(jié)需要確認(rèn)的問題與輸出
何時開會、會議主題、會議議程、計劃時長
- 有效溝通
l 告知可以反饋，但要注意告知范圍
l 溝通要有反饋確認(rèn)
l 會議要明確議題與議程，做好會議記錄、做好控場，避免跑題。
l 讓具體負(fù)責(zé)人直接溝通，消除中間環(huán)節(jié)，但注意溝通結(jié)果的信息同步
l 重要的事情說三遍
- 項目范圍
需求分解、變更必須和整個過程管理配合。
l 明確項目的核心價值，避免項目過度復(fù)雜或過度簡化，這是評估合適項目范圍的參考標(biāo)準(zhǔn)
l 需求管理：協(xié)助需求分解
l 變更管理
- 時間管理
組織任務(wù)分解，關(guān)鍵節(jié)點設(shè)定，計劃排期，跟蹤并應(yīng)急
l 工期估算
l 排期計劃
l 計劃跟蹤與修正
- 項目成本
跟蹤實際投入與產(chǎn)出，作為效率監(jiān)控
l 主要為資源投入、評估工作量，跟蹤相關(guān)工作量進展，為效率管理提供依據(jù)
- 項目質(zhì)量管理
l 產(chǎn)品方案評審
l 技術(shù)方案評審
l 驗收標(biāo)準(zhǔn)管理
l code review 的組織
l 測試計劃、測試范圍、測試用例評審等協(xié)調(diào)
l 測試報告
- 風(fēng)險管理
l 風(fēng)險識別
l 風(fēng)險分析
l 風(fēng)險應(yīng)對
l 風(fēng)險監(jiān)控
- 共享知識庫管理
l 需求、需求變更記錄及相關(guān)知識文檔（aone），討論記錄
l UI
l 技術(shù)方案，設(shè)計思路等
l 會議紀(jì)要(建議除郵件外,要有干系人共享的wiki版本)
l 排期計劃
l 發(fā)布計劃(部署方案)
l 測試計劃、測試用例、測試報告
過程管理
需求階段
需求收集、審批確認(rèn) —— 會議記錄、審批流程記入相關(guān)項目知識庫
建立項目知識庫，建立需求討論組
復(fù)雜的需要要制定需要計劃
l 需求收集
l 需求分析
l 評審記錄
l UI 設(shè)計
l 業(yè)務(wù)確認(rèn)
- 輸出產(chǎn)品方案(PRD、原型、UI)等
研發(fā)階段
需求評估 —— 簡易需求直接與需求評審會議合并，復(fù)雜的單獨組會評估
組織需求宣講
項目主要資源(產(chǎn)品\架構(gòu)\研發(fā)\測試\UED)對于項目進行整體評估
l 技術(shù)方案以及技術(shù)方案確認(rèn)
l 工作量評估（粗略保守估算）
l 資源評估
l 風(fēng)險評估（需求是否穩(wěn)定，資源是否充足、時間是否存在風(fēng)險，其他風(fēng)險）
l 可啟動開發(fā)條件是否充足
- 需求分解
l 用戶故事或者功能分解到適合一個迭代可完成的大?。ù致栽u估）
l 無法更細(xì)顆粒度分割不要強求分割，迭代時可按照任務(wù)分割
- 輸出項目排期計劃，整體迭代節(jié)奏，郵件通知相關(guān)責(zé)任人
迭代管理
組織迭代計劃會議，評估迭代內(nèi)完成的用戶故事\功能點\測試\UI,分解任務(wù),制定具體到天的迭代計劃,并輸出(郵件)給負(fù)責(zé)人，記錄到知識庫
組織每日立會(或隔日)
l 需要明確每個人最新進展、當(dāng)天計劃、遇到的問題，時間建議 15分鐘以內(nèi)，不討論具體時間，具體問題單組組會討論
l 小團隊項目，最新進度通過聊天同步即可(記錄到 doc 上)
l 需要跨組協(xié)作的項目，需要及時跨組進行同步
- 組織迭代演示及復(fù)盤
l 在項目上線前一兩天進行
l 在本階段完成的做一個簡單回顧
l 能演示的東西，向產(chǎn)品、測試或業(yè)務(wù)進行展示；可及時發(fā)現(xiàn)問題，增加大家對項目的了解，而不是等到開發(fā)完成才展示成果，有效提升項目信心、降低項目風(fēng)險。
l 迭代報告
- 測試計劃制定
l 盡早組織測試計劃制定，建議項目啟動測試即介入，尤其時研發(fā)兼PM時注意計劃、例會、演示等不要遺漏了測試同學(xué)
l 協(xié)調(diào)測試與產(chǎn)品溝通驗收條件（重點針對與需求場景而非功能點），含測試范圍（測試邊界），驗收標(biāo)準(zhǔn)，質(zhì)量標(biāo)準(zhǔn)，性能標(biāo)準(zhǔn)
l 協(xié)調(diào)測試輸出測試用例，進行用例評審
l 測試切入的時間計劃與資源安排
- 發(fā)布管理
l 制定發(fā)布計劃
l 多個項目的部署順序，是否依賴
l 部署步驟，各環(huán)節(jié)負(fù)責(zé)人，各環(huán)節(jié)部署時間
l 回滾計劃，或發(fā)布失敗的應(yīng)急方案
l 通知所有項目負(fù)責(zé)人，重要的負(fù)責(zé)人必須確認(rèn)
- 復(fù)盤（小項目直接通過迭代復(fù)盤）
l 回顧目標(biāo)
l 評估項目效果
l 總結(jié)做的好的地方，與不好的地方，并討論優(yōu)化思路
l 根據(jù)總結(jié)，形成行動計劃
效率管理
量化是我們評估項目投入，進度、效率的基礎(chǔ)。
推薦量化管理方案：
l 需求和任務(wù)要有工作量評估
l 以工作量評估作為基線，實際發(fā)生工作量做對比，評估進展，團隊效率
l 量化方式一（可閱讀Scrum相關(guān)資料）
l 盡量細(xì)化任務(wù)及需求,需求分解到一個迭代（兩周），做用戶故事點數(shù)或工作量評估（可細(xì)化到任務(wù)）
l 通過需求完成趨勢圖、需求燃盡圖作為效率衡量，在基準(zhǔn)線之上的項目要標(biāo)記為風(fēng)險
l 量化方式二（可閱讀掙值管理相關(guān)資料） <u>http://www.itdecent.cn/p/ffa22f2533a5</u>
根據(jù)項目評估項目價值（計劃值PV）
細(xì)化分解各個任務(wù)價值，作為任務(wù)估值
根據(jù)實際完成（EV）/計劃估值（PV），衡量項目進度偏差
根據(jù)實際完成（EV）-實際發(fā)生成本（AC），衡量成本偏差——計劃投入與實際投入偏差
統(tǒng)一的估值管理模型可以衡量整個團隊的效率問題
通過價值流圖識別浪費，然后優(yōu)化，聚焦于價值最大化，而不僅僅優(yōu)化成本
