组织、角色和工作节奏
目的
定义软件团队在引入 AI/Agent 前的组织方式、角色边界和协作节奏。重点不是先画组织架构，而是让每个工作能闭环：有人推进、有人拍板、有人 review、有人接收结果。
协调和决策细节见 12-协调和交接-coordination-and-handoff.md。
三角色治理细节见 10-三角色治理-three-role-governance.md。组织设计时至少要能找到技术负责人、产品负责人、平台 / 资深工程师这三个视角。
先定义角色闭环
在团队还不成熟时，不要先追求完整组织结构。每个任务先能映射到这些角色：
| 角色 | 最小职责 | 可以由谁兼任 |
|---|---|---|
| Requester | 解释问题背景和期望结果 | 老板、产品、运营、销售、客服 |
| Driver | 推动任务从记录到关闭 | 工程负责人、模块 owner、当班工程师 |
| Approver | 对 scope、验收、上线风险拍板 | 产品 owner、技术负责人、创始人 |
| Reviewer | 判断实现、测试和风险是否可接受 | 模块 owner、资深工程师 |
| Operator | 负责发布、回滚、线上观察 | 工程师、运维、平台负责人 |
一个人可以兼任多个角色，但 Driver 和 Approver 必须显式。多人共同负责不算显式。
三角色治理映射
| 治理角色 | 在任务里的常见身份 | 负责防止什么问题 |
|---|---|---|
| 技术负责人 | Approver / Reviewer / Tech Owner | 技术风险无人拍板，质量门禁被绕过 |
| 产品负责人 | Requester / Approver / Business Approver | 做错用户问题，做完没人验收 |
| 平台 / 资深工程师 | Reviewer / Operator / Doc Driver | 命令不可执行，环境和发布靠个人记忆 |
成熟后的参考结构
Product Council
- founder / product owner / tech lead 小组
Product Squad A
- 4-7 名工程师 + 产品/设计支持
Product Squad B
- 4-7 名工程师 + 产品/设计支持
Platform / Enablement
- 1-3 人负责 CI/CD、runtime、可观测性、开发体验、权限
Architecture / Quality Guild
- 跨小队维护技术规范、架构决策和质量门禁
这个结构不是第一天就要建立。草台团队先保证任务闭环，再逐步把角色固定到岗位。
角色
| 角色 | 负责什么 | 工具表面 |
|---|---|---|
| Product owner | 问题定义、优先级、验收 | Linear/Jira、Notion/Lark |
| Engineering lead | 交付计划、技术风险、人员协调 | Linear/Jira、GitHub、repo docs |
| Module owner | 模块契约、代码质量、评审 | GitHub CODEOWNERS、repo docs |
| Platform owner | CI/CD、环境、可观测性、密钥、开发体验 | GitHub Actions、Docker、Sentry/Grafana、1Password/Vault |
| Incident commander | 事故响应协调 | Slack/Lark 事故群、runbook |
| Reviewer | 代码质量和风险门禁 | GitHub PR |
工作节奏
| 频率 | 会议/产物 | 工具 | 输出 |
|---|---|---|---|
| 每日异步 | Closure check | Slack/Lark / Linear | 哪些任务 blocked，谁是 Driver，下一步是什么 |
| 每周 | Planning | Linear/Jira | 下个周期承诺工作，明确 Approver |
| 每周 | Demo / Review | 会议 + Notion/Lark 纪要 | 可运行结果、验收结论、反馈任务 |
| 双周 | Retro | Notion/Lark | 1-3 个流程改进行动 |
| 每月 | Architecture review | ADR/RFC repo docs | 接受/拒绝的技术决策 |
| 每季度 | Strategy planning | Notion/Lark + Linear project | 主题、资源、取舍 |
如果团队连周会都开不稳，最低只保留两个节奏：
- 每日 10 分钟看 blocked 任务。
- 每周 30 分钟关闭或重新分配悬空任务。
负责人模型
每个重要对象都必须有 owner：
| 对象 | Owner 类型 |
|---|---|
| 产品区域 | Product owner + engineering lead |
| 模块 | Module owner |
| 服务 | Service owner |
| CI pipeline | Platform owner |
| Runbook | Service owner |
| 安全策略 | Platform/security owner |
| 事故 action | 具体个人 |
后续 Agent 就绪要求
这一节在人类组织角色稳定后再看。
接入 Agent 前，每个任务必须能解析出：
- 产品 owner。
- 工程 owner。
- Repo 和 module owner。
- Reviewer。
- Runtime 或环境边界。
如果人类都说不清谁负责，Agent 不应该接手。
Agent 不应该承担最终决策角色。它可以做 scout、implementer、reviewer 或 scribe，但 Driver、Approver 和生产 Operator 必须能回到人。
下一步阅读
读完或填完这份文档后，通常继续看：
- 12-协调和交接-coordination-and-handoff.md：组织角色明确后，继续看协调、决策和交接。