> For the complete documentation index, see [llms.txt](https://zhouhao4221.gitbook.io/haiqing-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhouhao4221.gitbook.io/haiqing-docs/06-team/team-design-practice.md).

# 把团队当产品来设计：三个操作层次

> 思维模型见 [team-as-product.md](/haiqing-docs/01-thinking/team-as-product.md)

***

## 第一层：诊断——找到真实的摩擦点

产品诊断的第一步不是设计方案，是找到用户真正卡在哪里。团队诊断也一样。

**做法：定期一对一，换一套问题**

不问"工作进展怎么样"，问：

* 最近什么事情让你觉得卡住了？
* 有没有什么事情你觉得本不该这么麻烦？
* 如果你来改一件事，你会改什么？

这三个问题问出来的是**系统性摩擦**，而不是个人情绪。把答案归类，同一类问题反复出现，就是系统需要修的地方。

**团队层面的扫描**

每季度做一次匿名问卷，四个维度：

| 维度   | 核心问题               |
| ---- | ------------------ |
| 信息流转 | 我需要的信息能及时拿到吗？      |
| 决策速度 | 遇到需要判断的事情，等待时间合理吗？ |
| 协作摩擦 | 和其他人配合时，哪个环节最费劲？   |
| 能力支撑 | 我有足够的工具和上下文来做好工作吗？ |

不需要精确打分，只需要识别出哪个维度问题最集中，优先修那里。

***

## 第二层：设计——把协作规则变成可运行的机制

产品不靠"让用户应该这样做"来解决问题，而是**设计流程让对的行为自然发生**。团队也一样。

**原则：每个协作问题，对应一个具体机制**

不说"我们要多沟通"——这是意图，不是设计。

| 问题       | 设计成机制                        |
| -------- | ---------------------------- |
| 信息不同步    | 每天一条异步进度更新，固定格式，固定位置         |
| 决策拖延     | 超过两天没有决定的问题，自动升级到有权拍板的人      |
| 知识不传递    | 每次提交说明必须包含"为什么这样改"，不只是"改了什么" |
| AI 使用不稳定 | 站会新增一项：昨天用 AI 做了什么，遇到什么失败    |

每个机制要简单到可以执行，不依赖个人自律。

**机制要有人负责**

产品功能有 owner，团队机制也需要。没有人负责的机制会自然退化。指定一个人定期检查：这个机制还在用吗？有没有需要调整的地方？

***

## 第三层：衡量和迭代——像迭代产品一样迭代团队

产品靠数据判断方向对不对。团队也需要可以追踪的指标，否则改进只是凭感觉。

**三个核心健康指标**

| 指标     | 衡量方式                       | 健康信号         |
| ------ | -------------------------- | ------------ |
| 新人上手时间 | 新成员独立处理中等复杂任务需要多久          | 两周内能独立判断常见情况 |
| 决策速度   | 一个需要多人参与的决策平均等待几天          | 不超过两天有结论     |
| 知识可传递性 | 任意一个模块，非原作者能否在不问人的情况下读懂并修改 | 可以，且不需要解释背景  |

这三个指标不需要专门测量系统，日常就能感受到趋势。季度复盘时明确说出来，而不是"感觉最近还不错"。

**迭代节奏**

每个 Sprint 结束做一次简短的团队回顾，只问三件事：

* 这两周什么机制运转良好，继续？
* 什么卡住了，要改？
* 有没有新问题需要新机制？

把结论记录下来，下次回顾时检查上次改动是否生效。这就是团队产品的迭代循环。

***

## 判断设计做没做到位

一个检验标准：**你离开两周，团队能正常运转并做出正确决策吗？**

* 不行，什么都要等你——机制没建立，团队还是人依赖
* 基本可以，但遇到边界情况会卡住——机制覆盖了常见场景，需要继续完善
* 可以，而且会把遇到的新情况记录下来等你回来讨论——机制成熟，团队有自我修正能力

"你在场时运转良好"不是成功。**你不在场时依然运转良好**，才是把团队设计做对了。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://zhouhao4221.gitbook.io/haiqing-docs/06-team/team-design-practice.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.