Linear

一句话定位：它靠删功能而不是加功能来变好用——用一套固定流程换掉你团队的「每次都不一样」。

这是「一天一款产品」系列的第二篇。今天讲 Linear。

如果你用过 Jira，你会知道那种感觉：功能全到能应付任何流程，于是每个团队都要先花两周配置一遍自己的流程，配置完还得维护。需求越特殊，配置越复杂，最后没人愿意改配置，于是流程慢慢退化成「在描述里写清楚」。

Linear 走的是反方向。它的赌注是：大部分团队的流程其实是相似的，差别在于细节；而软件应该把常见流程直接做对，让人不用配置就能用。

这篇能回答什么

• Linear 到底删掉了什么？为什么删掉功能反而不让它显得简陋？
• 它的数据模型（Issue / Project / Cycle / Initiative）为什么能撑起那么多视图？
• 实时同步引擎是自己写的，这笔投入值不值？
• 什么时候该用它，什么时候老老实实上 Jira？

前置知识：了解基本的 issue 跟踪流程（issue、milestone、看板、迭代）；知道 Linear 和 Jira 属于同一类工具。

它解决什么问题

Linear 把 issue 管理拆成了三个真实存在的痛点：

第一，需求进得来，但没人认领。 客服、销售、老板、内部同事都会提需求，全丢进一个列表里就淹了。Linear 用一个叫 Triage 的收件箱解决这件事：所有新 issue 先落在这里，由一个负责人（通常是产品或工程负责人）分类、定优先级、分配给人，然后才进入正式流程。

第二，排期信息散落在各处。 issue 在哪、这轮做哪些、这个项目什么进度、这个季度方向是什么——如果这四个答案分散在四个工具里，周会就变成了同步现场。

第三，进度汇报靠人肉。 想要「这轮完成了多少、哪些延期了」，通常得手动筛一遍。

Linear 的解法是把它收敛成一条有向的数据链：

Initiative（季度方向）
  └─ Project（交付物，有明确起止）
       └─ Cycle（1～2 周的迭代）
            └─ Issue（具体任务）

每一层都继承上一层的上下文。 一个 issue 属于某个 Cycle，Cycle 属于某个 Project，Project 属于某个 Initiative。于是「这个季度有没有延期」不需要额外汇报工具，从这条链上直接算出来。

上手路径

1. 先建团队和工作流。 建 Team，定义状态流（一般三到五个状态就够），这是唯一需要认真配置的地方
2. 把项目名定成团队的共同语言。 Linear 里每个团队默认有自己的前缀（ENG、DESIGN），issue ID 天然带团队信息，跨团队沟通时不用再问「这是谁那边的」
3. 开启 Triage。 明确一个人（一个角色）负责收件箱，其他人不直接创建 issue，而是走 Triage
4. 让 Cycle 自动流转。 固定长度的迭代、到期自动关闭上一轮，节奏感是这类工具的核心价值

顺序不能反。 先建一堆项目再去配工作流，会退化成 Jira 的翻版；先把「三状态 + 两周一循环」跑顺，再往里加东西。

三个关键设计决定

一、删功能

Linear 相对同类工具明确少了很多东西：早期没有自定义字段、没有复杂的工作流嵌套、没有几十种报表。它把这些留白叫做「有意的限制」。

这条策略成立的前提是默认值足够准。它赌的是：

• 大多数团队的 issue 类型就那么几种
• 状态流越短，人越愿意更新状态
• 定制需求应该通过集成解决，而不是在核心里开洞

收益是速度。 每一个功能都要被所有团队使用才划算，一个 80% 团队用不到的功能会拖累剩下 20% 的体验。Linear 的做法是让核心保持小而准，把长尾放进集成和 API。

代价是天花板。 一旦团队的工作流真的特殊——比如需要按客户分级做审批、需要多层级资源编排——它会撞到墙，而这时迁出成本比一开始就选 Jira 高得多。

二、一个足够严的数据模型

Issue 不是孤立的条目，它同时挂在四个维度上：Team（谁负责）、Project（属于哪个交付）、Cycle（属于哪轮迭代）、Initiative（服务于哪个方向）。

这四个维度正交，组合起来就是它视图系统的全部来源：

• 「这个 Cycle 里所有未完成且属于 Project X 的 issue」——过滤
• 「这个季度所有 Delay 状态的 issue」——聚合
• 「某个人这周该做什么」——按 assignee 过滤

因为底层只有一个模型，视图就是查询，不需要为每种报表单独建表。这就是为什么它能同时给出个人视图、团队视图、项目视图而不显得笨重。

关键在于它没有给模型留太多后门。 一旦允许 issue 挂到任意多个自定义维度上，视图就会退化成一堆需要手动维护的过滤条件。

三、自己写实时同步引擎

Linear 没有用通用的 WebSocket 同步方案，也没有做「服务端推 + 客户端轮询」的折中，而是自己写了一套同步层。

对用户来说，这体现为：

• 任何一端改了数据，其他端立刻更新，不用刷新
• 离线时照样能编辑，联网后自动合并
• 打开页面的第一屏就是最新的，而不是先加载一版旧数据再替换

自己写同步的代价是持续的：协议要演进，冲突要处理，老客户端要兼容。这是那种「不做就不明显、做了就回不去」的功能——竞品很难在短期内复制，但用户一旦习惯就再也忍受不了加载转圈。

短板

• 小团队用不上。 5 人以下的公司，Linear 的大部分流程是空转，用 Trello 或 GitHub Issues 更省事
• 流程特殊的团队会撞墙。 上一节说过，这是有意的取舍，不是 bug
• 移动端是查看器不是编辑器。 移动应用适合看和批注，不适合规划
• 数据在云端。 相比本地优先的工具，导出能力和长期可访问性需要你自己确认（官方提供导出，但没有同步服务在时的可用性承诺）

替代方案

一句话评价

它没有解决「项目管理怎么做」，它解决的是「团队为什么永远在配工具」。