开发人员异常工程

我们需要就我们所说的开发者体验（DX）在以开发者为中心的公司中展开一些真正的讨论。

虽然克里斯·科伊尔（Chris Coyier）做过一项不错的调查，了解人们听到这个词时的想法，也有其他人尝试定义开发者赋能，但它并没有一个明确的定义。开发者赋能是开发者工具之间的一个区别点，因此它正在走向专业化，并逐渐渗透到职位名称中（我之前的职位名称是“开发者体验工程师”，我也不知道它到底是什么意思）。我完全相信它会发展成为一个成熟的子行业，拥有各种会议、思想领袖、把关人等等（甚至包括“开发者倡导联合创始人”）。

“开发者体验”

以下是企业在“开展数字化转型”时通常会关注的一些方面：

• 以少胜多：用少量代码替换大量代码；用一个徽标替换多个徽标；用一次点击（注册、部署）替换多个步骤。自动生成代码，无需手动编写。作为第一方产品，开箱即用，无需任何配置，即可提供强大的价值和丰富的功能。
• 丰富的文档：入门指南、示例演示、交互式示例、完整的 API 文档、指南和示例代码、强大的搜索功能、版本控制（与项目成熟度相匹配）。
• 更多工具：命令行界面、编辑器扩展、代码片段、Playgrounds、语言服务器。

我完全没有说这些事情不重要。事实上，做好这些事情很难，完全值得由专业人士来负责。这些开发者体验的基础部分也应该快速、直观，甚至达到可以猜到的程度。

“开发者例外情况”

但我还想说，开发者在使用我们的产品时，还会遇到许多其他事情，这些事情传统上并不属于“DX 人员”的范畴，因为它们与核心工程和产品承诺有关：

• 服务中断：当您的服务中断时，您的状态页面会撒谎吗？您是否因为害怕吓跑尚未拥有的客户而不敢发布相关信息，而不是安抚现有客户？您是否会及时发布坦诚的故障分析报告？您是否为服务中断时提供了有效的备用方案？您是否进行了灾难恢复演练？
• 响应时间：您是否不仅满足了服务级别协议 (SLA)，而且真正清晰地回答了客户的问题？对于尚未纳入 SLA 的用户，您采取了哪些措施？对于您的开源项目，用户是否相信他们的问题会得到解决，相关的 PR 会得到审核？还是您只是要求用户免费为您工作，然后置之不理？
• 功能缺失/不完整：没有哪个产品发布时功能是完整的。没人指望你做到。真正的考验在于，你是会提前解决这些问题，还是像藏着掖着一样把它们藏起来。开发者在探索你的产品时，会发现他们想要但你没有的功能，并会告诉你。你打算让开发者花多少时间去挖掘产品中已知的缺陷？开发者是否相信你会及时发布或拒绝这些功能，还是说这些功能是为永远不会到来的“v2”版本准备的？
• 产品路线图的不确定性：您最忠实的用户是否了解即将推出的功能，以便他们能够根据您的计划进行安排？如果这要求太高，那么您的员工是否了解即将推出的功能，以便他们能够很好地协调工作？您是否有“永久测试版”产品？当用户询问是否应该使用“孤儿”产品时，您如何沟通？（别不好意思，每个人都有这样的产品）
• 成本不确定性：您的定价是否可预测？用户是否需要使用电子表格才能计算出最终费用？如果费用意外高昂，开发人员能否利用您的软件找出原因？还是他们不得不苦苦哀求您的帮助？是否设置了良好的默认设置以便提前预警？您的员工是否曾经为贵公司的产品付费（或者是否需要向自己的雇主解释付费的合理性）？
• 弃用/锁定/可移植性：您是否经常弃用 API 和产品，导致用户白白付出额外的工作？一定程度的锁定在所难免，但您是否意识到您正在向用户强加多少专有 API？如果用户将来出于任何原因想要离开，您是否已记录在案并使其易于操作，还是他们只能自行解决？
• 调试：你的错误信息是清晰明了还是令人望而生畏？你是否将其设计成可搜索的，还是只有维护人员才能理解？当出现问题时，你的服务能否快速发现常见问题并提供解决方案？你是否能让用户找到他们自己都还没意识到的问题的答案？如果开发人员不断犯错，比如“拿手机的方式不对”，这究竟是他们的错还是你的错？
• 审计日志和访问控制：许多产品最初都是以单人模式开发的，然后在开始服务团队和企业时，向多人模式的过渡却非常笨拙。当发生了不应该做的事情时，您是否提供可靠的信息来源，以及防止再次发生的方法（或者，当然，从一开始就杜绝此类事件的发生）？
• 错误信息：你的错误信息是清晰易懂还是晦涩难懂？别让我费脑筋！

