編輯導語：產品經理需要具備哪些能力呢？ 35%的專案管理能力，15%的個人能力，20%的業務能力，15%的技術能力，15%的溝通處理衝突能力。那麼問題來了，既然專案管理能力這麼重要，產品經理應該如何提升去提升它呢？
產品即作品，一個產品經理需要對最終創造的產品負責，作品生產過程中的流程、涉及到的人事物、發展脈絡、抗風險能力需要做到心中有數。
類似於雜誌社的編輯、電影的導演、音樂的製作人一樣，產品經理作為一個統籌性質的職業，對產品的把控是其需要掌握的職業技能之一，在網際網路行業中，稱之為專案管理。
一、與專案管理有關的幾種模型
在計算機系統架構設計中，業界會將常用的軟體開發流程歸納為模型，如果產品經理在產品專案推進過程中感覺到衝突，可能是公司採取的開發模式不同。以下是我瞭解到的一些模型：
1. 瀑布模型
瀑布模型是將軟體生存週期的各項活動規定為按固定順序而連線的若干階段工作，形如瀑布流水，最終得到軟體產品。由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人以上的專案，無需甘特圖。
至於表格裡的內容也可根據專案大小和團隊需要進行調控，工時、相應研發、交付時間是必不可缺的。
2. 過程中進度把握：專案管理工具
幾乎每個公司都會有其相應的管理工具，有的是公司自研的系統，有的公司使用付費系統，有的使用Jira、teambition等系統，核心功能差別不大，使用熟練，達到團隊協作順暢即可。
四、產品經理專案管理的關鍵節點
專案管理中的關鍵節點皆可具化成相應時間點，以便更好的調控進度。
1. 重要時間點
後端建表時間：若是一個大專案的研發，一般需要進行後端建表，那麼在確定完產品研發方案後，可與研發人員敲定一下後端建表時間，產品和適當參與建表，起到明晰整個專案對映關係，並且可以double-check一下，以免一些小疏忽影響整個專案。
前後端聯調時間：在研發專案完成前會進行前後端聯調，這是前後端研發交付的第一步，需產品進一步跟進。
研發完成時間：這是最終研發開發完成、自測完成，交給測試的時間。是整個專案完成的基石，若這個階段平穩度過，專案風險大大下降。
測試時間：測試需參與評審，並提前做好專案測試相關文件，在研發提交分支後，在測試環境中進行測試的時長，最終交付給業務和產品。
交付時間：交付時間是上線時間的前夕，產品需讓業務參與，確認產品研發結果，產品需進行自測，多方確認後，準備上線。
上線時間：往往上線會統合多個功能專案一起上線，一般團隊也會規定每週幾為上線時間，可根據公司情況自行調配。需要注意的是，上線時，該專案的所有研發、UI、產品、測試都需要在場，以免上線出現問題，至少大的專案要做到如此，方能規避上線後給使用者第一時間造成的風險。
上線後測試：上線後，必須在正式環境再測試一遍，這也需要測試、產品提前做好準備，並且有相應研發在場隨時解決問題。
2. 里程碑
一般較大的專案，例如涉及到20人以上、跨時2個月以上等，需要立個里程碑，里程碑一般設立在一個節點：
某個feature研發完成；
進入某個階段：灰度/ABtest；
檢驗團隊的工作成果：管理層需要看到的效果。
3. 晨會&站會
同樣的較大的專案，時間跨度較長，需在研發過程中同步進度，這時候晨會站會就變得非常必要。每日/每週明確每人開發進度靈活調控，及時上報研發問題，快速響應解決。
五、專案管理中的風險把控
1. 出現需求變更
研發過程中不可避免的會出現需求變更。接到變更需求時，1。進行需求評估。2。劃分需求優先順序。3。評估工作量大小。4。需求做與不做的影響範圍。
公式非常簡單，只有當優先順序高、工作量小、不做的影響範圍危害極大時才能插入專案，其餘任何組合可放在下次迭代或另起專案跟進。
2. 出現新專案
一個團隊會處理多個專案，在一個專案受到另一個專案衝撞時，首先要明確互斥的專案中有沒有重疊的人員，將重疊人員按照專案先後順序進行工時排序後是不是最佳組合，若為最佳組合，則新專案上線時間順延。
若非最佳組合，可進行人員調配，達到最佳。再者，需調研並與全團隊明確專案風險與重要程度，將專案進行排序，更改排期順序。
3. 預留時間
幾乎所有專案，都會延期，區別在於延期長短。而產品在風險管控中要做的，是對這延期長短的把控：
根據團隊情況，預留出應急時間、延期時間；
留意每次預留時間的反饋，並進一步調控；
公開知道預留時間人不能超過3位，哪怕大家心裡都知道有預留時間，也不能形成公認現象。
4. 專案覆盤
不同團隊的研發風格、專案管理模式不同，這是一個不斷磨合和適應的過程。讓所有人參與進專案管理中，提高團隊的風險和守時意識。
因此每次專案後，尤其是大專案後需進行專案覆盤。跌過一次的跟頭不再跌這是把控風險的重要方法。相當於團隊在一起列舉各種研發中出現的風險，慢慢形成環環相扣的團隊。
本文由 @原碼詩 原創釋出於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議