痛點一:資源不足

討論背景：

任何一家公司、任何一個部門永遠不可能資源充足，管理人員要適應資源不足的常態(tài)，故而針對以下問題進行了內部討論：

需求太多，產(chǎn)品啥都要？

工期緊張，立flag卡時間？

人員有限，有hc招不到人？

依賴太多，狀況百出，各種延期？

交流心得：

一、需求太多–排優(yōu)先級

1.1. 產(chǎn)品

1.1.1. 確保主流程優(yōu)先

1.1.2. C端用戶體驗優(yōu)先

1.1.3. 探討方案替代(看透需求本質，產(chǎn)品要的是過河，不一定是船/橋)

1.1.4. 產(chǎn)品妥協(xié)、降級(先上線，再迭代)

1.1.5. prd需求質量(同頻共振，產(chǎn)研理解一致）

1.2. 技術

1.2.1. 復用已有組件/服務

1.2.2. 代碼規(guī)范性，風格可適當共存

1.2.3. 擴展性(預留2期,3期)

1.2.4. 架構不過度設計

1.2.5. 合二為一(技術類優(yōu)化可和產(chǎn)品需求合并，一次性開發(fā)、測試、上線)

1.2.6. 拔插式(部分服務沒改造之前，替代服務先使用，后局部升級)

二、工期緊張–提升效率

2.1. 架構方案折中(沒有完美架構，先實現(xiàn)需求，再迭代優(yōu)化)

2.2. 人員分工(經(jīng)驗豐富更熟練人員做最快)

2.3. 前緊后松(工期往前趕，余留buffer)

2.4. 集中封閉

2.5. 分模塊并行提測

2.6. 任務拆解詳細(粒度越細，把控更精準)

2.7. 外部依賴協(xié)調(高優(yōu)解決外部，明確需要對方做什么，時間點)

2.8. 同步做(服務、權限、數(shù)據(jù)庫，開發(fā)和線上一起申請)

2.9. 做預案 plan B

2.10. 整理上線todoList

2.11. 人員借調支援

2.12. 定時check（站會，晨會，周會）

2.13. 求教高人(技術難點，多問多溝通)

2.14. 當面求教(不限于IM溝通，電話，當面)

三、招不到人–注重平時積累

3.1. 靠介紹(主動找朋友、同事、前同事)

3.2. 自己去平臺找(BOSS，拉勾、脈脈)

3.3. 廣告(朋友圈、社交平臺宣傳)

3.4. 外部影響力(公眾號、社區(qū)、技術答疑引流)

3.5. 推薦獎勵

3.6. 提升現(xiàn)有人員能力

3.7. 提升研發(fā)效率

3.8. 崗位核心競爭力、崗位亮點

3.9. 適當放寬門檻

3.10. 適當提升福利待遇

3.11. 人脈積累

四、依賴太多–學會適應別人

4.1. 提前節(jié)點溝通(立項、開發(fā)、聯(lián)調、測試、上線)

4.2. 主動溝通(必要可升級溝通方式：電話，當面)

4.3. 做預案 plan B

4.4. 風險預警，問題向上升級

4.5. 維護人際關系

4.6. 站在別人角度想(解決他的困擾，eg：陪加班可開車送回家等)

4.7. 上線后感謝信

4.8. 請老板站臺

4.9. 自己人(不同部門都有處的好的朋友，通過朋友再推動)

4.10. 先看文檔，帶著問題結論尋求幫助(服務入?yún)?、出參?

綜上，核心三要素：MVP迭代，提升效率/能力，注重平時積累。

痛點二:情緒牽制

關鍵詞：溝通不暢，領導不滿意、員工鬧情緒

項目經(jīng)理一個很重要的職能就是溝通協(xié)調，多數(shù)項目管理人員缺少風險預判能力，當出現(xiàn)面臨風險和出現(xiàn)問題時又不能很好地向項目各方反饋，更提不出好的解決方案。

比如多數(shù)技術轉型項目管理人員面對不合理需求時，不敢也不會向客戶反饋、更不會向公司領導表述，任務強壓給團隊成員后，又不能安撫好員工情緒，結果可想而知。對于不懂技術項目管理人員的問題是分析問題（尤其是技術問題）不深入，往往口頭禪是這塊兒不太懂、這塊兒沒想到或沒想明白，由XXX來說，開個會恨不得能拉上整個團隊?；仡^分配任務，要不就是發(fā)號施令，要不就是傳聲筒，從而逐漸喪失威信。

項目經(jīng)理作為一線基礎管理人員，對外有客戶、甲方、用戶、監(jiān)理，對上有領導，對內項目團隊成員，需要合理規(guī)劃、統(tǒng)籌安排、有效溝通才能真正把項目做好。

交流心得：

一、領導不滿意

1、信息傳遞失真

1.1、多討論

1.2、反講確認

1.3、快速反饋

2、團隊效率不高

3、風險識別不夠

3.1、傳授方法論

3.2、親自帶著做

3.3、了解上下游

3.4、了解每個人困擾

3.5、多深入一線

4、主動向上匯報

5、主動性熱情不夠

5.1、權利不夠

5.2、價值沒說清楚

5.3、引導贊美鼓勵

5.4、提升視野、認知

5.5、關鍵先生

5.6、關系維護

6、下屬問題麻煩制造者

6.1、潤物細無聲，不是針對他，所有人都一樣

6.2、配備back up，彌補他

6.3、規(guī)范流程、明確制度要求

6.4、能力差—提升技術能力

6.5、粗心大意—責令改進

6.6、陪他一起習慣培養(yǎng)

6.7、準備工作做充分

7、軍令狀flag變來變去

7.1、調研不充分，信息決策不夠

7.2、團隊達成不統(tǒng)一

7.3、溝通不夠

7.4、粒度粗，不夠細致

7.5、轉危為機，找更優(yōu)解

8、描繪很好，結果沒執(zhí)行到位—不切實際給老板吹

9、老板基本工作要求未達成—定期周知老板，及時矯正

10、有擔當，不找借口

二、員工鬧情緒

1、工作分配不合理

1.1、了解每個人職業(yè)訴求，盡量滿足

1.2、是否愿意

1.3、工作量太多

1.4、長期固定

2、公眾場合被批評—私底下溝通

3、被甩鍋、委屈

3.1、幫他澄清

3.2、邊界劃清楚

3.3、適當安撫

3.4、風險提前周知(事實)

3.5、對結果保證(先于別人之前發(fā)現(xiàn)問題)

4、邊緣業(yè)務，沒價值沒成長

4.1、輪換制度

4.2、提高要求

4.3、技術賦能

4.4、關停下線(說服大家)

4.5、真誠溝通

4.6、放任務池，等主動認領

5、做得越多、錯越多

6、隊友不給力

6.1、擺正心態(tài)

6.2、互助提高

6.3、寬容、別較真

7、待遇被倒掛

7.1、所做事情要證明價值

7.2、成長性，放權給他

7.3、主動給予

8、榮譽獎勵不公

8.1、盡量公平

8.2、考核標準要明確

8.3、透明、公信力

8.4、其它方面補償

8.5、給最需要的人

9、性格孤僻、與團隊不和

10、被領導畫大餅

10.1、不要期待太多

10.2、領導盡量言行一致

11、被領導PUA

11.1、量力而行

11.2、容忍性

11.3、聽一聽就行

12、情緒低落

12.1、團隊關懷

12.2、自我調節(jié)

12.3、情緒宣泄

12.4、團隊榮譽感

綜上，面對項目團隊負面情緒，作為項目經(jīng)理要及時感知并調整。最重要的是：把事情做正確。

痛點三:全局迷失

關鍵詞：沒有全局規(guī)劃能力，資源調配失衡，目標不清晰

比較典型是水來土掩兵來將擋型，一事一議，全然沒有計劃型，結果導致資源調配失衡，不是資源浪費就是資源短缺。往往需求來了，不加以深入分析和設計，就急急忙忙向公司申請一大批開發(fā)人員介入，后期又過早把人員釋放，導致測試階段和上線后問題不斷，沒有人員及時修復系統(tǒng)缺陷。

項目管理人員從接觸需求開始，就要全面分析需求、任務拆解、階段劃分、人員配置等一系列工作，建立項目整體計劃并按計劃推進和資源調配。

交流心得：

一、為什么要分期

1.為什么分期

1.1 項目定位

1.1.1 創(chuàng)新試點類型–最小MVP，敏捷迭代

1.1.2 穩(wěn)定正常類型–固定跟版制、班車制

1.1.3 專項聚焦類型–集中資源，快速完結

1.2 資源短缺被迫拆解

1.3 外部依賴不可控

1.4 迭代開發(fā)，目標清晰

1.5 階段性驗證結果

1.6 規(guī)模小，可控制

1.7 最快看到收益

1.8 緩解大項目壓力

二、沒有規(guī)劃

2.1 緊急需求插入，節(jié)奏被打亂

2.1.1 盡量減少需求插入–提前預知，未來2個版本要做啥

2.1.2 留buffer–積少成多，會導致大時間軸被拉長

2.1.3 政策不可控–長期關注行業(yè)政策，提前準備

2.1.4 線上業(yè)務邏輯不合理

2.1.5 體驗優(yōu)化類

2.1.6 老板需求–敢于挑戰(zhàn)老板(雖然最后還是乖乖做)

2.2 人員變動

2.2.1 留出熟系/交接時間

2.2.2 平時培養(yǎng)backup

2.2.3 文檔沉淀–前人栽樹后人乘涼，衡量文檔寫得好不好，看第二個人能不能比第一個人時間更短，更快。

2.2.4 局部模塊明確–把業(yè)務需求翻譯為技術需求，直接開發(fā)

2.3 需求不明確

2.3.1 目標不夠明確

2.3.2 戰(zhàn)略決策調整

2.3.3 邏輯不明確–不同產(chǎn)品顧此失彼，缺乏全盤熟悉，整個項目團隊都梳理維護，技術補位

2.3.4 測試用例，分支不夠全

2.3.5 邊界不清晰

2.3.6 理解不一致，沒達成共識

2.3.7 對上下游了解不夠

三、資源調配

3.1 項目拆解粒度不夠細

3.2 需求理解不一致，不透徹–沒考慮問題根本，而是表象

3.3 調研不夠充分

3.4 聯(lián)調階段，阻塞block

3.5 外部依賴風險評估–可參考已接入案例，上期迭代等

3.6 大量工單走流程、審批–提前了解，提前申請

3.7 永遠要有plain B

3.8 對項目里每個人能力有準確了解

3.9 人員規(guī)模過大，溝通成本–項目團隊規(guī)?？刂?0人以內閉環(huán)。

痛點四:角色固化

關鍵詞：忙于細節(jié)，忽視角色變化：從拉馬車到趕馬車

從技術崗轉型到管理崗的項目經(jīng)理人員通病，多數(shù)就是因為技術和業(yè)務能力比較強，被領導重視和認可，逐漸過渡到帶團隊，進而轉型到項目管理工作。可是角色沒有及時調整和轉換，更多精力在于技術和業(yè)務細節(jié)上，忽視了整個項目的協(xié)調工作。項目成員不能放手去做，依賴性強，項目經(jīng)理本身還有一堆文檔要寫、協(xié)調事兒要處理示，結果就是項目經(jīng)理四處救火，忙得要死，且團隊成員也很難獨撐一面。

項目經(jīng)理的作用：正確定義目標、制定項目計劃、推動執(zhí)行、進行團隊建設及跨部門協(xié)調、保證質量、保證溝通、控制成本、密切監(jiān)控過程并糾偏等，這樣才能保證項目最終的成功。

交流心得：

一、去中心化

1.去中心化

1.1 提前全局規(guī)劃、分配

1.2. 所有人對項目全局了解(這期功能點，目前進度，哪天測試，哪天上線)

1.3. 提前培養(yǎng) backup

1.4. 文檔沉淀，“錯題本”積累

1.5. 責任邊界，所有人清晰誰負責哪些模塊

1.6. 敢于充分授權，只負責跟進

1.7. 同角色內部多分享，所有人都快速接手

1.8. 項目組內部信息廣播，傳遞(開大會，全員周知，不限于微信群，郵件)

二、流程規(guī)范

2.1. 之前做得好的，列出來借鑒

2.2. 兼職pmo，不能只關注自己開發(fā)任務

2.3. 整理項目管理清單，每日一問

2.4. 隨時把控關鍵角色

2.5. 關鍵節(jié)點check，有明確各方配合方案

2.6. 達成共識，不同階段該做什么

2.7. 至少組織3次全員會，需求評審，排期，聯(lián)調提測

三、到處救火

3.1. 提前評估難度、風險，并做準備

3.2. 子模塊業(yè)務可以獨當一面

3.3. 正確的行動計劃(重要&緊急)

3.4. 留出buffer時間

3.5. 做好復盤

3.6. 通過之前案例找到解決方案

3.7. 做事方法論的沉淀

3.8. 提升大家解決問題思路和能力

3.9. 做些通用demo可參考，只負責難點攻堅

痛點五:利益分配

關鍵詞：部門不同，目標不同，利益不同，利益分配的合理性　　

人們奮斗所爭取的一切，都同他們的利益有關，這是馬克思的至理名言。人們?yōu)閳F隊工作，總要獲得利益，或物質的，或精神的。利益的分配，代表著一個人的貢獻和成就。必須公平合理，同工同酬，論功行賞，這樣才可以調動職工的積極性，提高團隊士氣；反之，就會引起職工的不滿，挫傷職工的積極性，降低團隊的士氣。

交流心得：

一、多勞多得

(前提是要讓所有人認可規(guī)則，否則依然不公平)

1.1 項目角色(核心參與者)

1.2 簡單配合支持方要感謝(上線郵件、復盤會、當他領導面感謝)

1.3 目標把控者

1.4 過程中表現(xiàn)(平時收集細節(jié))

1.5 項目攻關人物

二、核心價值

2.1 滿足用戶核心需求(成就感)

2.2 增進不同部門協(xié)作

2.3 項目實際收益

2.4 獨有性(為什么是我們做)

2.5 關鍵先生，較大突破

三、平衡未來

3.1 動態(tài)看不同角色權重

3.2 提前考慮未來依賴部門

3.3 平時注重挖掘潛力人員

四、分配不合理(負面)

4.1 不愿意配合(外部門)

4.2 消極、應付(項目內成員)

4.3 onwer威望值下降

4.4 得不到認同感，人才流失

4.5 提前與各方領導申請資源，方便協(xié)調

上面列舉現(xiàn)象中，大部分之前已經(jīng)給過解決答案，或者問題本來就很簡單，不需要展開討論。綜上，希望能對大家在項目管理過程中有所啟發(fā)。

本文作者：李躍紅，已授權