原因

当然，这些问题都不是什么新问题，产品管理团队对此早已熟知。问题主要出在组织层面——“开发者倡导”这门学科是从“开发者布道”演变而来（从“单行道”变为“双向沟通”），如今又在向“开发者体验”发展。我认为开发者体验团队存在一个令人担忧的组织局限，他们将开发者体验定义为专注于提升“漏斗顶端”增长（减少摩擦、提高知名度、层出不穷的短期增长技巧模仿）——而对“漏斗底端”（客户流失率、满意度评分、账户拓展/客户成功）的影响却相对较少。面对一个漏水的桶，再多努力也无济于事。

康威定律是一条以其名字命名的定律，它指出“组织会设计与其自身沟通结构相匹配的系统”。史蒂文·西诺夫斯基则给出了一个更简洁的定义：“不要把你的组织结构图直接应用到产品中。” 我们需要谨慎对待将康威定律应用于开发者体验所带来的后果。

针对开发人员异常情况的工程设计

说实话，我还没完全想好该怎么做。我只是在自言自语。但我的直觉是，为了设计卓越的开发者体验，我们应该更加关注开发者的例外情况。作为开发者体验从业者，我们一直以来都非常关注…… try，或许我们应该好好审视一下catch……

首先要解决的是组织激励机制的问题。数字化转型工作不仅要让人感到受欢迎，更要成为一项必要工作，并且要对取得的成果给予奖励。没有人愿意觉得自己是在给已经不堪重负的工作清单上添油加醋。大多数组织的运作方式使得人们在不给予反馈时不会注意到反馈的缺失，而给予反馈又会让人觉得是额外的负担。不出所料，这不利于有效反馈。

第二点是围绕核心开发者体验建立不变的规则，并尽可能地实现这些规则的自动化监控和报告。能够坚守底线的工具非常强大。要想进步，首先要停止倒退。

我最后一点想法是关于帮助产品经理和工程经理打造用户体验，而不是自己承担主要责任。如果你自己提交 PR 和设计文档，你可能承担了太多别人的工作，这不仅效率低下，还可能招致不满。更好的做法是为他们提供决策所需的信息，并随时提供意见和即时反馈，因为你代表的是最终用户。通常情况下，需要处理的小事清单无穷无尽——这很难在内部推广——那么，如何将这些小事整合到主题项目中，激励工程师，并谨慎地向外界传达进展呢？

现在是时候跳出开发者体验中那些容易的问题，开始着手解决那些棘手的问题了。

注：这是我受第三方谈话启发而产生的想法，我并不代表我目前的雇主发言。

更多相关内容

• https://www.swyx.io/write-errors-that-don-t-make-me-think-24hg/
• https://lethain.com/platform-product-fit/

这些方法的差异或许最容易从它们各自的身份和访问管理 (IAM) 产品的发展演变中体现出来。谷歌的 IAM 历来提供简洁优雅的界面，但对诸如子存储桶对象权限管理等常见用例的支持有限。亚马逊的 IAM 则过于追求极致的灵活性，为了功能完整性而牺牲了易用性。在我看来，谷歌的平台虽然上手难度大大降低，并为新项目提供了更完善的默认设置，但对于规模化企业用户而言，其运维仍然困难重重，甚至难以实现。（季度收益也印证了这一点。）