學習成長

2020.04.21 | 2919次觀看

【PM 總動員】東西方的產品團隊有什麼差異?讓待過騰訊和 Spotify 的產品經理告訴你!

文/ 你好,我姓艾名許利。  由產品三眼怪 3PM LAB授權轉載

 
這篇文章將分別探討亞洲和歐美公司在技術、設計、產品這三種職位上工作內容和方式的差異,在產品開發的流程中,每個職位之間如何合作、分別要承擔哪些責任(Responsibility)以及最後應該要對產品的哪個部分的成敗負責(Accountability)。
這幾年越來越多人往海外發展,也有非常多文章在說明西方的網路公司內部各個職位如何運作,但台灣土生土長的我,其實很難想像實務上跟我原先的工作方式差異為何。進到Spotify之後,也因為工作方式的差異,所以花了很多時間適應新的合作方式和關係,同時也發現過去好像蠻常有每個職位之間職責和期待不一致的問題,因此一直很想跟大家分享這些差異。
想要跟大家強調的一件事情是,所有的合作關係和職責都會因為公司、部門、團隊、不同的領導人和成員等而稍有出入,每個團隊都會發展出適合他們的一套合作方式。我們部門就曾經花了兩個小時討論每個職位的責任是什麼、大家對這個職位的期待和認知是什麼。這篇文章是根據我前後在騰訊、Spotify兩間公司的經驗分享,不一定跟所有在中國或歐美工作者的經驗一致,因此這個分享會是個大方向的通則,而不是一個標準答案

開發流程差異分享

亞洲 — 以騰訊工作經驗為主

產品部門會先根據要解決哪些問題和需求產出產品需求文件、並排定項目優先級,而產品需求文件上基本上已經規劃好UX流程(甚至會有模型圖)。


接下來,產品會和交互討論需求,交互會將產品需求文件上的需求製作成有交互細節的線框圖,有可能更動原先產品提出的UX流程,但通常變動不大。


交互完成UX流程的草圖後,產品經理就可以和工程部門進行技術需求評審,同時也可以開始請視覺開始進行設計。工程部門會根據交互設計師提供的交互稿評估系統複雜度,如果發現有哪個地方需要修正、需要簡化,那麼就必須再請交互設計師重新修正交互稿。


交互定稿後,工程部門就可以開始開發,而同時UI設計師也會開始設計視覺,視覺定稿後,會再提供給工程部門。


工程部門開發完成會給產品經理、交互、UI設計師確認是否和交互、視覺稿一致,交由QA部門測試,完成後上線。


上線後,產品經理會追蹤數據,並再根據目標和數據訂定下次優化內容

歐美— 以Spotify工作經驗為主

產品經理會先主導目標和商業價值的部分,訂出團隊目標、要解決什麼問題、從哪個先解決等,之後把這個目標跟整個團隊討論,確認大家是否一致認同,這個步驟完成後,產品經理的階段性任務完成。


接下來,交由設計師主導產出體驗方案的流程,針對大家同意的目標和要解決的問題提出解決方案,提出解決方案的過程可能是整個團隊一起brainstorm等,但最終會由設計師來負責把整個體驗視覺化、詳細的製作成提案。提案會經跟團隊一起共同討論,技術提供所需資源、時間等資訊,最終綜合所有考量,產品經理會根據大家的意見決定執行哪個體驗方案。這個步驟完成後,設計師的階段性任務就完成。


接下來,交由工程部門主導開發到交付產品的流程,他們評估時程、決定什麼時候要完成什麼工作,並且由工程部門的主管去管理確認進度,目標是在訂定的時間交付高質量的產品。上線後,工程部門的階段性任務就完成。


上線後,數據分析師和產品經理會共同追蹤數據,確認產品是否達成商業目標。後續會再根據下一階段的目標和數據訂定下次優化內容。


技術 Tech

職責差異

