項目管理中常出現意料外的狀況，一個處置不當就會導致項目的失敗，產品上線延期、需求范圍變更、消耗資源增加等問題比比皆是。上篇文章以實際項目為例，對項目管理中啟用和計劃環節做了復盤。書接上回，本文繼續復盤項目執行和收尾環節?？纯磳嵤┻^程中的有哪些亮點、槽點、改進點。希望能夠在項目管理方面對大家有所幫助。

一、執行任務

經過任務分解和進度規劃，需要協調人員和各類資源來按照計劃實施任務。執行任務階段的難點主要體現在資源調配（配置情況、到位情況、發放情況、使用情況）和團隊管理兩個方面。在資源配置方面，“郵政郵區中心局”項目中首先面臨的問題就是產品和研發人員不足、服務器資源不足；在團隊管理方面，因為團隊分別來自兩個部門，加上兩地辦公，工作協調難度也比較大……總的來說，任重道遠。

1. 小亮點：持有資源的充分使用

項目的研發實施時間只要2個月，實施范圍基本覆蓋用工管理中長期工和臨時工兩條業務線的主要流程，時間非常緊張?，F有資源難以支撐滿足項目需求時，從充分利用現有資源和尋求外部幫助兩個方向來解決。

1）充分使用已有的資源

將已掌握的資源進行充分地利用，結合計劃階段拆解的任務進行人員安置。同時根據項目節點要求，酌情安排加班等措施來追趕進度。雖然交付物的輸出進度上有所改善，但加班不是長久之計。持續加班會影響團隊氛圍，越往后交付質量也會越低。所以也要尋求外部支持……

2） 積極獲取外部的支持

在現有資源不足的情況下，積極上級和兄弟部門協商，申請借調人力和采購硬件等資源。比如：面臨產品設計資源不足，就借調同部門不同小組的產品經理支援；面對服務器容量不足和不穩定的情況，及時向公司申請服務器上云和購買容量等措施。雖然最終在人力方面依然沒有得到很好的滿足，但是一定程度緩解了壓力。

2. 吐槽點：團隊成員之間的“各自為政”

誠然團隊成員都很努力，但由于大家對團隊其他人的任務目標了解不夠清晰，導致在工作協同方面表現的如同“各自為政”一樣。

雖然負責的是同一個項目，但是具體負責的模塊并不一樣，同時模塊之間相互影響，并不是孤立的。在工作協作中暴露了嚴重問題，在研發環節表現的尤為突出。

1）任務銜接不清晰

項目團隊中的研發人員分別來自兩個部門，工作習慣沒有得到較為充分的磨合。雖然在計劃階段對不同研發人員負責的功能模塊做了分工，但是各自功能模塊的數據交互等部分沒有銜接好，導致代碼質量、功能輸出進度等受到影響。

比如：A同學負責基礎業務數據功能“區域組別崗位”（現場作業級別劃分），B同學負責的“用工需求提報”業務流中需要調用該數據，因為溝通不夠充分，導致取值出現偏差。

2）發版流程不規范

不同團隊的代碼發布流程不一樣，但是在一個項目中出現了兩套代碼發布流程只會帶來混亂，在項目中就是不規范的！技術負責人在發布前沒有制定和統一拉通相關的規范，導致代碼多人多次發布到同一代碼環境，導致代碼混亂，功能崩潰。

3. 改進點：從澄清目標到團結合作

合理的工作協調是快速推動項目進程的基礎條件之一，所以為了避免“各自為政”的現象，可以從兩方面著手，一方面需要加強團隊成員之間工作習慣的磨合，建立合適的任務銜接模式。另一方面，需要就任務目標在團隊內部達成共識，從而促進團隊成員間的緊密合作。具體如下：

1）澄清目標意義

在團隊內部澄清具體的目標要求和目標意義，只有真正了解和認同了目標才能有效的提升凝聚力。

目標要求：是指項目目標下拆解后的子任務目標，根據SMART原則設定和傳達。

目標意義：來從過去的角度，闡述做這件事情的出發點是什么，需求解決什么樣的問題；從未來的角度，闡述做的事情會達成什么效果。

2）互相知曉目標

為什么要知道他人的任務目標？因為一方面可以提供相關的資源和信息進行輔助，同時可以避免和別人目標沖突的事情；另一方面公開自己的目標，也有利于他人的監督。具體可通過項目日會、周會、板報等形式來展現。

二、項目收尾

磕磕絆絆終于到了項目收尾環節，本環節主要任務是對驗收各項任務的輸出物，并且向業務部門推廣系統。如果驗收出現紕漏，項目也將功虧一簣。

