前言
可以說當你擔當一次 PM 之後，對專案來說自己不在一方面的資源，對專案、對產品的 owner 意識才能親身體會。當專案上線那一刻，就好比上學時一道難到全班的“數學題”被我給解出來了，成就感油然而生。 下面我根據自身的工作體會，已經在公司內部關於技術 PM 培訓總結了本文，用於各個 PM 參考，同時為哪些想提高管理技能(協同技能)的同學做一些參考。本次分享結合眾多大佬的心得和自己的實操，相對簡單粗暴，需要深入學習的同學需要查閱相關書籍。 本人實操經驗有限，難免有功力不到之處，歡迎指正
關於專案管理的一些看法
專案管理是人人具有的能力
有一本書叫《人人都是產品經理》，也有一本書叫《人人都是專案經理》，專案管理並不只出現在工作當中，可以拓開眼界，寬泛的說，有目標有價值的事情都可以當成一個個專案，比如生活中的如上學讀書、買房、結婚、旅遊等等都可以看成一個個專案；所以所謂的專案管理，就是在既定的時間內如何設定目標，確認優先順序，制定實施計劃，最後能夠達成管控的過程。
隨著軟體及網際網路的發展，開發工作已經告別了孤膽英雄的時代，在今天即重視技術大牛的能力，也更重視團隊協作能力，而隨著管理思潮的發展，企業也越來越注重培養自組織、高效敏捷型團隊，像我們日常工作中也會隨時拉一個人出來作為某個專案的owner，這種趨勢也需要團隊的人在專業能力外具有更強的管理協作能力，當你不具備這種能力時，你可能會逐漸落伍於這個時代，所以專案管理並不只是專案經理的專業能力，是需要每個人學習並具有的能力。
如何學習
首先推薦學習一些敏捷的思想和方法論，因為敏捷的思想更有助於我推動日常工作，方法論叫較多易於實踐。之後可以瞭解一些精益開發的思想，精益思想注重價值與優化，用於敏捷實踐的優化參考。在更多深入管理中可以學習借鑑經典專案管理理論，諸如計劃、時間、風險、資源、成本等，經典專案管理有更具體的方案。
PM職責
不同的工作需求，PM 職責不同。下面我結合目前工作的需要描述一下。
溝通管理
在團隊素質較高的今天，PM 第一職責就是保證有效溝通，核心是為了資訊更快更好傳遞給需要的人。
- 專案干係人管理
- 列出所有關係人：PM、PD、TC、前端、後端、其他負責人以及開發人員
- 專案動態及時通知相關責任人
- 建立專案管理群，相關文件材料以及開發進度列入群公告中
- 透明化
- 專案價值、產品方案、技術方案、專案計劃、各個結論等全員共享
- 專案狀態、風險、動態等即需要告知相關責任人，也需要同步效率平臺讓關注的人查閱
- 資訊傳達要及時，相關知識要共享。
- 溝通機制
- 建立溝通機制，溝通群、郵件組
- 專案協同工具：效率平臺、jira、gitlab
- 溝通頻率、溝通反饋與同步
- 需要給各個角色提供什麼資訊，何時提供
- 明確在過程中需要溝通的環節以及各個環節需要確認的問題與輸出
- 何時開會、會議主題、會議議程、計劃時長
- 有效溝通
- 告知可以反饋，但要注意告知範圍
- 溝通要有反饋確認
- 會議要明確議題與議程，做好會議記錄、做好控場，避免跑題。
- 讓具體負責人直接溝通，消除中間環節，但注意溝通結果的資訊同步
- 重要的事情說三遍
專案範圍
需求分解、變更必須和整個過程管理配合。
- 明確專案的核心價值，避免專案過度複雜或過度簡化，這是評估合適專案範圍的參考標準
- 需求管理：協助需求分解
- 變更管理
時間管理
組織任務分解，關鍵節點設定，計劃排期，跟蹤並應急
- 工期估算
- 排期計劃
- 計劃跟蹤與修正
專案成本
跟蹤實際投入與產出，作為效率監控
- 主要為資源投入、評估工作量，跟蹤相關工作量進展，為效率管理提供依據
專案質量管理
- 產品方案評審
- 技術方案評審
- 驗收標準管理
- code review 的組織
- 測試計劃、測試範圍、測試用例評審等協調
- 測試報告
風險管理
- 風險識別
- 風險分析
- 風險應對
- 風險監控
共享知識庫管理
- 需求、需求變更記錄及相關知識文件（aone），討論記錄
- UI
- 技術方案，設計思路等
- 會議紀要(建議除郵件外,要有干係人共享的wiki版本)
- 排期計劃
- 釋出計劃(部署方案)
- 測試計劃、測試用例、測試報告
過程管理(參考 scrum)
需求階段
- 需求收集、審批確認 —— 會議記錄、審批流程記入相關專案知識庫
- 建立專案知識庫，建立需求討論組
- 複雜的需要要制定需要計劃
- 需求收集
- 需求分析
- 評審記錄
- UI 設計
- 業務確認
- 輸出產品方案(PRD、原型、UI)等
研發階段
-
需求評估 —— 簡易需求直接與需求評審會議合併，複雜的單獨組會評估
- 組織需求宣講
- 專案主要資源(產品\架構\研發\測試\UED)對於專案進行整體評估
- 技術方案以及技術方案確認
- 工作量評估（粗略保守估算）
- 資源評估
- 風險評估（需求是否穩定，資源是否充足、時間是否存在風險，其他風險）
- 可啟動開發條件是否充足
- 需求分解
- 使用者故事或者功能分解到適合一個迭代可完成的大小（粗略評估）
- 無法更細顆粒度分割不要強求分割，迭代時可按照任務分割
- 輸出專案排期計劃，整體迭代節奏，郵件通知相關責任人
-
迭代管理
- 組織迭代計劃會議，評估迭代內完成的使用者故事\功能點\測試\UI,分解任務,制定具體到天的迭代計劃,並輸出(郵件)給負責人，記錄到知識庫
- 組織每日立會(或隔日)
- 需要明確每個人最新進展、當天計劃、遇到的問題，時間建議 15分鐘以內，不討論具體時間，具體問題單組組會討論
- 小團隊專案，最新進度通過聊天同步即可(記錄到 doc 上)
- 需要跨組協作的專案，需要及時跨組進行同步
- 組織迭代演示及覆盤
- 在專案上線前一兩天進行
- 在本階段完成的做一個簡單回顧
- 能演示的東西，向產品、測試或業務進行展示；可及時發現問題，增加大家對專案的瞭解，而不是等到開發完成才展示成果，有效提升專案信心、降低專案風險。
- 迭代報告
- 測試計劃制定
- 儘早組織測試計劃制定，建議專案啟動測試即介入，尤其時研發兼PM時注意計劃、例會、演示等不要遺漏了測試同學
- 協調測試與產品溝通驗收條件（重點針對與需求場景而非功能點），含測試範圍（測試邊界），驗收標準，質量標準，效能標準
- 協調測試輸出測試用例，進行用例評審
- 測試切入的時間計劃與資源安排
- 釋出管理
- 制定釋出計劃
- 多個專案的部署順序，是否依賴
- 部署步驟，各環節負責人，各環節部署時間
- 回滾計劃，或釋出失敗的應急方案
- 通知所有專案負責人，重要的負責人必須確認
- 覆盤（小專案直接通過迭代覆盤）
- 回顧目標
- 評估專案效果
- 總結做的好的地方，與不好的地方，並討論優化思路
- 根據總結，形成行動計劃
效率管理
沒有量化就沒有管理，量化是我們評估專案投入，進度、效率的基礎；作為 PM 得理解，在軟體專案管理中，每一種量化都有大量失敗案例，選一種適度量化方案，不要過度量化。 推薦量化管理方案：
- 需求和任務要有工作量評估
- 以工作量評估作為基線，實際發生工作量做對比，評估進展，團隊效率
- 量化方式一（可閱讀Scrum相關資料）
- 儘量細化任務及需求,需求分解到一個迭代（兩週），做使用者故事點數或工作量評估（可細化到任務）
- 通過需求完成趨勢圖、需求燃盡圖作為效率衡量，在基準線之上的專案要標記為風險
- 量化方式二（可閱讀掙值管理相關資料）
- 根據專案評估專案價值（計劃值PV）
- 細化分解各個任務價值，作為任務估值
- 根據實際完成（EV）/計劃估值（PV），衡量專案進度偏差
- 根據實際完成（EV）-實際發生成本（AC），衡量成本偏差——計劃投入與實際投入偏差
- 統一的估值管理模型可以衡量整個團隊的效率問題
- 通過價值流圖識別浪費，然後優化，聚焦於價值最大化，而不僅僅優化成本
風險管理
在專案整個過程中， PM 要維護風險列表。每個風險識別後，PM 要協調儘快明確應對方案以及風險負責人，跟蹤風險解決進展；要及時暴露風險給能處理或能決策的人。
風險識別以及基本應對：
- 需求以及產品風險：聚焦需求價值，以完成需求核心價值未衡量標準。管控產品方案複雜度，複雜需求要分階段、分塊評估，方案要圍繞需要核心價值。產品方案要經過技術評估、業務評估，必要時要經過審批以儘量降低需求及產品風險；PM 要確認需求以及產品方案經過評估以及稽核。PM 要管控專案變更，通知相關責任人（尤其是需求方），影響排期要進行風險管理，必要時升級主要決策人決定，要避免在相關負責人不知道的情況下私自更改方案。
- 資源風險：資源衝突，與其他專案PM或高階leader進行溝通，根據優先順序先協調排期，如衝突無法解決，升級到可決策的人做決定；單個資源在多個專案中或需要支援現有系統執行，與對應的資源溝通，明確專案可專案可佔用的時間，作為風險解決記錄，如風險太高，建議更換資源或增加輔助資源，必要時升級此風險到對應決策人；缺少特定資源，申請 PMO 支援或升級到相關決策人進行協調，如短期無法解決，標記風險高，每日跟進；資源不足，PM申請PMO或相關決策人支援，在內部無法協調解決時，申請並推動招聘與外包流程；資源突發情況管理，如突然請假等，建議重要專案PM在專案啟動時明確要求團隊成員提前申請請假等事項，如遇到突發請假的情況，及時通報風險給相關決策人，並做資源調整或計劃調整並告知干係人
- 時間風險：根據專案難度（複雜度），資源情況，deadline，排期等評估時間風險（極高，高，中，低）；時間風險高的要明確告知需求方（相關決策人），並確認；時間風險高的申請更高優先順序，優先佔用相關資源；時間風險高的根據情況適當申請加班（非必要避免過度加班，合適的研發節奏比加班更有效率）；減少非必要時間消耗，如不必要的會議等；降低溝通成本，集中專案成員統一區域辦公，異地人員可申請出差，必要時要求封閉開發減少外部打擾
- 技術風險：標記專案技術複雜度，或技術複雜模組，對於任何不熟悉的技術使用都不要盲目樂觀；從需求評估階段引入技術方案評估，如加入架構評估及技術管理委員會稽核的環節；研發階段要對相關技術方案不斷核對，及時調整或請架構、技術管理委員會評估，必要時申請外部資源支援；高風險的技術問題，要逐日更新解決進度
一些思考
《思考，快與慢》講到人類的思考其實有兩個系統，一個系統根據直覺做快速反應，另一個系統需要更長的思考並做出反應。系統一反應快，但複雜問題容易出錯，系統二反應慢，但應對出錯概率低。這是人類長期進化的結果。
那麼對映到專案管理中，在技術與思想日新月異的今天，針對專案管理沒有銀彈，我們不能用一套方案應對所有場景，需要區分快速響應的和需要持續投入的專案，我們需要不同的應對策略。針對快速響應的專案，需要簡化上文提到的環節，並允許犯錯。
一些理念
資訊與知識共享：資訊管理是專案管理的潛在核心，包括需求、背景知識、相關責任人、產品方案、時間計劃、覆盤等等資訊；就像程式一樣，資訊必須流轉到真正處理的人才會價值最大化，要確保資訊溝通；資訊的更廣泛傳播更有助於收集反饋資訊，PM要確保資訊儘量廣泛傳達（需保密的除外）；PM不要形成資訊瓶頸，即所有資訊都由PM中轉，發揮每個成員的溝通能力，並確保資訊同步給相關干係人
計劃：壞的計劃比沒有計劃強；敏捷不是甩開膀子埋頭幹，敏捷沒有計劃時一種誤解；計劃要詳細，但不要求過度準確；計劃要在執行過程中不斷調整修正；迭代儘量穩定，但允許接收緊急變化，變化要告知相關干係人並經過決策人的確認
需求：聚焦業務價值與場景,什麼角色為達到什麼目標（價值）需要一個什麼功能（或系統能力；聚焦業務描述，可以標註業務預期；EPIC是一個大的使用者故事，一般我們用於與使用者提出的需求對應，可以相對模糊，甚至是一句話
使用者故事與PRD：兩者不是對立的，一定程度上是同樣的事情；使用者故事更側重於價值與場景體現，但濫用時容易產生一句話需求，這是一個誤解；PRD可以由場景及價值描述，但PRD的形式更容易陷入功能實現描述而引發需求風險；明確價值與應用場景是我們的核心訴求，因為方案可以很多套，功能可增減，但沒有實現業務的核心訴求會導致專案南轅北轍
釋出：儘量構建並使用CI(持續整合)與CD(持續部署)的流程
度量：沒有量化就沒有管理,度量在管理中非常重要；過度度量(過度量化)，或工時記錄有很多失敗案例，會加大團隊成本；時間管理沒有必要小於天（或者0.5天),微觀時間管理應該交給個人；價值評估：不要等同於工作量評估，比如我們評估本專案價值100W，但不同於我們要化100W的人工，從上層專案開始估值，外包公司的外包專案也會有賺有賠，所以不要特別斤斤計較與估值準確度，需要用整個團隊視角觀察我們的產值；價值評估形成的績效資料建議僅佔少數績效考核，避免因估值誤差導致的績效誤差
浪費識別：無效溝通，過多的非必要會議，過多中間溝通環節（通過多個環節溝通），未被要求，非必要的功能；重複開發，錯誤開發，錯誤方案，過多返工，等待：等待各種確認、等待需求、等待前置任務、等待發布