項目管理培訓實踐心得

前言

能夠說當你擔當一次 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的人工，從上層項目開始估值，外包公司的外包項目也會有賺有賠，因此不要特別斤斤計較與估值準確度，須要用整個團隊視角觀察咱們的產值；價值評估造成的績效數據建議僅佔少數績效考覈，避免因估值偏差致使的績效偏差

浪費識別：無效溝通，過多的非必要會議，過多中間溝通環節（經過多個環節溝通），未被要求，非必要的功能；重複開發，錯誤開發，錯誤方案，過多返工，等待：等待各類確認、等待需求、等待前置任務、等待發布