編輯導語：相信大部分小伙伴都學過項目管理知識吧，但會發現在實踐中卻達不到預期效果。這篇文章作者詳細闡述了項目管理中的亮點、槽點、改進點，一起來看看吧。

很多朋友都學過項目管理知識，但是在項目實踐中卻難以達到期望的效果。因為項目上的情況和理論知識存在偏差，在執行中更加考驗項目負責人的靈活性，只有結合實際場景及時做出調整才有可能完成任務。

紙上得來終覺淺，絕知此事要躬行。本文以實際項目為例，根據項目的啟動、計劃、執行、收尾的4個階段分別拆解。作為項目的參與者（非項目經理），復盤實施過程中的有哪些亮點、槽點、及對應解決措施是什么。希望能夠在項目管理方面對大家有所幫助。

一、項目啟動

先介紹下項目概況。公司和X省郵政的郵區中心局合作，承接了該省一級郵件分撥中心的快遞包裹運營業務，即組織人員對各郵路的快遞進行分揀和裝卸任務。

為了降低運營中的人力成本支出，以及提高運營管理的作業效率和質量，公司成立了以“郵件運營管理業務升級”為目的的產品項目組。

雖然是公司內部的信息化系統建設，但涉及了全新業務，同時橫跨多個部門和團隊，項目整體相對復雜。

1. 小亮點：明確的項目目標和需求范圍

解決問題的第一步是要澄清問題。所以在啟動階段的首先要明確項目要做成什么樣？代表了領導在當前業務狀態下對項目（產品）的訴求。在充分了解項目需求、項目目標以及項目范圍后才能進入計劃階段。

公司是首次負責郵件運營型業務，所以針對運營場景下的各類業務流程及管理辦法都處在不斷探索和調整中。因此項目經理和產品經理在前期除了研究業務資料，還參與業務運行邏輯討論，以及對關鍵業務負責人和一線人員進行多輪調研。充分了解了業務場景、業務痛點、項目訴求。

發現包含但不限于以下痛點：

1. 數據獲取分散：現場通過紙質單據、微信、郵件等多種途徑進行數據的交流，下游人員不能及時獲取。
2. 數據流轉繁瑣：用工需求等業務通過紙質單據流轉，需要員工在現場找各領導審批，造成長時間等待，影響業務進程。
3. 數據無法沉淀：由于數據分散且多形式存儲的特點，無法有效沉淀業務歷史數據，不利于成本優化等分析。

最終通過產品規劃，擬定1階段任務為：對運營管理中的現場人員用工（長期工、臨時工）相關業務進行信息化改造，并通過系統優化部分業務流程。目的在于提高信息流轉效率和準確性，同時滿足管理者對業務執行過程及結果的監管訴求。

2. 吐槽點：較為薄弱的團隊管控力度

關于項目團隊組建這件事……公司先后指派了2個項目團隊負責執行任務。先由A部門的項目組負責，包含項目經理1人、產品經理2人、研發測試6人。

因為A團隊的項目結果達不到預期，后改由B部門的項目組負責，同時因為時間緊任務重，B部門研發資源不足，借調了A部門的部分人員。最終項目組包含項目經理1人、產品經理2人（含借調1人）、研發測試6人（含借調3人）。

我們就是B部門的項目組?？梢钥吹巾椖拷M成員構成相對復雜，不僅是跨部門協作，更是涉及前團隊人員。更加考驗項目經理對團隊的管理能力。

雖然做了部分預案和措施，執行中依然出現了各種問題，比如：

1）團隊協作的習慣沖突

不同團隊的工作習慣不一樣，組建新團隊后各兩方人員沒有較好的磨合，導致交付物輸出進度和質量受到影響。比如：多人擁有代碼部署權限，導致線上系統代碼沖突，出現bug等情況。

2）人員狀態的管控薄弱

團隊成員分別在兩地辦公，部分在業務現場，部分在總部。項目經理對團隊人員請假or在崗狀態沒有第一時間掌控，造成進度延期。

3）團隊氛圍持續性低迷

A項目組成員經過數月高強度工作，成果卻不被認可，又安排進入接手團隊中。誠然更熟悉業務和代碼，但也有疲憊和抵觸心理。

3. 改進點：管理制度的建立、維護和更新

對上述問題需要通過多個維度來解決。無規矩不成方圓，讓隨意松散的行為受到約束是提升團隊管控粒度效率和質量的前提條件。比如從項目管理制度的建立、維護、更新3方面著手。

1）建立管理制度

在工作鏈條上交集的團隊成員提前約定好交付規范和時間節點等內容，避免后續因為習慣問題引發的沖突。確保所有人員遵循同一套流程規范。比如：需求管理流程，版本發布流程，內外溝通機制……

2）維護管理制度

制度的執行不能只依靠一份文件，需要不斷的宣貫。相應負責人需要及時識別偏離制度的行為并予以修正。比如：溝通流程中的日會制度，目的在于持續的進度和問題反饋，主持人要注意把控內容，不要讓會議變成走形式的流水賬。

