思维模型见 team-as-product.md
第一层：诊断——找到真实的摩擦点
产品诊断的第一步不是设计方案，是找到用户真正卡在哪里。团队诊断也一样。
做法：定期一对一，换一套问题
不问”工作进展怎么样”，问：
– 最近什么事情让你觉得卡住了？
– 有没有什么事情你觉得本不该这么麻烦？
– 如果你来改一件事，你会改什么？
这三个问题问出来的是系统性摩擦，而不是个人情绪。把答案归类，同一类问题反复出现，就是系统需要修的地方。
团队层面的扫描
每季度做一次匿名问卷，四个维度：
| 维度 | 核心问题 |
|---|---|
| 信息流转 | 我需要的信息能及时拿到吗？ |
| 决策速度 | 遇到需要判断的事情，等待时间合理吗？ |
| 协作摩擦 | 和其他人配合时，哪个环节最费劲？ |
| 能力支撑 | 我有足够的工具和上下文来做好工作吗？ |
不需要精确打分，只需要识别出哪个维度问题最集中，优先修那里。
第二层：设计——把协作规则变成可运行的机制
产品不靠”让用户应该这样做”来解决问题，而是设计流程让对的行为自然发生。团队也一样。
原则：每个协作问题，对应一个具体机制
不说”我们要多沟通”——这是意图，不是设计。
| 问题 | 设计成机制 |
|---|---|
| 信息不同步 | 每天一条异步进度更新，固定格式，固定位置 |
| 决策拖延 | 超过两天没有决定的问题，自动升级到有权拍板的人 |
| 知识不传递 | 每次提交说明必须包含”为什么这样改”，不只是”改了什么” |
| AI 使用不稳定 | 站会新增一项：昨天用 AI 做了什么，遇到什么失败 |
每个机制要简单到可以执行，不依赖个人自律。
机制要有人负责
产品功能有 owner，团队机制也需要。没有人负责的机制会自然退化。指定一个人定期检查：这个机制还在用吗？有没有需要调整的地方？
第三层：衡量和迭代——像迭代产品一样迭代团队
产品靠数据判断方向对不对。团队也需要可以追踪的指标，否则改进只是凭感觉。
三个核心健康指标
| 指标 | 衡量方式 | 健康信号 |
|---|---|---|
| 新人上手时间 | 新成员独立处理中等复杂任务需要多久 | 两周内能独立判断常见情况 |
| 决策速度 | 一个需要多人参与的决策平均等待几天 | 不超过两天有结论 |
| 知识可传递性 | 任意一个模块，非原作者能否在不问人的情况下读懂并修改 | 可以，且不需要解释背景 |
这三个指标不需要专门测量系统，日常就能感受到趋势。季度复盘时明确说出来，而不是”感觉最近还不错”。
迭代节奏
每个 Sprint 结束做一次简短的团队回顾，只问三件事：
– 这两周什么机制运转良好，继续？
– 什么卡住了，要改？
– 有没有新问题需要新机制？
把结论记录下来，下次回顾时检查上次改动是否生效。这就是团队产品的迭代循环。
判断设计做没做到位
一个检验标准：你离开两周，团队能正常运转并做出正确决策吗？
- 不行，什么都要等你——机制没建立，团队还是人依赖
- 基本可以，但遇到边界情况会卡住——机制覆盖了常见场景，需要继续完善
- 可以，而且会把遇到的新情况记录下来等你回来讨论——机制成熟，团队有自我修正能力
“你在场时运转良好”不是成功。你不在场时依然运转良好，才是把团队设计做对了。