Header Ads Widget

Ticker

6/recent/ticker-posts

Relaciones con desarrolladores: cómo ofrecer un alcance incomparable para desarrolladores

 

cómo-ofrecer-un-incomparable-alcance-para-desarrolladores-nordic-apis

Las API son necesariamente un esfuerzo comunitario: la comunidad fomentada entre los usuarios, los proveedores y aquellos que dependen de la API para las funciones de sus propios servicios impulsa el entorno de desarrollo del espacio API.

En consecuencia, el alcance de los desarrolladores  es absolutamente esencial para cultivar una red de usuarios y agentes de API. Más allá de comprender esta importancia, descubrir los canales adecuados, la frecuencia de comunicación y las metodologías de alcance efectivo para los desarrolladores puede convertir un producto poderoso en una potencia absoluta.

La importancia del alcance de los desarrolladores

En primer lugar, consideremos específicamente por qué es tan importante el alcance de los desarrolladores. Un sistema solo es útil cuando se usa; sin un grupo de desarrolladores que lo utilicen, ese sistema está esencialmente aislado y pierde gran parte de su potencial.

Los proveedores de API normalmente enfrentan tres obstáculos únicos que inhiben la adopción de API: falta de conocimiento, falta de comprensión y falta de visión. Separemos cada uno de estos y consideremos su impacto en un proveedor de API.

La falta de conciencia es, simplemente, la falta de conciencia de que existe un servicio. ¿Cuántas veces se ha mostrado un producto, una solución que se encontró por primera vez, donde la persona promedio dice "por supuesto, por qué no pensé en eso?" El hecho es que la mayoría de las personas desconocen la herramienta en nuestra hipótesis porque no sabían que tenían el problema y, por lo tanto, no tenían los medios para descubrir la solución.

El mismo problema entra en juego cuando se proporciona una API. Si un desarrollador necesita una solución para un problema complejo, y a menudo lo hace, no comercializar  su API y hacer que los demás se den cuenta de su existencia es tan malo como no tener ninguna API.

La falta de comprensión , sin embargo, es una bestia más voluble y posiblemente dañina. Si bien un desarrollador puede estar al tanto de una API, si usarla parece demasiado abrumador, puede terminar una relación en ciernes extremadamente rápido. Las devoluciones de errores deficientes, la documentación deficiente , incluso la falta de presencia en el foro pueden condenar una API al montón de "rechazados" por la simple razón de "difícil de usar, sin soporte".

Finalmente, Lack of Vision afecta a muchos proveedores de API. Esto no quiere decir que los desarrolladores no sean creativos o no puedan imaginar un producto; de hecho, todo lo contrario. Esta es decir, sin embargo, que los consumidores desarrolladores son a menudo incapaces de visualizar el producto y su utilidad a no ser claramente identificados.

Preguntas sin respuesta como "¿por qué necesito esto?" y "¿cómo me ayuda esto?" provienen de una API que carece de visión, pero nuevamente, no porque el desarrollador carece de las habilidades para ver las posibilidades: el proveedor de API simplemente no ha proporcionado casos de uso de ejemplo , o descripciones funcionales en un lenguaje sencillo en el que basar esta visión de implementación exitosa.

Afortunadamente, cada uno de estos se puede rectificar fácilmente utilizando algunas técnicas básicas.

Más información sobre la experiencia del desarrollador: día en la vida de un evangelista de API

Correo electrónico, chat y redes sociales

Una broma para la era de Internet: una empresa consulta con una empresa sobre cómo mejorar su marketing y ventas. La firma pregunta si tienen alguna presencia significativa en las redes sociales. La empresa se burla y dice "por supuesto que no tenemos presencia en las redes sociales, ¡somos el proveedor de Internet!"

Puede que no sea una broma particularmente buena, pero es reveladora: cuando se trata de negocios en Internet, muchas empresas todavía piensan en la mentalidad ancestral de “venta directa y en papel”. Sea profesional, comercialice directamente, ¡y listo! Sin embargo, esa no es la realidad de la era moderna.

