了解我们的项目管理系统为何有一个持续的开放测试版。
许多 B2B SaaS 初创公司以测试版启动，这是有充分理由的。这是硅谷传统格言 “快速行动，打破常规” 的一部分。
在产品上贴上“测试版”标签可以降低期望值。
有东西坏了吗？哦，那只是测试版。
系统慢吗？哦，那只是测试版。
文档不存在？哦，好吧……你明白我的意思。
这实际上是 好事。LinkedIn 的创始人 Reid Hoffman 曾说过：
如果你对产品的第一个版本不感到尴尬，那你就发布得太晚了。
而测试版标签对客户也是有好处的。它帮助他们自我选择。
尝试测试版产品的客户通常处于技术采用生命周期的早期阶段，也称为产品采用曲线。
技术采用生命周期通常分为五个主要阶段：
- 创新者
- 早期采用者
- 早期大众
- 后期大众
- 落后者
然而，最终产品必须成熟，客户期望一个稳定、可用的产品。他们不想访问一个“测试版”环境，那里会出现问题。
或者他们想要？
这个 是我们问自己的问题。
我们相信我们之所以问自己这个问题，是因为 Blue 最初的构建方式。Blue 最初是一个繁忙设计公司的分支，因此我们在一个积极使用 Blue 来管理所有项目的公司的办公室 内部 工作。
这意味着多年来，我们能够观察到 真实 的人类——就坐在我们旁边！——在日常生活中如何使用 Blue。
而且因为他们从早期就使用 Blue，这个团队总是使用 Blue Beta！
因此，允许我们的其他客户也使用它对我们来说是自然而然的。
这就是为什么我们没有专门的测试团队。
没错。
在 Blue 没有人 单独 负责确保我们的平台运行良好且稳定。
这是出于几个原因。
第一个是成本基础较低。
没有全职测试团队显著降低了我们的成本，我们能够将这些节省转嫁给客户，以行业最低的价格提供服务。
为了让你更好地理解，我们提供的企业级功能集，竞争对手收费 $30-$55/用户/月，而我们只收取 $7/月。
这不是偶然发生的，而是 经过设计 的。
然而，如果产品不工作，销售更便宜的产品并不是一个好的策略。
所以 真正的问题是，我们如何在没有专门测试团队的情况下，成功创建一个数千个客户可以使用的稳定平台？
当然，我们的开放测试版方法对此至关重要，但在深入探讨之前，我们想谈谈开发者的责任。
我们在 Blue 早期就决定，绝不会将前端和后端技术的责任分开。我们只会雇佣或培训全栈开发者。
我们做出这个决定的原因是为了确保开发者能够完全拥有他们正在开发的功能。因此，不会出现你有时会遇到的 “把问题扔过花园围栏” 的心态，当功能有共同责任时。
这也延伸到功能的测试、理解客户用例和请求，以及阅读和评论规格。
换句话说，每个开发者都会对他们正在构建的功能建立深刻而直观的理解。
好了，现在让我们谈谈我们的开放测试版。
当我们说它是“开放的”时——我们是认真的。任何客户只需在我们的网络应用程序 URL 前添加“beta”即可尝试。
因此，“app.blue.cc”变成“beta.app.blue.cc”。
当他们这样做时，他们能够看到他们的常规数据，因为 Beta 和生产环境共享同一个数据库，但他们也能看到新功能。
即使他们的一些团队成员在生产环境中，而一些好奇的成员在 Beta 中，客户也可以轻松工作。
我们通常有几百个客户在任何时候使用 Beta，我们在我们的社区论坛上发布功能预览，以便他们查看新内容并尝试。
而这就是重点：我们有 几百个 测试者！
所有这些客户将在他们的工作流程中尝试功能，如果有什么不对，他们会非常直言，因为他们 已经 在他们的业务中实施了这个功能！
最常见的反馈是一些小但非常有用的更改，解决了我们没有考虑到的边缘案例。
我们将新功能保留在 Beta 中 2-4 周。每当我们觉得它们稳定时，我们就会发布到生产环境。
我们还可以在需要时通过快速通道标志绕过 Beta。这通常用于我们不想在发布到生产之前等待 2-4 周的错误修复。
结果是什么？
推送到生产感觉……嗯，乏味！就像没什么——对我们来说根本不是什么大事。
这意味着这平滑了我们的发布日程，这使我们能够在过去六年中 像时钟一样每月发布功能。
然而，像任何选择一样，这也有一些权衡。
客户支持稍微复杂一些，因为我们必须支持客户在我们平台的两个版本之间。有时这可能会导致使用两个不同版本的团队成员的客户感到困惑。
另一个痛点是，这种方法有时会减缓整体发布到生产的进度。对于较大的功能，如果有其他相关功能出现问题并需要进一步工作，它们可能会在 Beta 中“卡住”。
但总体而言，我们认为这些权衡是值得的，因为它带来了更低的成本基础和更高的客户参与度。
我们是少数几个接受这种方法的软件公司之一，但这现在已成为我们产品开发方法的基本部分。