團隊變形記(下)- 中大型軟體產品團隊、產品經理的組織分工

Anne Hsiao
3PM LAB 產品三眼怪實驗室
8 min readFeb 9, 2019
離開世界之前,一切都是過程,活著不難,最難的是做人。
- 蛋堡《過程

前情提要:《團隊變形記:小型到大型產品團隊的 PM 定位大不同!》、《團隊變形記(上)- 小型團隊PM的多重人格》、《團隊變形記(中)- PM 的工具人自我養成計畫

我之前加入了一個快速從 20 人成長到近 200 人的團隊,這一篇來說說當PM、工程師團隊擴張後後,我們嘗試了哪些分工方式。

這個階段產品與業務趨於穩定,團隊有很多想做的事,所以瘋狂招募新人加入。當時產品經理、設計師共約 10 人、QA 手動與自動測試 10 人、工程師 30 人,全部加起來已經是一個 50 人的產品團隊了!可惜人手多不一定好辦事,隨時都要拿出《人月神話》來警惕自己一下。

Ref: unsplash

產品團隊如何分工?

當時整個產品團隊從單純的資源角度分工(A工程師現在有空,那就來修B功能吧),改為「功能模組」來分工,每個工作小組包含獨立的產品經理、工程師、QA,而設計師資源稀缺所以共用。以電商平台為例可分為:

【功能模組分工】
・產品、訂單管理
・金流、物流
・優惠活動、行銷廣告
・顧客、會員管理
・商店設計
・購物車、結帳流程產品

這樣分工的好處是整個公司的人都能夠很清楚知道,產品某個地方出問題可以找哪個組別負責處理,但一定會有漏網之魚、或是功能重疊的問題。

舉例來說,我們要做「將商品加入我的最愛清單」的功能,這算是顧客管理的功能、同時影響商店設計、更涉及了整個購物車和結帳流程

Ref: http://www.sarahcarne.com/wishlist/

另一種常見的分工方式是以「目標」來分工,同樣以電商平台舉例:

【目標分工】
・優化賣家體驗
・優化買家體驗
・用戶增長(Growth)
・變現(Monetization)
・提升信任(Trust, Fraud & Risk Control)

上面提到的「將商品加入我的最愛清單」功能就可以歸類在優化買家體驗小組中,然而像是「即時訊息」的功能,同時觸及賣家體驗、買家體驗、且一開始可能是由負責增進產品信任的小組提出,一樣會有權責模糊的問題。

分工方式百百種,我自己會去看一些大型產品團隊的徵才頁面與 Job Description 來旁敲側擊他們的分工方式。

Ref: Careers at Agoda

權責不清的解方:溝通

不管是哪種分工方式,都難免還是會有權責模糊不清的狀況發生,這只能仰賴分工的調整,與 PM 之間頻繁的溝通來處理。(聽來聽去都是幹話,但事實就是這樣😭😭😭)

第一是要避免重工,也就是幾個人在做同樣的事情造成資源的浪費。PM人數不多時我們每天跟著工程師 standup meeting 確保彼此做的事情沒有重複且都是 top priority 事項,人數多分工之後我們每兩週 sprint 開始前會有所有 PM 一起的全會,分享彼此手上正在進行的事項。

再來是處理上述案例中功能重疊在很多模組中的狀況。以模組分工中「最愛清單」的案例來說,一開始是負責顧客管理的 PM 從使用者訪談、回饋中發現這個需求,而因為會牽涉到商店設計結帳流程,可以先召集這兩個 PM 討論目的、目標、初步構想與需要其他團隊幫忙的地方。

【顧客管理PM】基於ABC理由,我想要在商品頁、結帳頁加入我的最愛icon,並在顧客登入後的會員中心加入一個「最愛清單」頁面。【商店設計PM】我們目前在這幾個頁面正在做DE的功能,跟這個功能有dependency,需要等我們把DE功能都推上線後再來開發跟測試「最愛清單」功能,設計的時候也要考慮到DE功能到時候已經在頁面上囉!【結帳流程PM】我不建議在結帳頁加入這功能,尤其不適合低單價的快銷品商店使用,可能間接造成轉換率下降(而轉換率是我們小組的重要指標),是否能多做些實驗或研究再決定呢?

