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

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

01

項目啟動

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

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

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

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

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

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

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

1）數(shù)據(jù)獲取分散：現(xiàn)場通過紙質(zhì)單據(jù)、微信、郵件等多種途徑進行數(shù)據(jù)的交流，下游人員不能及時獲取。

2）數(shù)據(jù)流轉(zhuǎn)繁瑣：用工需求等業(yè)務(wù)通過紙質(zhì)單據(jù)流轉(zhuǎn)，需要員工在現(xiàn)場找各領(lǐng)導(dǎo)審批，造成長時間等待，影響業(yè)務(wù)進程。

3）數(shù)據(jù)無法沉淀：由于數(shù)據(jù)分散且多形式存儲的特點，無法有效沉淀業(yè)務(wù)歷史數(shù)據(jù)，不利于成本優(yōu)化等分析。

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

在多次需求澄清會議后，由產(chǎn)品人員輸出《人資系統(tǒng)業(yè)務(wù)需求規(guī)格說明書》并由領(lǐng)導(dǎo)簽字確認，確保雙方在需求方面達成共識。

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

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

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

我們就是B部門的項目組。可以看到項目組成員構(gòu)成相對復(fù)雜，不僅是跨部門協(xié)作，更是涉及前團隊人員。更加考驗項目經(jīng)理對團隊的管理能力。

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

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

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

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

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

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

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

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

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

1）建立管理制度：

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

2）維護管理制度：

制度的執(zhí)行不能只依靠一份文件，需要不斷的宣貫。相應(yīng)負責(zé)人需要及時識別偏離制度的行為并予以修正。

比如：溝通流程中的日會制度，目的在于持續(xù)的進度和問題反饋，主持人要注意把控內(nèi)容，不要讓會議變成走形式的流水賬。

3）更新管理制度：

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

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

02

制定計劃

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

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

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

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

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

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

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

1）系統(tǒng)基礎(chǔ)設(shè)置：組織管理、部門管理、角色管理、用戶管理等。

2）業(yè)務(wù)基礎(chǔ)設(shè)置：臨時工管理、長期工管理、黑名單管理、渠道商管理、長期工排班設(shè)置、長期工考勤設(shè)置等。

3）業(yè)務(wù)運營管理：用工需求管理、渠道人數(shù)分配、臨時工考勤、臨時工工資、長期工考勤等。

吐槽點：淡薄的風(fēng)控意識和清單

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

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

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

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

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

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

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

改進點：風(fēng)險清單增補機制

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

1）補充風(fēng)險清單內(nèi)容：

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

– 完善清單內(nèi)容：通過過往項目的風(fēng)險清單篩選出符合本項目情況的內(nèi)容進行繼承。同時結(jié)合項目情況進行新增。比如：采購?fù)獍邪l(fā)人員的事項，在之前項目中沒有遇到，所以在本次梳理清單時應(yīng)予以補充。

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

2）風(fēng)險識別機制調(diào)整：

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

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

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

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

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