【2022 曼陀號領航計畫】PM 組月會心得筆記 — 完整產品開發流程及組織架構
2022 PM 組的船長是街口支付的產品長 Clare，第一次月會中 Clare 跟我們分享了她一路走來當上 PM 的經歷，也以 91 App 跟街口支付為例子介紹了不同團隊規模的組織架構及開發流程，並將組員分組討論目前任職的公司為何種組織架構及開發流程方式。
產品組織架構
如下以街口支付為例，闡述各個產品團隊規模階段的 Pros and Cons
第 0 階段 — 創業初期、無明確組織
沒有明確的開發流程，大家一起做夢一起達成目標
- 優勢：資源透明、彈性、目標一致、溝通誤差少
- 限制：團隊超過 10 人以後難以執行
第 1 階段 — 成員變多、組織成形
- 優勢：有了基本的流程，可以追蹤任務進度
- 限制：產品複雜度提高，或是團隊超過特定人數開發速度即變得緩慢
第 2 階段 — 「上帝之手」依專案指派成員形成臨時團隊
- 優勢：多線進行、人力及資源彈性
- 限制：過度仰賴「上帝之手」的調度能力、臨時團隊開發的服務難以長期維護、系統混亂
第 3 階段 — 成員逐漸固定、形成專業領域團隊
而在第 3 階段，同時為大型專案編制跨模組團隊
- 優勢：向心力變強、顧及服務的穩定及領域知識
- 限制：瀑布開發緩慢、大型項目開發時跨領域合作需要新的機制、團隊間資源難以調度、考驗專業領域劃分能力
開發流程 — 開發前
開發前 — 1.1 Pre-Kickoff
目標：讓全體成員具備「目標」、「時程」與「風險」等意識，提前為開發工作做準備
會議內容 ：
1. 闡述專案來由
2. 分享初期調研結果
3. 專案要達成的質化、量化目標及可能時程
4. 團隊對於此專案的想法及建議
Action Item：
1. PM創立專案channel
2. 發出 meeting minutes
3. 針對代辦事項， Owner 期限內回覆結論
開發前 — 1.2 功能與需求說明
目標：讓全體成員具備「目標」、「時程」與「風險」等意識，提前為開發工作做準備
會議內容 ：
1. 闡述專案來由
2. 分享初期調研結果
3. 專案要達成的質化、量化目標及可能時程
4. 團隊對於此專案的想法及建議
Action Item：
1. PM創立專案channel
2. 發出 meeting minutes
3. 針對代辦事項， Owner 期限內回覆結論
開發前 — 1.3 PRD Review
目標：
1. 需求定稿，不再新增 Use Case
2. 使產品開發團隊都清楚 PRD 內容，且可構思開發架構
會議內容 ：
通常進行兩輪，範圍較大或涉及模組眾多的專案可能會需要超過兩輪，需求單純的單一Task型專案可能合併為一輪
1. 第一輪:PRD 完成度 80%，主要邏輯、流程、Wireframe確認2. 第二輪:PRD 完成度 95%，錯誤處理、頁面狀態、邊界條件、文案細節等確認
Action Item：
1. RD 依照 PRD 進行系統架構及技術方案設計
開發前 — 1.4 Design Review
目標：
1. 產出一套符合產品需求、高效、可擴充的技術解決方案
2. 排定技術人力並確定個別時程
會議內容 ：
1. 各 RD 輪流說明系統架構、資料結構、業務流程、系統部署等文件，並由其他人進行審核
2. 並確保設計內容充分考量業務、法規、資訊安全、效能及技術風險等各方面
Action Item：
1.專案 Kickoff ，開發時程定案
2. PM 列出專案風險點，並提出降低風險的解決方案
3. PM 和 RD 一起將 Task 切分放上任務管理系統（如 Jira, Trello…等）
4. QA準備測試計畫
開發期間— 2.1 Test Case Review
目標：讓專案成員理解測試的範疇、功能概況，讓 PRD 完善度逼近 100%
會議內容 ：
1. 說明 Test Case 的思路與細節
2. 依據當下的內容進行討論，或直接修正案例及新增不足的案例
Action Item：
1. QA 和 PM、RD 對齊所有不一致的行為與Spec，並修正完一版最完整的 Test Case 給予所有專案成員
開發期間 — 2.2 程式開發及 QA Automation
PM工作內容:
1. 協助 RD 及 QA 解決開發及測試中遇到的問題
2. 與數據團隊確認發佈後的指標追蹤方式
3. 跨部門制定市場策略
4. 準備下一個專案的前期調研及 PRD 撰寫
開發流程 — 測試期間
測試期間 — 3.1 功能 Demo 及冒煙測試
目標：
1. 確保RD的成果與 PRD一致，且沒有影響主流程操作的大 Bug
2. 確保 PRD實作後符合專案需求
會議內容 ：
1. 後端 API 開發完、交付前端前，執行 API Demo/ 確認 API SPEC
2. 前端 RD 開發完成進廁前， Demo 功能、行為
3. PM、QA、其他RD 確認與 PRD相符
4. 如發現部分功能需大幅異動 PRD內容，則 PM判斷是否暫時從專案中移除，或立即調整
Action Item：
1. 通過 Demo 的功能即可進入 SIT 測試（未通過則先修 Bug)
2. 如需調整 PRD 則由 PM協調部分流程從 1–3 重新開始
測試期間 — 3.2 SIT測試
目標：
1. 完成基本功能測試
2. 確保 Edge Case 與服務的耦合，不可出現任何 P0 Bug
會議內容 ：
1. 黑箱為主：手動測試覆蓋至少 80% 的功能測試主要流程及驗證點，確認使用者端的操作一切正常
2. 白箱為輔：手動確認相關 API 與邏輯是否如預期，再將香菇的驗冊自動化，確認相關邏輯都有被覆蓋到
Action Item：
1. 依據檢測結果，決定是否進入 Stage 測試
測試期間 — 3.3 PM驗測
目標及內容:依據階段性的驗收範疇，列出各驗收項目，並定義 P0、P1 的 Bug
Reference: Bug等級定義
P0: 系統崩潰、核心功能不能使用、金流錯誤、重大資安風險
P1: 次要功能不能使用，功能實現不完整，介面顯示不正確影響功能使用
P2: 影響使用者體驗，如 UI 與設計不符、介面顯示不正確、字串錯誤
P3: 機率極低且繁瑣的錯誤，機率極低的系統崩潰，複雜流程中影響用戶極少的不可用，功能存在歧異造成用戶困擾
p4: 建議與改善測試期間 — 3.4 Stage 測試
目標：
1. 確認新服務部署後不會影響原服務進行
會議內容 ：
1. 系統整合測試
2. 壓力測試
Action Item：
1. QA 發出測試報告，內容包含未修復 Bug 分析及風險揭露
測試期間 — 3.5 PM進行上線判定
目標及內容：依據 QA 發出的測試報告及自行驗測之結果，確認該功能是否上線
開發流程 — 發佈期
發佈期 — 4.1 上版會議
目標：
1. 確保上版過程不影響現有服務操作，且新功能順利發佈
會議內容 ：
1. 擬定上版流程及時間
2. 確保上版過程中線上功能影響最小化
3. 制定灰度發佈或全像發佈的計畫，頂氣特殊情境 Roll Back 處理方案
Action Item：
1. 通報受影響單位此上版計畫
發佈期 — 4.2 正式環境部署
目標及工作內容: RD 依照上版會議之共識於進行部署
發佈期 — 4.3 上線觀測、回歸測試
目標及工作內容:
1. QA 於上版後立刻進行回歸測試
2. RD 及 QA 透過監控體系確保服務運作正常
開發流程 — 上線後
上線後 — 5.1 回顧會議
目標：
1. 針對本次做得好和不好的地方進行復盤
會議內容 ：
1. 回顧本次專案（做了什麼？遇到什麼困難？）
2. 分享做的好的地方/做不好的地方/需要協助的事/學習到的通用知識/想要感謝的人
3. 討論尚未完善/開發的需求，是否排入下階段開發流程
Action Item：
1. 帶著收穫開啟新的專案
上線後 — 5.2指標持續追蹤
目標及工作內容：
1. RD 及 QA 透過監控體系確保服務運作正常
2. PM 定期檢視專案目標成果是否符合預期
由於平常公司執行的是敏捷開發，並沒有執行上述如此全面的開發流程。所以我也很慶幸能夠藉由這一次月會的分享及討論，學習到其他公司的開發及協作流程！