字節跳動後端工程師職責,取自拉勾網
-
-
Spotify後端工程師職責,取自Spotify Career

職責(Responsibility)

從求職網頁上的工作內容看起來,兩者差異不大,主要都是開發安全、高可用性、高擴展性(Scalable)的技術解決方案。但歐美公司會特別強調和產品經理、設計師之間的協作,一起討論如何解決問題、達成目標。

課責(Accountability)

技術部門須對技術產出負責,時間上在共同商議的時間完成、上線,且確定系統質量。這點在歐美和亞洲的認知上一致。

實質工作方式差異

歐美文化中非常強調協作關係及共同產出,因此技術會參與產品開發整個流程的討論,包含決定要針對哪種用戶、解決什麼問題時,到後期決定要使用哪個解決方案,產品、設計、技術都會共同商議並決策。而技術可以針對任何事情提出意見,包含優先級排序、產品應該如何設計,並不侷限於技術考量。技術也不只是參與目標、問題、解決方案的訂定,所有的Design Sprint、Design Workshop、用戶訪談等,技術也都會一同參與,因此他們會有更完整、全面的訊息、對用戶的認識和除了Coding以外的參與。在公司內也曾有技術自己開發出了很酷的東西,然後產品經理和設計協助溝通、商業化及上線的案例(例:Discover Weekly剛開始就是工程師自己開發出來的功能,在公司內廣受好評,因此產品經理和設計師協助把這個技術包裝、上線)。

在台灣和中國的工作經驗是,技術通常都是到產品需求評審的時候才開始參與討論,主要的意見也著重在這個設計在技術上怎麼實現、需要花費多久,而往往對產品優先級、解決方案的選擇比較沒有話語權,比較偏向評估後執行的角色。

所以歸納出來,最大差異如下:

  • 參與產品設計時間點:歐美文化中工程師會在方案尚未成形時就參與討論;亞洲文化中通常是在產品、設計方案已經確定才參與。
  • 參與產品設計的程度:歐美文化中工程師會是產品設計的一員,提供意見給設計師和產品經理,並參與Design Sprint等設計討論流程,甚至可以自己設計出產品後,主導項目進行。亞洲文化中,工程師通常僅限於技術架構的設計。


產品經理 Product

職責差異

快手、攜程產品經理職責,取自拉勾網
Spotify產品經理職責,取自Spotify Career
Facebook產品經理職責,取自Facebook Career

職責(Responsibility)

從求職網頁上的工作內容可以發現兩個文化下的差異非常大。
在亞洲對於產品經理的工作內容包含追蹤產品設計、開發、測試上線全流程,透過競品、數據分析等方式優化產品及負責跨部門溝通。有些公司還會要求產品經理需要負責產品框架設計、原型輸出。

在歐美公司,工作內容則是理解公司策略和方向,並將那些方向轉化爲團隊可執行的項目和目標,同時透過產品分析、量化和質化的數據來訂定部門的策略、目標、Roadmap、項目優先級,並定義成功的指標(Success Metric)。當然,這也因公司而異,在新創公司的話,產品經理可能也會需要協助原型輸出。

課責(Accountability)

亞洲文化往往強調產品經理就是產品的負責人,因此須對產品功能最終效果負責。但功能最終效果的定義卻很廣泛,可能包含設計、系統穩定度、是否改善數據⋯⋯等。

歐美文化中,產品經理的任務著重在策略和商業角度,即是否定義了正確的目標、這個功能有沒有達到我們預先估計的商業目標和價值。

實質工作方式差異

歐美文化中,產品經理需要負責的是Vision和Goal,透過理解公司策略、解讀量化和質化數據、蒐集大家的意見後,決定What to work on & Why we work on this,但How to solve this往往是和設計、技術一起共同負責,設計產出UI UX體驗解決方案、技術負責怎麼打造這個體驗及確保體驗的質量。

