Header Ads Widget

Ticker

6/recent/ticker-posts

Por qué su API necesita un equipo dedicado a la experiencia del desarrollador

 


En el informe State of API de 2019, sorprendentemente, solo el 37% de los proveedores de API vieron la documentación como una prioridad máxima. Cuando se les pidió a los consumidores de API que votaran sobre la característica más importante de una API, el 60% señaló la "facilidad de uso" como su deseo principal al integrarse, con la documentación en el tercer lugar. Si bien la documentación puede contribuir a la facilidad de uso general, estos números revelan que no es el único elemento que contribuye a una buena experiencia de desarrollador.

Entonces, la pregunta es: ¿Cómo pueden las empresas de API mejorar su proceso general y brindar la experiencia de alta calidad que desean sus usuarios? Una de las mejores respuestas a esa pregunta es: Concéntrese en crear un equipo de experiencia de desarrollador dedicado que pueda capacitar a sus usuarios al hacer que sea más fácil de entender, más fácil de construir y más fácil de integrar (especialmente si su empresa desarrolla API orientadas al cliente).

Comprender la diferencia: DevRel y DX

¿Qué es exactamente la experiencia del desarrollador (DX)? DX se trata de comprender a los desarrolladores, sus necesidades, sus habilidades, sus valores, lo que están tratando de lograr, qué herramientas y tecnologías están usando, los puntos de integración y cómo se sienten al usar un producto.

Las relaciones con los desarrolladores (DevRel) son un componente vital de una estrategia integral de DX. Algunas empresas son lo suficientemente grandes como para tener un equipo DevRel dedicado, quizás incluso con múltiples roles distintos, incluidos evangelistas, defensores y, a veces, incluso escritores de tecnología y hackers de crecimiento. Todos estos roles tienen como objetivo inspirar relaciones positivas con los usuarios desarrolladores, mediante el intercambio de conocimientos que llenan el vacío entre los creadores y los consumidores de tecnología.

Ya sea que su empresa tenga un equipo DevRel dedicado o un equipo DX que incluya responsabilidades de DevRel, sería negligente no reconocer el papel que desempeñan las relaciones con los desarrolladores en el marco más amplio de la experiencia del desarrollador.

¿Por qué Developer Experience?

Las empresas de software y los proveedores de SaaS que venden productos de interfaz de usuario (UI) han reconocido la importancia de una buena experiencia de usuario (UX) durante décadas. Una gran UX puede ser el diferenciador clave que hace que su producto sea exitoso. Así es como Apple ganó el mercado de la telefonía celular y cómo Nest hizo que los termostatos fueran atractivos.

DX es para API como UX es para UI. Las API son productos y los desarrolladores utilizan esos productos. Esos desarrolladores esperan un alto nivel de calidad, facilidad de uso, incorporación y soporte gracias a empresas como Stripe, Nexmo y HelloSign, que están subiendo el listón continuamente.

“DX es la adquisición de conocimientos necesarios para implementar una API. Facilite la adquisición; conocimiento más digerible; el viaje de implementarlo más simple; mejor vida de los desarrolladores ”- Anthony Tran, creador del sistema de diseño Luna

¿Por qué el cambio?

Entonces, ¿por qué las empresas comienzan a darse cuenta de repente de que necesitan un equipo de DX? Después de todo, han sobrevivido sin DX durante décadas. ¿Qué cambió?

A principios de la década de los 90 y en el siglo XXI, las empresas normalmente invirtieron millones de dólares en paquetes de software locales, como CRM, ERP y bases de datos. Luego confiaron en un ejército de contratistas costosos para personalizar estos productos para satisfacer sus necesidades. La integración en décadas pasadas fue una gran empresa, en términos de habilidades, trabajo y capital.

