---

您即将获得关于 Blue 如何构建 Blue 的内部参观。

在 Blue，我们吃自己的狗粮。

这意味着我们使用 Blue 来 构建 Blue。

这个听起来奇怪的术语，通常被称为“狗粮”，常常归因于 1980 年代微软的一位经理 Paul Maritz。他据说曾发送一封主题为 “吃自己的狗粮” 的电子邮件，以鼓励微软员工使用公司的产品。

使用自己的工具来构建工具的想法是，它会导致积极的反馈循环。

使用自己的工具来构建工具的想法会导致积极的反馈循环，创造出许多好处：

• 它帮助我们快速识别现实世界中的可用性问题。 由于我们每天使用 Blue，我们会遇到用户可能面临的相同挑战，从而使我们能够主动解决这些问题。
• 它加速了错误发现。 内部使用通常会在错误到达客户之前揭示它们，从而提高整体产品质量。
• 它增强了我们对最终用户的同理心。 我们的团队获得了对 Blue 的优缺点的第一手经验，帮助我们做出更以用户为中心的决策。
• 它推动了我们组织内的质量文化。 当每个人都使用该产品时，大家对其卓越性有共同的利益。
• 它促进了创新。 定期使用通常会激发新功能或改进的想法，使 Blue 保持在前沿。

我们之前谈到过为什么我们没有专门的测试团队，这又是一个原因。

如果我们的系统中有错误，我们几乎总是在对平台的持续日常使用中发现它们。这也创造了一个强制性因素来修复它们，因为我们显然会觉得它们非常烦人，因为我们可能是 Blue 的顶级用户之一！

这种方法展示了我们对产品的承诺。通过依靠 Blue，我们向客户展示了我们真正相信我们正在构建的东西。这不仅仅是我们销售的产品——它是我们每天依赖的工具。

主要流程

我们在 Blue 中有一个项目，恰当地命名为“产品”。

与我们产品开发相关的所有内容 都在这里跟踪。客户反馈、错误、功能想法、正在进行的工作等等。将所有内容跟踪在一个项目中的想法是 促进更好的团队合作。

每个记录都是一个功能或功能的一部分。这就是我们如何从“如果...那就太酷了”转变为“看看这个令人惊叹的新功能！”。

该项目具有以下列表：

• 想法/反馈：这是一个团队想法或基于电话或电子邮件交流的客户反馈列表。欢迎在这里添加任何想法！在这个列表中，我们尚未决定是否会构建这些功能，但我们会定期审查以寻找我们想进一步探索的想法。
• 待办事项（长期）：如果我们决定某些功能将是 Blue 的良好补充，则这些功能将从想法/反馈列表中转移到这里。
• {当前季度}：这通常以“Qx YYYY”的形式构建，显示我们的季度优先事项。
• 错误：这是团队或客户报告的已知错误列表。添加到这里的错误将自动添加“错误”标签。
• 规格：这些功能目前正在制定规格。并非每个功能都需要规格或设计；这取决于功能的预期大小以及我们对边缘情况和复杂性的信心水平。
• 设计待办事项：这是设计师的待办事项，每当他们完成正在进行的工作时，他们可以从这个列表中选择任何项目。
• 进行中的设计：这是设计师正在设计的当前功能。
• 设计审查：这是功能设计目前正在审查的地方。
• 待办事项（短期）：这是我们可能在接下来的几周内开始工作的功能列表。这是分配的地方。首席执行官和工程主管根据之前的经验和工作量决定将哪些功能分配给哪个工程师。团队成员可以在完成当前工作后将这些功能拉入进行中。
• 进行中：这些是当前正在开发的功能。
• 代码审查：一旦功能开发完成，它将进行代码审查。然后，如果需要调整，它将被移回“进行中”，或者部署到开发环境。
• 开发：这些是当前在开发环境中的所有功能。其他团队成员和某些客户可以对此进行审查。
• 测试版：这些是当前在 测试环境 中的所有功能。许多客户将其作为他们的日常 Blue 平台，并将提供反馈。
• 生产：当功能达到生产阶段时，它就被视为完成。

有时，在我们开发一个功能时，我们意识到某些子功能的实现比最初预期的要困难，我们可能选择不在我们部署给客户的初始版本中实现它们。在这种情况下，我们可以创建一个新记录，名称遵循格式“{功能名称} V2”，并将所有子功能作为检查项包含在内。

标签

• 移动：这意味着该功能特定于我们的 iOS、Android 或 iPad 应用程序。
• {企业客户名称}：该功能是专门为企业客户构建的。跟踪很重要，因为通常每个功能都有额外的商业协议。
• 错误：这意味着这是一个需要修复的错误。
• 快速通道：这意味着这是一个快速通道更改，不必经过上述完整的发布周期。
• 主要：这是一个主要功能开发。通常保留给主要基础设施工作、大型依赖升级和 Blue 内的重要新模块。
• 人工智能：该功能包含人工智能组件。
• 安全：这意味着必须审查安全隐患或需要补丁。

快速通道标签特别有趣。这是保留给较小、复杂性较低的更新，不需要我们的完整发布周期，并且我们希望在 24-48 小时内将其交付给客户。

快速通道更改通常是小的调整，可以显著改善用户体验，而不会改变核心功能。想想在 UI 中修复拼写错误、调整按钮填充或添加新图标以提供更好的视觉指导。这些都是小的更改，但可以在用户感知和与我们产品的互动中产生重大影响。如果它们需要很长时间才能发布，那就很烦人了！

我们的快速通道流程是简单明了的。

它从从主分支创建一个新分支开始，实施更改，然后为每个目标分支（开发、测试版和生产）创建合并请求。我们生成一个预览链接以供审查，确保即使是这些小更改也符合我们的质量标准。一旦获得批准，更改将同时合并到所有分支中，保持我们的环境同步。

自定义字段

我们在产品项目中没有很多自定义字段。

• 规格：这链接到具有特定功能规格的 Blue 文档。这并不总是完成，因为这取决于功能的复杂性。
• 合并请求：这是我们托管代码的 Gitlab 中的合并请求链接。
• 预览链接：对于主要更改前端的功能，我们可以为每个提交创建一个唯一的 URL，以便我们可以轻松审查更改。
• 负责人：该字段告诉我们哪个高级工程师负责代码审查。它确保每个功能都能获得应有的专家关注，并且总有一个明确的联系人来解答问题或关注事项。

检查清单

在我们的每周演示中，我们会将讨论的反馈放入一个名为“反馈”的检查清单中，还有另一个检查清单包含该功能的主要 WBS（工作分解结构），以便我们可以轻松了解已完成的内容和尚未完成的内容。

结论

就这样！

我们认为，有时人们会对我们的流程是多么简单感到惊讶，但我们相信简单的流程往往远远优于那些难以理解的过于复杂的流程。

这种简单性是有意为之。它使我们能够保持敏捷，快速响应客户需求，并保持整个团队的协调。

通过使用 Blue 来构建 Blue，我们不仅仅是在开发一个产品——我们是在生活它。

所以下次您使用 Blue 时，请记住：您不仅仅是在使用我们构建的产品。您正在使用一个我们每天都依赖的产品。

这才是最重要的。