本文最初发布于领英技术博客，经领英中国授权由 InfoQ 中文站翻译并分享。

在过去的一年中，我们一直在使用实时反馈来改进我们的工具链，并为领英开发人员提供效率更高的体验。在它的帮助下，我们将反馈的参与度提高了一倍，更重要的是我们可以由此做出更好的推荐和改进。

对于希望改善开发体验的工程组织来说，以下问题会是一个良好的研究起点：

• 我们如何才能让我们的开发人员更具生产力，获得更愉悦的开发体验？
• 作为面向内部开发人员的工具负责人，我应该投入哪些领域来尽可能帮助我的用户？
• 能否有一种方法可以在开发人员遇到问题或获得良好体验时立即获得他们的反馈？

这篇文章分享了我们在实时反馈功能实现过程中的经验教训，我们希望它能帮助其他组织改进自己的流程，从而在开发人员和工具负责人之间建立一个自然的反馈循环。

传统调查面临的挑战

在过去的几年中，我们依靠一份开发人员季度调查来与工程师交流，并就他们所使用的工具征求全面反馈。但是，我们发现这种方法遇到了许多挑战：

• 开发人员有时会对他们很久没有使用的工具提出意见。在某些情况下，我们发现为某款工具打分的反馈者中，有超过 90％的人们在调查发布前六个月中没有使用过该工具。
• 工具负责人对所提供的反馈几乎没有任何背景概念。开发人员是根据什么评分的？他们指的是哪些具体工具或活动？这意味着大部分反馈内容实际上是无效的。
• 很难衡量定期调查期间的情况。在两次调查之间发布功能和错误修复时，我们无法确定用户评级适用于“之前”状态还是“之后”状态。此外，在两次调查之间，我们完全无法掌握开发人员的想法。

从宏观层面来看，这些调查结果帮助我们了解了用户对整个工具链生态系统的总体看法，并让我们在工具链NSAT方面取得了重大进展。但是，我们对痛点的具体内容缺乏深入了解，因此希望就内部用户对他们手头工具的感受获得更准确的信息。

解决方案：实时反馈

为了克服这些挑战，我们开发了一种称为实时反馈（Real-Time Feedback）的机制。实时反馈是一个系统，其首先收集关于开发人员在我们的工具链生态系统中所做行为的信息，然后基于这些上下文信息来确定是否、何时以及如何向开发人员征求反馈。

例如，我们可能会注意到开发人员刚刚完成了部署，并且在过去的两周内没有被要求提供有关任何工具活动的反馈。在这种情况下，我们可以发送电子邮件以征询与特定部署相关的工具链体验的反馈。将反馈请求无缝集成到日常工作流程中，意味着开发人员无需每季度坐下来一次，单凭记忆给出意见，而是可以在每次见到自动反馈提示时一点点积累看法。

捕获上下文

当我们向使用工具的开发人员提供反馈时，我们能够在其中加入开发人员在提供反馈时所做特定活动的上下文。

如上所述，定期调查的挑战之一是从反馈中提取可采取行动的信息。提到“有时”的评论尤其难以理解。现在我们能确切地知道在特定时间发生了什么并立即询问（实时），因此我们传递的反馈会更加精确，同时还提供了关于特定会话和使用情况的更多细节。

为了捕获这些上下文信息，我们创建了一个系统，其通过多种渠道记录开发人员的操作：内部 WebUI（使用Matomo）、命令行界面（CLI）和内部 API（利用我们的内部日志记录和审核机制，将信息发布到 Apache Kafka）。

上下文捕获是我们策略的关键要素，它也不仅用于反馈机制。我们计划将其用作一套新系统的基础，这套新系统将帮助开发人员获得工具方面的帮助。从理论上讲，如果我们能够全面了解开发人员在寻求帮助时所做的事情，那么这类支持将更容易提供。

参与率

对于任何调查流程来说，决定其有效性的一个主要因素就是用户群体的响应意愿。实际上，当我们转向实时反馈方法时，我们一直关注的一个主要问题就是持续的参与率。

事实证明，就用户覆盖率而言，实时调研方法比我们的传统调查更有效。我们得以将参与调查的用户比例增加了一倍（从定期调查的大约 15％增加到实时方法的 30％以上）。

