我一直喜欢网络的一件事就是它的即时性。你写了一段代码，把它发布到某个地方，人们就可以访问它。没有编译步骤，没有打包和分发，没有在市场或应用程序商店上架——只需按一下按钮。
这给人一种错误的印象，认为这种工作方式应该扩展到产品和大公司。通常感觉快速而灵活的初创公司可以“快速且经常失败”是那些做得正确的公司，而相比之下，规模更大、历史更悠久的公司感觉就像行动缓慢的恐龙。当您查看已发布产品的成熟度时，它会变得很有趣。 “预览版”或永久“测试版”中的产品可以快速周转，而完整版需要做的不仅仅是提供功能。
主要区别在于大公司的完整版本发布需要考虑合规性。内部质量合规性，以及——在更大程度上——外部法律合规性。当我开始在 Microsoft 工作并从开发人员转变为产品经理时，我意识到在我们发布产品之前需要做很多工作和努力。
- 安全性——产品是否免受攻击？
- 表现
- 产品运行是否快速流畅？
- 它对可能的父产品（浏览器、操作系统……）的整体字节大小和速度有多大影响？
- 可维护性
- 该产品是否依赖于将来可能不可用或存在许可问题的第三方代码？
- 该产品是否需要在不久的将来可能不受支持的平台或语言？
- 隐私
- 产品是否记录了可以识别用户身份的信息？
- 信息去哪儿了？
- 您是否正在使用也可以获得该信息的第三方软件包？
- 遵守
- 用户是否知道他们的信息正在被记录？
- 信息只保留很短的时间还是长期的？
- 人们可以选择退出吗？
- 该产品是否在不同市场以不同语言提供？
- 产品是否符合当地法规？
- 所有人都可以使用该产品吗？
其中每一个都有一个你需要经历的过程，这取决于公司的专家部门、审查周期和需要修复的错误报告。因此，虽然您的产品可能已经可用，但这通常至少会增加几周的发布时间。更糟糕的是，产品的每一次改变都会重新开始这个循环。
令人沮丧，是的——但非常重要
看到一个代码完整的产品从一个 sprint 移动到另一个 sprint 是非常令人沮丧的，因为审阅者不在，或者是一个问题但无法修复的错误是令人沮丧的。我不得不处理许多只出现在第三方软件中的可访问性问题，例如 Mac 上的 Voiceover 或 Linux 系统上的 Orca。虽然我的团队所做的一切都是正确的，但我们的产品却无法与他们合作。提交报告并没有太大的区别，所以我们经常不得不让产品的功能选择加入，默认情况下它是关闭的，以解决这些问题。
这让所有相关人员都感到沮丧，因为其中一些功能是一种差异化因素，可能会带来大量新用户。但随着它成为一种选择加入，这已经是一种不会让很多用户使用此功能的万无一失的方法。
但事实仍然是，我们作为软件开发人员所做的一切都会对最终用户产生直接影响。不涵盖所有边缘情况可能是我们的捷径，但这可能意味着我们的产品可能会泄露用户的信息，从而导致他们的身份被盗。
我们可以阻止用户，因为我们认为不会使用鼠标的任何人都不会使用我们的产品。我花了很多时间为屏幕阅读器制作一个颜色选择器工具。这感觉没有必要，但重点是并非每个屏幕阅读器用户都无法看到。通过使其更易于使用并添加更多标签，该工具对所有用户来说变得更加方便。
最后，重要的是最终用户体验。虽然快速迭代和尝试许多很酷的新方式来与信息交互是令人兴奋的，但这可能意味着我们将许多潜在用户拒之门外，他们无法更改他们的设置，或者——更糟的是——他们的身体可以做什么。虽然像GDPR这样的一些法律要求感觉有些矫枉过正，但它们可能是我们反思我们需要从用户那里获得多少信息以及我们如何处理这些信息的好方法。
我们怎样才能走得更快？
合规性的伟大之处在于它是可预测的。我们将不得不在大公司和某些出版领域这样做。因此，我们不妨尽快为它做好计划——即使是在项目的设计和规划阶段。例如，关于可访问性的最大非新闻是，越早处理它，您要做的工作就越少。使现有产品易于访问是通过辅助技术支持、跨平台问题和框架支持来打地鼠游戏。从一开始就根据需要对其进行规划，或者使用已经过测试的可访问组件意味着合规性可能只需要几个小时，而不是几周。
我们记录并希望保留的数据也是如此。我们并不经常想出一些全新的东西——通常我们只是在现有产品上添加一个功能。所以问题是是否真的有必要向每个界面元素添加遥测，或者可能深入研究我们已经从父产品中获得的东西。
我将在另一篇文章中深入探讨这一点，因为有一些方法可以满足合规性需求并且仍然可以快速行动。但就目前而言，重要的是要记住，大公司的开发人员并不比野外的开发人员更慢或更少开启。他们需要关心的不仅仅是编写代码。这对我来说是一件好事，因为我们写的东西可以成就或破坏用户的在线体验。