项目管理工具指南

Jira/Linear/飞书、看板设计——工具是手段，流程才是目的

一、工具不是越强大越好——是越少越好

你待过的团队的标配：
  Jira（任务）+ Confluence（文档）+ Slack（聊天）
  + 飞书（另一个聊天）+ GitHub（代码）+ Figma（设计）
  + 腾讯文档（又一份文档）+ Excel（排期表）+ 邮件（没人在看）
  → 信息散落在 8 个地方。"这个需求的最新描述在哪？"——没人知道。

工具越多，信息越碎。信息越碎，隐性成本越高。 一个人每天花 30 分钟在 8 个工具之间找信息——10 人团队就是 5 人·小时/天。

工具选型的最低要求

一个团队最少只需要 3 个工具：

1. 任务管理   → 看板。谁在做什么、什么状态、什么时候做完
2. 文档中心   → wiki/知识库。所有决策、方案、记录的唯一存放地
3. 即时沟通   → 聊天 + 音视频。不在聊天记录里找重要决策

---

二、看板——不是贴满标签就算在看板了

2.1 看板的正确结构

❌ 过简的看板：
  Todo → Doing → Done
  问题：看不出任务卡在哪一步。所有东西都在 Doing 里。

✅ 反映真实流程的看板：
  Backlog → 待开发 → 开发中 → Code Review → 测试中 → 待发布 → 已发布
              ↑                                  ↑
         开发瓶颈                          测试瓶颈

看板的列应该匹配你的交付流程。 看一遍从"接需求"到"用户用上"走过了哪些阶段——每一阶段就是一个列。

2.2 WIP 限制——看板最被忽略的功能

没有 WIP 限制的看板：
  开发中：12 个任务 → 每个都是"本周能做完"
  测试中：0 个        → 测试同事在等开发做完
  → Sprint 结束：开发中 12 个没有一个完成到可发布状态

有 WIP 限制的看板：
  开发中（WIP=3）：3 个任务
  Code Review（WIP=2）：2 个任务
  测试中（WIP=2）：2 个任务
  → 开发必须做完并提测，才能从 Backlog 拉新任务
  → 不让"开始做"的速度超过"做完"的速度

WIP 限制是在强制你完成，而不是开始。

2.3 看板上的卡——写什么

每一张卡的标题能独立回答："这是什么事？"

❌ 模糊的标题：
  "用户模块优化"
  "修复bug"
  "性能优化"
  → 一周后没人记得这是要干嘛

✅ 清晰的标题：
  "[用户] 手机号注册支持国际号码 +86 以外的区号"
  "[支付] 修复订单取消后优惠券未退回的bug"
  "[性能] 商品搜索接口 P99 < 500ms"
  → 谁看都明白，不需要点进去看描述

---

三、工具推荐——按团队规模选

工具	适合	不适合	一句话评价
Linear	10-50 人工程团队	非技术人员主导的团队	界面最清爽，工程师幸福感最高的项目管理工具
Jira	50+ 人或强流程团队	小团队（太重了）	最强大也最复杂——90% 的功能你用不上
Trello	5 人以下小团队	需要 Sprint 管理	最简单的看板，但缺少 Sprint/Velocity
飞书多维表格	什么都想要但不想搞太重	复杂的工程管理	中国版 Notion 数据库，够用但不专业
GitHub Projects	代码仓和项目紧密绑定	非技术人员参与多的项目	PR 和任务天然关联，但非技术人员用不惯

Linear 是当前最推荐的工程团队工具——不是因为功能多，是因为它把工程师日常要做的事（建 issue、排优先级、追踪状态、看 View）做到尽可能少地打断你的思路。

---

四、工具的反模式

4.1 Jira 变成了"电子监狱"

你的 Jira 是不是这样的：
  - 每个 story 有 20 个必填字段
  - 状态从 Todo 到 Done 中间有 8 个状态
  - 每个 transition 都需要特定角色审批
  - 你花了 10 分钟建一个 task，又花了 5 分钟把状态改对

→ 恭喜，你不是在用 Jira 管理项目——是 Jira 在用你的时间填字段。

解决：只保留 4-5 个字段（标题、指派人、状态、优先级、Sprint），
      状态流不超过 5 个步骤。

4.2 在聊天工具里做决策

Slack 里：
  "我们数据库连接池从 50 改到 100 吧？" → "行" → 改了
  三个月后——没人记得为什么是 100，也没有文档记录。

聊天工具的消息是流动的——重要的决策必须落地到文档/wiki。
流程：在聊天里讨论 → 把结论写到 wiki → 关联到对应的 Jira/Linear task。

---

五、看板自动化——让工具替你做事

5.1 最值得设置的自动化规则

规则	效果
PR 创建 → 自动移动到 "Review" 列	不用人手拖卡
PR 合入 → 自动移动到 "Done" 列 + 关闭 issue	卡永远反映真实状态
卡在 "In Progress" > 3 天 → 自动 @ 负责人	暴露阻塞
卡移动到 "Done" → 自动通知 PM 验收	缩短验收等待

5.2 度量面板——三张图就够了

① 累积流图（Cumulative Flow Diagram）
   → 一张图看团队瓶颈：In Progress 在变宽 → WIP 过高

② 周期时间分布（Cycle Time Histogram）
   → 从开始到完成，多大比例的卡在 N 天内
   → 目标：85% 的卡在 5 天内完成

③ 吞吐量趋势（Throughput）
   → 每周完成多少张卡
   → 不是考核——是预测"下一迭代能完成多少"的基准

六、工具迁移——什么时候该换

信号	说明
你在工具上花的时间比在代码上多	工具反客为主
团队绕过工具沟通	工具体现不了真实流程
工具缺少关键信息	比如看不到跨项目依赖

迁移原则：不要"先导数据再切换"——数据迁移是最耗时的部分。新的从今天开始用，旧的只读保留 6 个月。

七、小结

工具选型三原则：
1. 先定流程，再选工具
2. 用最少的工具——3 个就够了
3. WIP 限制 > 更多的列——看板核心在"限制并行"
4. 三张图看透团队——累积流图 + 周期时间 + 吞吐量
5. 工具替你做事——自动化规则减少人为操作

行动清单：

• [ ] 数一下团队在用几个工具——能合并掉 1-2 个？
• [ ] 打开看板，看 "开发中" 有多少张卡——设置 WIP 限制
• [ ] 读一遍最近 10 个 issue 的标题——不用描述，能知道是什么吗？
• [ ] 设置一条自动化规则——PR 合入自动关 issue，最简单的开始