編輯導語：產品經理需要具備哪些能力呢？ 35%的項目管理能力，15%的個人能力，20%的業務能力，15%的技術能力，15%的溝通處理衝突能力。那麼問題來了，既然項目管理能力這麼重要，產品經理應該如何提升去提升它呢？
產品即作品，一個產品經理需要對最終創造的產品負責，作品生產過程中的流程、涉及到的人事物、發展脈絡、抗風險能力需要做到心中有數。
類似於雜誌社的編輯、電影的導演、音樂的製作人一樣，產品經理作為一個統籌性質的職業，對產品的把控是其需要掌握的職業技能之一，在互聯網行業中，稱之為項目管理。
一、與項目管理有關的幾種模型在計算機系統架構設計中，業界會將常用的軟件開發流程歸納為模型，如果產品經理在產品項目推進過程中感覺到衝突，可能是公司採取的開發模式不同。以下是我瞭解到的一些模型：
瀑布模型是將軟件生存週期的各項活動規定為按固定順序而連接的若干階段工作，形如瀑布流水，最終得到軟件產品。由1970年温斯頓·羅伊斯（WinstonRoyce）提出，直到80年代早期，它一直是唯一被廣泛採用的軟件開發模型。
這種模型常用於大型產品的開發和管理，若產品一個環節出錯，牽扯到的部門較多，容易返工反而不利於開發。
當開發的系統是有積累的已知領域和行業，也非常適用，現在大的網絡公司往往採取這種模式。或者對安全和性能有極其嚴格的要求，容不得半點疏漏，例如航空航天軟件，這樣用瀑布模型的話能夠有效地控制每一環節，所有流程都有文檔可循。
2. 原型模型原型模型是在瀑布模型基礎上一個重要環節的推進，也是產品經理最常接觸和了解的形式。
80年代後，隨着計算機輔助設計的應用，產品造型和設計能力得到極大提高，可以在產品設計完成後，批量生產前，製出樣品以表達設計構想，快速獲取產品設計的反饋信息，並對產品設計的可行性作出評估、論證。
幾乎目前所有的系統，設計都適用並且無法避免地涉及到這種模式。
3. 螺旋模型1988年，巴利·玻姆(BarryBoehm)正式發表了軟件系統開發的“螺旋模型”，它將瀑布模型和原型模型結合起來，強調了其他模型所忽視的風險分析。
螺旋模型基本做法是在“瀑布模型”的每一個開發階段前引入一個非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一個個小項目。每個小項目都標識一個或多個主要風險，直到所有的主要風險因素都被確定。
特別適用於龐大、複雜並具有高風險的系統，對於這些系統，風險是軟件開發不可忽視且潛在的不利因素，它可能在不同程度上損害軟件開發過程，影響軟件產品的質量，例如金融系統、公共事業系統。
二、產品經理的項目管理能力由於公司的開發模式、營業規模、行業領域不同，產品經理往往要兼顧項目管理的工作；並且產品經理要把控整個項目、整個產品、整個迭代，項目管理能力也是產品經理的基礎能力之一。
1. 經過驗證的項目管理流程好的項目管理其實非常簡潔明瞭，一個20-50人的研發團隊，所涉及的項目不會超過20個。而再往大了説，大公司的團隊對具體某個部門的項目把控已上升到OKR的管理模式。
因此，如果項目管理的模式過於複雜，反而不利於團隊對項目的理解，產品經理實際實施階段的項目管理基本上只需要做到：
1）明確產品需求
是產品經理前期對需求的判斷和該需求對應產品上應當作出的設計，這部分更屬於產品經理需求分析的能力。在項目管理中，需要注意的是，需求與各方的明確，以減少後續需求插入和變更的風險。
2）確定產品迭代內容
一般來説，採用的方式為評審。評審後形成共識，這個功能要做如何做什麼時候做好。
3）達成排期
這是項目管理中最關鍵的環節，首先要確認好工時，最好對每個功能小到接口大到技術問題的解決都確定好工時，並且對應到相應的研發人員。在確認工時階段，工時是可以根據研發調研情況自行調控的。
在大致確認好工時後，一定要按工時進行項目排期，不管項目是大是小，都確定好一個交付時間。這個時間可以根據研發人員上一個項目的完結時間依次順延。
最後，不要忘記聯調和測試時間。
4）明確重要時間點
是指每個項目的交付時間、聯調時間、測試時間、上線時間、發佈時間等，只有明確好重要時間點並在團隊中形成共識和契約，整個項目管理才會在一個可控的範圍內進行。
5）把控項目風險
最常見的項目風險就是需求變更，或無法按照如期完成。這時，產品經理一定要在第一時間瞭解項目風險，並解除。
2. 不良項目管理導致的問題不良的項目管理相當於一段有bug或者冗餘的代碼，在產品開發過程中需要注意的不恰當的管理方式：
1）項目無具體排期表，多個項目無連接
迭代過程中，會有一些誤區，排期由研發來定，而產品經理在評審之後，難以確定某個模塊、一個功能或整個項目的交付時間。
採用這樣項目形式的公司往往追求一種靈活的研發方式，並以研發為主來調控整個項目，意為研發驅動，例如讓研發作為一個項目的負責人。
這種形式在初期的創業公司非常受歡迎，而此時產品經理往往作為一個界面設計者，而缺失了多個項目的連接者和管理者，多個項目管理陷入空白。
2）需求由上級觸發，隨意插入項目、延長工期
產品在研發過程中，往往確定性低。若項目管理、研發排期分配不夠合理、公開並形成公認文件。隨時會由於各種各樣的原因空降上級，對當前項目作出指示，加入某某需求或改動某某需求。更有甚者，會直接插入一個項目，延長了工期。
這個問題主要在前期需求和項目立項啓動時，調研不夠充分，並且沒有形成相應的契約。產品總是在不斷迭代升級的，需求的變更不可避免。但一旦涉及到來回變更、隨意插入、延長工期的變更，會變成整個團隊項目管理中的風險。
三、項目管理使用到的工具1. 一個excel表就可以解決這一切前面説到項目管理需要簡潔明瞭更有利於團隊理解，因此一般來説，項目排期表一個Excel表格就可以解決這一切，如果不涉及到牽扯20人以上的項目，無需甘特圖。
至於表格裏的內容也可根據項目大小和團隊需要進行調控，工時、相應研發、交付時間是必不可缺的。
幾乎每個公司都會有其相應的管理工具，有的是公司自研的系統，有的公司使用付費系統，有的使用Jira、teambition等系統，核心功能差別不大，使用熟練，達到團隊協作順暢即可。
四、產品經理項目管理的關鍵節點項目管理中的關鍵節點皆可具化成相應時間點，以便更好的調控進度。
1. 重要時間點- 後端建表時間：若是一個大項目的研發，一般需要進行後端建表，那麼在確定完產品研發方案後，可與研發人員敲定一下後端建表時間，產品和適當參與建表，起到明晰整個項目映射關係，並且可以double-check一下，以免一些小疏忽影響整個項目。
- 前後端聯調時間：在研發項目完成前會進行前後端聯調，這是前後端研發交付的第一步，需產品進一步跟進。
- 研發完成時間：這是最終研發開發完成、自測完成，交給測試的時間。是整個項目完成的基石，若這個階段平穩度過，項目風險大大下降。
- 測試時間：測試需參與評審，並提前做好項目測試相關文檔，在研發提交分支後，在測試環境中進行測試的時長，最終交付給業務和產品。
- 交付時間：交付時間是上線時間的前夕，產品需讓業務參與，確認產品研發結果，產品需進行自測，多方確認後，準備上線。
- 上線時間：往往上線會統合多個功能項目一起上線，一般團隊也會規定每週幾為上線時間，可根據公司情況自行調配。需要注意的是，上線時，該項目的所有研發、UI、產品、測試都需要在場，以免上線出現問題，至少大的項目要做到如此，方能規避上線後給用户第一時間造成的風險。
- 上線後測試：上線後，必須在正式環境再測試一遍，這也需要測試、產品提前做好準備，並且有相應研發在場隨時解決問題。
一般較大的項目，例如涉及到20人以上、跨時2個月以上等，需要立個里程碑，里程碑一般設立在一個節點:
- 某個feature研發完成；
- 進入某個階段：灰度/ABtest；
- 檢驗團隊的工作成果：管理層需要看到的效果。
同樣的較大的項目，時間跨度較長，需在研發過程中同步進度，這時候晨會站會就變得非常必要。每日/每週明確每人開發進度靈活調控，及時上報研發問題，快速響應解決。
五、項目管理中的風險把控1. 出現需求變更研發過程中不可避免的會出現需求變更。接到變更需求時，1.進行需求評估。2.劃分需求優先級。3.評估工作量大小。4.需求做與不做的影響範圍。
公式非常簡單，只有當優先級高、工作量小、不做的影響範圍危害極大時才能插入項目，其餘任何組合可放在下次迭代或另起項目跟進。
2. 出現新項目一個團隊會處理多個項目，在一個項目受到另一個項目衝撞時，首先要明確互斥的項目中有沒有重疊的人員，將重疊人員按照項目先後順序進行工時排序後是不是最佳組合，若為最佳組合，則新項目上線時間順延。
若非最佳組合，可進行人員調配，達到最佳。再者，需調研並與全團隊明確項目風險與重要程度，將項目進行排序，更改排期順序。
3. 預留時間幾乎所有項目，都會延期，區別在於延期長短。而產品在風險管控中要做的，是對這延期長短的把控：
- 根據團隊情況，預留出應急時間、延期時間；
- 留意每次預留時間的反饋，並進一步調控；
- 公開知道預留時間人不能超過3位，哪怕大家心裏都知道有預留時間，也不能形成公認現象。
不同團隊的研發風格、項目管理模式不同，這是一個不斷磨合和適應的過程。讓所有人蔘與進項目管理中，提高團隊的風險和守時意識。
因此每次項目後，尤其是大項目後需進行項目覆盤。跌過一次的跟頭不再跌這是把控風險的重要方法。相當於團隊在一起枚舉各種研發中出現的風險，慢慢形成環環相扣的團隊。
本文由 @原碼詩 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議