Las comunidades de API , al igual que con otros espacios en línea, son principalmente aquellas que consumen recursos en línea y se comunican en ese medio. En consecuencia, los desarrolladores de API son algunos de los usuarios más activos y prolíficos tanto del correo electrónico como de las redes sociales, y no solo de "CatFacts" y tweets en vivo sobre Game of Thrones. Los desarrolladores de API utilizan estos canales para distribuir nuevos servicios, probar funciones y llamadas, descubrir nuevas soluciones e incluso autenticarse con herramientas.

No tener una presencia adecuada en línea es una forma segura de condenar a un proveedor de API a la oscuridad. Básicamente, existen dos enfoques para la generación de presencia en línea y el mantenimiento a largo plazo. Estos enfoques se bifurcan en dos direcciones generales: directa e indirecta.

El alcance directo es simplemente comunicación directa con desarrolladores interesados ​​o desarrolladores dentro de un grupo demográfico establecido. Involucrar a los usuarios en el correo electrónico o las redes sociales cuando han demostrado interés en una solución determinada puede informar que el producto ya existe y tiene un equipo receptivo detrás de él.

Sin embargo, esto conlleva un riesgo bastante significativo: ¿cuándo fue la última vez que un consumidor recibió una llamada en frío casual y dijo "oh, gracias, eso es genial, absolutamente utilizaremos su servicio"? El hecho es que las discusiones iniciales mal formadas y los métodos de venta agresivos pueden hacer más daño que bien, por lo que estas relaciones deben ser algo casuales por naturaleza, enmarcadas dentro del concepto de un desarrollador ayudando a otro.

El otro enfoque es el de marketing indirecto , también conocido como "boca a boca". Crear una presencia en línea estelar publicando blogs pertenecientes a la industria, mostrando nuevos proyectos experimentales o incluso simplemente compartiendo socios que usted cree que son increíbles puede hacer mucho para vincular la marca del proveedor de API con el éxito de los productos referidos.

Los portales de desarrolladores en línea no deben ser un anuncio, pero los testimonios de buena reputación son definitivamente útiles cuando son genuinos. Ofrezca soluciones : publique fragmentos de código que le parezcan interesantes, o plataformas que crea que otros podrían usar, y vincúlelos a su API, enmarcándolo como un "portal a grandes soluciones". Si abres estos canales de comunicación, cuando los desarrolladores vengan a buscar soluciones, te encontrarán. Cuando lleguen a su sitio, tenga un chat instantáneo disponible con su equipo de soporte.

La divulgación no es una conversación unilateral. Cuando se le envía un tweet, se le comenta en videos instructivos de YouTube, se le contacta por correo electrónico, etc., debe responder de manera oportuna y profesional. Las redes viven y mueren por la fuerza de sus componentes individuales; incluso una mala experiencia hecha pública puede influir en la forma en que todos los demás desarrolladores interactúan con usted.

Aprenda de la lucha de 10 años de Twitter con las relaciones con los desarrolladores

Asistencia y alojamiento de eventos

El espacio de la API puede ser digital, pero los desarrolladores son completamente humanos . Con demasiada frecuencia olvidamos que detrás de cada servidor, detrás de cada terminal, parte integral de cada fragmento de código API, hay un ser humano vivo, que respira y único, con una variedad de experiencias que informan sus habilidades y opiniones.

Los eventos , por lo tanto, presentan una oportunidad única para involucrar a una comunidad en formas que de otra manera no serían posibles. Cuando discutimos eventos, lo que realmente estamos discutiendo es cualquier evento organizado por un proveedor de API donde desarrolladores, proveedores, usuarios y partes interesadas de ideas afines pueden reunirse para discutir las API y la práctica de API .

Existe una amplia gama de beneficios potenciales de organizar un evento. Primero, está la experiencia obvia de valor agregado de asistir. En segundo lugar,  ayuda a establecer al proveedor de API como una entidad útil que busca hacer de la industria un lugar mejor. Sin embargo, lo más importante es la oportunidad para que el proveedor de API se involucre de una manera más directa y personal con los usuarios desarrolladores que las redes sociales simplemente no pueden igualar.

