← LAUNCH·ATLAS·BLUEPRINT
COMPANION VIEW NINE ROLES · FIFTY+ DELIVERABLES ← BACK TO ATLAS
0,0 · ORIGIN
DOC 01 · PROCESS BLUEPRINT

軟體服務
的 開發流程
導覽 地圖。

這份文件把一個產品從「客戶說一句話」 到「使用者打開 App」之間的每一棒拆開—— 9 個角色 · 50+ 必要交付物 · 完整 DAG 協作鏈。 每個交付物都附上一個你可以直接複製貼上的公開範本連結。

09
Roles · Stages
50+
Deliverables
11
Decision Points
∞
Cycle Iterations
Scroll · 01 of 06
SECTION01The DAG

一張 協作流程圖
看完整個 SDLC。

左→右是時間軸，從商業需求到使用者落地。實線箭頭代表交付物傳遞， 虛線代表回饋與校驗。 相鄰的角色不是各自封閉的盒子——他們在每個決策點上都是互相疊加的。

FIG. 01 · DELIVERABLE FLOW · LEFT-TO-RIGHT TOPOLOGY SOURCE DISCOVERY DESIGN · WHAT DESIGN · HOW DETAIL · DATA BUILD VERIFY · RUN USER Customer SOURCE PM PRODUCT MGR UX / UI DESIGNER SA SYS ANALYST Architect SYS BOUNDARY SD SYS DESIGN DBA DATA LIFELINE Dev FE · BE QA VERIFIER DevOps SRE · ONCALL Users END briefing PRD user story use case flow + UI arch + NFR data ownership API spec schema PR + UT pass report release
交付物傳遞 · DELIVERABLE 回饋 · FEEDBACK / BUG / INCIDENT 外部角色 · EXTERNAL 點任一節點直接跳到該角色卡 →
SECTION02Roles

每個階段 · 必要交付物
＋ 可貼上的範本。

每張卡片都標示三件事：產出（這階段交什麼）、 上下游邊界（接誰、交給誰）、 新手陷阱。 所有範本連結都是公開、可立即使用的素材。

/01P
M

Product Manager

PM · 需求壓縮器
把「我想做 AI」壓縮成可衡量的目標
核心 · 客戶說的永遠不是需求。PM 的工作是把客戶的話往下挖到「降低客服成本 40%」「轉單率 +15%」這種可衡量的目標——不是當傳聲筒。

Deliverables

5 items
ArtifactWhat forReference templates · 直接可貼
PRD 產品需求文件，幾十頁的脈絡與規格 Atlassian PRD Notion PM Templates ProductPlan
User Story 「身為 X，我想 Y，這樣 Z」一句話需求單位 Atlassian Guide Mike Cohn
Backlog Epic → Story → Task 的待辦池 Jira Templates GitLab Handbook
Persona 目標用戶輪廓 1 頁人物卡 HubSpot Persona Tool Xtensio
Roadmap 時程 / 優先級 / 季度路線 ProductPlan Roadmaps Aha! Roadmaps
UPSTREAM 接誰
客戶 · 業務 · 老闆
商業需求源頭，含口頭、Slack、PPT、email
DOWNSTREAM 交誰
UX · SA · Architect
把模糊需求翻譯成下游可執行的東西
Anti-Pattern
越界指定「要用 React」「要用 PostgreSQL」——那是 Architect 的事。PM 是 Product 不是 Project，管「做什麼」「為什麼做」，不管「用什麼做」。
/02U
X

UX · UI

UX · 動線 / UI · 樣品屋
UX 決定「能不能順利做完」 · UI 決定「看起來想不想做」
核心 · UX 是動線、UI 是樣品屋。新手最常見的盲點是「打開 Figma 就開始畫」——成熟的 UX 會先問「給誰看、看什麼決策、多久看一次」。

Deliverables

5 items
ArtifactWhat forReference templates · 直接可貼
User Journey 使用者完整體驗地圖 + 情緒曲線 Miro Templates NN/g Guide Figma Journey Map
Wireframe 畫面骨架 · 灰階線框 · 不關心顏色字型 Figma Wireframe Kits wireframe.cc Balsamiq
Prototype 可點擊互動原型 Figma Prototyping Proto.io
Mockup 高保真視覺稿 · 含顏色 / 字型 / 圖片 Figma Templates Dribbble UI
Design System 元件庫 + 規範 + Color / Spacing token Material Design 3 Apple HIG Atlassian DS Shopify Polaris
UPSTREAM
PM
拿 PRD、User Story、KPI 來畫流程
DOWNSTREAM
Architect · SA · FE Dev
把可用性結論交給 SA 補規則、給 FE 實作
Anti-Pattern
越界決定「這欄位必填」「逾期就退費」——那是 SA 的事。UX 只反映規則，不發明規則。
/03S
A

