品牌行銷策略，產品行銷與設計，各類型行銷推廣案例分享-品牌行銷點點讚
編輯導語：產品經理交接項目的時刻，也是最容易踩坑的時刻，稍不注意，就要花費不少精力去彌補。本文作者結合自身經歷，在復盤總結了交接項目的全過程之后，為我們分享了一些建議，希望能對大家以后交接項目有所幫助。
最近，我發現“復盤”對于產品經理可真太重要了，可謂是成長的一道捷徑，但今天我想聊的不是復盤的重要性，而是想分享下在對今年新手新產品項目復盤后的一些感想，讓大家盡量避免在接手他人項目時踩坑。
曾經我以為接手新項目就是對方把產品框架、開發團隊介紹一遍，把產品文檔待做事項交代好就ok的了，然而事實證明，是我太天真，里面的坑全是心酸淚。
捋了一遍交接項目的過程后，得出了以下幾點建議。
一、正式交接前
和原PM初步接觸，了解產品概況，初步定下交接時間。
二、列交接文檔清單
根據初步溝通情況，列出需要的交接文檔清單，避免正式交接時，完全按著原PM的節奏走，而遺漏了自己真實所需。
1. 產品架構介紹、需求文檔、原型等資料整體了解產品結構，掌握主要功能和用戶使用場景
文檔、原型均需拿到源文件，以便后期迭代優化，直接在原有原型上改即可，而不用自己重新搗鼓一份
2. 原計劃的產品規劃建設
后續正式接手后你對該產品的規劃可參考此文檔。
3. 對接外部團隊的聯系人文檔
需原PM把該產品對接的不同系統的對接人和聯系方式都一一細致列清楚，等到時候真正接手的時候，你會發現，找人是個非常困難的事。
- 開發團隊：需列明開發老大、項目管理、各個開發負責的模塊前后端、功能模塊；
- 測試團隊：測試老大、測試人員；
- 運營團隊、市場拓展團隊等的姓名和員工ID，并需要向各個對接方都有一個簡單的雙方介紹，拉進溝通群，以避免后續溝通時找不到正確的對接人（同名同姓），或者對方不知道換了新產品經理而拒絕溝通。
4. 當前的版本迭代流程
本以為同在一個公司且同一個團隊，版本迭代流程大體一致，也沒細問，接手了發現，原來這個項目的開發可直接接需求提需求，只是在需求澄清的時候問下PM意見是否能做，而PM只能在會議上給個結果而不是對需求進行深思熟慮后再由自己來確定，且沒有案例評審流程，因為當時我也同時接手幾個項目，所以沒注意到。
等新項目第一個迭代快上線的時候才發現，一問才知道：由于原PM特別忙，測試直接和開發完成評審，跳過了PM。那我就只能去UAT環境進行細細驗證，對于與需求有出入的地方挑差異大，影響實際使用的先改，一堆小問題再放下一個迭代繼續修改。
5. 近幾期版本迭代內容
了解版本迭代節奏和近期迭代方向。
6. 日常管理事項
月度數據報告、產品運營情況通報等。
7. 待辦問題事項
明確需要做但尚未完成的需求或是產品待優化的bug，避免因人員變動而漏掉，使得新PM在遇到時需重新捋一遍，多做一次無用功。
三、正式交接時
正式交接過程中，一邊跟著原PM的交接節奏走，一邊比對之前列好的交接清單查漏補缺，同時更新交接內容。
四、交接完后
盡快熟悉產品，邏輯細節，對于該產品的適用場景，都要有所了解，盡快熟悉的理由除了本身接手新任務就該熟悉產品外。
更重要的是你面對的開發同事是已經負責兩年以上，對于這個產品而言，和他們相比，你是個新人，你需要讓他們知道你對確實了解這個項目，并不是交接時原PM介紹你多么厲害，他們就能服你了，他們可清楚那些只是門面話。
這可是我遇到的最難受的點，第一次開這個產品的需求澄清會時，開發總能找到點懟你，并有種他強你弱的感覺，而你又不好太過強勢，畢竟對于這個項目，我確實是個新人，懟的點，就記下來，會后與市場調研，用數據說話。
2) 產品規劃建設會議，研究公司戰略、市場情況、競品分析，對接手的產品做一個未來一年的規劃。這個會議是用來宣示產品你對這個產品的主權，并訂立規則的，一定要好好把握。
拉上開發、測試同事一起，把產品的建設重點和未來的功能與大家溝通，讓團隊有一致的目標，并把迭代開發流程與大家一起梳理，先按自己過往經驗出一個流程，再根據開發和測試同事反饋意見，進行優化，最后得出一個大家都認可的迭代流程。
對于先前遇到的問題，例如開發同事直接提需求，需在會議明確需求流程規則，需求池的內容必須由產品提。若開發同事有好的想法可以提，但需要提給先產品經理，產品經理考慮后再決定是否錄入。決定權是握在產品手里的。因為該項目要是出問題，第一責任人是產品。
五、總結
新項目的坑縱然很多，但對PM來說，是拓寬產品知識面的好機會，要好好把握。產品道路上的坑，且踩且珍惜。每一個坑，都是一個成長的機會點。
希望這篇文章可以幫助到你，讓我們在成為優秀產品經理的路上一起成長。
作者：張開心；微信公眾號：張開心呀
本文由 @張開心 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議