Organizar eventos también es una excelente manera de crear una comunidad y una base de conocimientos independientes y próspera . Invitar a los desarrolladores a una reunión y guiarlos a través de casos de uso y soluciones comunes prueba su producto, le informa sobre sus deficiencias y fortalezas, y crea en los usuarios un conocimiento directo del producto. Esto ayuda además a crear un espacio innovador y con visión de futuro, lo que permite un espacio para recibir comentarios sobre su servicio y visiones de mejoras.

Sin embargo, tenga en cuenta que estos eventos no pueden ser solo sobre el proveedor de API; debe ser un esfuerzo comunitario unificado . No seas el niño que exige que todos vengan a su fiesta de cumpleaños con regalos, y luego, misteriosamente, nunca está presente para nadie más.

Bases de documentación y conocimientos

La documentación te hará libre. Esa simple frase ha guiado a más desarrolladores de los que le corresponden, y suena más cierta a medida que los sistemas que impulsan esta hermosa y loca autopista de la información interconectada se vuelven cada vez más complejos.

Por lo tanto, la forma más rápida de que un proveedor de API no atraiga a los desarrolladores es la falta de documentación y provisión de conocimientos para sus servicios. No documentar la funcionalidad principal es un clavo en el ataúd para la tumba cavada por el proveedor de API, pero incluso no ofrecer  documentación fácil de usar puede agregar gradualmente la suciedad sobre su cabeza.

Sin embargo, hay dos líneas de pensamiento sobre la documentación que contrastan marcadamente entre sí. Una es la idea de que la documentación debe realizarse directamente y mediante los esfuerzos del desarrollador que crea el sistema en sí; la documentación del fin de todo .

Si bien esto ciertamente agrega una gran cantidad de control sobre la documentación resultante y la comunidad que la usa, tiene algunos inconvenientes. El primero y más destacado es el estrés adicional sobre el proveedor de API. Si bien la documentación básica es un requisito fundamental, documentar cada solución a cada problema que pueda surgir o no en un número infinito de situaciones es abrumador y prácticamente imposible.

Igual de importante es el hecho de que la documentación del desarrollador a menudo procederá de quienes escribieron el código y, en ocasiones, puede ser de naturaleza demasiado técnica; La documentación de la API debe proporcionar legibilidad tanto para máquinas como para humanos . Si bien tener buenos informes de errores, sintaxis, restricciones de estilo y códigos de documentación pueden ayudar mucho en este sentido, crea una carga de información considerable que mantener.

La segunda línea de pensamiento es establecer una  base de conocimientos centrada en el usuario . La creación de una base de datos donde los usuarios pueden etiquetar problemas, tal vez en forma de ticket o incluso en una interfaz tipo wiki, permite a los propios usuarios documentar y resaltar nuevos problemas, así como sugerir sus soluciones, para futuros usuarios.

La documentación generada por el usuario es, por naturaleza, muy legible por humanos. Por supuesto, hay una gran advertencia. Repita lo siguiente: las bases de conocimientos no reemplazan el contacto humano. Existen demasiadas bases de datos corporativas que documentan problemas encontrados en API, sistemas operativos y aplicaciones que terminan con una respuesta genérica: esto es un error en la comunicación.

Cuando un usuario encuentra un artículo de la base de conocimientos, la mejor esperanza es que responda a su pregunta y le brinde una solución fácil. Sin embargo, si no lo hace, terminar en el artículo y reemplazar su presencia en las redes sociales con este simple artículo o ticket puede arruinar una API más rápido que cualquier otra cosa.

Recuerde: las bases de conocimientos deben aumentar y respaldar el correo electrónico, los foros y las redes sociales, no reemplazarlos.

Obtenga más información sobre las formas estándar de documentar las API RESTful

Conclusión

Estas técnicas y enfoques básicos deben comprender el 99% de la mayoría de las estrategias de los proveedores de API cuando se trata de fomentar un alcance de desarrolladores sin igual Si bien parte de esto parece de sentido común, muchos se sorprenderían de cuán comunes y épicos son estos fracasos en el alcance básico en toda la industria. La adaptación de estas soluciones proporcionará el apalancamiento que los proveedores de API necesitan para tener éxito, catapultando el éxito inicial y la buena voluntad a un plano nuevo y superior.

Publicar un comentario

0 Comentarios