Linear 是一款优秀的团队项目管理工具，到现在市场占有率已经达到 10%。今天这篇文章是讲在 Linear 内部，他们的项目管理是怎么做的。
在 Linear，我们觉得写用户故事那一套有点繁琐，会拖慢节奏。我们更倾向于直接写简短、简单的问题，用通俗清晰的语言把任务描述清楚。
写问题的目的是让执行者明白要做什么，同时让团队的相关成员也能轻松理解任务的背景和内容。所以，写问题的核心就是让任务能高效、快速地完成。
#01
用户故事原本是为了更好地梳理需求，但如今却逐渐沦为一种形式主义的流程。表面上看起来合理，但实际上却消耗了大量的资源和时间。它是一种间接描述任务的方式，但往往模糊了工作的真正重点。
撰写和阅读用户故事不仅耗时，还容易让工程师陷入机械执行的模式，仅仅按照需求编码，而忽略了从产品全局角度去思考用户体验。用户故事本身复杂且难以界定范围，其中一个关键问题在于，它试图把本该属于产品层面的细节强行纳入任务层面，这与我们在实际工作中讨论软件的方式并不相符。
#02
每个问题都应该描述一项具体的任务，并明确结果。这可能涉及代码开发、设计优化、文档撰写或其他具体操作。如果它不是一个实际可执行的任务，就不应出现在问题跟踪系统中。或许它只是一个需要进一步讨论的想法，或者是一个较大的功能，需要拆解为更小、更具体的可交付工作。
当然，也有例外。比如，在开发某个功能之前，可能需要先摸索设计方案或技术路径。在这种情况下，可以先创建一个占位问题（例如，探索设计），后续再细化，或者将其定义为一个具体的交付项（例如，编写项目规范）。
清晰直接地写
任务标题要简洁明了，方便大家在任务列表或看板上快速浏览和理解。任务描述可以视情况而定，不是必须的，但如果有背景信息、思考要点或者相关链接，也可以补充进去。关键是要确保信息足够清晰，让团队成员能够顺利执行任务，同时把握住核心要点。
在提交功能请求或 bug 报告时，建议直接引用用户的原始反馈，而不是自行总结。毕竟，客户自己的描述往往比我们转述的更真实、更准确。而且直接引用还能节省时间，避免误解。另外，如果能附上相关用户对话的链接就更好了，这样在需要更多信息时，能更快地找到源头。
自己亲自撰写问题
在团队协作中，建议每位成员都参与撰写问题描述。由熟悉任务细节的人来编写问题，不仅能提高效率，还能确保团队成员对任务的理解更加准确，从而更顺畅地推进执行。
此外，亲自撰写问题描述的过程本身也是一种深度思考，有助于发现更优的解决方案，识别潜在的优化点或遗漏之处。这种做法还能潜移默化地改变成员对工作的态度，使其从单纯完成任务转变为专注于产品或项目的最终交付。
当然，在某些特定场景下，例如提交 bug 报告时，由他人代为撰写问题描述可能更为合理。这种做法应被鼓励，但需注意方式方法 —— 撰写时应聚焦于问题本身，而非直接提供解决方案。将问题视为一种需求描述，让执行者自行提出解决方案，并在此基础上将问题转化为具体任务。
在产品层面讨论用户体验
在制定项目规划和构建产品路线图时，应将用户体验作为重点在产品层面进行充分讨论。在此过程中，需组织包括设计师、工程师以及面向客户的团队成员在内的全体人员参与。
通过跨部门的深入交流，确保团队成员能够全面理解用户需求、技术限制以及产品要求。在此基础上，将任务分配给项目团队，并明确交付目标。这样一来，团队成员对用户体验的理解将更加直观，从而在任务执行阶段无需再进行额外说明。
#03
（文：AI大模型实验室）