3）更新管理制度

制度并不是一成不變的，會根據當下的特殊性進行制度的更新。比如：需求管理機制的更新。

最開始產品從0到1時是整個產品的方案輸出，評審后只需要發布原型并告知開發測試即可。隨著產品迭代，需求更加零散，新流程則需要將方案發布到禪道（項目協作工具）并在需求池中標注編號。

二、制定計劃

在確定了項目目標、需求范圍、可調用的資源等情況后，項目就過渡到了制定計劃階段。計劃就是要把抽象的需求轉換成可執行的具體事項。因此，本階段任務圍繞具體事項展開，包含任務分解、進度規劃、風險控制等內容。

不要認為企業內部的項目對進度的管控會有所松弛。事實上項目用時每多一天，企業就需要支付數千元的成本，所以更加關注產品的快速價值變現。

1. 小亮點：細致的任務分解和進度規劃

任務的細化是多維度全面的細化，包含但不限于：與上一團隊的項目交接、本項目團隊的組建、產品任務細化、研發及部署任務細化等內容。同時充分考慮項目受到的約束條件，比如截止日期、可調用資源等要素，對任務做出合理的進度規劃。

在產品細化方面，秉持著先滿足主流程，后滿足分支流程的原則。決定先處理基礎數據模塊和業務主流程，對結果數據的統計報表等需求降低了優先級，后延至下一階段處理。

考慮到業務處于不穩定的階段，先處理相對固定的業務形態對應的需求，避免出現產品上線后不久就面臨大范圍修改的情況。

基于以上，對本階段的產品功能模塊進行了細顆粒度的拆解。拆解內容如下（已簡化處理）：

• 系統基礎設置：組織管理、部門管理、角色管理、用戶管理等。
• 業務基礎設置：臨時工管理、長期工管理、黑名單管理、渠道商管理、長期工排班設置、長期工考勤設置等。
• 業務運營管理：用工需求管理、渠道人數分配、臨時工考勤、臨時工工資、長期工考勤等。

2. 吐槽點：淡薄的風控意識和清單

雖然對常見的風險事項做了預案，比如項目任務進度規劃、需求管理機制、溝通管理機制……但是從最終結果來看依然偏離了預期——產品發布延期。

導致延期的原因有很多，其中一個重要原因是風控反饋行為遲鈍。事實上每個項目在執行時都會出現風控問題，重點在于及時識別和處理。

什么是風控反饋行為遲鈍呢？對風險清單內的問題處理不夠及時，對風險清單外的問題識別不夠及時。最終導致問題的擴大，由小問題變成大問題。在本次項目中多次出現風控問題，因為未能及時處理導致影響范圍擴散。如下：

1）研發外包采購無結果

項目組的部分研發人員是通過其他部門借調加入的，但借調只是一時之計，所以項目之初就制定了招募研發外包人員的采購計劃。截至一階段項目結束時，依然沒有人員入職。研發資源不足也是導致發布延期的誘因之一。

2）溝通機制執行不規范

為防止項目實施中出現職責不清或溝通不暢，擬定了《項目階段事項細化及干系人表》。但是項目相關會議上沒有進行持續的宣貫和強調，致使產品研發等部分環節中需要咨詢和告知的對象沒有溝通到位。

3. 改進點：風險清單增補機制

風險的存在不以主觀意識而轉移。風險管控的重點就是對各類風險進行預測、識別、定級、應對。事實上，在項目計劃階段已提供了風控清單，依然出現問題！原因是清單外的問題識別不及時、風險應對不及時?？梢酝ㄟ^以下舉措避免來規避問題。

1）補充風險清單內容

風險清單是有序管控風險的依據，一方面需要完善風險上報內容，一方面要健全風險上報字段。

完善清單內容：通過過往項目的風險清單篩選出符合本項目情況的內容進行繼承。同時結合項目情況進行新增。比如：采購外包研發人員的事項，在之前項目中沒有遇到，所以在本次梳理清單時應予以補充。

精簡清單字段：風險上報內容應簡要精準，降低上報難度。字段包含但不限于以下：編號、風險類型、風險描述、風險等級、上報人、上報日期、應對措施、應對責任人、預計解決時間、狀態、備注。

2）風險識別機制調整

在原有的機制中更多的是對已知的風險清單內容進行識別，并且風險清單的巡查不及時，無法將問題遏制在萌芽階段。應從3方面解決：

每日巡查清單：在每日的項目例會后，根據反饋的情況對照風險清單進行巡查，及時識別風險。

風險項目增補：項目執行中，出現的任何異常情況或代辦事項，酌情轉為潛在的風險清單內容。

問題持續追蹤：很多問題已經發現并反饋了，但最終依然不了了之，直至問題爆發。所以對已發生的問題要標記跟進人和反饋時間，做好持續跟進和預警。

以上項目管理中啟用和計劃環節的復盤，下一篇繼續復盤執行和收尾環節。敬請關注。

本文由 @耳目不染 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議