在我剛來團隊那會兒，服務端的開發方式很少以項目的方式推進，可能同時對接多個PD，需求顯得零散，沒有整體的節奏感，且在團隊內部不透明，從15年下半年開始，產品需求以單個月為時間節點統一管理，客戶端發布節奏控制在每個月一個新版本，上個月我作為PM負責服務端開發的項目推進（輪崗）。

一、以下是項目開展期間遇到的一些問題：

1. 產品方案未細化 ： 前期考慮不完善、產品部分功能對應后臺未提及、做了一半的需求被終止、運營需求未進行產品化

2. 改需求加需求 ：溝通不充分，運營策略臨時改動，進入預發測試之后還在改產品細節

3. 前端資源節奏不匹配 ：部分功能需要和前端對接，但前端資源投入過晚

4. 時間評估偏少 ：直播技術方案，細節和交互規則多方多次確認，實際耗時更長

5. 依賴方環境不夠穩定 ：算法接入環境不穩定增加額外的聯調成本

6. 上個月遺留需求 ：實際遺留需求額外工作量比想象的多，無人跟進整理

7. 穿插項目期間的線上問題排查 ：新引入或者歷史原因遺留的bug修復優先級問題

8. 項目管理工具沒有被用起來 : 只在項目初期羅列了拆解的任務，中間需求變更和新增時被繞過， 項目進入開發后需求情況開始變得不透明

9. 視覺稿影響方案設計：開發階段以交互稿為參考，但視覺稿出來之后，又新增了改動點，導致設計方案重新考慮

沒有包含服務端測試和客戶端測試部分，可能還有一些遺漏的地方。

二、以上列舉的這些情況，可以抽象地分為幾類：

1、根據分工不同，在不同角色進行配合時，分工角色沒有充分做好本職工作，導致產品需求或者技術需求沒有被充分表達，導致方案在后期不斷變更，增加溝通成本，時間成本，頻繁修改重新設計，引起參與者的不滿情緒

2、不可靠的依賴方，未建立強有力的有效推進機制，表現在兩方面，一是合作方互相信息不互通，問題沒有及時感知和快速解決，二是前期規則沒有定義清楚，導致各方推進節奏不一致，無法及時獲取反饋，甚至互相阻塞，耽誤時間

3、部分風險點在項目前期討論被忽視，導致后期時間排期緊張，部分風險點在項目開展過程中產生，但沒有被納入管理，也沒有被透明化出來，不斷積累項目風險，部分風險點被轉移到下一個版本

從整個項目周期來看，每個階段都有可能遇到問題，有些是人為，有些似乎不可避免，由此也引出一個思考點，項目管理到底是在管什么？

產品需求從提出到落地，主要涉及的角色包括產品、交互視覺、前端、客戶端、服務端、測試，項目管理在其中最大的作用，用一句話就是，保證需求在每個環節以可靠的方式被正確地傳遞和表達。

a. 這首先要求每個環節的參與者都明確地知道自己所承擔的職責，清楚每個時間點應該做些什么，參與者要有相應的能力，不能成為整個鏈路的短板和風險點

b. 其次是在進行需求對接時，各方需要進行充分的溝通，確保需求在前期就考慮完善，明確清晰，且被準確傳達，防止后期不斷修改，少做無用功

c. 再者是在項目推進中需要有高效的問題解決機制，能快速地發現問題和解決問題，避免風險點積累導致項目不可控

三、本次項目的幾個改進方向

1、項目排期的時候，有些細節點未考慮周全不可避免，但是可以盡量減少這部分風險，如更完善的產品方案，在部分產品需求點的細化，其實是被后移至開發階段的，需要減少這種情況的發生；

2、項目開發中，產品在加需求和改需求的同時，需要考慮重新梳理需求的優先級，砍掉一部分優先級較低的需求，否則項目風險會不斷增加，并且這些多出來的工作量，像在本次項目中，都是靠開發同學加班加點趕出來的；

3、基于本次項目中出現的以上幾點情況，后續項目中都需要考慮到，至少預留一定的時間，還可以每天進行一個簡短的會議明確要解決的問題，建立相應的溝通項目群；

補充：有哪些時間是被浪費的，有哪些返工是可以避免的，有哪些節奏是可以配合得更好的，有哪些方法可以兼顧靈活性減少無用功，有哪些行為是堅決制止的？