Sin embargo, a medida que las empresas se han trasladado a la nube, se han alejado de las plataformas de software monolíticas y se han orientado hacia productos SaaS más pequeños basados ​​en micropagos. Esta propagación de productos SaaS ha llevado a la necesidad de integraciones estandarizadas entre ellos, lo que a su vez ha impulsado el aumento de la economía API . Para 2011, REST era un estándar de la industria y, en poco menos de una década, hemos visto un aumento de casi un 1,000% en la cantidad de API en el mercado.

Esta explosión del Cámbrico prácticamente ha eliminado la necesidad de costosos consultores que comprendan las complejidades de los paquetes de software de un millón de dólares. Ahora cualquier desarrollador puede integrarse con estas API para vincular sistemas dispares y automatizar los flujos de trabajo de sus empresas.

La economía de las API ha creado una cultura de expectativas para las API. Ahora se supone que una API estará disponible y, en muchos casos, sin medición, para los consumidores o desarrolladores que buscan "conectarse" a su aplicación. De hecho, para muchos clientes, su API es más importante que su UI. El hecho de que tenga una API y lo fácil que sea usarla pueden ser los diferenciadores que hagan que el cliente elija su producto sobre el de la competencia.

Entonces, ¿cómo se asegura de que obtengan la mejor y más completa API?

Necesita un equipo dedicado a la experiencia del desarrollador

Los desarrolladores no son los mejores para incorporar la interfaz de usuario en sus diseños. Es por eso que muchas empresas emplean especialistas en UI que son responsables de instalar una interfaz amigable además de los componentes que ha construido un equipo de desarrollo.

Lo mismo ocurre con las API. Su equipo de desarrollo no debería ser el único responsable de la experiencia del desarrollador de una API, porque esa no es la especialidad del equipo de desarrollo.

Durante los primeros días de ShipEngine, uno de los momentos decisivos para nuestro equipo de desarrollo fue reconocer que para aumentar la adopción teníamos que centrarnos más en la creación de un producto que los desarrolladores adoraran lo suficiente como para justificar la construcción de una nueva integración. No fuimos la primera API de envío del mercado y no seremos los últimos, por lo que sabíamos que necesitábamos una forma de destacar.

Comenzamos a ver cómo las empresas de API de otras industrias se movían alrededor de su competencia.

Tome las plataformas de procesamiento de pagos populares como PayPal y Stripe, por ejemplo. Muchos pueden reconocer a PayPal como uno de los líderes en la industria y, como uno de los primeros en el mercado, merecen un asiento en la mesa. Pero, históricamente, su API ha sido torpe y difícil de usar. Cuando se presentó Stripe por primera vez, sabían que estaban ofreciendo un producto que a los desarrolladores les encantaría, pero también sabían que ganar seguidores leales requeriría mucho trabajo preliminar.

¿Cómo pudieron hacerlo?

Construyendo una API con un buen DX. 

Diseñaron una API excelente con énfasis en la consistencia y los estándares de calidad, escribieron documentación fácil de usar, proporcionaron muestras de código útiles y potentes bibliotecas de SDK, diseñaron su sitio web para priorizar las necesidades de los desarrolladores y emplearon un excelente equipo de relaciones con los desarrolladores que asistió a conferencias y escribió artículos basados ​​en el conocimiento. Se abrieron camino en un mercado ajustado al crear un producto que a los desarrolladores les encantó y una experiencia que querrían compartir con otros.

"Los desarrolladores felices son desarrolladores conversadores, y cuando hablamos entre nosotros para recomendar productos, los que tienen el mejor DX están en la parte superior de la lista". Sam Jarman , locutor y escritor DX

Stripe aprovechó su facilidad de uso, sabiendo que podían apoyarse en los desarrolladores para que les vendieran su producto siempre que pudieran mostrarles lo agradable que podía ser la experiencia de integración Su éxito fue incluso suficiente para poner celoso a PayPa l .

Entonces, ¿cuál es la comida para llevar?

Stripe no es la única empresa que se ha hecho cargo rápidamente de la cuota de mercado gracias a una experiencia de desarrollador mejorada. Entonces, ¿cómo pudieron acaparar el mercado en tan poco tiempo? Creo que fue empleando un equipo multidisciplinario diverso dedicado a los cuatro elementos principales de la experiencia del desarrollador.

