從臉書產品經理的一則貼文，探討軟體開發的流程與分工問題
Facebook 臉書產品經理（PM） Ben Erez，前幾天在 LinkedIn（領英）發表了一篇動態，感嘆他之前擔任 PM 時，花太多時間在需求管理的瑣事上，比如在 JIRA 創建任務清單、規劃衝刺期內容等。
而在擔任臉書 PM 後，這些專案管理的文檔事務改由工程師自治負責，他則專注在策略、願景與夥伴關係，發揮自己的價值。
他建議同業思考：「團隊是否花太多時間在需求管理的瑣事上？」
業界的正反迴響
文檔與任務管理真的是產品經理（PM）可以拋棄的瑣事嗎？
這則貼文吸引七百多則回應，回應中有三個主要觀點：
- 贊同派認為，Ben Erez 點出敏捷開發的弊病，也就是過於專注在方法與標準流程，卻忽略敏捷的精神。
同時，這樣的做法將 PM 從日常文檔瑣事解放，更有機會發揮產品經理的價值。 - 中立派覺得，貼文描述一個極為理想的開發環境，也是許多 PM 希望能達到的境界。但也許只適用於特定條件下：(A) 資源豐富的企業，如臉書；(B) 矽谷等高階工程人才齊聚的地方； (C) 或是具有高度自治能力的團隊。
畢竟多數工程師，更傾向看到整理列好的任務清單，這樣他們能專注於程式開發與討論。 - 反對派則指出，當 PM 不再管理需求，也不再處理這些專案管理的事務時，究竟是對公司、團隊帶來更多益處，還是只對自己的時間管理有利？若 PM 抽離專案管理與工程參與，真的能確保專案開發的效率與成果嗎？
後續也有一位 Atlassian 的產品經理附和 Ben Erez ，不過他也坦承：即使在 Atlassian ，也不是每個 PM 都能擺脫文檔管理的工作。而確實，以他的職位，也不是負責做這件事的人，因此要下論斷並不適合。
不少人指出，之所以有人能擺脫文檔管理的工作，也許只是因為團隊中有別人去做了這件事。畢竟文檔與任務管理、進度追蹤等工作，終歸要有人去做。換言之，也不一定就是工程師該接手去做。
從正反立論可以看出，產品開發流程、團隊管理與職責分配，其實相當複雜，並沒有一體適用的最佳方法。多數人的自述清楚地呈現，不同公司體系、不同團隊規模，甚至不同產品，都有各自的開發流程問題。
不過，大概所有人都同意一個事實：「最終，團隊仍需要有人負責需求管理、建立任務清單，以及追蹤進度」，問題在於，「誰」來做比較好？
產品經理的文檔與管理困境
確實，產品經理的文書工作相當繁瑣。要在 JIRA 上創建任務，寫清楚每張任務的價值、目標、用戶故事（User Story）與實作細節等，並非三兩下就能完成的。
以我的團隊為例，工程師超過 6 位（4 位資深），每兩週完成一次衝刺（Sprint），能交付的任務總量很大，相對地事前要準備的工作也很多。
在這種情況下，除非你有 Delivery Manager 或其他 PM 協助，否則單靠一位 PM 很快就會燃燒殆盡。畢竟，PM 除了組織每個 sprint，也還有各種需求與討論會議要參加，也得抽時間規劃與定位產品、研究競品，甚至設計數據報表、參與用戶調研。
不過，產品經理會成為文檔的最佳撰寫者，有其原因。作為各團隊的橋樑，產品需求多半由產品經理收集而來，因此能說清楚任務價值、目標、開發原因的人，自然也非產品經理莫屬。
此外，藉由需求收集與討論、文檔撰寫、開發討論等，產品經理對公司的其他服務、自身的產品功能與價值，能更深入地理解（這點我體會甚深）。
只是，人力不足的情況已相當明顯。若要 PM 細緻寫完所有文檔再開始開發，PM 就很容易成為團隊的瓶頸（bottleneck），所有事情都卡在那邊。
那麼，我們到底該怎麼應對呢？
我的團隊怎麼改善工作流程、提升效率？
在調整開發流程之前，原本的做法是由 PM 寫需求文檔，並在 JIRA 開完所有 Ticket ，連同 Subtask 一起列好。如果文檔還沒準備好、功能尚未問清楚做法，就會延後到下個衝刺期再開工。
然而，隨著產品規模增長、功能變多、內部跨團隊協作機會增加，倚賴 PM 一人變得越來越不可行。
我們團隊意識到人力與流程問題，因此很積極調整協作與開發流程。經過三個季度，藉由一對一面談、衝刺後檢討會、季末回饋等討論，我們總結而摸索出的方法，就是依據職能優點，在各階段分工，藉此改善原先集中於 PM 所導致的開發困難。
現在， PM 依然會收集需求，寫清楚核心功能的需求與規格，但更多發展中的需求，會交由工程師去作早期調查。文件部分，也適當的調整期望，只要溝通有效即可，不追求每次都寫得超細緻。
簡單來說，我們不再要求需求提交得「一次到位」，而是藉由拆分並進，跑得更快。
調整後的新流程
- 需求收集
- 產品經理收集需求後，經過一段時間的研究與討論，說清楚為什麼開發
- 開發結果會帶來的價值與結果
- 預期看到怎樣的改變
- 專注回答 Why, Who, What and Where
- 工程發想
- 工程師與工程主管，針對 PM 所提（或自己發起）的需求，先提出大概的解法
- 告知前置作業、風險、兼容性考量
- 預估交付時程、是否需分階段交付
- 專注 How and When
- 需求排序
- 當需求討論日漸成熟，足以成為一項任務時，PM 會將之排進開發清單
- 依優先層級或前置開發所需，排出下次衝刺期的概要任務清單與目標
- 定案最終設計稿與產品需求文檔
- 向團隊與利益關係人說明最終的交付項目
- 實際分工
- 工程主管會再帶領工程師，針對概要清單，討論詳細作法
- 開立更詳細的分工任務，也可能衍伸更多工作
- 這個階段由工程主管或工程師自治，會比產品經理更適合；但產品經理還是會參與部分討論，確保工程師的實作討論，不會為了「快」或「好做」，而偏離實際需求，或是為了達成目的而過度設計
- 成果交付
- 工程師會在衝刺期開始時，承諾本期預定交付的項目
- 產品經理則作為 End User 的代表，在開發過程中提供開發決策建議，或適時調整交付預期
- 技術文檔則會在開發過程中完成
分工優點
藉由拆解文檔階段與轉移階段負責人，讓各職能可以在不同階段依據所長發揮。產品經理更專注在回答「為什麼要做這件事」，而工程師則涉入更多的開發設計與分工協調。
在實行一段時間後，我們發現，過往由產品經理主導開發工作時，很容易漏掉一支 API，或忽略營運端的 UI 流程設計，導致功能上線後仍需要工程師幫忙改東改西，或在衝刺期中追加許多工作。
但在交給工程師主導開發細節後，由於前後端充分討論，因此漏工程的情況大幅減少。此外，將文檔拆成初稿與終稿兩個階段，除了讓 PM 能爭取更多編寫與思考的時間，也讓工程師有更多思考與設計的空間（對，工程是需要設計的！）
最好的開發流程，應該依團隊而變化
回到 Ben Erez 這則貼文，從他後續的回應，可以知道 Ben Erez 其實仍花很多時間，運用 Gsheet 與臉書內部工具撰寫功能概要、追蹤開發狀態。
此外，他的 EM （Engineer Manager） 與 PPM （Principal PM）則承擔了跨專案追蹤進度的工作。
換言之，他雖然從 JIRA 解放，但並未擺脫文檔工作，而他所描述的美好成果（讓 PM 更專注於策略與願景），則是因為適度分工才能達到的成果。
假設你的團隊沒有 EM ，那有經驗的產品經理可能要更頻繁涉入開發討論。而若你的工程師都是業界頂尖人才，也許文檔不用細到破表，幾個手繪示意圖就能完成溝通。
而你省下的文檔製作時間，可以拿來做更具影響力的事情。比如調節開發節奏，或是中長期的產品定位與願景規劃，以及更多的產品與用戶調研。
總而言之，不同團隊有不同的行事方法與溝通流程，但最重要的是，與團隊一起優化屬於你們的服務設計，才能更有效率地產出。
而我更建議，產品經理主動帶著團隊所有成員，一起討論、改善開發流程。
也許有些成員需要多點時間思考，因此傾向早點知道需求概況；有些成員喜歡詳盡的文檔，然後邊做邊找問題；有些人則還在職涯早期，可能沒有特別偏好，但需要多一點產品或商業知識的建構。
究竟什麼方法／工具適合你們，很值得團隊花時間探討。而探索的過程，也是團隊建構的一個重要環節，能為團隊帶來很多正面影響。
最終，良好的工作流程與文檔成果，更取決於團隊各職能的成熟度與共識。產品經理若想要有更多時間，專注於產品願景、定位、計畫，最重要的不是把日常工作通通拋開，而是先搞定最適合團隊的開發流程。
本文由 Selena Chen (陳亭勻) 授權轉載，原文連結
瀏覽 4,486 次