亞洲文化中的產品經理很辛苦,不只要產品規劃和設計,整個流程的項目管理也是由產品經理負責。以前我在騰訊工作時,花很多時間產出整體UX Flow的線圖草稿,定義需求文件上每個按鍵按完會發生什麼事,還要追殺開發開始QA了沒、什麼時候可以上線,到了Spotify之後發現原來這裡的產品經理完全不需要做這件事,請想像我有多麽的吃驚。也由於大家對於產品經理到底對什麼東西負責很模糊,因此幾乎什麼事情都找產品經理(因為任何事情都跟產品有關,所以產品經理應該要負責)。有bug找產品經理、不喜歡視覺找產品經理、反應時間很慢(Latency problem)也找產品經理,最後產品經理就會各處忙於奔波。

兩種工作方式有好有壞,在亞洲文化中,產品經理因為需要做很多事情,因此可以受到多方面的訓練,但同時也會弱化設計師和技術的角色和權力,以及產品經理無法專注在真正能夠發揮價值的地方。而歐美文化中,產品經理需要負責的是產品方向和策略,並確保產品策略能夠確實達成商業目標(例:增加用戶數X %、轉化率提高Y %),會需要整合很多團隊內、外部的資訊和意見,同時也需要不斷的和大家Pitch這套策略和方向。偶爾會覺得好像一切很空洞和空泛、沒有實質產出,但如果一個團隊中,有人可以專注於前景和方向、有人可以專注於解決方案的打造,這樣的方式可以讓團隊中的每個人發揮專長,一致的往正確的目標前進。

所以歸納出來,最大差異如下:

  • 工作內容的廣泛度:歐美文化中,產品經理定義產品方向、問題和策略,帶領團隊往同樣的目標前進;亞洲文化中,產品經理需做產品整體規劃、設計,並追蹤產品從發想到上線到持續優化的整個流程。
  • 課責項目:歐美文化中,產品經理對最終商業目標和價值負責,若產品沒有達到預估的成功指標(Success Metric),那麼就是產品經理的責任。亞洲文化中,產品經理對產品功能最終效果負責,可能包含設計、體驗、目標是否達成。


設計 Designer

職責差異

大型網路公司(例:騰訊、阿里)通常把視覺和交互分開,分別為交互設計師和UI、視覺設計師,但在歐美網路公司是合併在一起的Product Designer。

左為字節跳動交互設計師職責、右為微博UI設計師職責,取自拉勾網
Facebook Product Designer職責,取自Facebook Career

職責(Responsibility)

從求職網頁上的工作內容可以發現由於拆分成兩項工作,因此差異頗大。
在亞洲,設計師們要和產品經理和開發合作,交互設計師負責產出交互原型和框架,UI設計師負責設計UI界面

在歐美公司,工作內容則是將概念性的想法轉化為對用戶有價值的解決方案,和團隊合作並設計出整個體驗(包含視覺及交互)

課責(Accountability)

亞洲文化中,設計師和產品經理的課責項目常常不是很清晰,往往常將視覺和體驗的責任交給產品經理,或是產品經理覺得自己對體驗有決定權,因此相當程度的削弱了設計師的權力及忽視他們的專業。

歐美文化中,設計師需要為整體體驗負責,包含易用性(Usability)、有用性(Usefulness)、是否使用戶愉悅(Delight)⋯⋯等。

實質工作方式差異

歐美文化中,我覺得設計師負責的工作很像Solution Designer,他們參與團隊的方向和策略的討論,並根據共同定義的方向和問題設計完整的解決方案,而為了設計出完善的解決方案,他們會需要跟技術、數據部門、用戶研究部門、當地市場的工作人員討論,而且負責設計發想到產出解決方案的整個流程。

