开发人员异常工程

我们需要对以开发人员为中心的公司所说的开发人员体验（DX）进行真正的讨论。

尽管Chris Coyier对人们听到该词时的想法进行了很好的调查，但其他人仍在尝试定义“开发者支持”，但它的定义还不够明确。它是devtools之间的一个区别，所以它当然是专业化的，并且逐渐升为职务（我的最后一个职务是“开发人员经验工程师”，无论实际上是什么意思）。我完全希望这会发展成为一个成熟的子行业，其中包括会议，思想领袖，网守等（直接到＆＃34; Dev Advocate联合创始人＆＃34;）。

几行替换：用几行代码替换多行代码。用一个徽标替换许多徽标。一键替换许多步骤（注册，部署）。生成代码，因此您无需手写代码。作为第一方，即装即用或零配置，提供巨大的价值和丰富的功能。

大量文档：入门。示例演示。互动示例。完整的API文档。指南和食谱。好搜索。版本控制。 （取决于项目成熟度）

我一点也不说这些都不重要。他们甚至很难做得好，并且完全应该得到专家的支持。这些基础的开发人员经验还应该快速而直观，以便于猜测。

但是我也要说，开发人员在使用我们的产品时会遇到许多传统上不是DX人员领域的事情，因为它们与核心工程和产品承诺：

停机时间：服务中断时，您的状态页是否位于？您是否避免发推文，以免吓倒您还没有的客户，而不是让您放心的客户放心？您是否发布即时的，不废话的验尸报告？当服务中断时，您是否提供良好的备用选项？您练习灾难恢复吗？

响应时间：您不仅在满足您的SLA，而且实际上清楚地回答了客户问题吗？您正在为SLA尚未涵盖的用户做什么？对于您的开源足迹，用户是否有信心将解决他们的问题并审查适当的PR，还是您在要求人们为您做免费的工作，然后您将其忽略？

缺少功能/功能不完整：没有产品发布功能完整。没有人期望您。真正的考验是您是先解决它还是将它像肮脏的秘密一样隐藏。当开发人员探索您的产品时，他们会找到他们想要的东西，而您没有的东西会告诉您。您需要多长时间开发人员才能在产品中发现已知漏洞？开发人员是否有信心您会立即发布或拒绝这些功能，或者它们是否适用于＆＃34; v2＆＃34 ;？那永远不会来？

路线图的不确定性：您最热衷的用户是否知道会发生什么，以便他们可以围绕您的计划进行计划？如果这个门槛太高，您自己的员工是否知道接下来会发生什么，以便他们能够很好地协调？您有＆＃34;永久性Beta＆＃34;吗？产品？当用户询问是否应使用＆＃34; orphan＆＃34;时，您如何沟通？产品？ （不要羞愧，每个人都有）

费用的不确定性：您的定价是否可以预测？您的用户是否需要电子表格来确定要向他们收取的费用？如果费用出乎意料地高，开发人员可以使用您的软件找出原因，还是必须乞求帮助？是否有适当的默认设置来获得提前警告？您的员工是否曾经为自己的产品付款（或必须向自己的雇主付款）？

弃用/锁定/可移植性：您是否不断弃用API和产品，从而导致额外的工作，却一无所获？不可避免地会有一些锁定，但是您是否意识到要向用户施加多少专有API？您的用户是否应该出于某种原因而想离开某天，是否已将其记录在案并简化了操作？还是他们一个人呆着？

调试：您的错误是有益的还是令人恐惧的？您是否将它们设计为可搜索的，或者它们仅对维护人员有意义？当出现问题时，您的服务多快能发现常见问题并提供解决步骤？使用户能够回答他们尚不知道的问题该怎么办？如果开发人员不断犯错误，并且＆＃34;拿错电话，是他们的错还是你的错？

审核日志和访问控制：许多产品以单人游戏模式开始，然后在开始为团队和企业服务时执行非常笨拙的向多人游戏的过渡。当完成了不应该做的事情时，您是否提供了可信赖的真相来源以及防止重复的方法（或者，当然，首先使其不可能）？

当然，这些都不是新问题，并且对于产品管理来说是众所周知的。问题主要是组织方面的问题-作为“开发者倡导”这是一门从＆＃34;开发人员福音传承而来的学科。 （从一条1号路到一条2号路），它现在正在演变为＆＃34;开发人员经验＆＃34;。我看到了DX人员的组织限制，将DX定义为着眼于增加＆＃34; funnel＆＃34;增长（减少摩擦，提高意识，模仿者短期增长黑客的无休止游行）-并且对漏斗底部的影响相对要小得多内容（徽标流失，满意度得分，客户扩展/客户成功）。面对漏水的水桶时，多下雨几乎没有意义。

康威法则是一项同名法律，其中规定组织设计的系统应反映其自身的通信结构。史蒂芬·辛诺夫斯基（Steven Sinofsky）的快照定义是不要寄出您的组织结构图。我们需要注意让Conway的法律适用于开发人员体验的后果。

明确地说，我还真的不知道该怎么做。我只是想大声一点。但是我的直觉是，为了设计出色的开发人员体验，我们应该更多地注意开发人员异常。作为DX人员，我们已经集中精力进行尝试，也许我们应该对捕捞情况有个很好的了解。

首先要解决的是组织激励措施。 DX工作不仅要受到欢迎，还必须得到要求，并要取得好的结果。没有人会想像他们正在增加已经超负荷的积压订单。大多数组织的设置方式是，在没有反馈的情况下就不会注意到这种反馈，而给与反馈的感觉就像是额外的负担。毫不奇怪，这不利于反馈。

第二件事是围绕您的核心开发人员经验建立不变性，并在最大程度上自动监控和报告这些不变性。掌握这一点的工具功能强大。要取得进展，您需要首先停止回归。

我的最后想法是帮助PM和EM创建DX，而不是承担主要责任。如果您自己发送PR和设计文档，则可能是您在别人的工作上做得太多，因而无效和/或怨恨。最好是为他们提供决策所需的信息，因为您代表最终用户，因此可以提供意见和即时反馈。通常有无数的小事情要做-而且内部很难销售-那么如何将它们捆绑到主题项目中，激励工程师，并仔细地将进步传达给更广阔的世界？

现在是时候让我们超越开发人员经验中的简单问题，并着手解决不舒服的问题了。

注意：这是第三方对话引发的我自己的想法，我并不是代表当前的雇主发言。