如何将开发者调查结果付诸行动_AI阅读总结 — 包阅AI

Internal developer portals (IDPs) have become essential for any organization that wants to increase developer productivity, output and — above all — satisfaction. But how do you know if your IDP is achieving those goals? With measurement, in part, by running a developer survey.

In my previous article in this two-part series, I described how to design a developer survey to determine what your team wants in an IDP. In this article, I’ll share some ways to put your findings into action.

At Port’s recent Portal Talks event, Abi Noda, CEO of DX, explained three steps to using survey data to take actions:

1. Getting the data into the right hands and in front of the right people.
2. Interpreting the data and making decisions on what actions to take.
3. Following through on those actions, then remeasuring after those actions or initiatives are delivered to learn whether they move the needle and what impact they have.

I’ll break down those steps and a few more below.

Use the Data To Decide on Features

The most important part of a survey is using it to make effective changes.

For example, one of our customers used the following format:

AppSec provides immediate visibility into the security posture of any app, while cloud cost combines cost data, associates resources with costs, and provides dashboards for visibility and further analysis.

Having this insight enables you to set priorities.

Compare Against Benchmarks

The above example is clear cut because it is about actual pain points and features. But some questions are more difficult to analyze to determine appropriate actions to address them. Examples might include: “How productive do you feel?” or “Do you get enough time to focus on development?”

In these cases, you can use benchmarks — from previous surveys you’ve conducted, employee satisfaction surveys across the business, or comparisons with other organizations in your industry — to see if there are noticeable changes and try to get to their root cause.

Talk With the Team

Some scores warrant further discussion. For instance, if the survey provided low results across the board, you may want to dig deeper into the issues developers face by having an open team talk or one-on-one chats. This can help you find out where the real problems are.

Regardless, managers should schedule meetings with their team to discuss the results and create an action plan to fix issues.

Prioritize

Some questions may provide you with clear priorities to tackle. But don’t take on everything at once; instead, focus on making changes to important tasks one at a time and iterate according to feedback you receive.

Acknowledge the Input

One of the hardest things about surveys is to keep engagement going (or to give people a reason to engage). It’s important to say “thank you” to the respondents and provide them with feedback. This can even be as vague as “the survey will help us keep track of developer experience and improve it.” The more open you are, the better engagement you’re likely to get, so if you’re in a position to provide some details about the actions you’re going to take based on the survey results, you’ll help keep the team feeling appreciated and engaged.

Combine Your Findings

Developer experience surveys are only one factor in assessing developers. Combine the survey results with other measures such as developer productivity metrics, employee satisfaction surveys, in-the-moment feedback (while developers are using the portal) and team talks. You’ll get a clearer picture of what’s really going on, and build a business case for new features, updates or changes.

Get Feedback on Your Actions

If you made changes due to the results of a survey, you need to know how those changes have affected the developers. Are they happy with the new feature or process put in place? Has it changed things for the better?

Asking questions quickly after a developer has used a new feature can be helpful, DX’s Noda explained. This makes feedback immediate and avoids problems recalling their experience.

This can look like a series of questions:

• A question about the way the new feature works: “How was using this self-service action for spinning up a new service? Was it easy/satisfactory/difficult?”
• Objective metrics: “How long did it take you to complete that action?”
• Open feedback: “How could this feature in the developer portal be improved?”

Conclusion

Developer experience surveys can act as a feedback loop for your internal developer portal, enabling you to get the maximum benefits from your team. They can also impact the way your developers feel about their work, reduce their friction points and improve their productivity.