你可能不需要问题追踪器

如果你在你的初创公司使用问题追踪器，你可能需要考虑放弃它，改用简单的文本。

作为工程师，你唯一应该关心的是交付。任何阻碍你的东西都需要从工作流中消除。这听起来可能有些疯狂，但在我在 @framer 的团队中，我们的项目不使用任何问题追踪器。相反，我们写 Slack 线程和 Notion 文档。

无追踪器的工作流

构建新功能时的工作流：

每个新细节都作为评论添加到 RFC 中、PR 描述中，或相关 Slack 频道的摘要中。只是文本形式的上下文。任何需要了解提案或实现信息的人都可以直接找到来源。

加入 LLM 后，你可以将你选择的 AI 指向这些来源，问"X 是如何工作的？"，并获得带引用的摘要。

这有效的原因归结于一件事：上下文。

不仅因为它让你的 AI 更聪明，还因为组织内复利的知识帮助你以及后来必须与你的代码交互的每个人。最终，你的文档是你最大的资产。它本身可以帮助你规划、维护、支持并在几个月前你或别人交付的功能之上构建。

这也归结于你作为产品工程师拥有交付过程。你得到一个简报，但大部分设计、研究和执行都落在你的肩上。写作是让团队其他成员了解循环的方式。如果你被分配到一个项目，你可能已经知道如何接近它或知道如何弄清楚，并且可以在正确的渠道中提供上下文，而无需维护问题看板。

这不是说我们零项目管理。我们只是保持尽可能轻量：一个共享的 Notion 文档（或 Slack 画布），每个新功能或 bug 都是一个链接回原始 Slack 线程的单一条目。当有人接手时，他们就去构建它，留下通常的 RFC、PR 描述和 Slack 更新轨迹。一旦交付，条目被删除，下一个滚动进来。

没有 ticket 维护，没有状态列，没有需要同步的额外表面。这可能看起来太简单，但对我们有效。

这引出了一个问题：在我们已经在文本中拥有的所有上下文之上，我们真的需要额外的管理层吗？

你在 PR 中写实现细节，用注释记录代码，在 Slack 中讨论权衡，在 RFC 中巩固方法。一个位于所有之上的 ticket 板只是另一个需要维护的表面，它很少告诉你底层上下文没有更好表达的东西。

特别是在 Agentic 工作流时代，将所有内容保存在文本中，通过 LLM 摘要连接项目技术层的点，速度要快得多。Ticket 板不能为你做到这一点。

半个多世纪以来，我被 conditioning 相信没有 Jira 之类的东西就无法高效交付任何东西。想象一下，当我加入 Framer 并意识到我们的团队没有项目看板时，我的难以置信。

我认识的人中很少有人真正享受 discovery、spikes、epics、stories、refinement、planning、retros 和 post-mortems 的歌舞，每两周重复一次。其中很多是仪式性的仪式。如果直接告诉我们构建什么，然后我们去研究、制作和交付，不是更容易吗？

这在某些团队中比其他团队更有效。我在 Framer 的团队很小，建立在人与人之间的信任基础上，这是其他一切的基础。我们的"请求原谅，而不是许可"方法之所以有效，是因为我们信任彼此领导自己的工作并良好地沟通。这已经是大部分工作了。

所有这一切的核心实际上不是写作。而是独立性。工程师领导自己的项目，拥有决策权，并在文本中留下纸质轨迹，而不是冗余的 ticket。当你以这种方式工作时，写作自然而来。

甚至 Linear 最近也发表了一篇名为"Issue tracking is dead"的文章，认为传统的追踪是为 handoff 模型构建的，不再适合团队的工作方式，尤其是有 Agent 参与的情况下。项目管理需要进化，而我们已经有工具来实现它。

核心原则：远离不必要的仪式，回到我们都在这里做的事情：交付。