The MentorShip 曼陀號是由 Girls In Tech 主辦的職涯探索計劃，透過四次月會，在船長的帶領下讓同領域學員們彼此交流。
2022 年有幸錄取計畫，與街口支付產品長 Clare 及各位 PM 伙伴們一起在每月週日早上交流成長 💪
透過文字紀錄月會經驗，希望分享給更多伙伴 🙌
組織成長過程的團隊配置演進史
Clare 從 91APP 產品長李昆謀的文章《91APP的軟體開發之道 — 從20人到200人的組織發展旅程》帶我們一同檢視組織從創立初期、小而緊密的狀態，到逐漸壯大，人員、專案越來越多時會產生什麼問題談起。這裡快速帶各位複習各階段內容，同時加入討論過程中，針對原文的補充：
第０階段：創業初期——無明確組織
此階段成員們彼此關係緊密，目標一致，溝通無礙。
第１階段：瀑布來了——組織成形
隨著成員增加，彼此負責的職能開始有明確劃分，能夠完成瀑布式的接力開發模式。
第２階段：上帝之手 ——依專案行程臨時團隊
隨著產品中專案多線開發，具有資源協商能力的「上帝之手」會彈性安排各個成員在不同專案中，讓開發多線進行。然而非專責的團隊較難培養長期維護責任感，也容易產生系統混亂。
第３階段：成員固定——專業領域團隊成形
不同功能開始有各個團隊專責維運，各個小團隊間向心力強，且可長期發展專業領域知識與穩定服務。然而不同功能需要開發的時程、內容不一，若無妥善調度人力，可能會有部分人員閒置、部分人員過載。另外，當出現需要跨功能模組合作的專案，需要新的機制分配人力、彼此協作。
第４階段：導入敏捷
敏捷開發 (Agile) 是一種哲學方向，理念可參考敏捷宣言：
「個人與互動」比「流程和工具」更重要
「實際運作軟體」比「包山包海的文件說明」更重要
「客戶合作」比「簽約協商」更重要
「回應變化」比「遵循計畫」更重要
Scrum 是多數人用來實現敏捷開發的方式，包含三種角色、五項活動、三大要件、五大價值。
導入敏捷之後，成員們注重開發效率。然而這些 Agile、Scrum 的開發守則有時反而會讓團隊成員陷入字義、角色權責之間解釋的爭論，誠如原文提到的「我們太過於計較跑步的姿勢，而忘記了跑步的速度」。
第５階段：團隊自主管理
在這個階段，各個專業小組各有自己的 Sprint planning，為各自的開發內容負責。小團體的緊密互動，仿若回到了第０階段的創業緊密階段。然而跨團隊之間的溝通方式相較較弱，彼此之間可能是競爭關係。
第６階段：跨團隊主管會議 (One Team)——整合團隊方向
當團隊內與團隊間的節奏、目標漸行漸遠，彼此間競爭性越來越強、難以韓做，就需要各團隊裡的主管階層 (上帝之手) 們組成「團隊的團隊」(One Team) 讓大家對齊方向
第７階段：矩陣式組織及後續調整
當團隊組織走到矩陣式，會有兩個目標：一方便有自己所在的專業團隊，負責功能開發；另一方面在自己所屬的職能，又要對主管負責 (例如一位工程師要負責Ａ功能 report 給對應 PM，又要 report 給工程團隊主管)。
此時組織可能會走向重整，以專業領域作為一個部門單位，將成員的日常工作編制與 KPI 掛勾，對齊方向。此做法適合產品與開發團隊都相當資深，可以為各自所屬專業功能負責的階段。
延伸閱讀：The JKOPAY Way
船長 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 不藏私分享了許多街口開發的細節。在學員們交流期間，也聽到了來自不同類型產業、公司的開發方式，從彼此的做法中交流。
