當數據產品經理突然通知接手一個新的業務， 那麼如何能夠快速的上手並建立起工作模型呢？這篇文章會繼續深入探討。
01 建立工作模型
當產品經理找到了主要的stakeholder之後，接下來的就是建立一個有效的合作模式（engage model）。
筆者公司是核心業務是互聯網電商，公司內部推行的工作框架是自上而下的V2MOM計劃模型和敏捷開發模型。
在這種環境下，對於PM來說，快速熟悉所對應業務的年度計劃並快速的建起來適合高效的合作模式可以為之後的工作打下堅實的基礎，可以少趟很多坑，接下來我會根據自身經驗，介紹一下筆者在這次實際操作中是如何完成對外和對內的框架搭建。
在進行下面的分享前，先對齊一下概念，簡單介紹一下筆者公司的兩款工作模型。
1. V2MOM模型
V2MOM分別代表願景（vision）、價值（values）、方法（methods）、障礙（obstacles）、衡量指標（measurement）。
公司層面會在每年進行一次年度計劃， 自上而下對現有問題的展開分析從而制定明年公司的多個願景（vision）並確定願景所量化產生的價值（value），公司的目標自上而下將會分配在每條業務線並形成基於高度而不斷細分的方法（Method），筆者公司為2級， M1 公司層面，M2業務部門, scope從大到小。
交付團隊需要每個M2進行基於V2MOM框架的詳細的價值闡述，將M2分解成可落地的M3並寫出已有Obstacle和最終的衡量指標。完成後，進行逐級向上的橫向評估，最終完成公司具體的項目篩選，並完成資源分配。
2. 敏捷開發 – Scrum 網絡上的內容很多， 大家可以自己搜索
3. 對外面向客戶 : 業務 – 計劃 – 需求 – 目標 – 回顧
對於每個團隊來說，在完成了年度計劃後，一年的工作重心會圍繞重點項目以保證能夠交付所計劃的產品和完成目標， 與之對接的數據產品經理需要了解核心stakeholder的M2和M3，理解其今年需要每個產品交付的核心需求以及核心的成功指標（success metrics). 這個可以很好的幫助PM解釋所有客戶產品的深層次需求，筆者一直認為單純的從數據推演的價值是有限的，而目標導向的數據才能萃取出數據的價值。
那麼在這些前提下， 產品經理需要完成以下幾步而完成對業務的理解， 確認對團隊的需求並瞭解設定目標。
1）啟動會議 – 核心瞭解業務重點和實施計劃
產品經理需要和stakeholder建立計劃會議，用以瞭解業務方需求，這個會議上不需要談及技術細節，主要了解業務內容和可能的合作模式。筆者的經驗一般從以下幾個問題引入主題。
- 核心業務介紹
- 今年的業務計劃以及文檔
- 今年的主要項目，開始和交付計劃以及成功衡量指標
- 每個項目的主要的合作方以及職能介紹
- 可能的話需要產品的設計相關文檔
2）設計定期審查會議模型（Regular Review）
定期審查會議的主要作用是和主要的stakeholder共同完成以下行為
- 建立需求列表
- 回顧上一個生產週期的交付
- 確認最新優先級，並承諾下一生產週期的交付計劃
那麼在真正於staekholder建立定期審查會議之前一定要慎重，產品經理需要認真的規劃會議的架構以及期望目標。主要是有三個層面，
- 價值 –這個會議的前提是雙方有長期的合作價值，產品經理需要根據客戶所在部門的年度計劃理解對你的團隊的需求程度來決定是用基於項目的會議框架還是需要設定regular review 來進行持續交付。
- 承諾 –因為這個會議代表著和stakeholder建立一個長期的合作模型，用戶會定期和你進行需求的審查並不斷豐富需求列表，並可以定義需求列表的優先級。
- 效率 –如果你對接的是一個比較大的組織，如筆者這次對接的需求來自於一個上千人的組織，已知的需求方來自10+個團隊，假設每兩週進行一次審查，這無疑對產品經理的大量時間將浪費在準備會議， 參加會議上。而對於獨立產品經理來講，你的效率將會成為團隊產出的瓶頸。
基於以上的背景，筆者強烈建議需要將這個會議進行收斂，將需求向上整合，並建立基於大組織架構的的產品列表。下圖為筆者的收斂過程。
Before – 筆者需要和以下所有的團隊進行對接
After – 為筆者實際的會議僅為4個審查會議（綠色部分）
通過這種方法，筆者在實際工作中大大的提高了工作效率，節約了近60%的會議時間成本。要知道在筆者接收這個業務前，這個業務線一共有4個全職的產品經理，而筆者只有個人的50%的時間資源投入並預期完成同樣的產出，所以筆者要保證會議的每一分鐘都極度高效的。接下來筆者分享一下自己如何進行高效的會議。
3）啟動定期審查會議
設計好會議框架後， 就要開始實際進行會議了。
會議建立
- 確定參會者 – 根據之前的業務瞭解，產品經理已經有能力選擇需要合作的核心人物來參加這個定期審查會議。
- 搭建需求列表（backlog grooming） – 收集需求列表，通過協同工具或者郵件在會議開始前進行需求收集。並對每一個需求要進行了解，產品經理需要能夠回答好這個需求的交付標準（DoD）究竟是什麼，需求的負責人是誰以及有哪些相關方需要參與在這個項目中。
會前準備
- 需要清楚的把握上一個生產週期的具體產出，確認承諾的項目的最新進度，並對backlog進行更新。
- 需要列出所有影響項目產出的主要的問題和即將發生的隱患，這極為重要，因為你需要一方面管理stakeholder的預期並尋求他們的幫助。
- 瞭解新的需求並尋求開發的同事的幫助，幫助評估需求的開發量（t-shirt size), 這將給很大的信息在會議上完成對下一個生產週期的規劃。
- 個人策略 – 你需要很瞭解業務方的重點，並準備好將對那些項目進行傾向性建議。這個策略主要是因為當你面對客戶時，雙方一定會存在概念不對齊，很多項目實際上是互相有依賴關係或者開發效率的最優次序，所以這些信息你需要準備好並在會上進行提案，站在用戶的角度幫助他們實現交付最優。
開展會議
- 快速更新每一個項目的最新進展 – 10% time
- 闡述遇到的問題並確定有結果導向的會後行為， 需要客戶幫助或者暫停項目等待 – 20%
- 橫向對每個業務線進行需求梳理， 並對最高優先級需求進行一輪篩選 – 40%
- 對各業務部門的需求進行第二輪的橫向評估，確定最終項目優先級輸入 – 20%
- 對下個生產週期的項目進行評選並預計交付成果 – 10%
筆者想著重闡述一下c&d， 由於將需求進行向上收斂， 我們的會議實際上並不是面向一個單一的團隊進行而是跨團隊評估， 那麼如何評估每個團隊的需求並保證資源配置符合預期，筆者會
- 將每個團隊的項目進行一輪篩選並提取最高優先級項目
- 進行第二輪的橫向評估並完成優先級輸入
這能最大程度保證優先級得到所有參會者的認同並完成資源配置。
會後總結
筆者強烈建議每一次會議需要寫一封會議紀要（meeting minutes)， 這個會極大的提升會議的效果以及固化會議產出。
- 有助於概念對齊，有時候會議上的共識並不是100%，將結論記錄下來可以幫助參會者對齊概念和DoD。
- 可供之後參考， 好記性不如爛筆頭，記下來的東西可以方便以後查找並固化產出，非常便利。
在每次會議後產品經理需要花30 – 60 分鐘對會議的內容進行消化並進行項目需求和交付標準的撰寫。並準備交付到另一個閉環進行投產 – let’s do sprint。
4. 對內面向研發 : 需求列表輸入 – 計劃 – 生產 – 交付 & 回顧
當產品經理對外完成了backlog搭建後， 接下來就是完成和研發團隊的高效工作模型。
筆者這次的場景比較特別，原產品和研發團隊同時離開，並沒有給足交接信息，這直接導致研發團隊也面臨著巨大的考驗來接手項目並進行持續交付。那麼筆者將介紹產品和研發團隊是如何一起解決這個困境的。
資源分配調整
首先所有人都應該確認一個事情， 就是在這段時間，最終要的一定保證已有的產品線沒有問題，而對於已有產品的運維在這個階段的成本將會遠遠超過平時，所有資源應該大量的傾斜於已有產品的運維。以下是筆者團隊的的資源比例 –
- 縮減新需求資源投入比例 – 15%
- 增加維護的資源比例比例 – 85%
這個情況會隨著時間逐漸平衡，以下為2個月後的資源分配
- 新需求 – 65%
- 運維 – 35%
預期為70% & 30%。
梳理現有產品線並建立技術文檔
對現有的產品， 需要技術的同事快速通過項目代碼分析而掌握整個產品的dataflow和架構，併產出文檔。由於時間緊迫，前期可提供簡圖，這會快速幫助團隊熟悉產品的產品的設計並確定主要的產品相關方。
這個時候，產品經理需要根據從stakeholder處掌握的產品重要性，並快速優先熟悉重要的產品線。
以上行為大概需要3個星期，這三個星期基本上是無法完成新項目交付的，產品經理需要對外確保客戶的合理期望。
開始計劃會議 – sprint meeting
經過三週後，團隊已經熟悉了30%的核心產品，基本上覆蓋了主要的服務人群，這個時候可以開始將工作重心開始向新需求進行傾斜。
筆者團隊開始就是在這個時候開始進行每兩週一次的sprint meeting. 具體的sprint的細節由於外部已經有很多文檔， 筆者這裡就不詳述了。
基於業務的資源分配
由於筆者團隊涵蓋的數據較廣，要求每個工程師熟悉所有的業務是不切實際的，那麼我們需要將人員進行基於domain的分配。
由於在剛接手的時候團隊其實並不知道合理的分配比例，我們團隊的做法是先進行較為廣泛的資源分割，在進行2-3 個sprint後，我們會搞清楚哪些業務的需求較大且與戰略更匹配，那麼我們會進行的人員在業務線的調整，大概兩輪後人員的分配更加合理，產出也得到很大的優化。
總結
以上就是筆者基於個人經驗的一個總結，這次的業務交接發生的很突然， 筆者團隊臨危受命，在人員縮減，完全沒有交接的情況下，發揮了最大的“聰明才智”，廣泛溝通，快速熟悉業務，併成功收斂成高效的合作模型，最終成功的在1個多月的時間裡接手原來的業務並實現了較原團隊更為高效的產出。
回顧整體資源變化：
- 研發 – 縮減20%
- 產品- 縮減75%
- 產出 – 120%相較於原團隊產出（統計截止於接手後2個月）
筆者的踩過的雷能夠給大家未來的工作一點幫助吧。
該文章主要為個人實踐中的心得，如果有什麼問題的話歡迎交流 [email protected]。
作者：Stanley；郵箱： [email protected]
本文由 @Stanley原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自 unsplash，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
