前幾天突然在公司信箱收到“Successful Completion of Probationary Period”的信件，才終於「正式」意識到時間過得這麼快，原來自己已加入新公司剛滿 3 個月了。

入職至今，手上已正式獨立運作 2 條產品線（敝司光是內部產品線就將近 40 條……），且都是從其他 PM 手上接來的。經過這些交接，才突然意識到：原來我沒有當過「被交接者」！

在前前公司做行銷時，我是該產品線第一個行銷；在前公司做產品經理時，我雖然不是第一個 PM，但因為某些因素，當時也不算是很妥善地被交接……所以嚴格說起來，在現職公司是我第一次從別人手中接下一個運作中的產品。

經過這段時間的的交接期，這篇就想來談談，到底該怎樣才能「妥善」交接並「無縫」處理從其他 PM 來的專案（或者把專案交接給其他 PM）。

前情提要＆背景資訊

我在現職公司負責 2 條產品線，都是從其他 PM 手上交接來的，礙於公司內部規定，細節不能講太多，但依然可以介紹一下這 2 條產品線當時的進度：

- 產品線 A：
已改版 3 次並持續運作中的內部工具。
我是 6 月接手，當時只知道 9 月初需進行第 4 次改版的上線，但需求尚未收集完畢。

- 產品線 B：
尚未上線的內部工具，但已完成前期的用戶訪談、PRD、UX flow。
我是 5 月接手，當時只知道主管希望可在 Q3 結束前（9/30）把這個產品推上線。

這兩個產品原本都是由不同的 PM 和 UX 負責，但兩位 PM 交接給我的方式倒是大同小異：

1. 在內部通訊工具問我何時可交接，要約交接會議

2. 雙方約到時間後，在會議前會提供相關文件（用戶訪談、競品分析、PRD、UX flow、UI）並請我先看

3. 會議上會說明：
(1) 該產品主要的 user flow（但不會逐一講 PRD 或 UX flow）
(2) 目前進度（完成哪些、還剩什麼）
(3) 我的自由問答時間

而交接會議後，他們可能以為交接完畢了，但實際上發生的情況是：

1. 該產品線出事了（比如有急需修復的 bug）：交接給我的 PM 還是得第一線處理並回覆

2. 我在內部通訊工具問了幾百個問題

3. 我另外約了不止一次的「後交接」會議

4. 我在規劃好改版需求或特定功能後，又再次諮詢交接給我的 PM

由於我之前也沒有被交接的經驗，經過這兩次的交接才知道，「被交接」比「交接」痛苦好幾倍……（抱歉了，之前要交接我工作的前同事們……）。

原因有二：

1. 「交接者」與「被交接者」兩者在角色上本來就有著天壤之別：「交接給別人」代表「（基本上）之後不用再管這個產品了」；被交接的人則是「要接住一切狗屁倒灶的事（= 各種前人留下的坑與 backlog）」

2. 交接者一定對產品比較熟，很多交接者認為再基本不過、不用特別交接的事，對被交接者而言卻可能至關重要。比如，有些內部產品要連上內網才能用、有些內部產品的資料來源是 X 資料庫，其他產品則是來自 Y 資料庫……諸如此類的大小細節。

但到底該怎樣才能好好完成交接？怎樣才能妥善地交手處理別人交接來的產品呢？經過這幾次的嘗試，以下努力歸納了以下幾個交接起手式：

一、產品文件（PRD (Product Requirement Document)）

背景資訊

在交接產品時，跟做產品一樣的重要的事情是，要知道 “why”：當初為什麼要做這個產品。能夠回答這個核心問題，才會知道這個產品的定位與目標，否則之後一定會難以推進產品迭代。

舉例來說，假如某天主管要求這個產品要加 A 功能，但如果 PM 本人根本不知道這個產品的用途，也不知道要加 A 功能的原因，那又怎麼能夠跟工程團隊爭取人力來做這個功能？又怎麼說服設計團隊一起來規劃新功能的 UIUX？就算功能真的上線，又要怎麼跟大家說明這個功能出現的來龍去脈？

現有的測試環境、帳號、權限

一般來說，每個軟體或網站在上線前應該都有所謂的測試環境，如果是比較大的產品，甚至會再切成不同階段的測試環境，一步步確認沒問題後，才會正式上線。

