Header Ads Widget

Ticker

6/recent/ticker-posts

7 mantras para una experiencia de desarrollador de calidad

Conclusiones clave del LiveCast de la experiencia del desarrollador de 2019



La experiencia del desarrollador es un aspecto crucial de la propiedad de API de hoy en día. Con una competencia feroz entre los proveedores de API en casi todas las industrias, ya no se trata de lo que puede hacer su API , sino de lo que deben hacer los desarrolladores Y, sin embargo, conseguir la experiencia de desarrollador de forma correcta todavía se siente como magia negra del siglo XXI para algunos ...

En septiembre de 2019, organizamos un seminario web de una hora sobre la experiencia del desarrollador , con dos miembros principales de la comunidad: Emmelyn Wang , estratega de API en Axway , y yo, Thomas Bush , redactor de tecnología en las API nórdicas. En este artículo, recapitularemos siete conclusiones clave de LiveCast para que pueda iniciar el viaje de DX de su organización con más de diez años de experiencia combinada en el campo.


Nuestros LiveCasts cuentan con miembros principales de la comunidad sobre temas específicos de API. Si desea hablar en un LiveCast futuro, contáctenos aquí .

1. DX es cualquier cosa que facilite el uso de su API.

Comencé mi charla respondiendo la pregunta: "¿Qué es una buena experiencia de desarrollador?" Si bien un buen DX a menudo incluye documentación completa, numerosos SDK / bibliotecas de cliente y una cuenta de Twitter ingeniosa orientada al desarrollador, eso no es todo lo que hay.

Presento una nueva definición de las mejores prácticas de la experiencia del desarrollador: DX es cualquier cosa que facilite el uso de su API . Sí, tanto los documentos completos como las bibliotecas cliente se incluyen en esta definición, pero es esencial reconocer que hay mucho más, lo discutiremos más adelante.

2. Los clientes lo adorarán por su facilidad de uso. He aquí por qué.

Para explicar la importancia de la experiencia del desarrollador, hice referencia al informe Smartbear State of API Report 2019 , que reveló que más del 50% de la razón principal de los consumidores para usar una API era la velocidad o el costo.

Al mejorar la experiencia del desarrollador, en otras palabras, al hacer que una API sea más fácil de usar, le permite al desarrollador hacer su trabajo más rápido y, a su vez, le permite a la empresa completar el proyecto más barato . Dado que la velocidad y el costo son algunas de las principales razones para usar una API, está brindando apoyo a los clientes de una manera significativa para ellos al mejorar la experiencia del desarrollador.

Algunos consumidores no utilizan una API por velocidad o costo, sino que necesitan integración. Para estos casos, piense en mejorar la experiencia del desarrollador como una inversión en la satisfacción del cliente. Es posible que no vea resultados mañana, pero las ganancias de ingresos a largo plazo son inevitables.

3. Piense siempre de afuera hacia adentro, no de adentro hacia afuera.

La estrategia DX de Emmelyn comienza con una regla simple pero efectiva: piensa de afuera hacia adentro . Demasiadas empresas son culpables de pensar de adentro hacia afuera: quieren crear una API, por lo que se sumergen en el código y exponen nuevas funcionalidades, sin pensar en cómo eso impacta las cosas hacia arriba y hacia abajo.

En cambio, Emmelyn sugiere que comience con el consumidor y trabaje hacia atrás. Esto significa desarrollar una profunda empatía por todos sus consumidores, incluso aquellos que de otro modo podría descuidar.

4. Un DX positivo comienza con un diseño intuitivo.

Continuando con mi tesis de que la experiencia de desarrollador significa facilidad de uso, creo que la construcción de la mejor experiencia de desarrollador posible comienza con un diseño de API intuitivo. Muchos proveedores de API se centran completamente en recursos adicionales, como documentos, bibliotecas y tutoriales, pero no en la usabilidad de la API en sí, que debería ser el punto de partida.

Al diseñar una nueva API, haga preguntas conscientes del desarrollador, como "¿qué terminales necesitarán los consumidores?", "¿Los terminales toman parámetros intuitivos y dan respuestas intuitivas?", Etc. Al hacerlo, se ahorrará dolores de cabeza en el futuro.

5. Reduzca la sobrecarga técnica y luego cree alternativas.

Secundario a un buen diseño es reducir los gastos técnicos. Facilite a los desarrolladores el uso de su API 1) ocupándose de tareas redundantes / repetitivas y 2) hablando el idioma de sus desarrolladores (es decir, apoyando los lenguajes de programación preferidos de su desarrollador). Tomé prestadas estas ideas de Adeel Ali de APIMatic, cuyas excelentes ideas sobre DX he cubierto antes .

Solo una vez que haya diseñado adecuadamente y reducido la sobrecarga técnica innecesaria, debería preocuparse por lo que yo llamo "fallbacks": documentación, canales de soporte y más. Si bien todos estos elementos son parte de una buena estrategia de DX, los pongo en segundo lugar, ya que a menudo se necesitan como consecuencia de un diseño deficiente o un exceso de gastos generales.

6. Documentación y sandboxes: inicie la integración correctamente.

Un área donde la documentación es más que esencial es la incorporación . Emmelyn dice que puede preparar a sus desarrolladores para el éxito dándoles un marco de referencia claro desde el principio del proceso de incorporación, dejando claro lo que puede y no puede hacer con su API en las páginas de introducción de sus documentos.

Además de eso, Emmelyn recomienda diseñar su proceso de incorporación con un objetivo claro en mente: que el desarrollador cree un valor rápido y tangible. Para ello, querrá que los tutoriales, los ejemplos de código y las guías de inicio rápido sean fácilmente visibles en la página principal de su documentación.

Una idea adicional es ayudar a los desarrolladores a rastrear dónde se encuentran durante el proceso de registro para evitar frustraciones o confusiones innecesarias. También es crucial en la documentación inicial la divulgación progresiva de información, que garantiza que no abrumará a los desarrolladores con información innecesaria.

Otro elemento crucial en la incorporación, dice Emmelyn, es la caja de arena . Al brindar a los desarrolladores un entorno de prueba listo para usar, les permite aprender (y, por lo tanto, construir) rápidamente, cumpliendo el objetivo de incorporación de crear valor rápido y tangible. Dicho esto, asegúrese de que las reglas precisas acompañen a su sandbox, para que los desarrolladores no se confundan si las compilaciones de producción tienen reglas en conflicto.

7. Repetir siempre.

Finalmente, Emmelyn cree que una gran parte de lograr que la experiencia del desarrollador sea correcta es la iteración. Al mejorar continuamente su portal de desarrolladores, crear nuevos recursos y tener en cuenta los comentarios de los desarrolladores, puede cubrir temas importantes de DX más rápido de lo que cree. Durante este tiempo, Emmelyn recomienda que practique la comunicación de resultados claros para que pueda asegurarse de que las partes interesadas de la empresa se comprometan incluso en momentos de duda.

Pensamientos finales

Ahí lo tienes: siete aprendizajes clave del LiveCast de la API nórdica sobre la experiencia del desarrollador. Con todo este contexto útil, incluido lo que es DX y cómo abordarlo, y muchas recomendaciones específicas, como qué gastos generales técnicos cortar y cómo incorporar, tiene todos los elementos esenciales para una estrategia efectiva de Experiencia de desarrollador.

Para obtener la primicia completa sobre DX, asegúrese de ver el LiveCast de la experiencia del desarrollador completo . O únase al boletín para obtener información sobre DX en el futuro.


Publicar un comentario

0 Comentarios