System Analyst

SA · 補規則的縫隙
PM 給的是箭頭 · SA 給的是箭頭旁邊的條件
核心 · PM 說「做一個訂單系統」，UX 畫了結帳流程。但沒人說：30 分鐘不付款怎辦？付完才發現庫存不夠怎辦？這些縫隙 SA 必須補完，Dev 才寫得下去。

Deliverables

6 items
ArtifactWhat forReference templates · 直接可貼
Use Case 使用案例 · UML 圖 + 描述表 PlantUML Use Case Lucidchart Guide
State Diagram 狀態轉換 · pending→paid→shipped PlantUML State Mermaid stateDiagram
Business Rule 商業規則 · 條列式清單 Modern Analyst IIBA Resources
Data Dictionary 欄位 + 型別 + 約束 Panoply Template dbdiagram.io
Permission Matrix RACI · 角色 × 操作核取表 Smartsheet RACI Atlassian RACI
Exception Flow 失敗 / 邊界情境流程 UML Activity Mermaid Flowchart
UPSTREAM
PM
拿 What / Why 來補 How
DOWNSTREAM
Architect · SD · Dev · QA
把業務規則翻成系統規格
Anti-Pattern
越界寫「用 Redis cache」——SA 該寫的是「這查詢必須 < 1 秒」，怎麼做是 Architect 決定。SA 寫需求，不寫實作。
/04A
R

System Architect

ARCH · 城市規劃師 · 定邊界
NFR 才是真正的產品 · 架構圖只是溝通工具
核心 · 新手以為架構師的產出 = 一張漂亮的架構圖。錯。架構師真正在交付的是 NFR（非功能需求）——系統能不能撐流量、會不會掛、好不好改、能不能 debug。功能撐不住 = 全部歸零。

Deliverables

5 items
ArtifactWhat forReference templates · 直接可貼
Architecture Diagram 系統結構全景 · C4 / 區塊圖 C4 Model Structurizr Excalidraw Eraser.io
ADR 架構決策紀錄 · 脈絡 / 選項 / 後果 ADR · Nygard MADR MADR Templates
NFR Spec SLA / RPS / Latency 表 ISO 25010 Google SRE SLO
Service Boundary 領域圖 + 責任清單 DDD by Evans Bounded Context Canvas
Integration Pattern 同步 REST / 非同步 Event 選擇 EIP Catalog microservices.io
UPSTREAM
PM · SA
商業需求 + 業務規則 + NFR
DOWNSTREAM
SD · DBA · DevOps · Dev
技術決策的單點責任 · 跨所有交付角色
Anti-Pattern
越界寫 API endpoint 細節→ SD 沒空間；不越界又不出手 → 系統長歪。架構師關鍵：定邊界，不定細節。
/05S
D

System Design

SD · 建築設計師 · 定細部
Dev 拿到文件，從頭到尾不用再問問題就能寫完
核心 · 很多 SD 寫的「設計文件」滿是業務術語、沒 endpoint、沒欄位、沒錯誤碼，Dev 看完還是要問三遍。好的 SD 產出有一個唯一指標：Dev 看完不用再問問題。

Deliverables

5 items
ArtifactWhat forReference templates · 直接可貼
Module Design 服務內模組怎麼切 + 責任清單 C4 Component System Design Primer
API Spec 對外契約 · OpenAPI / Swagger YAML OpenAPI Spec Swagger Editor Stoplight Elements Zalando Guidelines
Sequence Diagram 一次互動的時間軸 Mermaid Sequence PlantUML Sequence sequencediagram.org
Component Design 元件責任與依賴關係 UML Component Structurizr DSL
Class Diagram 物件結構 · 屬性 / 方法 / 繼承 PlantUML Class Mermaid Class
UPSTREAM
Architect · SA
拿系統邊界 + NFR + 業務規則
DOWNSTREAM
Dev · DBA · QA · DevOps
設計與實作的橋 · 把架構決策落地成可開工的圖
Anti-Pattern
SD 越界寫實作邏輯 → Dev 沒空間；不寫 sequence → Dev 各寫各的。API 命名是 SD 的靈魂——一致、可預測、不誤導。
/06D
B

DBA · Data

DBA · 資料生命線
資料怎麼存 · 怎麼活 · 怎麼回得來
核心 · DBA 不是寫 CREATE TABLE 完就結束，是把 Schema + Index + Transaction + Backup + Governance 這 5 件事連在一起設計。「真出事還回得來」才是 DBA 的命脈。

Deliverables