通常 PM 也會在這些測試環境建立許多測試帳號與資料，所以如果已經有現有資源可用，直接跟交接 PM 拿是最快的！畢竟有些情境可能很難重現（比如要等待特定時間或到達指定人數），能有現成的通常會方便很多。

另外，許多網站也會有所謂的 role & permission，也就是像「訪客」或「管理員」等管理權限的高低之分，有時甚至還有推播與發信等黑白名單（white／black list），這些都記得請交接 PM 幫忙設好權限，才能確保自己接手後在產品中能暢行無阻。

基本介紹

- 最主要的流程

- 主要的頁面與邏輯

- 系統中的角色與權限

雖然有的產品線很龐大，但經過這幾次的經驗，我還是會建議 PM 在交接時，直接把交接會議當作產品 Kick-Off 的會議，從頭到尾把上述各種細節說一次，也就是把 PRD 或 UX 整個過一遍。

相較於讓被交接者自己去看文件，或者純粹由交接者口述給交接者，這樣做的好處是，可以確保被交接者得到的是相對詳盡的規格與資訊，日後衍生的問題（通常）也會比較少，其實也能夠減少雙方交接後的負擔。

二、設計文件

- UI layout

- UX flow

很多時候，雖然 PRD 已囊括很多規格，但百密總有一疏，或者有些極端案例很難在測試機上重現，又或者某些細節就是看了畫面才會知道（比如點了這個按鈕後，畫面會怎麼展開、警示訊息是 tooltip 還是 pop-up 樣式等），所以交接時一定要取得最新版的 UI（和 UX）。

以敝司來說，大家（連 PM 我本人都是）依賴 UX flow 通常是大於 PRD 也大於 UI layout 的，一來因為 PRD 通常沒有畫面，只看文字的話，前端也不知道畫面該怎麼做，與其拿著 PRD 對照 UI，不如直接看 UX；二來 UX designer 其實在做 UX flow 時就會跟 PM 討論許多細節，比如每個資料欄位的規則與限制、畫面上每個按鈕的交互（點了會發生什麼事）等，所以基本上 PRD 有的東西，UX 上也都會有，只是兩者排版的邏輯不同而已。

三、輔助文件

- 每次的迭代紀錄

- 每次的會議紀錄

- 目前進度、下一步

- backlog

上述這些資料，有些 PM 會一起放在 PRD 裡，有些人會另外放；然而，也有些人是放在「自己的」雲端，甚至有些人是完全沒有這些文件。

這些文件之所以重要，是因為「產品」就像是一個有機體，它會從零到有慢慢長出來，通常上述的產品與設計文件只是產品在某個時間點的剖面，觀者可以藉此知道產品「此刻」長怎樣，但不知道產品「曾經」長怎樣、「未來」會擴充成什麼樣子，而這就是這些輔助文件的用途了。

- 迭代紀錄

幫助 PM 了解每次產品改版加了或改了哪些東西，方便以此確認某些功能的出現或消失時間，也方便在 bug 出現時，稍微推測出相關的原因（比如可能是因為當時動了 A，連帶影響到 B，最後造成 bug 出現）。

- 會議記錄

讓 PM 回溯當時是誰基於哪些原因做了什麼決定。不要以為自己記性很好，PM 要處理的屁事真的太～～～多了，不要萬事仰賴大腦，白紙黑字記下來才是最妥當的。更現實點來說，有白紙黑字，也才知道誰要為哪些事情負責。

- 目前進度與下一步

被交接者才能藉此盤點手上有的資源、要做哪些事、下一個查核點（checkpoint）是什麼時候，並以此開始推進交接專案的前進。

- backlog

個人私下都將 backlog 暱稱為「那些可能永遠都沒空做的各界願望清單」。可能是 QA 發現的不會影響主要功能的微小 bug、可能是某個需求端許願已久但沒有也不會死的功能，總之就是每個 PM 在回答需求端說「這個功能我們再討論一下」之後，那些功能會去到的地方。

但也不是說這些 backlog 就是冷宮，只要有人手（比如工程師提早做完某個功能且心情正好）或有適合的理由（比如原本這個待在 backlog 的功能多度被不同需求端提起），在 backlog 裡的項目仍然有可能被排進實作裡。

而且，backlog 除了記載願望清單，也得寫明提出的人、當下的時空背景與脈絡等，這樣萬一之後再被問起「為什麼說了這麽久，某某功能還是沒做？」才知道該怎麼回答。

