產品經理的專案管理實戰
做為無所不能的產品經理，雖不是上知天文下知地理，但是也要對產品相關的知識領域有所涉獵。專案管理就是與產品密切相關的一個知識領域，同時也是產品經理日常工作中經常要負責的一部分內容，別問我為什麼不是專案經理負責，因為沒有……
本文結合實際工作實踐以及專案管理方面書籍所學，深入淺出介紹在敏捷開發的網際網路公司中一個專案從無到有所經歷的各個環節，當然專案管理這門學問還有很多需要深入探索的領域，以下僅僅對沒有過多專案管理經驗的產品新人做一個入門引導。
一、做產品還是做專案？
產品就是專案，專案就是產品。在很多敏捷開發的網際網路公司中，產品是專案制，功能也是專案制，在策劃一個新功能的時候，對於產品經理來說就是在策劃一個專案。
在PMBOK第六版的官方指南中， 專案指為創造獨特的產品、服務或成果而進行的臨時性工作，專案有固定的起止時間週期。 在大一點的網際網路公司，多個產品經理為同一個產品服務，每一個產品都會絞盡腦汁想一個idea去實現產品、使用者的價值提升。
每一個idea就是一個專案，當專案經歷了立項、啟動、執行、上線、收尾，這個專案就變成了產品的一個功能或一個服務。
二、專案的生命週期
一個產品從無到有，從生到死會經歷多個需求、互動、設計、計劃、開發、提測、上線、hotfix、解決線上問題、運維、運營的生命週期閉環。而在產品生命週期當中也會包含多個專案的生命週期，每一個專案都會經歷 專案啟動、專案執行、專案監控、專案收尾 （PMP中專案的五大過程組在這裡被縮減成為了四個，其中專案啟動包含了專案啟動和專案規劃）。
1. 專案啟動
1.1 需求收集
這個階段其實是產品經理最擅長的領域，即 為什麼要做這個專案 ？在這裡可以參考 精益創業畫布 中的9個要素去回答：
- 服務的使用者群體是誰？
- 解決的問題是什麼？
- 解決方案是什麼？
- 你的優勢是什麼？
- 衡量效果的關鍵指標是什麼？
- 與競品相比，你的門檻優勢是什麼？
- 專案成本有多少（人力成本、時間成本）？
- 專案收益有多少（收入、使用者感知）？
回答好上面的9個問題後，就可以拿著你的idea去和其他產品pk了，能不能獲得老闆們的資源傾斜成功立項，就看你的專案能不能真的打動老闆。在這之中，對於老闆來說，往往更關心專案成本和收益：即用最少的人力、時間成本，得到更大的收入、使用者價值提升。
在這個階段，對於負責專案的產品經理來說，需要輸出的是需求文件及原型，這是你用來打動老闆的基礎，也是需要與涉及專案團隊成員溝通需求的基礎。
1.2 專案啟動會
在立項會上順利從老闆那裡獲得資源後，專案可以真正開始啟動了，這時就需要召開一個專案啟動會，將專案涉及的各個團隊召集到一起，給大家講一個充滿想象力的美好故事，讓大家為了這個目標而努力。
好吧扯淡完了，具體需要做哪些呢：
- 明確專案要做什麼 ，其實在這個環節，就是給各團隊的同學講為什麼要做這個專案，這個專案能解決什麼問題，帶來什麼樣的收益，用專案價值去打動各團隊一起努力比老闆說必須做這個理由更有說服力和感染力，也會讓所有人全心全意去為專案努力付出
- 明確各團隊的職責 ，即為了這個專案需要做哪些功能的新增或對現有功能的優化
- 明確時間節點 ，即針對於上面提到的功能或優化，各團隊開發、測試以及聯調的時間節點，明確時間節點可以保證專案可以在計劃的時間內完成
- 明確專案干係人 ：專案負責人、技術負責人、測試負責人，在遇到問題時可以找到對應負責人溝通
這個階段，在專案啟動會完要出一份會議紀要，周知專案涉及的所有成員，注意不僅僅是與會人員，有時在專案啟動會參與的同學也許僅僅是各團隊的主要負責人，並不一定是最終參與專案開發和測試的同學。所以在會議結束後將會議的內容整理成郵件，群發涉及各團隊的所有成員。會議紀要郵件中可以附上專案需求文件及原型，方便專案成員理解，同時還需要在會議紀要中明確專案啟動會中確定的幾個關鍵要素：專案負責人、專案中各團隊需要做的功能或優化的功能點，專案的時間節點：開發時間、測試時間、聯調時間和上線時間。
1.3 需求討論及需求分析
作為產品經理，你可能是某一個專案的負責人，也可能是專案相關團隊的產品經理。無論哪一個，你都需要針對自己團隊負責的任務進行需求整理，與自己團隊的開發、互動視覺設計、測試確認需求、評估需求。
基於需求文件與開發、測試、設計進行溝通，確認需求並由相關人員給出工時，在需求確認階段要注意的是，每個迭代的人力成本和時間成本是有限的，並不是所有的需求都要在一個迭代幹完，參照MVP設計原則，專案也是按照一期二期這樣規劃的。所以在需求確認過程中，確認需求的優先順序及排期，哪些必須一期實現，哪些需要在二期進行完善。在進行需求優先順序排序的過程中可以參考KANO模型，同時也要根據需求點的工時排列，保證在當前排期內可以完成。
這個階段，輸出的文件並非需要由產品負責，而是由具體的開發人員、測試人員、設計人員給出各自負責功能的任務項拆分，細化到天的顆粒度，保證任務是在監控的範圍內。
2. 專案執行與監控
2.1 專案執行
需求確認、工時評估完成後，正式進入專案執行階段，由相關成員進行開發、設計及測試。
2.2 站立會、週會
每日站立會以及週會是保證專案正常進行的手段之一，通過每天的站立會溝通，確認團隊成員是否遇到了問題，針對問題進行及時溝通與解決，保證專案可以正常進行。
如果專案時間較長，通過週會可以統計週期內好的現象以及遇到的問題，通過會議總結，讓各團隊瞭解當前專案進度以及遇到的阻礙。
對於跨團隊的專案，往往沒有時間聚集起所有團隊成員一起進行會議溝通，可以由專案負責人與各團隊負責人進行週期性溝通，確認可團隊的專案進度。
這個階段，專案負責人會輸出專案週報，週報的內容主要包含專案當前進度，專案遇到的問題與阻礙，專案下一階段的計劃，涉及各團隊的關鍵里程碑節點。
2.3 聯調
聯調往往是跨團隊專案需要考慮的問題，只要專案涉及的團隊大於兩個，就需要進行專案聯調，保證各自團隊負責的功能模組不會因為新的需求出現問題。如果涉及多團隊涉及從前到後的流程變更，需要在聯調前，召集各團隊測試負責人進行溝通，明確測試範圍、測試時間以及迴歸範圍，保證專案上線時新功能模組的使用以及之前相容功能的正常使用。
在測試聯調階段，需要每日召開團隊間的站立會，確認各團隊之間測試遇到的問題，如環境問題、版本問題等，提高測試效率，保證上線時間和上線質量，不要因為測試不充分出現上線後回滾的問題。
2.4 專案監控
專案監控，是保證專案進度，保證專案可以在規定時間內保質按時上線，簡單來說就是對專案風險的管理。遇到專案風險如何處理，如何解決。
專案風險的可能性有很多，比如開發的delay、測試出現嚴重bug、業務需求方在專案進展過程中頻繁變更需求導致工時無限延長等等。
專案管理指南中指出了專案管理的鐵三角：範圍、成本、時間，但是在筆者看來，專案管理的本質是對人的管理，通過溝通與跟進保證專案的風險出現的可能性儘可能低。這裡的溝通可能是向上溝通也可能是平行溝通，發現問題背後最本質的原因，基於此去解決問題，如果風險過大真的導致專案的delay，那麼也要許溝通專案的各個相關方，保證當前線上不會出現問題。
3. 專案收尾
結束是新的開始，專案也好、產品也好，只要沒有死，就一定還會有新的開始。在產品的生命週期中，包含著無數個專案，這其中有好的專案也有不好的專案。
每一次的專案上線或收尾，都需要對專案進行一次覆盤和回顧，發現專案過程中的優點與不足，優點繼續保持，不足找到解決方案，在下一次專案中儘可能的避免。
在專案上線後，召集專案成員進行專案的總結與覆盤，同時基於專案上線後的效果進行監控，為專案的下一期規劃提供指導意見。如果通過專案發現與市場、使用者完全不契合，那麼儘快放棄尋找新的方向；如果專案效果還不錯，還有值得優化提高的地方，尋找可以優化的點進行新的排期與規劃，通過不斷的迭代提升產品價值，為使用者創造更大的價值。
三、異地跨團隊專案的坑
因為業務系統的融合，最近做了一個涉及兩地跨團隊的專案：後端兩個業務系統之間的對接，涉及業務訂單發票的全業務流程對接。
坑一：專案並沒有召開啟動會，兩方團隊對專案的重視程度不一致，導致一方將優先順序排的較高，而另一方僅僅認為是換介面而已，雙方沒有就專案達成認知上的共識，在對接過程中積極程度不一樣。
坑二：業務流程是從老流程到新流程的切換，雙方前期僅僅對於業務概念進行溝通，雙方認為各自對業務流程達成了一致。但是有一種你認為並不真的是你認為，這個問題在真正專案上線小流量測試的時候才發現，原來雙方對業務流程的認知偏差很大，導致線上不斷暴露問題。
坑三：在遇到專案風險和專案delay時，雙方團隊的負責人一直在針對線上問題而解決問題，並沒有認識到問題出現的本質原因是雙方流程上的差異，最終導致的結果就是一直在針對暴露的問題而修復，問題不斷暴露，產生了持續性的delay。
對於有較為充足的專案經驗的產品或者專案經理來說，這個專案中的坑都是小兒科的問題，但是對於一些初入職場負責專案管理的產品來說，還是有可能踩到的。當產品負責人感覺到自己已經深陷入專案的坑中，不如先跳出整個專案，重新去梳理遇到問題的原因，從一個旁觀者的視角去分析一下遇到的問題，尋找解決方案。當局者迷，旁觀者清。
四、總結
做專案與做產品一樣，都是一個不斷迭代不斷打磨的過程，對於產品經理來說尤其是對於沒有專案經理配合的產品經理來說，並不是產品需求確認後就可以坐等產品上線了。在產品開發過程當中，不僅要考慮未來產品的規劃，還要關注當前產品的進度，通過溝通、監控、協調，保證當前功能可以正常上線，否則再多的規劃如果無法真的落地，也終究是規劃。做產品就是做專案，一個優秀的產品經理也必然是一個優秀的專案經理，也許你並不需要考PMP，但是你要對實戰中的專案管理有自己的認知和方法，這樣才能保證你的產品健康的活下去。
#專欄作家#
記小憶，公眾號：PM龍門陣，人人都是產品經理專欄作家。野蠻生長的產品經理，擅長從0-1搭建產品經理知識體系。
本文原創釋出於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議