PM‧001｜從臉書產品經理的一則貼文，探討軟體開發的流程與分工問題
Facebook 臉書產品經理（PM） Ben Erez，2021 年在 LinkedIn（領英）發表了一篇動態，感嘆他之前擔任 PM 時，花太多時間在需求管理的瑣事上，比如在 JIRA 創建任務清單、規劃衝刺期內容等。
而在擔任臉書 PM 後，這些專案管理的文檔事務改由工程師自治負責，他則專注在策略、願景與夥伴關係，發揮自己的價值。
他建議同業思考：「團隊是否花太多時間在需求管理的瑣事上？」
本文於 2022 年 8 月 1 日授權轉載網站「科技島」：《從臉書產品經理的一則貼文，探討軟體開發的流程與分工問題》
業界的正反迴響
文檔與任務管理真的是產品經理（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 ，那有經驗的產品經理可能要更頻繁涉入開發討論。而若你的工程師都是業界頂尖人才，也許文檔不用細到破表，幾個手繪示意圖就能完成溝通。
而你省下的文檔製作時間，可以拿來做更具影響力的事情。比如調節開發節奏，或是中長期的產品定位與願景規劃，以及更多的產品與用戶調研。
總而言之，不同團隊有不同的行事方法與溝通流程，但最重要的是，與團隊一起優化屬於你們的服務設計，才能更有效率地產出。
而我更建議，產品經理主動帶著團隊所有成員，一起討論、改善開發流程。
也許有些成員需要多點時間思考，因此傾向早點知道需求概況；有些成員喜歡詳盡的文檔，然後邊做邊找問題；有些人則還在職涯早期，可能沒有特別偏好，但需要多一點產品或商業知識的建構。
究竟什麼方法／工具適合你們，很值得團隊花時間探討。而探索的過程，也是團隊建構的一個重要環節，能為團隊帶來很多正面影響。
最終，良好的工作流程與文檔成果，更取決於團隊各職能的成熟度與共識。產品經理若想要有更多時間，專注於產品願景、定位、計畫，最重要的不是把日常工作通通拋開，而是先搞定最適合團隊的開發流程。
（本文完成於 Ben Erez 該篇貼文發布的 3 天後，感謝臉書 PM 社團與部落格讀者的交流指教。）
Selena 您好，
謝謝您分享這一篇很棒的文章，在 “調整後的新流程” 這個段落關於需求收集，原文如下，想進一步請教
在接案形式的軟體專案公司，個人觀察到一些困難，例如工程師問 “爲什麼要做這個功能”、“爲什麼客戶要用 A 這個方式而不是 B”、“我覺得客戶說的 A 這個方式很爛，不想做”…這樣的情況
個人一開始覺得是收集需求端的時候不夠完備、與客戶互動時考慮還不周延，但是長久下來，發現並不見得完全是需求收集端的問題。
首先是客戶提需求的單位，他們本身不一定能完整的說明爲什麼，這個需求可能是來自他的大老闆（付錢的業主的最高決策人，但我們無法接觸這個人）
其次，提需求的業務單位的說法，接需求的人可以理解認同，但工程師可能認爲他自己提的才是最好，或是必須提到他認爲好的需求，他才做
想請問以上的情況，您會建議怎麼處理呢？
需求不清楚這件事，終歸要回到「需求」本身。其實不管是不是接案公司， PM 都很常被問「為什麼要做」，而我們的工作確實就是該解決這個疑慮，才能推動人去產出。
情況一、 上級逼我做
如果是成熟的工程師，其實我會直接告訴他，這個是公司或上級決策，而我找不到數據或其他證據說「做了會不好」。既然沒有 downside，那就試試看，畢竟有些 business insight 可能是產品端看不出來的。如果秉持著敏捷的精神，在迭代很快的情況下，試一試無妨。
當然，我也會在該階段就跟工程師或設計師討論清楚，如果做了成果真的不好，之後可能有哪些調整方向（藉此來決定東西要做多死或多彈性，也讓他們知道這可能是個中長期的工）
情況二、 發案端的需求不明確
這個就很仰賴窗口的溝通囉。其實我的商務/行銷也會發一些假設需求，我自己當商務時也會提給 PM 需求。
理想來說，PM 接到需求後，到合約簽定或真正決策前，不會照單全收。因為 PM 一定要搞清楚「這個需求背後想達成什麼目標」以及「衡量的指標」。
如果對方沒有指定作法，那作法就跟工程師討論（只要抓緊目標就好）。但若對方指定作法，就看工程上有沒有什麼困難，再討論執行方法。或者，用一些不花工程時間的方式作 a/b testing，效果貼近需求，再進工程。
但話說回來，這樣來回溝通的時間成本很高！因此遇到不明確的發案端，經驗感覺「要討論很久」時，更要講清楚時程跟預算。
我以前跟某A 百貨公司討論 APP 開發案時，對方先是說三個月內要做一款 EDM 型的 APP，當時估完覺得加上一些小功能，合約簽訂後三個月內可以用四人團隊搞定。
結果後來對方又說，想改成 3 個月內做一款跟 B 百貨一樣的 APP，要有會員系統、線上結帳、還有可以管控的後台，最好還要有線上金流。
這下時程跟人力規模就完全不一樣了。
假設你或工程師主管經驗豐富，應該能就這個案子拆解一個可行的方案，比如三個月內可以做到什麼程度，然後驗收要分期，明確說明哪些東西可能要第二期交付（比如 3-6個月時出第二版帶金流功能）。
公司想賺錢，會想要什麼都接，但如果前期不先談定比較合理的產出，那下到執行層一定會有很多怨言。
而假如你覺得自己不是最理想的人月／資源評估者，一定要多問問其他有經驗的人。如果可以，多問一點，比如「這個功能要做三個月，是涵蓋到什麼程度？這個東西可以拆做，分不同時間 delivery 嗎？還是一定要三個月才能做完？做完是包含哪些功能？」這樣如果發案端不滿意評估的時程，你還有拆期程去分期交付的機會。
記住，你是 PM 的話，最重要的事情是釐清原因跟需求優先級，講清楚交付的可行性。然後，你要為這個結果負責。
情況三、 團隊成員不理解/不支持你
最後，工程師越資深、越成熟，通常越能理解上層或PM的難處（有些東西確實就是沒道理），這些有賴 PM/工程師日常多多互相理解。
但話說回來，不是決策者的人，不應該有「這需求不夠好所以我不做」的心態。若該員不是專案負最終責任的人，那他的義務是「提出潛在風險」並跟PM合力擬出「可行的解法」，而不是就「不幹了」。
如果真的遇到這種人（不管是工程師還是其他職能），直接找上級主管協調可能比較快，或是約對方1:1面談，釐清真正的問題是什麼。
竹下隆一郎在書籍《不善社交的內向人，怎麼打造好人脈？》曾經說過，人的煩惱分為「白宮煩惱」跟「咖啡廳煩惱」。前者是人生永恆的重大課題（比如戰爭怎麼消失、經濟怎麼成長），後者則是跟家人朋友會聊的生活煩惱。
如果成員不斷質疑「這個功能做下去超沒用，會傷害公司商譽」，但客戶或主管就是堅持要，有時候不妨就直接跟成員說：「等你成為出錢的人，再來煩惱做下去會不會妨礙商譽吧」。
以上淺見，希望有回應到你的問題。
Good point. Here shares another article from Facebook PM https://productlife.to/p/-execution-at-facebook
Thank you for sharing the good post! I like what he said in key points below, and it’s related to my recent experience!
– PMs are responsible for the outcomes of the team; the inputs are subjective. Your goal should be to find the best combination of inputs to maximize the outcomes of your team.
– The more senior a PM you become, the more impact you can have with strategy. Freeing your own capacity while not allowing outcomes to suffer requires meta-execution.
– But regardless of your delegation abilities, you will stay accountable for execution.
Hello Selena 您好：
抱歉，冒昧打擾~我是「科技島」社群編輯，科技島這個社群的目的之一，是希望能透過科技業精英前輩現身說法，針對職務心得、工作技巧、從業所得提供經驗分享，讓現正從事科技業或未來想進入科技業的學弟妹們可以更加瞭解這個行業。
剛剛在瀏覽您網站時，看到您撰寫的《從臉書產品經理的一則貼文，探討軟體開發的流程與分工問題》這篇文章，很適合科技島讀者。
不知您是否願意授權我們以『原文原PO，並註明原文作者及出處連結』的方式讓我們轉載於科技島網站，跟科技人一起分享呢？謝謝。
靜待回覆！並附上科技島網站連結，給您參考 :
https://www.technice.com.tw/
聯絡Email:
techniceeditor@gmail.com
您好，沒問題！（也有收到您臉書的回訊，我一併回復在這邊）
文章發布後請告知網址，我會於原文標註轉載並互相連結。謝謝您。