千萬不要把需求端的話當耳邊風或直接河蟹掉，一來這本來就很不尊重人，二來則是上面說的，我們永遠不知道這些 backlog 會不會在哪天突然變成下一個要開發的主要功能。

四、利益關係人名單

- 跟需求端先打好照面、加群組

- 合作的工程師與設計師

不論是做內部產品還是 to B 或 to C 產品，一般來說，利益關係人都還是可以分成對內和對外，建議可以請交接 PM 列出名單，方便日後逐一打招呼或聯繫。

以我目前做內部產品而言，對內仍有自己團隊裡的其他 PM、工程師、設計師，對外則有這些產品的需求端，比如同公司的財務、人資、各部門的使用者等。

在接手專案時，跟「利益關係人」建立關係是很重要的。對外的部分，首先可以請交接的 PM 先把自己邀進工作群組並簡單介紹，讓對方明確知道這個專案的負責人，才不會有分工不清的問題。

再來可以簡單寒暄並說明下一步，如果已經有需要對方配合的地方，比如之後要開需求會議或請對方確認 UI，也可以在此先開個頭，日後追進度時才不會顯得唐突。

對內的話，如果剛好都沒和這些工程與設計合作過，建議可以在接手時和對方約個一對一會議，時間也不用太長，10 到 15 分鐘就可以！要說明的內容跟上面差不多，另外也可以藉此了解或直接詢問對方的做事風格，或許有助於之後的合作默契。

像我目前合作的 UX 就說，他有碰過管很多的 PM，也有碰過比較佛系的，他就要自己獨立處理比較多細節，兩種 PM 他都可以，但就是跟他說清楚即可，他才知道自己該怎麼做。

五、那些不可書面化的資訊

- 某人的眉角

- 某些後端有做但前端沒有的隱藏功能

- 某些不能讓使用者知道的邏輯

最後，也是最「微妙」的一項交接清單，就是那些「可意會可言傳但不能白紙黑字寫下的資訊」。

合作久了，PM 一定都知道每個利益關係人的毛，哪個工程師最痛恨 PM 開票寫不清楚、哪個工程師最討厭臨時改 UI、哪個設計師有 pixel eye、哪個需求端每次提需求都超不清楚……這些資訊有的是個人特質、有的是工作習慣，一時之間難以記下來，也不一定適合記下來。

但如果有機會，建議還是可以不經意地主動問問看交接 PM，看對方可否分享一些和利益關係人合作的心得，畢竟有問有機會嘛，而且這種事通常比較敏感，雖然這些資訊很實用，但也可能被人認為是在講人長短，所以通常交接者也不會主動提起。

另外，除了與「人」相處之外，也有些隱藏在產品中的「坑」或「彩蛋」是沒有記在 PRD 裡的，比如很多時候資料設錯、儲存後想收回，前端上做不到（畫面上沒有「收回」或「復原」的選項），但後端其實有保留這個功能，或者工程師可以手動處理。但為了不讓需求端常常來煩，並希望大家依循產品原本的使用邏輯，所以產品工程團隊通常也不會主動告知有此功能。

此外，PRD 中雖然都會記錄各種使用情境（use case）和使用流程（user flow），但不一定每個產品都適合寫到 100% 清楚。舉例來說，某間公司有做內部的績效考核工具，但該公司員工對於績效考核的全部流程、參與考核給分的主管、考核標準並不全然清楚，所以這些資訊即使有助於 PM 了解整個產品設計與運作的邏輯，但就只能私下跟負責考核的人資確認，實際的使用情境都不能寫在 PRD 裡。

結論

經過這幾個月的交接，以及無數次在群組與線上會議騷擾交接 PM 們之後，我總算在第三個月把產品接起來了，也能夠直接站在第一線回答需求端的各種問題！感謝把案子交接給我的同事的各種包容，很多時候我都已經問到不好意思了，但他們都還是和顏悅色回答我各種問題。

也感謝這些交接機會，讓我有相關經驗能寫出這篇文章，當時交接完只覺得「欸也還好嘛？看交接同事說得雲淡風輕，這產品應該沒有太多坑」，結果實際使用產品後，才發現自己忽略超多細節，因而衍生出後面的各種二度交接會議與時不時的通訊軟體訊息轟炸。但也是有了這些經驗，才讓我盤點出上面這些交接清單。

希望之後自己再次扮演交接者時，能夠更站在被交接者的立場去撰寫交接文件、讓交接這件事情變得更順暢且無痛。

本文轉貼自：MH（原文連結）