01 - 总览：两个角色的视角区别与全局图
架构师 vs 产品总负责人——同一个项目，两种视角。看到的东西不一样，决策不一样，要的工具也不一样。
一句话
架构师 = 决策"系统怎么建"的人，担"技术风险"；产品总负责人 = 决策"建什么、为谁"的人，担"产品风险"——两人都要看到全图，但关注点不同。两者协作好了，项目就稳。
两个角色的根本区别
架构师（Tech Lead / Architect）
核心问题：
- 系统能不能稳定跑起来？
- 改动一处会不会影响十处？
- 团队能不能持续加新功能而不崩？
决策范围：
- 技术栈选型
- 模块边界划分
- 接口契约
- 性能 / 可扩展性 / 可靠性
- 重构计划
关键工具：
- ADR（架构决策记录）
- 系统架构图（C4 模型 / Dependency Graph）
- 技术雷达（哪些技术值得用）
- 代码仓库结构
- 监控告警 + 事故复盘
反模式：只刷技术债不见业务价值——技术决策必须挂到业务结果上。
产品总负责人（Product Lead / 业务负责人）
核心问题：
- 我们到底在解决谁的什么问题？
- 投入产出比是否合理？
- 用户/客户/股东都满意吗？
决策范围：
- 业务目标 / OKR
- 优先级排序
- 范围取舍
- 上线节奏
- 资源分配
关键工具：
- Roadmap
- 用户故事地图 / 需求池
- 业务指标仪表盘
- 竞品 / 市场分析
- 利益相关者沟通
反模式：只追业务指标不管技术债——3 个月内必崩。
两者的协作点
业务问题（产品）
↓
技术方案（架构）
↓
排期交付（共同）
↓
上线 + 监控（共同）
↓
反馈循环（共同）
↓
回到业务关键决策往往是两边共同定的：
- 选 PostgreSQL 还是 MongoDB → 架构主导，告知业务影响
- 这个需求到底做不做 → 产品主导，告知技术影响
- 这周发版还是下周 → 共同决策，看业务时机 + 技术准备
项目生命周期的 8 大关键问题
任何项目从想法到上线必答这 8 个问题（按顺序）：
| # | 问题 | 谁主导 | 答错了的代价 |
|---|---|---|---|
| 1 | 为什么做？ | 产品 | 资源浪费 |
| 2 | 为谁做？ | 产品 | 做出来没人用 |
| 3 | 做什么？ | 产品 | 范围蔓延 |
| 4 | 怎么做？ | 架构 | 系统难维护 |
| 5 | 什么时候做？ | 共同 | 错失时机 |
| 6 | 谁来做？ | 共同 | 责任真空 |
| 7 | 怎么发？ | 架构 | 部署事故 |
| 8 | 怎么衡量成功？ | 产品 | 不知道做得好不好 |
8 个问题答不全 = 项目一定失控。
全局信息流图
┌──────────────────────────────────────────────────────────┐
│ 1. 想法/客户反馈/竞品分析 │
│ (Notion / 飞书 / 客户工单系统) │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 2. 立项 + Roadmap │
│ (Notion 主文档 + 利益相关者名单 + OKR) │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 3. 需求（业务问题 → 用户故事） │
│ (Jira/Plane Story + Notion RFC + 验收标准) │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 4. 架构设计（技术决策 → 系统图） │
│ (Wiki ADR + 系统架构图 + API 契约 + Schema) │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 5. 任务拆分（需求 → Issue） │
│ (Jira/Plane Task + Story + Epic + Sub-task) │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 6. 编码 + Review（代码 → 合并） │
│ (Git branch + PR + CI/CD + 测试通过) │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 7. 部署 + 监控（合并 → 用户可用） │
│ (CI/CD 部署 + 监控告警 + 业务指标仪表盘) │
└──────────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 8. 反馈循环（用户行为 → 改进方向） │
│ (数据分析 + 用户反馈 + 事故复盘 → 回到想法) │
└──────────────────────────────────────────────────────────┘
↓
循环上升关键工具栈（基于团队规模）
| 维度 | 5-10 人 | 10-30 人 | 30-100 人 |
|---|---|---|---|
| 任务 | Plane 开源 / GitHub Issues / Notion | Jira / Plane Cloud / Linear | Jira + Confluence |
| 代码 + Review | GitHub | GitHub / GitLab | GitHub Enterprise / GitLab |
| CI/CD | GitHub Actions | GitHub Actions + ArgoCD | Jenkins / GitLab CI / Spinnaker |
| 部署目标 | Vercel / Railway / 阿里云 | Docker + K8s | 自建 K8s / 多云 |
| 监控 | Sentry + Grafana Cloud | Prometheus + Grafana + Sentry | Datadog / 自建全栈 |
| 知识库 | Notion / 语雀 | Notion / Confluence | Confluence / 自建 Wiki |
| 沟通 | 飞书 / Slack / 钉钉 | 同左 + 视频会议设备 | 同左 + 协作规范 |
原则：工具数量 ≤ 7——超过 7 个工具，每个团队成员的时间就会被切换成本吞噬。
4 个关键治理点
无论团队大小，必须有的 4 个治理动作：
1. 每周一 30 分钟站会（Standup）
不是"周会"！是站立开的、快节奏、同步级别的短会。
议程模板：
[姓名] [日期]
1. 上周五做了什么：X / Y / Z
2. 今天计划：X' / Y'
3. 阻塞（需要谁帮忙）：A 找 B 关于 C为什么不是周会：周会变"轮流汇报"——每个人都听 90% 不相关的事。Standup 只同步阻塞和风险，剩下的 1-1 聊。
2. 每两周一次 Demo
不是内部 Demo——是给真实用户/客户/利益相关者看。
目的：避免"做完了发现不是用户要的"——Demo 是真实反馈。
频率：每两周（太长会失去节奏；太短会变成走形式）。
3. 每月一次 Retro（回顾）
不是"团建"！是系统性复盘——什么是做对的、什么是做错的、下个月改什么。
模板：
[月份] Retro
✅ Stop doing: [我们应该停止的事]
▶️ Start doing: [我们应该开始的事]
▶️ Continue doing: [做得对的继续]
📈 Metrics: [关键指标变化]3.5 每月一次 1-1（管理者与每个直属）
30 分钟，一对一。不是汇报工作——是聊个人状态 + 职业发展 + 团队问题。
关键问题：
- 这个月让你最有成就感的是什么？
- 什么事情让你卡住了？
- 你下个月想专注什么技能？
- 团队里有什么让你不舒服的事？
4. 每季度一次 Roadmap 评审
重新评估 Roadmap 是否还合理——3 个月前的判断可能已失效。
核心问题：
- 业务目标还成立吗？
- 优先级变了吗？
- 有没有新的风险？
- 团队节奏怎么样？
角色清晰度检查清单
如果你读完上面对架构师 / 产品负责人的描述有疑问，回答这些问题：
| 问题 | 是 | 否 |
|---|---|---|
| 我知道我们团队的两个角色分别是谁 | ✅ | 🚨 需要明确 |
| 技术决策有明确的负责人（不是争议） | ✅ | 🚨 需要 ADR 流程 |
| 业务优先级有明确的负责人 | ✅ | 🚨 需要产品 OKR |
| 跨团队改动有"协调员"角色 | ✅ | 🚨 必出责任真空 |
反模式自检
最常见的 5 种失败模式：
- "只刷技术债不见业务价值"——架构师埋头重构，业务拿不到结果 → 半年后被裁
- "只追业务指标不管技术债"——产品负责人强行塞需求 → 三个月后系统崩
- "决策在聊天里说完就结束"——Slack 聊完没人记录 → 三个月后争议
- "周会变周报"——每周轮流汇报 2 小时 → 团队麻木
- "责任真空"——跨团队改动没人推 → 烂尾
进入下一章
读完总览后：
- 如果你是 架构师 → 直接看 03 需求打磨 + 04 架构设计 + 06 代码评审 + 07 部署
- 如果你是 产品总负责人 → 直接看 02 立项与 Roadmap + 03 需求打磨 + 05 任务与冲刺 + 08 团队流程
- 如果两者都要 → 按 02-08 顺序读
作者：基于 SE@Google / INCOSE / IDDD 三书 + 行业实践综合 最后更新：2026-06-28