權責不清最怕遇到的事情就是未溝通就先斬後奏,影響到其他PM原先設定好的計畫與指標。設計與開發的時候也有可能因為沒考慮到其他正在進行的功能與優化,彼此糾纏不清、BUG修不完、永遠上不了線,因此設計師每週分享、直接調用其他組的工程師或是 pair programming 都會有幫助。

最後一個問題就是資源分配出現異議時,需要有人來決定開發的優先級。這就涉及到了產品經理之間的階層與矩陣分工。

產品經理如何分工?

產品經理間主要是以上述模組分工,各小組由一個產品經理為主,幾位產品副理、助理協助做使用者研究、數據分析、產品營運等等。

除了模組分工外,也會負責營運相關的工作,例如輪流負責處理緊急的 Issues、Bug Tracking、Release Management… 等等,這些工作是不分模組或目標,而是為了讓產品更加穩定而必須做的工。

在一些更大的團隊中,會找專門的人來負責。以 Release Manager / Delivery Manager 來說,需要判斷待上線功能的 dependency 與優先級,且會直接影響到功能上線的時間,由PM來負責不一定是最好的選擇。

產品主管則要負責資源分配、優先級的評判、對其他部門的溝通,解決產品經理之間、以及產品經理與其他人間可能會遇到的問題。

產品主管的會議人生

畢竟每個團隊有不同的 KPI、OKR,他們提出的需求也會依照目標而不同,業務團隊認為要多增加可讓賣家設定的優惠活動、行銷方式才能吸引更多客戶上門;每天在第一線協助賣家的客服團隊表示,優化訂單管理與出貨流程才是當務之急;負責大型客戶管理的AM團隊則說,客戶表示最近顧客將商品加入購物車卻不完成結帳的比例很高,需要優先優化購物流程來留住大客戶。

每半年到一年,公司會舉辦全體員工的 all-hands meeting 說明公司整體的商業與策略目標,產品主管則會依據這些目標向下訂定每一季的產品目標,原則上每一季的開發重點與優先順序會在這些會議中確定好。

當資源分配有衝突時,就回去檢視目標優先級。

每週一次的主管會議中,產品主管則會更新大型功能的開發進度,若其他部門主管有意見也會在此時提出。在過程中若順序有變動、資源有增減、出現隕石開發需求,產品主管會更新 Product Roadmap 讓整個產品團隊清楚原因與最新的團隊目標。

最後,產品主管也要對產業與使用者極度敏銳,並頻繁與其他常與客戶、使用者直接接觸的部門(業務、客服、AM)蒐集回饋,在每個產品經理各司其職埋頭苦幹時,從更高的層級去思考新的市場切入點,例如:商業模式的轉換、嘗試新的產品線等等,為下一個季度、年度的目標做準備。

結語

在我離開團隊後,目前整個亞洲團隊應該已經成長到超過 200 人了,這些經驗現在寫起來雲淡風輕,但當時是用超多時間、金錢、崩潰的心與革命情感堆砌起來的,這段旅程走得很痛苦也很有收穫。

在小團隊中,「人」的問題比「事」的專業更難處理,PM 又是個需要頻繁溝通、處理人的問題的角色,希望這個系列能夠讓想要加入早期階段公司的勇者們一窺箇中奧秘。

謝謝你的閱讀!如果有任何疑問、想聽的主題,歡迎留下 Private Note 或留言給我 📒如果單純想給我一點鼓勵,請給我 1–10 個拍手;
如果覺得文章對你有點幫助,請給我 11-20 個拍手;
如果還有興趣繼續看「團隊」相關的分享請給我 21-30 個拍手;
如果有興趣看我開始寫「職涯」相關的分享請給我 30+ 個拍手讓我知道 👏🏻
想要持續追蹤我們的最新文章,請追蹤產品三眼怪實驗室 (◉◉◉)
每週六下午三點,會有人準時發文的~~~

--

--