4 responsabilidades principales de un equipo de experiencia de desarrollador

En ShipEngine, nuestro equipo de Experiencia de Desarrollador existe para asegurar una experiencia excepcional para los desarrolladores y clientes que utilizan nuestros productos API. Al centrarnos en estas cuatro áreas principales de responsabilidad, hemos podido diseñar mejores funciones, defender los intereses de los desarrolladores, traducir los comentarios y asesorar a otros departamentos internos sobre cómo empatizar y diseñar mejor para los desarrolladores.

Las cuatro áreas principales son:

1. Diseño de API

Si bien el desarrollo de productos se deja en gran medida en manos de ingenieros y equipos de productos, un equipo de Experiencia de desarrollador debe mantener la responsabilidad de proporcionar la orientación y los estándares que los ingenieros necesitan para crear un producto que sea bien recibido por los demás. Esto incluye cada parte de su interfaz, incluido el protocolo, estilo, nombres, modelos, operaciones, autenticación, códigos de estado, encabezados, errores, paginación, clasificación, consultas y más. También puede incluir algunos aspectos del comportamiento y los detalles de implementación de la API. Tipos de entregables:

  • Orientación de diseño
  • Revisión de diseño
  • Guías de estilo
  • Especificaciones / definiciones

2. Garantía de calidad

¡Con las API, siempre desea apuntar a la calidad a través de la coherencia! Para garantizar que un producto API y las herramientas del desarrollador cumplan con un alto estándar de calidad, el equipo de DX debe hacerse responsable de emplear pruebas, linters y procesos automatizados que verifiquen el cumplimiento de los diseños, esquemas y guías de estilo. El aseguramiento de la calidad también implica la propagación de una cultura de calidad en todos los equipos de diseño, producto e ingeniería. Tipos de entregables:

  • Prueba de contrato
  • Prueba de especificación
  • Prueba de cumplimiento de la guía de estilo
  • Verificación de la precisión y claridad de los documentos y las herramientas

3. Herramientas para desarrolladores

Quiere darles a los desarrolladores la oportunidad de probar su API antes de invertir en una integración completa. Por lo tanto, proporcionar una biblioteca sólida de herramientas para desarrolladores es una excelente manera de mostrarles, no de decirles , lo bueno que eres. Los desarrolladores quieren y necesitan esquemas, ejemplos de código, implementaciones de referencia, SDK y una variedad de otros recursos para ayudarlos a guiarlos a través de la construcción. Tipos de entregables:

  • Muestras de código
  • Implementaciones de demostraciones / referencias
  • SDK y bibliotecas
  • Especificaciones, definiciones y esquemas
  • Automatización y herramientas internas
  • Integraciones con herramientas y servicios para desarrolladores

4. Relaciones con los desarrolladores

Y finalmente, el rol con el que nosotros (y los usuarios) estamos más familiarizados. Todas las comunicaciones e interacciones con los clientes desarrolladores, como la documentación, la formación, las notas de la versión, los eventos de la comunidad y los estudios de comentarios de los usuarios, se incluyen en las Relaciones con los desarrolladores. Entregables:

  • Documentación / Tutoriales / Preguntas frecuentes
  • Notas de la versión / registros de cambios
  • Información de estado del sistema (tiempo de inactividad, errores, rendimiento)
  • Contenido multimedia (blogs, videos, etc.)
  • Capacitación y materiales
  • Estudios de investigación de usuarios
  • Eventos / participación comunitaria (reuniones, hackatones, conferencias, etc.)

Pensamientos finales

Así como UI / UX ha sido un diferenciador clave para los productos de interfaz gráfica de usuario, Developer Experience es un diferenciador clave para los productos API. Y una buena estrategia de DX se extiende más allá de las funciones y responsabilidades de DevRel.

Publicar un comentario

0 Comentarios