產品團隊的組織架構——The MentorShip 曼陀號 PM 組月會 01
閱讀時間約 6 分鐘
The MentorShip 曼陀號是由 Girls In Tech 主辦的職涯探索計劃，透過四次月會，在船長的帶領下讓同領域學員們彼此交流。
2022 年有幸錄取計畫，與街口支付產品長 Clare 及各位 PM 伙伴們一起在每月週日早上交流成長 💪
透過文字紀錄月會經驗，希望分享給更多伙伴 🙌
組織成長過程的團隊配置演進史
Clare 從 91APP 產品長李昆謀的文章《91APP的軟體開發之道 — 從20人到200人的組織發展旅程》帶我們一同檢視組織從創立初期、小而緊密的狀態，到逐漸壯大，人員、專案越來越多時會產生什麼問題談起。這裡快速帶各位複習各階段內容，同時加入討論過程中，針對原文的補充：
第０階段：創業初期——無明確組織
此階段成員們彼此關係緊密，目標一致，溝通無礙。
此階段成員們彼此關係緊密，目標一致，溝通無礙。
第１階段：瀑布來了——組織成形
隨著成員增加，彼此負責的職能開始有明確劃分，能夠完成瀑布式的接力開發模式。
隨著成員增加，彼此負責的職能開始有明確劃分，能夠完成瀑布式的接力開發模式。
第２階段：上帝之手 ——依專案行程臨時團隊
隨著產品中專案多線開發，具有資源協商能力的「上帝之手」會彈性安排各個成員在不同專案中，讓開發多線進行。然而非專責的團隊較難培養長期維護責任感，也容易產生系統混亂。
隨著產品中專案多線開發，具有資源協商能力的「上帝之手」會彈性安排各個成員在不同專案中，讓開發多線進行。然而非專責的團隊較難培養長期維護責任感，也容易產生系統混亂。
第３階段：成員固定——專業領域團隊成形
不同功能開始有各個團隊專責維運，各個小團隊間向心力強，且可長期發展專業領域知識與穩定服務。然而不同功能需要開發的時程、內容不一，若無妥善調度人力，可能會有部分人員閒置、部分人員過載。另外，當出現需要跨功能模組合作的專案，需要新的機制分配人力、彼此協作。
不同功能開始有各個團隊專責維運，各個小團隊間向心力強，且可長期發展專業領域知識與穩定服務。然而不同功能需要開發的時程、內容不一，若無妥善調度人力，可能會有部分人員閒置、部分人員過載。另外，當出現需要跨功能模組合作的專案，需要新的機制分配人力、彼此協作。
第４階段：導入敏捷
敏捷開發 (Agile) 是一種哲學方向，理念可參考敏捷宣言：
敏捷開發 (Agile) 是一種哲學方向，理念可參考敏捷宣言：
「個人與互動」比「流程和工具」更重要
「實際運作軟體」比「包山包海的文件說明」更重要
「客戶合作」比「簽約協商」更重要
「回應變化」比「遵循計畫」更重要
Scrum 是多數人用來實現敏捷開發的方式，包含三種角色、五項活動、三大要件、五大價值。
導入敏捷之後，成員們注重開發效率。然而這些 Agile、Scrum 的開發守則有時反而會讓團隊成員陷入字義、角色權責之間解釋的爭論，誠如原文提到的「我們太過於計較跑步的姿勢，而忘記了跑步的速度」。
第５階段：團隊自主管理
在這個階段，各個專業小組各有自己的 Sprint planning，為各自的開發內容負責。小團體的緊密互動，仿若回到了第０階段的創業緊密階段。然而跨團隊之間的溝通方式相較較弱，彼此之間可能是競爭關係。
在這個階段，各個專業小組各有自己的 Sprint planning，為各自的開發內容負責。小團體的緊密互動，仿若回到了第０階段的創業緊密階段。然而跨團隊之間的溝通方式相較較弱，彼此之間可能是競爭關係。
第６階段：跨團隊主管會議 (One Team)——整合團隊方向
當團隊內與團隊間的節奏、目標漸行漸遠，彼此間競爭性越來越強、難以韓做，就需要各團隊裡的主管階層 (上帝之手) 們組成「團隊的團隊」(One Team) 讓大家對齊方向
當團隊內與團隊間的節奏、目標漸行漸遠，彼此間競爭性越來越強、難以韓做，就需要各團隊裡的主管階層 (上帝之手) 們組成「團隊的團隊」(One Team) 讓大家對齊方向
第７階段：矩陣式組織及後續調整
當團隊組織走到矩陣式，會有兩個目標：一方便有自己所在的專業團隊，負責功能開發；另一方面在自己所屬的職能，又要對主管負責 (例如一位工程師要負責Ａ功能 report 給對應 PM，又要 report 給工程團隊主管)。
此時組織可能會走向重整，以專業領域作為一個部門單位，將成員的日常工作編制與 KPI 掛勾，對齊方向。此做法適合產品與開發團隊都相當資深，可以為各自所屬專業功能負責的階段。
當團隊組織走到矩陣式，會有兩個目標：一方便有自己所在的專業團隊，負責功能開發；另一方面在自己所屬的職能，又要對主管負責 (例如一位工程師要負責Ａ功能 report 給對應 PM，又要 report 給工程團隊主管)。
此時組織可能會走向重整，以專業領域作為一個部門單位，將成員的日常工作編制與 KPI 掛勾，對齊方向。此做法適合產品與開發團隊都相當資深，可以為各自所屬專業功能負責的階段。
延伸閱讀：The JKOPAY Way
船長 Clare 以街口進行案例分享，目前街口針對各個功能已形成專業模組。電子支付的產品有複雜的後端串接系統，相較之下前端有共用的資源，形成了獨特的做法：前端共用資源、後端各自形成專業模組。
當大型專案、跨模組的需求出現，會由 PO (Product Owner; 產品負責人) 統籌規劃，與各個專業模組的 PM (Product Manager; 產品經理) 進行橫向溝通。
船長 Clare 以街口進行案例分享，目前街口針對各個功能已形成專業模組。電子支付的產品有複雜的後端串接系統，相較之下前端有共用的資源，形成了獨特的做法：前端共用資源、後端各自形成專業模組。
當大型專案、跨模組的需求出現，會由 PO (Product Owner; 產品負責人) 統籌規劃，與各個專業模組的 PM (Product Manager; 產品經理) 進行橫向溝通。
開發流程前中後
第二階段，Clare 為學員們介紹街口的開發流程，並且在討論後讓彼此分享各自公司的開發方式。以下介紹以街口開發流程為例：
開發前準備
- 1–1 Pre-Kickoff (PM)
凝聚成員共識、闡述專案緣由與目標 - 1–2 功能需求說明 (PM)
以具備一定完整程度的 PRD 與開發團隊取得初步共識，確認實作細節，作為下一步完成 PRD 的基礎 - 1–3 PRD Review (PM)
需求定稿 - 1–4 Design Review (TPM / RD Lead)
確保內容經開發與相關業務團隊審核通過，內容拆分成細部的 task 進入開發
開發期 (Sprint)
- 2–1 Test Case Review (RD / QA)
- 2–2 程式開發與 QA Automation (RD / QA)
- Note: PM 在此階段會
a. 協助工程團隊解決開發、測試中的問題
b. 與數據團隊確認發布後指標追蹤
c. 跨部門制定市場策略
d. 準備下個 Sprint 的專案
測試期 (Sprint)
- 3–1 功能 Demo 與冒煙測試 (RD)
確保開發交付內容符合 PRD
💡冒煙測試：優先串接測試主要功能（相比於全面測試） - 3–2 SIT 測試 (QA)
黑箱測試為主、白箱測試為輔
💡黑箱測試 (Black-box testing)：模擬駭客入侵，就程式碼本身找出安全性弱點
💡白箱測試 (White-box testing)：以程式本身結構設計進行測試，例如依使 - 3–3 PM 驗測
驗收 P0、P1 bug - 3–4 Stage 測試 (QA)
確保新功能部署不影響原服務，視情況進行壓測 - 3–5 PM 上線判定
發布期
- 4–1 上版會議 (PM)
確保上版過程對既有服務影響最小化，制定灰度發布或全像發布
💡灰度發布 (Gray release)：先針對一小群用戶上線功能，早期獲得用戶反饋、確保上線無問題，再拓展至全用戶發布 - 4–2 正式環境部署 (RD)
- 4–3 上線觀測、回歸測試 (RD)
上線後
- 5–1 回顧會議 (Retrospective) (PM)
回顧專案中的好與壞，作為後續的養分與改善空間 - 5–2 指標持續追蹤
確保專案是否達成預期目標、功能服務一切正常
PM 組的月會內容非常扎實，很感謝 Clare 不藏私分享了許多街口開發的細節。在學員們交流期間，也聽到了來自不同類型產業、公司的開發方式，從彼此的做法中交流。
留言0
查看全部
你可能也想看
Google News 追蹤
如何有效運用Scrum的船舶理論來主持專案檢討會。船舶理論將專案比作船，通過風帆、礁石、錨等元素可視化檢討內容。會議前的準備、進行步驟及專案經理的主持技巧，幫助團隊在輕鬆愉快的氛圍中總結經驗、識別問題、制定改進計劃，從而提升未來專案的成功率。
在快速發展的時代中，團隊合作是成功不可或缺的要素。這篇文章介紹了一支嶄新的團隊，成員介紹了他們在團隊中的角色和貢獻。並探討了團隊合作的重要性以及有效的溝通和知識共享在團隊發展中的關鍵作用。
在數位時代，Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件，並結合我開發CDP的實際經驗，分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum，優化專案流程。
本次專訪，怪獸科技公司和 Spotify 資深產品經理 Agnes 將與我們探討五大 PM 產品實戰問題，帶你瞭解如何有效提升產品團隊效能、解決商業問題，以及最大化 Side Project 的成果，在競爭激烈的市場中脫穎而出（沒經驗、跨領域轉職的菜鳥也可以）！
本文淺談專案管理(PM)在公司中的重要性，以及圍繞在 PM 周圍的各單位分工。介紹了專案範圍管理、專案成本管理、專案溝通管理、專案風險管理、專案整合管理等專案管理的相關內容，並著重介紹了 TPM、EPM、OPM、Sales Product Manager 等常見的專案管理角色。
在瞬息萬變的商業環境中，如何引領團隊從被動執行轉為主動思考？這篇文章分享了一個部門營業目標的轉型實例，包括轉型契機與挑戰、設定績效目標的關鍵步驟、轉型後的成果與反思，並給予其他主管的建議。透過明確的目標、可量化的指標、有效的溝通與回饋，成功實現了從被動到主動、從執行到創新的轉變。
擁有豐富的團隊溝通與協作經驗的矽谷阿雅，分享了如何識別和解決合作中的常見障礙，以及建立有效溝通流程的具體方法。在本次專訪中，矽谷阿雅探討了跨部門合作時的挑戰，如何提高溝通效率，以及如何優化團隊溝通與協作。
這篇文章分享創業團隊在管理壓力和溝通上的心法和經驗，並提到適當的小里程碑能夠維持團隊的前進動力，以及創造溝通環境的自由性，減少溝通上的不安。
在上一篇討論中，我們從心態的四個方向出發，探討了科技對我們人生的影響。接下來，我們進入實戰篇，請矽谷新創工程師職涯與創業教練 Yi 姐分享她從新創到成為自由工作者的經歷，以及在產品開發的各種經驗是如何影響了她的生活，以及我們可以從中學習的策略。
技術與非技術、團隊內外部的有效溝通
「策略」在科技
在企業管理中，產品經理（Product Management）與專案經理（Project Management）這兩個角色雖然都被簡稱為「PM」，但實際上存在著相異之處與部分重疊。
如何有效運用Scrum的船舶理論來主持專案檢討會。船舶理論將專案比作船，通過風帆、礁石、錨等元素可視化檢討內容。會議前的準備、進行步驟及專案經理的主持技巧，幫助團隊在輕鬆愉快的氛圍中總結經驗、識別問題、制定改進計劃，從而提升未來專案的成功率。
在快速發展的時代中，團隊合作是成功不可或缺的要素。這篇文章介紹了一支嶄新的團隊，成員介紹了他們在團隊中的角色和貢獻。並探討了團隊合作的重要性以及有效的溝通和知識共享在團隊發展中的關鍵作用。
在數位時代，Scrum已成為專案管理的利器。本文介紹Scrum的核心角色、工件和事件，並結合我開發CDP的實際經驗，分享如何通過產品待辦清單管理、Sprint計劃與執行、每日站會和Sprint回顧來提升專案靈活性與效率。希望能啟發更多專案經理運用Scrum，優化專案流程。
本次專訪，怪獸科技公司和 Spotify 資深產品經理 Agnes 將與我們探討五大 PM 產品實戰問題，帶你瞭解如何有效提升產品團隊效能、解決商業問題，以及最大化 Side Project 的成果，在競爭激烈的市場中脫穎而出（沒經驗、跨領域轉職的菜鳥也可以）！
本文淺談專案管理(PM)在公司中的重要性，以及圍繞在 PM 周圍的各單位分工。介紹了專案範圍管理、專案成本管理、專案溝通管理、專案風險管理、專案整合管理等專案管理的相關內容，並著重介紹了 TPM、EPM、OPM、Sales Product Manager 等常見的專案管理角色。
在瞬息萬變的商業環境中，如何引領團隊從被動執行轉為主動思考？這篇文章分享了一個部門營業目標的轉型實例，包括轉型契機與挑戰、設定績效目標的關鍵步驟、轉型後的成果與反思，並給予其他主管的建議。透過明確的目標、可量化的指標、有效的溝通與回饋，成功實現了從被動到主動、從執行到創新的轉變。
擁有豐富的團隊溝通與協作經驗的矽谷阿雅，分享了如何識別和解決合作中的常見障礙，以及建立有效溝通流程的具體方法。在本次專訪中，矽谷阿雅探討了跨部門合作時的挑戰，如何提高溝通效率，以及如何優化團隊溝通與協作。
這篇文章分享創業團隊在管理壓力和溝通上的心法和經驗，並提到適當的小里程碑能夠維持團隊的前進動力，以及創造溝通環境的自由性，減少溝通上的不安。
在上一篇討論中，我們從心態的四個方向出發，探討了科技對我們人生的影響。接下來，我們進入實戰篇，請矽谷新創工程師職涯與創業教練 Yi 姐分享她從新創到成為自由工作者的經歷，以及在產品開發的各種經驗是如何影響了她的生活，以及我們可以從中學習的策略。
技術與非技術、團隊內外部的有效溝通
「策略」在科技
在企業管理中，產品經理（Product Management）與專案經理（Project Management）這兩個角色雖然都被簡稱為「PM」，但實際上存在著相異之處與部分重疊。