亞洲文化中,設計師的職責最大的影響因子通常是你跟怎樣的產品經理一起工作。如果產品經理很不尊重專業,或是認為產品經理有權力決定體驗的話,那很容易設計師就會淪為美工、畫圖的角色。但如果產品經理能夠充分的信任設計團隊,設計師就可以有比較大的空間。不過在我過去的工作經驗中,亞洲文化的設計師較少參與關於項目優先級、應該解決什麼問題等這種產品開發初期的討論,通常產品經理都已經決定好項目內容、大致的UX流程後,才跟設計進行討論。

所以歸納出來,最大差異如下:

  • 產品開發的參與時間點:歐美文化中,設計師會參與產品經理定義產品方向、問題和項目優先級的流程,並尋找、設計問題的最完善解決方案。亞洲文化中,設計師通常是產品經理已經大致完成產品功能規劃和大致的UX Flow後才開始參與討論。
  • 設計著重點:歐美文化中,設計師會是解決方案及體驗的負責人,要領導團隊一起思考最佳解決方案、同時和技術、外部人員進行溝通,並著重設計是否解決問題。亞洲文化中,設計師比較不需要去領導整個項目,比較著重在設計是否達成產品需求


優劣

根據我個人的經驗,其實兩種工作方式各有好壞,也適合不同人。

在歐美,強調團隊共識和每個人的想法和專業,因此會充分賦予每個職位在其專業的主導權,同時除了要負責自己專業的的部分之外,也要花費時間參與其他的部分,包含解決方案的brainstorm、參與用戶訪談、參與大大小小的團隊決策的會議。


好處是:

  • 團隊內部盡量達到資訊透明化:團隊的每個成員可以了解為什麼我們在做這件事情、做了這件事情可以帶來什麼影響、用戶有什麼反饋等。
  • 累積非自己專業領域上的能力:工程師可以多了解目標設定、用戶體驗、用戶需求、設計體驗等,設計師可以多了解定義問題、工程部分的困難。產品經理好像反而相反,可以把比較多的責任交給專業領域的成員負責,專注於目標、問題和商業價值。
  • 在專業領域有主導權:雖然還是透過團隊討論達成共識,但在自己的專業領域可以領導整個過程。產品經理主導目標、問題設定,設計師主導產出解決問題的方案的過程,工程部門主導把能夠解決問題的方案開發上限的過程。相反的,在亞洲很容易幾乎都是產品經理決定所有事情,很限制其他職位的發展和話語權。

壞處是:

  • 會議很多:由於要參與整個過程,並分別主導不同部分,因此要花費很多時間在達成共識和討論。
  • 工程部門會降低專業領域上的時間:由於花費較多的時間在非專業領域的部分,因此當然會比較少時間處理專業領域的事情。但這並不代表能力比較差,或是學習和成長比較緩慢,我只是想要說明,假設你是工程師,你會需要花費很多時間處理coding以外的事情。
  • 設計師需具備UX/UI能力:這點不知道算是好處還是壞處。在歐美,沒有將交互和UI分成兩個職缺,因此每個設計師都要具備兩項能力。在亞洲交互和UI設計師是兩個職缺,因此可以專注地處理各自的部分,雖然增加了溝通成本,但會將體驗拆分成兩部分更完整的思考。但這對整體用戶體驗到底比較好還是壞,我目前也沒有答案,也會受到每個團隊的合作默契和方式影響。


歐美公司職責總覽

最後製作了一張圖表總結歐美公司的各職位分工,亞洲的情況大家可能比較熟悉及有經驗,因此就沒有特別再另外製作圖表。

歐美公司職責總覽(自製,請勿轉載。)

結語

上述分享了我在歐美和亞洲的工作經驗得出的一些結論,但基於不同規模的公司、不一樣的團隊、不一樣的公司文化,或許大家也會有不同的經驗與認識。



|關於3PM LAB|
產品三眼怪實驗室 (◉◉◉) – 來自網路圈的三位 PM ,分享網路產品經理實務、產品開發案例、趨勢、新知。歡迎訂閱