如何妥善、無縫、無痛地交接(或被交接)其他產品經理的專案?

如何妥善、無縫、無痛地交接(或被交接)其他產品經理的專案?

前幾天突然在公司信箱收到“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原文連結

本站所有文章未經事先書面授權,請勿任意利用、引用、轉載。