5 items
ArtifactWhat forReference templates · 直接可貼
ERD 資料實體關聯圖 dbdiagram.io drawSQL Lucidchart ERD Mermaid ER
Schema + Index DDL + 索引策略 + Partition PostgreSQL DDL Use The Index Luke
Transaction 策略 Saga / Outbox / 鎖表規則 Saga Pattern Outbox Pattern
Backup Plan RPO / RTO / PITR 文件 AWS Backup PostgreSQL PITR
Data Governance Retention / 稽核 / ACL GDPR Checklist DAMA DMBOK
UPSTREAM
Architect
決定資料歸屬哪個服務、跨服務一致性策略
DOWNSTREAM
SD · Dev · QA · DevOps
所有要碰 DB 的人
Anti-Pattern
越界決定「該不該拆服務」會踩到 Architect；Dev 越界決定 index 順序會踩到 DBA。DBA 用數據說話，不憑直覺。
/07D
v

Developer

DEV · FE / BE · 寫 Code 的人
在 AI 時代，價值從「寫 Code」變成「判斷該寫什麼 Code」
核心 · Dev 不是只交 code，要交 PR + Unit Test + 文件 + Build artifact。AI 可以寫 80% 的 code——但剩下的 20%（架構 fit / debug / 業務理解 / Code Review / 命名）是 Dev 真正的價值。

Deliverables

5 items
ArtifactWhat forReference templates · 直接可貼
Code (PR diff) 可運行的程式碼 · PR / MR 格式 Conventional Commits Spec v1.0 GH PR Template
Unit Tests 驗證自己寫的單元 · 跟 PR 一起進 pytest Jest Vitest JUnit 5
Documentation README / docstring / ADR makeareadme.com Diátaxis Framework Write The Docs
Build Artifacts Docker image / npm package / binary Dockerfile Best Practices distroless
Tech Spike / PoC 不確定方案先試 · demo repo + 心得 Agile Glossary awesome lists
UPSTREAM
SD · DBA · UX/UI
拿施工圖、schema、Mockup
DOWNSTREAM
QA · DevOps
交給 QA 驗收、交給 DevOps 部署
Anti-Pattern
SD 文件沒寫的地方，新手 Dev 自己猜（「retry 3 次吧」）。師傅樣的 Dev：不猜、不英雄主義，把模糊變明確並寫下來——拉 SA / Architect 拍板，補進 PR description。
/08Q
A

Quality Assurance

QA · 把驗收變成可重複的資產
產出不是「找了幾個 bug」，是留下可重複驗證的資產
核心 · Dev 顧底層（Unit Test），QA 顧上層（Integration / E2E / Load）。在 AI 系統，QA 從「驗證已知」變成「定義未知」——對的答案要先被定義。

Deliverables

5 items
ArtifactWhat forReference templates · 直接可貼
Test Case 單一驗證步驟 · 前置 / 步驟 / 預期 TestRail Templates Jira Test Case
Test Plan 一次發版的測試藍圖 IEEE 829 Template Atlassian Testing
Bug Report 重現步驟 + log + 截圖 + 優先級 Atlassian Bug Report Bugzilla Docs
Test Automation 自動回歸腳本 Playwright Cypress k6 Load Selenium
Coverage Report 哪些路徑被測過了 + risk map Codecov coverage.py Istanbul
UPSTREAM
PM · SA · Dev
驗收條件 + 規格 + PR 實作
DOWNSTREAM
DevOps
驗證資產進 CI/CD · release gate
Anti-Pattern
Dev 拍胸脯「我測過了」通常只測過 happy path。E2E + edge case 是 QA 的責任。新手 QA 只跑 smoke test 就 release——成熟 QA 補完 E2E 並加進回歸 suite，下次自動跑。
/09O
P

DevOps · SRE

OPS · 把運維變成 Code
產出不是「裝好機器」，是讓運維本身可被版本控制 · 可被重複
核心 · 從 Dev 寫完 commit 那刻、到 user 看到頁面那刻，全是責任區。on-call 不是「誰寫的誰修」，是先止血再究責——SRE 文化的核心。

Deliverables

5 items
ArtifactWhat forReference templates · 直接可貼
CI/CD Pipeline 自動測試 + 部署 · lint→test→build→deploy GitHub Actions Starters GitLab CI Examples CircleCI Orbs
Infra as Code 用程式定義基礎設施 Terraform Registry Ansible Galaxy Helm Charts (ArtifactHub) AWS CDK
Monitoring Dashboard 系統健康即時可見 Grafana Dashboards Prometheus Best Practices Datadog Dashboards
Runbook 出事時誰按哪個鈕 · on-call playbook Atlassian Runbook PagerDuty Response Run-book Template
Incident Report Postmortem · RCA + 行動項 Google SRE Postmortem PagerDuty Postmortem Postmortem Templates
UPSTREAM
Dev · QA
產出 code + 測試 → 進 CI/CD
DOWNSTREAM
使用者 · Monitoring · 自己 (on-call)
上線後活下來的系統
Anti-Pattern
替 Dev 寫業務 code → 越界。界線是「程式怎麼跑」，不是「程式做什麼」。DevOps / SRE 主導 deploy 策略、監控閾值、容量規劃；不主導 API 設計與業務優先級。
SECTION03Decision