最終項目驗收通過。但是延期了將近1周的時間，而且功能范圍也和項目計劃出現偏差。因為在產品研發過程中業務已經發生變化，原先的產品設計已不能適應新的業務場景，不得不進行調整，執行需求變更流程。

1. 小亮點：可接受范圍的產品發布

因為需求變更、團隊資源限制（外包研發人員沒有到位）等原因，產品的驗收的時間和范圍跟原計劃并不一致。好在項目執行過程中做了預警，變更結果獲得了項目干系人的認可。同時項目團隊為了系統上線后的使用推廣做了很多工作。

1）組織產品驗收

產品驗收并不沒有很高的操作難度，但是是過程相對繁瑣。由研發、測試、產品等多個角色從各自的角度參與驗收工作。

研發驗收：根據需求文檔在本地環境進行單元測試、集成測試，如有功能性的bug先在研發團隊內部處理。

測試驗收：根據測試用例在測試環境進行測試。發現、分析、跟蹤bug，并提交測試報告。

產品驗收：檢查功能清單中的功能邏輯實現是否完整。因為本期資源不足，對交互反饋和UI方面沒有嚴格的要求。

2）系統推廣準備

面向企業的業務系統不像個人應用那么容易理解和操作，同時系統對現有業務流進行了改造，所以在前期需要產品人員輔助推廣和使用。

基礎數據配置：產品人員在系統中配置了初始化數據，包含系統基礎信息和業務基礎信息，如：組織部門、用戶角色、班次、人力供應商、人力運營方案等內容。

系統使用培訓：項目經理組織了《人資系統》的多場系統專項功能使用培訓會議。

系統操作手冊：產品人員提供了《人資系統操作手冊》，以及面向不同業務角色的《系統操作任務：人事專員/人事經理/業務主管……》。

2. 吐槽點：推動系統使用較困難

研發系統的初衷是降低項目運營上的成本支出，同時提高運營管理的作業效率和質量。要達成此目的必然是離不開各業務人員的支持。雖然項目團隊做了很多工作，但從結果上看依然不樂觀，存在部分業務環節人員的配合意愿不高等情況。

經過分析，造成不愿使用的原因可能是：

1）增加了用戶工作量

在系統試運行階段，系統各功能和數據沒有得到驗證，所以業務人員要同時執行原業務流操作和人資系統功能的雙流程操作，造成了工作量增加。

2）系統功能不夠完善

人資系統V1.0版本的功能模塊對業務場景的覆蓋不夠全面，在數據報表等結果數據呈現的缺失嚴重。同時系統在交互體驗上也存在很大優化空間。

3）對用系統不夠重視

因為沒有管理層的強烈要求，在推進使用時出現過用戶不會操作或遇到bug時就停下來了，并不主動反饋。只有項目經理或產品經理問起時才會提起說明情況。

3. 改進點：多維度的推進使用

在推動業務人員使用系統方面，除了上述常規的方法之外，也需要豐富其他的方式方法。不僅僅是團隊人員的自身努力，也要適時借助第三方的力量共同推動事項的進程，比如：更上級的領導，尋求能夠自上而下推動的力量。

具體的方法拓展，包含但不限于以下：

1）陪同系統使用

安排產品人員或客戶服務人員在業務現場陪同生產，從業務流源頭開始，系統功能使用逐一攻克。用戶操作時提供必要的指導，減少用戶的學習成本和抵觸情緒，從而保障系統中業務流程的順利流轉。同時產品人員也可以借機近距離觀察用戶使用過程中遇到的障礙，記錄后轉為需求池的內容。

2）快速響應需求

系統的設計不可能完全貼合業務場景，所以用戶在使用系統會提出的各種疑問和需求。面對疑問要及時解答，面對需求同樣要快速響應。這里的“快速響應”并不是立刻設計方案進入研發，而是需求記錄和進度告知，以此提升用戶受重視的感覺。需求采集后進入常規的需求管理流程即可。

3）借助高層力量

在剛引入系統的新老流程并行階段，必然會增加用戶的工作量。所以在推動系統使用方面，除了來自團隊人員努力，爭取高層領導對系統的價值認可（立項階段基本完成），由高層領導給予一定程度的支持也非常重要。需要根據引入系統后的新業務流程制定出配套的管理制度或作業規范等，自上而下的推行更加有力。以上項目管理中執行和復盤環節的復盤。文中有太多未盡之處，歡迎私信溝通。

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

題圖來自Unsplash，基于CC0協議