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

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

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

一、項目啟動

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

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

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

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

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

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

發(fā)現(xiàn)包含但不限于以下痛點：

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

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

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

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

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

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

雖然做了部分預案和措施，執(zhí)行中依然出現(xiàn)了各種問題，比如：

1）團隊協(xié)作的習慣沖突

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

2）人員狀態(tài)的管控薄弱

團隊成員分別在兩地辦公，部分在業(yè)務現(xiàn)場，部分在總部。項目經(jīng)理對團隊人員請假or在崗狀態(tài)沒有第一時間掌控，造成進度延期。

3）團隊氛圍持續(xù)性低迷

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

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

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

1）建立管理制度

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

2）維護管理制度

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

3）更新管理制度

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

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

二、制定計劃

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

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

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

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

在產(chǎn)品細化方面，秉持著先滿足主流程，后滿足分支流程的原則。決定先處理基礎數(shù)據(jù)模塊和業(yè)務主流程，對結果數(shù)據(jù)的統(tǒng)計報表等需求降低了優(yōu)先級，后延至下一階段處理。

考慮到業(yè)務處于不穩(wěn)定的階段，先處理相對固定的業(yè)務形態(tài)對應的需求，避免出現(xiàn)產(chǎn)品上線后不久就面臨大范圍修改的情況。

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

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

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

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

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

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

1）研發(fā)外包采購無結果

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

2）溝通機制執(zhí)行不規(guī)范

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

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

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

1）補充風險清單內(nèi)容

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

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

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

2）風險識別機制調(diào)整

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

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

風險項目增補：項目執(zhí)行中，出現(xiàn)的任何異常情況或代辦事項，酌情轉為潛在的風險清單內(nèi)容。

問題持續(xù)追蹤：很多問題已經(jīng)發(fā)現(xiàn)并反饋了，但最終依然不了了之，直至問題爆發(fā)。所以對已發(fā)生的問題要標記跟進人和反饋時間，做好持續(xù)跟進和預警。

以上項目管理中啟用和計劃環(huán)節(jié)的復盤，下一篇繼續(xù)復盤執(zhí)行和收尾環(huán)節(jié)。敬請關注。

本文由 @耳目不染 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載。

題圖來自Unsplash，基于CC0協(xié)議