由于参与度的提高，我们现在能够对开发人员群体进行更好的市场细分。在领英有很多开发人员类型：UX 开发人员、后端开发人员、站点可靠性工程师和机器学习专家等等。不同的开发人员类型（开发人员的分组/群组）具有不同的需求、使用模式和生产力诉求。更精确的定位和细分将带来更好、更个性化的工具，以满足每种开发人员类型的特定需求。

我们也意识到不应该过多地要求开发人员征询反馈，否则参与度可能会急剧下降。因此我们实现了一种智能节流机制，以确保仅在开发人员完成其意图后（即流程结束时）才会被征询反馈。调研本身的重点在于他们的体验，而不是具体的工具或技术栈的某一层。例如，我们可能会问他们整个部署流程的感受如何，而不是仅仅使用一种工具的体验。

我们还会特别尊重关于反馈调研的偏好。开发人员可以选择要多久被征询一次反馈，以及希望通过哪些渠道（例如电子邮件、Web、Slack 等）提交反馈。我们认为，这种灵活性可以将反馈的交付内容纳入每位开发人员的工作流程中，这也起到了增加参与度的作用。

开发人员可以选择他们希望被询问的频率，以及他们想被询问的渠道。这些渠道包括：

• 电子邮件：完全依靠电子邮件客户端来捕获反馈（单击，基于mailto链接）。
• 可插拔的 UI 小部件：我们开发了一种产品内可插拔的 UI 小部件，可服务于各种请求机制，包括被动和主动的请求机制（例如在线、吐司通知和弹出窗口）。
• Slack：通过与即时消息集成，我们还开发了一种通过 Slack 收集反馈的方法。
• Web 门户：我们开发了一种 Web 门户，开发人员可以通过它独立提供反馈，并与其他用户报告的内容互动（如投票、评论）。

针对反馈采取行动

聆听反馈是一个很好的起点，但是实现反馈机制后会发生的事情才是促使我们创建实时反馈的动力。从各种渠道收集反馈后，我们便将其合成为可共享的报告（文档和其他产品，例如仪表板）。我们确保相关团队能根据反馈采取行动，并且当他们选择不这样做时，我们会确保他们给出的理由能分享给提供反馈的开发人员。确保完成这一循环对于维持健康的反馈文化来说非常重要，这样反馈的提供者就可以知道他们正在被倾听，并继续提供有价值的输入。

我们的“聆听，行动和分享”框架

建立向内（面向工具开发人员）和向外（向整个公司的工程师）这两种类型的关系后，我们就建立了一种共生关系。我们将深入了解如何让开发人员变得更加高效和快乐的见解，并与工具开发人员交流以提出改进建议，从而更好地帮助他们所服务的受众。

从反馈中获得的见解

我们想分享两个例子，这些例子是从我们收集的主观反馈中获得的重要见解。

• 我们的内部 CI 系统提供了管道预期运行时间的估算值。事实证明，这些估计有时不是很准确，导致开发人员对所讨论工具链的可靠性问题产生了怀疑。
• 当流量变化导致分析失败时，我们的金丝雀部署监视系统（EKG）添加了一个保护层，以确保开发人员意识到该分析是不可靠的，因为控件可能已更改了其行为。不幸的是，开发人员到头来会认为 EKG 本身不可靠，因此忽略了分析。通过获得这种现象的相关反馈，我们改进了系统，现在正在以更好的方式处理这种情况。

总而言之，认识到我们之前传统调查方法的盲点有助于我们重新思考如何收集反馈。通过创建实时反馈这样一种从开发人员那里收集反馈的全渠道上下文方法，我们得以提升所获反馈的数量和质量，从而使我们在如何更好地为开发人员提供支持方面获得了更具可行性的见解。

致谢

我们要感谢 Vineet Juneja，他根据以往的经验帮助我们在这一领域提供了指导；管理团队的 Ben Lai、Awais Tariq、Narsi Nagampalli、Jeff Galdes 和 Jared Green；工程团队的 NamanJ ain、Troy Holsapple、Sahil Patwardhan、Sunting Sun、Aaron Dai、Barry Warsaw 和 MaxKanat-Alexander（特别感谢 Max 在本文中的帮助！）；我们的 UX 合作伙伴 Arun Yegappan、Kuan-Ying Chen 和 Kyle Smith；最后是我们的数据科学合作伙伴 Yue Wu。领英上的许多团队都参与了实时反馈的研发，我们感谢他们的支持。

原文链接：How LinkedIn turned to real-time feedback for developer tooling