誰拍板 · 誰參與。
11 個決策 × 9 個角色。

Overlap 不是壞事，是必要的多重視角——問題不是 overlap，是 overlap 時誰拍板。★ 主是拍板人；●是參與者，「－」代表通常不碰。

決策PMUXSAArchSDDBADevQAOps
商業目標 / KPI★●●－－－－－－
使用者旅程●★●－－－●－－
業務規則 · 狀態機●●★●●●●●－
服務邊界 · 拆幾個 service－－●★●●－－●
技術選型 / NFR / SLA●－●★●●●－●
Data Schema · Index 策略－－●●●★●－－
API endpoint 命名 · Sequence－－－●★●●●－
程式碼結構 · Function 切分－－－－●－★－－
Unit / Integration / E2E－－－－－－●★●
CI/CD · Deploy 策略－－－●－－●●★
監控 · Alert · Incident－－－●－●●●★
SECTION04Three views

同一個需求 · 三種翻譯。
每翻一次降低一層不確定性。

以「使用者結帳付款」為例。把同一個需求畫三次，是因為每一層要回答的問題不一樣——這是新手最容易省略、最容易出錯的步驟。

LAYER 01 · USER FLOW

User Flow

PM / UX · 回答「使用者怎麼走」
購物車
  ↓
結帳頁
  ↓ 填地址
選付款方式
  ↓
完成 · 訂單成立
Miro FigJam Overflow
LAYER 02 · SYSTEM FLOW

System Flow

SA · 回答「系統怎麼判斷」
check_stock()
  ↓
lock_stock(reservation_id)
  ↓
create_order(pending_payment)
  ↓
call_payment_gateway()
  ↓ ok ─→ paid · release_reservation
  ↓ fail → cancel · unlock_stock
PlantUML Activity Mermaid State
LAYER 03 · ARCHITECTURE FLOW

Arch Flow

Architect · 回答「服務 / 資料 / 事件怎麼跑」
Web → API GW
      ↓
   Order-Svc ──► Payment-Svc
      ↓               │
 Inventory-Svc     [3rd Party]
      ↓
   Kafka → Notify-Svc
   Kafka → Analytics
C4 Model Structurizr Excalidraw
SECTION05Handoffs

每一棒 · 交什麼。
交棒不是傳球，是傳責任。

每個角色的產出就是下個角色的輸入——產出爛，下游全部跟著爛。反模式：把交棒當成「丟過去就好」——不確認下游讀懂，等於沒交。

PM━━▸UX
  • PRD
  • User Story
  • KPI · Persona
PM━━▸SA
  • PRD
  • Business Goal
  • 核心 Use Cases
UX━━▸FE Dev
  • Wireframe + Mockup
  • Prototype 連結
  • Design System token
SA━━▸Architect
  • Use Case
  • State Diagram
  • Permission Matrix
Architect━━▸SD
  • Architecture Diagram
  • Service Boundary
  • NFR Spec + ADR
SD━━▸Dev
  • API Spec (OpenAPI)
  • Sequence Diagram
  • Module Design + 錯誤碼
Architect━━▸DBA
  • Data Ownership
  • 一致性策略
  • 跨服務事件 / Saga
SD━━▸DBA
  • Data Access Pattern
  • Query Plan 預估
  • 讀寫比例
Dev━━▸QA
  • PR + Unit Test
  • Test Plan 對應
  • Build artifact
QA━━▸DevOps
  • Pass Report
  • Coverage Map
  • E2E Suite 進 CI
Dev/Ops━━▸SRE
  • Runbook
  • Monitoring Spec
  • SLO / Alert 閾值
User⟵ ⟵PM
  • 使用數據 · NPS
  • 客服工單
  • Postmortem → 下迭代
陷阱 01
文件過期
PRD 改了，工程師還在看舊版。永遠**指向同一個 source of truth**，不要複製貼上。
陷阱 02
過度詳細
寫了 30 頁 PRD 沒人會讀，最後只能靠口頭問。該寫的細，該砍的砍。
陷阱 03
版本對不起來
Slack 一句、會議一句、Jira 一句——所有決策都應該沉澱到 source of truth。