Breaking

Post Top Ad

Your Ad Spot

sábado, 25 de enero de 2020

7 mantras para una experiencia de desarrollador de calidad

La experiencia del desarrollador es un aspecto crucial de la propiedad moderna de API. Con una feroz competencia entre los proveedores de API en casi todas las industrias, ya no se trata de lo que su API puede hacer , sino de lo que los desarrolladores deben hacer . Y, sin embargo, hacer que la Experiencia del desarrollador sea 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 Developer Experience , con dos miembros principales de la comunidad: Emmelyn Wang , estratega de API en Axway , y yo, Thomas Bush , escritor de tecnología en Nordic API. En este artículo, resumiremos siete conclusiones clave de LiveCast para que pueda iniciar el viaje DX de su organización con más de diez años de experiencia combinada en el campo.

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

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

Comencé mi charla respondiendo a 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 y orientada al desarrollador, eso no es todo lo que hay.
Presento una nueva definición para las mejores prácticas de Developer Experience: DX es cualquier cosa que facilite el uso de su API . Sí, los documentos completos y las bibliotecas de clientes se incluyen en esta definición, pero es esencial reconocer que hay mucho más: discutiremos qué más adelante.

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

Para explicar la importancia de Developer Experience, hice referencia al Informe Smartbear State of API 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, permite que el desarrollador haga su trabajo más rápido y, a su vez, permite que la empresa complete el proyecto más barato . Dado que la velocidad y el costo son algunas de las principales razones para usar una API, usted está apoyando a los clientes de una manera significativa para ellos al mejorar la Experiencia del desarrollador.
Algunos consumidores no están utilizando una API por velocidad o costo, pero 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. Siempre piense de afuera hacia adentro, no de adentro hacia afuera.

La estrategia DX de Emmelyn comienza con una regla simple pero efectiva: pensar 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 comiences con el consumidor y trabajes hacia atrás. Esto significa crear una empatía aguda para todos sus consumidores, incluso aquellos que de otro modo podrían descuidar.

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

Continuando con mi tesis de que la Experiencia del desarrollador significa facilidad de uso, creo que construir la mejor Experiencia del desarrollador posible comienza con un diseño intuitivo de la API. 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.
Cuando diseñe una nueva API, haga preguntas conscientes para los desarrolladores, como "¿qué puntos finales necesitarán los consumidores?", "¿Los puntos finales toman parámetros intuitivos y dan respuestas intuitivas?" Al hacerlo, se ahorrará dolores de cabeza en el futuro.

5. Reduzca los gastos generales técnicos, luego cree retrocesos.

Secundario al buen diseño está reduciendo la sobrecarga técnica. Facilite a los desarrolladores el uso de su API al 1) ocuparse de tareas redundantes / repetitivas, y 2) hablar el idioma de sus desarrolladores (es decir, admitir 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 y reducido adecuadamente la sobrecarga técnica innecesaria, debería preocuparse por lo que yo denomino "fallbacks": documentación, canales de soporte y más. Si bien estos elementos son parte de una buena estrategia de DX, los puse 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 cajas de arena: incorpore bien.

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 al darles un marco de referencia claro al principio del proceso de incorporación, dejando en claro lo que puede y no puede hacer con su API en las páginas introductorias 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 tangible y rápido. Para esto, querrá hacer recorridos, ejemplos de código y guías de inicio rápido 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 temprana la divulgación progresiva de información, lo que garantiza que no abrumes a los desarrolladores con información innecesaria.
Otro elemento crucial en la incorporación, dice Emmelyn, es la caja de arena . Al proporcionar 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 un valor rápido y tangible. Dicho esto, asegúrese de que reglas precisas acompañen a su entorno limitado, para que los desarrolladores no se confundan si las compilaciones de producción tienen reglas en conflicto.

7. Siempre iterar.

Finalmente, Emmelyn cree que una gran parte de acertar con la Experiencia del desarrollador es la iteración. Al mejorar continuamente su portal para desarrolladores, crear nuevos recursos y tener en cuenta los comentarios de los desarrolladores, puede cubrir un terreno DX serio más rápido de lo que piensa. Durante este tiempo, Emmelyn recomienda que practique la comunicación de resultados claros para que pueda garantizar la aceptación de las partes interesadas de la empresa incluso en momentos de duda.

Pensamientos finales

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

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

Post Top Ad

Your Ad Spot

Páginas