开发者真正想要的内部开发者门户

尝试以下调查技巧，以获得有关平台和门户网站中应包含的正确功能和能力的诚实答案。

译自 What Devs Really Want in an Internal Developer Portal，作者 Sooraj Shah。

衡量开发人员的生产力已成为一个有争议的话题。有些人认为应该衡量开发人员可以编写多少行代码、他们可以多快地发布新功能以及他们可以多快地找到错误修复。其他人认为这些指标只反映了工程领导者对故事的一部分，而开发人员体验——开发人员对工作的感受——同样重要。

开发人员体验是一个广泛的术语，涵盖了入职、与经理、同事和其他团队的关系、技术、流程、政策和审批、软件速度和质量等等。它正成为工程领导者关注的领域，因为研究表明更好的开发人员体验会导致更高的开发人员生产力。

内部开发者门户采用的核心驱动因素之一是改善开发人员体验。它源于这样的认识：如果在软件开发生命周期 (SDLC) 中，开发人员发现难以发现信息，需要等待DevOps 或站点可靠性工程 (SRE) 来搭建服务，或者找不到其他服务或 API，那么开发人员体验就不会很好。

通过调查衡量开发人员体验

衡量开发人员体验很重要，因为如果 SLDC 流程缓慢、效率低下，并且充满了偏差和缺失数据，开发人员如何才能提高生产力？此外，如果没有这些数据，工程领导者如何才能改善开发人员体验和生产力？

在实施门户之前实施开发人员体验调查有助于您广泛地衡量开发人员体验，并就门户中要包含的内容做出明智的决定。通过了解开发人员的感受，您可以更好地评估他们的需求，并创建一个变更管理流程和路线图。

调查还可以帮助您设想初始门户最小可行产品 (MVP) 的样子，以及每个冲刺将重点关注哪些功能。许多工程领导者正在使用开发人员体验调查来生成见解，帮助他们决定接下来在门户中做什么，并展示优先考虑或实施新功能的结果。

以下是关于创建、实施和使用开发人员体验调查的全部内容。

准备调查

最终目标是什么？

首先问问您想从调查中得到什么。除了通过利用门户的功能来改善开发人员体验之外，您可能还想了解：

改善开发人员入职。
提高高质量代码的发布速度。
消除 SDLC 中的瓶颈。
减少平均修复、解决、恢复或响应时间 ( MTTR)。
减少倦怠。

专注于有助于您针对特定领域采取行动的问题。利用调查发现您可能没有考虑到的痛点，并评估您在解决这些痛点方面的效果。

例如，如果您认为可以通过帮助团队更快地找到问题的答案或解决方案来消除 SDLC 中的瓶颈，您可以询问：

在平均的一天中，您通常会花多少时间搜索工作中遇到的问题答案或解决方案？（包括您自己搜索、询问同事或等待回复的时间。）

包括从每天 15 分钟到每天超过 120 分钟的多个选择答案。

应该调查谁？

这可能很简单，比如“我们所有的开发人员”，但也许您的调查可以适应组织中的其他角色。开发人员的日常工作与 DevOps、SRE 和其他人重叠，这些角色也可以受益于内部开发者门户。不同的角色拥有不同的技术知识水平，并使用不同的技术和功能。例如，经理可能需要一种快速评估标准合规性的方法，而开发人员可能需要自助服务。我们的一位客户通过调查其云原生开发人员开始了其门户范围界定工作，因为这是该组织新的关注点。而 LinkedIn 会调查其所有开发人员，但会将所得数据细分为开发人员角色以评估结果。

需要花费多少时间？

您需要在参与度和生产力之间找到平衡。调查问卷的完成时间不应超过 15 分钟；这可能会提供良好的数据样本，而不会占用太多时间。

我们的一位客户使用专门的开发人员体验平台每周进行调查，涵盖开发人员体验和其他主题。团队必须完成调查，参与度超过 90%。但是，年度或季度调查更加常见。

DX 首席执行官 Abi Noda 在 Port 最近的 Portal Talks 活动中解释说，您必须能够维持 80% 到 90% 的参与率，才能使自我报告的数据具有可信度。

使调查匿名可以使开发人员诚实地回答问题，而不必担心后果。即使是匿名调查，也可以在较小的团队或具有特定角色或角色的情况下推断出受访者。这可能会导致开发人员回答他们认为“应该”如何回答，而不是如实回答。解决此问题的一种方法是独立保存每个答案，而不是以线程形式保存。即使调查是匿名的，您也不能假设结果反映了全部真相，因此在查看数据时请牢记这一点。

为了提高参与率，Noda 说调查设计和体验必须高质量、相关且对工程组织、高管以及开发人员和团队有用。重要的是要传达调查结果和组织学习成果。

主要要点：将调查视为旨在帮助开发人员的练习，而不是测试或发现他们的错误。

创建调查问卷

应该使用什么调查工具？

您可以选择专门为开发人员调查设计的平台，例如 DX 或 Culture Amp，或者选择更通用的工具，例如 SurveyMonkey、Google 表格或 Qualtrics。

应该避免什么？

要避免的两件事是引导性问题和验证假设。

验证假设：工程领导者通常会倾向于以他们希望验证自己假设的方式提出问题。这没有帮助。问题不仅不公平也不平衡，而且可能会导致您在不是开发人员主要痛点的领域工作。这可能会造成怨恨和不信任，并破坏未来的调查和参与。
引导性问题：提出引导性问题可能无法得到您想要的答案。例如，如果您要求您的团队对诸如“[任务 X] 提供糟糕的体验”之类的陈述进行评分，您可能会得到混合的答案。一方面，这是一个引导性问题，他们可能不同意或没有意见，而且问题的框架和格式也不合适。相反，提出更开放式的问题，例如“从 1 到 10 对 [任务 X] 进行评分，其中 10 代表良好的体验”。

主要要点：使用适合获得更好答案的格式；排名或评分是一个不错的选择。

应该询问哪些主题？

任务的重要性

为了避免确认您自己的假设，请询问开发人员特定问题对他们来说有多重要，然后询问他们对该问题的满意度。例如：

您的团队发布代码的速度对您的开发人员体验有多重要？
您对团队发布高质量代码的速度有多满意？

痛点

Port 的 DevEx 调查模板 (免费获取副本，请与我们联系) 试图找出开发人员最大的痛点，以便您可以通过使用门户的功能来帮助缓解摩擦。问题可能包括：

从 1 到 5 对在典型一周中 花费在特定任务上的时间 进行排名，包括审查拉取请求 (PR)、编写新功能、管理事件、解决错误、执行与运维相关的任务、重构代码和会议。
对 日常工作的主要阻碍 进行排名，例如等待拉取请求 (PR) 被审查、等待 DevOps 解决请求、查找服务/API 的所有者或等待其他人提供知识、权限或访问权限。
估计 开发人员入职需要多长时间。
对 开发人员在工作计划、开发、发布和管理生产过程中遇到的 26 个最大痛点 进行排名，包括 Jira 票证管理、搭建新服务以切换功能标志或了解和排查故障。

开放式问题有助于识别您尚未考虑的问题，尤其是在许多开发人员都遇到相同问题时。

在您开始使用门户并实施功能后，重新运行痛点调查。这将告诉您您的更改是否产生了明显的影响。