上周 @Anonymous 介绍了 Linear 创始人 Karri Saarinen 关于今日软件缘何丧失了「魔力」的文章。有趣的是，在月初的时候，flomo 团队也从 Tower & Notion 上迁移到了 Linear。原因是今年团队计划扩张，加上都是远程工作，所以「生产工具的系统」也需要跟着升级，Linear 就这样进入到了视线里面来。
这篇文章主要谈两个方面，一方面是作为 Linear 的使用者来思考其产品设计的独特之处；另一方面是 Linear 有一套称之为 Linear Method 的方法，和 flomo101 一样，即使你不用他们家的工具，这套方法论也会很有启发。
01从一个 issue 构建整套系统
最初选择用 tower 纯粹是多年前的习惯使然，最核心的其实是用看板来处理任务协作。和许多看板类工具一样，一旦任务多了之后，就会被海量细节淹没，沉浸在事务性的工作中，而丧失了长期的视角。
后续 Lightory 我们俩就在 Notion 中开了一个新的看板，用来将近期的最重要的里程碑事情罗列出来，每周确保这个看板上的项目能被推进掉，而 Tower 上则是这些项目执行的具体子任务。
但依旧会产生问题：跨系统的割裂性格很强；宏观微观之间切换很麻烦。后续在寻找替代系统的时候，Lightory 提炼出来关于协作工具的两个诉求：
- 使用方便，不要反而降低工作效率；
- 灵活视角，固定的 view 足够主流覆盖大多场景，custom view 足够方便 DIY。
Linear 在第一部分虽然有加分，但是核心是第二部分 —— Alan Kay 说过，好的视角能值 80 分的 IQ。
Linear 其设计思路和之前分析过的 Figma 相关 很像，将老的竞争对手核心对象拆解为更原子化的对象（如 Photoshop 的 PSD 是以图层为最小单位，而 Figma 则是以元件为最小单位），来重新获得竞争优势，这样的好处是：
- 没有那么大的历史负担，只专注于其中一小部分（figma 主要是偏 UI/UX 设计，Linear 主要是偏 issue 管理）
- 通过解构，可以将处理的对象拆为更小单元，降低了创建对象的难度，也提高了组合对象的灵活性（Linear 的issue可以构成 Project 和 Milestone，也可以独立存在；而传统的项目管理工具，总让你每个任务都属于一个项目）
- 通过不同的对原子化对象的筛选和不同的呈现方式，可以用更多维度的视图来对对象进行 Zoom in 或者 Zoom out 的观察。（figma 中可以从元件的维度来看项目的构成，也可以从色彩的维度来看）
所以基于 issue 的原子性，Linear 设计了类似 Airtable 的 View 功能：通过筛选加不同的表现形式，让用户能在任务中保持宏观和微观的视角，以及基于各自不同身份创建独特视角。
- Roadmap 是宏观视图，能看到对应 Milestone 下的 Project 是什么，继而进入到对应 Project 的 issue 看板。
- My issues 是微观视图，能看到自己创建/被指派的任务列表
- 最重要的还有第三个 Views 自定义视图，就像 Airtable 中的 View 一样，你可以根据任意条件对 issue 进行筛选，然后创建出来属于你的视图，还可以共享。下图 flomo - All 就是指 flomo 的所有 issue，而最近完成则是从issue 关闭时间维度进行排序，不仅有 flomo 中的issue，还有公司运营等其他项目的 issue，并且 Lightory 将其共享给了公司内部。
通过系统默认的宏观（Roadmap）/ 微观（My issue） View ，加上自定义的 View，既能满足我们对大方向的把控，又能深入到某个细节来看当前的任务是什么，而自定义的 view 则能让每个人从不同的视角来看待现在的进展，确保了能从各个角度来看这台「设计工具的系统」运转如何。
这种「解构上一代工具的处理对象」的产品设计思路在这些年逐渐变多，Figma/Notion/Airtable/Linear 等，也许在 Web3 到来之前，许多古典产品或许都还有重构的机会，从这个角度来看，互联网产品的未来并不是一片灰暗，只不过需要打破之前多年积攒下来的惯性思维。
不过和 Lightory 的讨论过程中也有一个有趣的洞察，并不是原子化 + View 就能包打一切，还是要回归到具体的用户情境去。View 是一种「相对稳定」的设计思路，这和产品所在的情境是高度相关的，比如在 Linear 因为大家的角色和项目不会天天换，所以需要这种稳定的视角；而在 flomo 中，虽然每个 MEMO 足够小，但大多数场景都是临时的，流动的，所以与其做出固定的视图，倒不如让搜索更简单一些，随用随取；又或者仅仅提供一个临时的 View，用来存放当下想要挑选出来的 MEMO 即可（类似微信浮窗），并不需要长期保存，也不需要花里胡哨的表现形式。
Linear 还有许多有意思的设计细节，有兴趣的可以看他们的 Blog 文章，在这里先不做展开。
02Linear Method
和 flomo 101 很像，Linear 也有很强烈的观点，这部分翻译的是来自他们官网的 Linear Method 中的原则与实践部分，即使你不用 Linear ，也会对日常项目协作有所启发。
2.1 原则部分
为创作者构建：软件项目管理工具在构建时应考虑到最终用户（创建者）。保持个人生产力比生成完美的报告更重要。
固执己见的软件：生产力软件应该固执己见。这是产品真正为您完成繁重工作的唯一途径。灵活的软件让每个人都能发明自己的工作流程，这最终会随着团队的扩展而造成混乱。
创造动力 – 不要冲刺：我们应该找到工作的节奏和规律。在周期中，我们决定优先事项并分配任务。我们的目标是与我们的团队保持健康的势头，而不是急于求成。
有意义的方向：我们的日常工作可能充满了任务，但我们应该理解并提醒我们的团队我们工作的目的和长期目标。路线图、项目和里程碑都很重要，在我们计划每周时间表时要牢记在心。
以清晰为目标：如果可能的话，不要创造术语，因为这些术语可能会在不同的团队中混淆并具有不同的含义。项目应该称为项目。
对繁忙的工作说不：我们的工具不应该让我们成为它们的设计者和维护者。我们应该抛弃繁忙的工作或者自动化工作，这样你才能专注于更重要的工作。
先简单，后功能强大：不同规模的团队有不同的需求。工具应该易于上手，并随着时间的推移变得越来越强大。
决定并继续前进：并不总是有最好的答案。重要的是要做出决定，然后继续前进。
2.2 实践部分
设置月度、季度或/和年度路线图：雄心勃勃的目标是产生重大影响的唯一途径。公司在定义高层次方向时应该关注它们。在路线图上保留一些空间，以备不时之需，并在需要时更改路线图。
通过项目将日常工作与更大的目标联系起来：所有项目和工作都应与这些目标直接相关。在路线图会议期间查看项目及其目标日期，并在计划周期时从项目中提取。
以 n 周为周期工作：周期创造了健康的日常生活，并让团队专注于接下来需要发生的事情。两周的周期是软件构建中最常见的。它们足够短，不会忽略其他优先级，但也足够长，可以构建重要的功能。周期应该是合理的，不要用任务使周期过载，并让未完成的项目自动移动到下一个周期。
保持可管理的积压工作：您无需保存每个功能请求或反馈。重要的问题将重新浮出水面，而低优先级问题将永远无法修复。更有针对性的待办事项列表使得计划周期更加容易和快速，并确保工作真正得以完成。
混合功能和质量工作：所有的软件都有漏洞，我们无法修复所有。将 bug 和其他修复作为你的周期的一部分。投资工具，如果做得对的话，它就会成为一个力量倍增器。
指定项目和问题所有者：每个项目都应该有一个指定的所有者负责自己的交付并撰写项目简介。问题也是如此。其他人应该合作，但责任应该由一个人承担。
编写项目规范：以简洁为目标。较短的规格更有可能被阅读。规范的目的是向团队的其他成员简要传达项目的"为什么"，"什么"和"如何"。理想情况下，这些简短的文档迫使团队确定工作范围，以便明确优先级，并且团队避免构建错误的东西。
了解您的用户：你的产品越受欢迎，你得到的反馈就越多。反馈变多是一个好的标志，除非它们都是 bug。不要太担心组织所有的反馈。收集它，并在开发新功能时将其用作研究库。试着发现趋势。利用反馈，甚至是抱怨，作为一个了解你的用户的机会，让他们解释为什么他们需要一个特定的功能，这样你就可以了解他们的需求。解决问题——不要只是构建特性。
范围问题应尽可能小：在处理大型任务时，很难看到明显的进度，这可能会令人沮丧。将工作分解为较小的部分，并在可能的情况下为每个部分创建一个问题。理想情况下，您每周可以完成几项具体任务。将问题标记为已完成感觉很棒。
通过实际工时衡量进度：查看某些内容是否完整的最清晰方法是在代码或设计文件中显示差异。当任务范围较小时，您的更改将很小，也更易于查看。避免大规模的拉取请求或大型设计更改。
运行跨职能团队：设计师和工程师应该在项目上一起工作，创造一种自然的推动力。设计师将他们的技能用于探索想法并推动团队的思维。工程师可以挑战围绕实施的思维，并将成功的想法变为现实。最好的创作者往往对这两者都有天赋。在构建其他团队将使用的功能或要求与他们交互的客户使用时，直接循环其他团队。
编写更新日志：回顾并庆祝您作为一个团队所取得的成就非常重要。一致的更改日志还向用户传达新功能、他们从产品中获得的价值以及您对改进产品的承诺。这也是将团队的个人工作与他们创造的集体价值联系起来的简单方法。阅读更多关于我们如何编写我们的。
推荐阅读：