起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識管理千萬級項目群一年后，我的總結
在不少公司，基本上都是由產品擔任項目管理的工作。而且由于公司、團隊的原因，系統的項目管理經驗很難一一對應。就比如正文作者分享的這些管理經驗，就只有實踐中才能得出的思考。
在2025年第一次出差的高鐵，恰逢手機沒電充電寶無法有效使用的情況，索性不去管他，給自己一下午的清凈來做一個2024年關于項目管理的回顧和總結。
2024年完整的一年，做為一家上市企業倉儲物數字化項目群的負責人，項目群包括生產端OTWBY、零售端OTWB、網絡貨運、城配系統、物流客服等，年底來看整體評價還不錯，基本上按計劃年初既定計劃平穩推進，得到了關鍵用戶正面反饋。 經過這一年的布局，幾乎已經打好了所有板塊的基礎，后續任務就是不斷深耕和復制。
下面是關于項目管理的一點點心得體會，整體視角從實操端出發，以解決問題推進項目為導向。
一、項目啟動期
項目管理中溝通問題是個老大難，一個屋子里有甲方、供應商、關鍵用戶、外包等等角色的人員，看似一天都在說話但實際信息壁壘很嚴重，開始組建團隊時候還好，逐漸到了項目后期基本都溝通都沒有了。所以再啟動期一定要有意識的建立溝通機制，無法正常溝通的時候就只能用各種流程來規范，比如填很多表、日報、周報這樣的形式。
對于供應商管理，如果你是甲方能遇到一個有拼勁的乙方太難了，傳統意義的乙方只賺固定工資，干的好壞又有什么關系呢？（勿噴，通過自己2年的乙方經驗總結，謹代表個人觀點）畫餅獎勵的年代已經過去了，我認為給乙方動力和激情的方式還是甲方項目經理的狀態以及個人推動，可能這就是領導力的體現，一味的加強制度的限制物極必反。通過扣錢或者高層溝通去壓制干活的人，效果有限。
資源配置問題，乙方的人員資源使用基本會配置到極致，“只要干不死就往死里干”。項目中幾個剛畢業的小顧問，持續高強的工作下基本已經毫無精力，但是無新人資源補進持續硬扛。對項目成員工作節奏的把握很重要，持續高強度壓榨或者一直平平慢慢的做都不可取，壓過了人會崩，不壓無動力，工作節奏要像松緊帶一樣，有緊有松，張弛有度，把壓力分攤開。
做項目啟動前一定要領導支持，開始階段一定事從上向下宣貫，否則寸步難行。下面人用一些獎勵手段，比如上線獎金、關鍵用戶配合獎金之類的記錄措施，確保實操人員的配合度。組拳打出去，上下一心才能有一個穩定的項目啟動環境。
二、項目動蕩期
項目進入動蕩期后，最多的工作就是匯報、和供應商干仗。
甲方項目經理有決定性的關系，協調型、命令型等不同的甲方項目經理管理風格，干法是不一樣的。項目難度也是關鍵因素，難度上了一個臺階壓力自然大了一個程度。對于乙方項目經理的底層邏輯需要提前明確，例如技術出身的項目經理底層邏輯是實現思維，產品出身的項目經理底層邏輯在系統功能使用順暢友好，項目經理出身的項目經理基本不會拒絕需求但可能無法實現，甲方應該知曉并且相應適配。
資源問題成了這個時期溝通最多的事情，需要明確確定資源前需確定為什么缺資源，缺什么資源，這就引出了對關鍵用戶預期管理的話題，做任何項目決策前都需要統一預期目標一致。首先需要明確需求充分溝通，確保期望一致，如果推進過程中涉及需求變更，要一起評估影響及風險及時跟進。
再說回資源的問題，甲乙方誰來確定資源名單？如果甲方按自己的理解和需求提出資源名單讓乙方去滿足，大概率會多于正常值，也好理解既然要人還不多要一點，這勢必會讓乙方覺得浪費資源。如果乙方自己定資源，乙方會將資源壓縮到極致，甲方看來又是缺資源的一個情形。第三種形式回歸本質，甲方要求的是活干完而不是見到多少乙方的人，所以甲方提出需求及驗收要求，由乙方自行搭配資源并將方案和甲方匯報，甲方“按時收租”，這樣的方式對誰都好。
再聊聊高層溝通匯報的事情，有問題及時上升是解決問題的一個常規手段，有問題先自己想辦法解決，實在解決不了了再向領導求助，但是要明確每一級的上報都會損失一部分信息，越來越失真，下面都炸了上面還一片和諧。高層溝通會后的向下傳達也容易出現問題，領導們高談闊論說的都很好，但執行不下去，讓高層會看起來沒什么效果，這個就需要有個持續跟進的機制，比如按會后決議每周郵件匯報，直至決議完全落地為止。
三、項目運營期
找對關鍵用戶，項目運營期前必須要先研究項目主體的組織架構，不能讓關鍵用戶管理缺失，否則后期投訴會很難解釋，全程沒參與的人但上線后影響人家工作，項目當然要被人投訴而且培養信任的過程也是影響項目口碑問題的關鍵影響因素。 這個角度來看，項目管理的本質就是人的管理，管好人才能做好事，做好事才能讓人放心。
過程節點簽字文件留檔問題很重要，關鍵時刻能保命。簽字的過程一來表示確認，更重要的是責任風險分擔。項目經理切記不要把風險都歸集到自己或者項目組，一切順利的時候會有人說你高高風亮節勇于承擔，出問題的時候百口莫辯全是過失，功勞歸零苦勞更會被抹去。關鍵用戶之所以關鍵，一定要留著關鍵時刻發揮關鍵的作用。
針對信息化項目，一個老生常談的問題就是測試要充分，能全量數據測試的一定要全量，有的功能和性能問題在數據量少的時候是無法出現的。需要有一個和生產環境代碼原則上一模一樣的環境用于測試。完整測試，盡早的暴露問題。
對于上線后投訴的處理及應急問題向處理不當也是可能導致項目失敗的很重要的因素。處理應急問題基本上純靠項目經理的經驗，那個時候是壓力最大最需要經驗智慧的時候，同時也是關鍵用戶和一線實操用戶罵最兇的時候，在慌亂中做出決策的能力非常重要。
四、項目管理因地制宜
常規項目管理，自研的一般做敏捷模式，外購的一般做瀑布流的管理。但項目管理是因地制宜的過程，可以結合多種思路。
例如項目A，大體上是做瀑布流的管理，即立項、需求調研、藍圖、上線、驗收這幾個環節，理論上來講各階段是順序排布，因為前一個環節完成了后一個環節才具備進行條件。比如藍圖驗收完成，才可以進行開發上線。但A項目把這幾個節點并行推進，需求調研大概完成MVP版就開始寫藍圖，一邊調研一邊寫，同時啟動了部分功能的研發工作，并且在多板塊還沒有階段性成果的時候，做全流程割接演練，割接結果自然是失敗。
在看似亂糟糟的管理，在瀑布里面又加入了敏捷sprint迭代的邏輯，把需求分成多次迭代，把藍圖分成多次迭代，割接演練也分成多次，這樣共同推進也能管理起來。
另一個層面來看，相關方都提早啟動了起來，好處就是事項提前準備提前推進，壞處就是當前階段都沒做完就去考慮下一階段的事情，有應付不過來的團隊反而拖慢了整體進度。
例如項目B，推進方式正好反過來，是以敏捷的思路為基底，但以瀑布流的形式去管理。需求非常多，但可以和用戶一起識別出來哪些是最主要的拼成mvp版，按一份合同立項、開發測試、驗收上線為執行邏輯，后續的需求再循環這個過程。但這個方式的注意不要走到極端，用戶接受分版本進行，也有mvp的觀念，但需求控不住，迭代停不下來，原本一年的項目迭代了三年也沒做完。
以上項目管理的方式都可以作為一個參考，因為項目管理方式本來就是靈活多變，因地制宜的，只要讓關鍵用戶滿意并且能按時完成的項目都叫好項目，使用的項目管理方法就是好的模式，一定有借鑒的意義。
五、項目群管理
全局思維是項目群管理的基礎，處理好各單獨項目之間的關系，管理好整體及個體的節奏非常重要。比如項目群的目標是1月1號上線，相關系統必須以此目標進行計劃倒排，并且要明確好關聯關系，避免作出的計劃后置環節先于前置環節完成。項目群的管理廣度大于深度，對于各項目間的調和比單線項目的理解更重要。
項目群一定要打通信息通道，切忌各自為政各干各的，導致重復用功。最常規有效的方式就是日例會或者周例會，讓各系項目的項目經理分別匯報項目進展，重點是識別出對關聯系統的要求。
資源有限的情況下，優先將資源投入到高投入產出的板塊中，橫向對比，統一度量口徑。每個項目都說自己價值大都要更多資源，如何區分優先級是項目群管理重要的一個問題。按實際情況，統一對比口徑，比如將項目的價值轉換為可提升的人天、給公司創造的經濟價值轉換成錢，比如提升了30個人天/月，那意味著可以裁掉一個人或者調配一個人到別的項目，如果達不到說明評估有誤或項目失敗，后續將減少該板塊的資源投入。此方法尤其針對板塊多且差異大的項目，比如客服項目和業務系統的對比。
小尾巴：一下午沒法看手機回消息，回到酒店打開電腦，99+的消息和十幾個OA待辦，全部處理完了再看好像也沒有那么著急，公司么，項目么。離了誰都能轉～
本文由 @謝宇 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
感同身受，管項目的本質是在管人和統籌資源。