Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué cualidades hacen a un gran propietario de producto API?


 El papel del propietario de un producto API web todavía es bastante confuso, en gran parte debido al hecho de que es una posición relativamente nueva. Eso es interesante, porque cualquiera que esté interesado en el desarrollo empresarial de API sabe lo valioso que es ese puesto. Un gran propietario de producto API puede ser muy beneficioso y puede aprovechar las fortalezas del producto a mayores alturas.

En este artículo, vamos a discutir qué cualidades hacen a un gran propietario de producto API y qué significan estas cualidades para el proceso de desarrollo en su conjunto. Una vez que haya terminado esta pieza, debe tener una comprensión sólida de estas cualidades y una rúbrica básica sobre la cual se pueden comparar y contrastar con su candidato de elección.

Por qué es importante la propiedad del producto API

La propiedad del producto API es una faceta importante de las estructuras organizativas del equipo de API web moderno. A pesar de esta importancia, la relativa novedad del rol es tal que, incluso cuando se reconoce el valor, lo que hace una buena colocación no es tan obvio. Tener a alguien que pueda administrar un equipo y un producto es poderoso; tener a alguien que pueda hacer eso y al mismo tiempo evangelizar su proyecto interna y externamente lo es exponencialmente más.

Sin embargo, existe una diferencia entre "hacer algo" y "ser dueño de un proyecto", y es esta distinción la que hace que la colocación de un puesto sea una gran victoria o un gran fracaso. La propiedad de un proyecto y todos los elementos de ese proyecto tienen una especie de efecto en cascada que puede ser más poderoso que la suma de sus partes, aumentando la productividad, mejorando el bienestar organizacional y creando una cultura de responsabilidad personal.

Pero, ¿qué implica específicamente una posición de propietario de producto API? Y lo que es más importante, ¿qué elementos se esperan de una persona en tal posición?

Desarrollador versus gerente de producto versus evangelista: cuando los mundos chocan

El paradigma clásico de la creación de productos digitales es una batalla entre el desarrollador y el administrador. Los desarrolladores intentan crear algo en lo que creen que sea funcional y de alta calidad. Los gerentes de productos, por otro lado, están tratando de cumplir con los objetivos comerciales, tratando de determinar el verdadero valor del producto que otros estarían dispuestos a invertir en él. Los evangelistas ocupan un espacio único y completamente diferente. Provienen de una formación técnica, pero a menudo están más preocupados por generar conciencia, tanto interna como externa.

Esta perspectiva está pasada de moda, pero funcionó en épocas pasadas de desarrollo. Sin embargo, la nueva situación de desarrollo ha rechazado los roles tradicionales en muchos casos, y los pequeños estudios y grupos tienen más herramientas y mejores fondos que nunca para crear soluciones únicas, personales y, a menudo, de nicho.

En este nuevo paradigma, el enfoque pasado de moda simplemente no siempre funciona. El nuevo ecosistema de desarrollo a menudo implica gerentes de producto como desarrolladores, evangelistas como desarrolladores, etc., y a medida que esas líneas se han difuminado, también lo han hecho las posiciones que ocupaban esos espacios. Dado que los desarrolladores tienen que desempeñar tantas funciones debido a la propia naturaleza del ciclo de desarrollo, la propiedad del producto API, como concepto y como "puesto" dentro de una empresa, puede implicar muchas cosas.

Con eso en mente, veamos algunos de esos atributos importantes que definen este rol.

Verdadero liderazgo

“Concéntrese en la iteración constante de su producto o servicio. Nunca se aferre demasiado a su idea, pero esté abierto al cambio y la innovación ".

Candace Carpenter

El propietario de un producto API no solo vende una API, sino todo lo que hay detrás. Para los consumidores de desarrolladores, el valor es la suma del soporte ofrecido, la experiencia del equipo de desarrolladores, el soporte para desarrolladores , la documentación y otros materiales del portal para desarrolladores. Todo este valor adicional, sin embargo, es impulsado directamente por el liderazgo de ese equipo; la documentación no tiene valor, por ejemplo, si el liderazgo no permite que sea examinada y revisada.

En consecuencia, el valor de un producto se magnifica por la calidad del liderazgo en el espacio de propiedad de productos API. Los propietarios de productos deben ser líderes y fuertes en eso. Deben tomar la iniciativa para desarrollar nuevos proyectos, estar dispuestos a asumir riesgos por nuevas soluciones y hacer todo esto manteniendo el valor para la empresa y para el usuario. En resumen, el viejo adagio suena cierto: la cabeza en las nubes, los pies en el suelo .

Parte de esto también significa, por supuesto, que el propietario del producto debe ser responsable de sus decisiones y ser capaz de racionalizar estas elecciones en los movimientos de productos y proyectos no solo para la empresa y el equipo, sino también para la base de usuarios. La comunicación clara juega un papel muy importante en esto, y la documentación efectiva es una gran parte de este enfoque.

Dominio del lenguaje versus familiaridad con la solución

El equilibrio entre el dominio de un idioma determinado y la familiaridad con el tipo de implementación es delicado y, a menudo, se pasa por alto. Imaginemos que está creando una API en Go . Ahora, ¿su elección de gerente de producto está más impulsada por alguien que es un maestro de Go o por alguien que tiene una gran experiencia con microservicios distribuidos, pero no necesariamente con experiencia en Go?

Este es el acto de equilibrio que debe considerarse detenidamente. Puede ser tentador mirar en qué está integrado su producto y luego contratarlo según el idioma, pero esto podría resultar en un candidato que sea un experto en el idioma pero que apenas pueda comprender la estructura distribuida de su familia de microservicios.

Comprender los requisitos de diseño específicos de una API es imprescindible aquí, pero siempre considere los atributos adjuntos. Si está diseñando aplicaciones RESTful, necesita encontrar a alguien versado en JSON. Si trabaja con SOAP , entonces XML es definitivamente un beneficio adicional. El conocimiento de las soluciones y los estándares de API de código abierto es importante si esa es su intención final.

Estas consideraciones son vitales y, si se consideran adecuadamente, permiten el movimiento si su API alguna vez necesita girar y cambiar. Tener la capacidad de adaptarse a las mareas cambiantes del desarrollo web hace que un propietario de producto API poderoso lo sea aún más.

Marketing vs.Desarrollo

“La marca es solo una percepción, y la percepción coincidirá con la realidad con el tiempo. A veces estará por delante, otras veces estará por detrás. Pero la marca es simplemente una impresión colectiva que algunos tienen sobre un producto ".

Elon Musk, director ejecutivo de SpaceX y Tesla

Una consideración principal en la mentalidad de propiedad del producto API es si el propietario del producto debería o no posicionarse más en términos de marketing o en términos de desarrollo. Si bien esto se relaciona de alguna manera con nuestra comparación anterior de desarrollo, administración y evangelización, esto es mucho más una consideración de mentalidad que una de deber laboral, por razones que pronto se harán evidentes.

Bill Gates innovó la computadora del lugar de trabajo, Steve Jobs innovó la forma en que consumimos los medios móviles, Elon Musk innovó la forma en que procesamos los pagos en línea (sin mencionar la exploración espacial y los vehículos impulsados ​​por energías renovables). Cuando la gente habla de innovadores, esos nombres a menudo se adjuntan al producto. El punto es que, en el espacio tecnológico, el propietario del producto es tanto una marca como lo que intenta vender.

En consecuencia, no existe tal cosa como "solo" un desarrollador o "solo" un comercializador en el espacio de trabajo moderno. Con el ecosistema moderno de desarrollo e innovación, el propietario del producto debe ser tan reconocible como el producto en sí.

En consecuencia, el propietario del producto debe tener cualidades que reflejen y permitan esto. Ser capaz de tomar el sol en el centro de atención , mientras redirige esa atención al producto, es inmensamente valioso. También es valioso enmarcar la solución con casos de uso críticos empresariales específicos Ser capaz de supervisar el desarrollo , ponerse de pie y decir qué es y qué hace específicamente, y por qué es necesario, eso lo convierte en un buen propietario de producto API.

Gestión de equipos

"He aprendido que nada es seguro excepto la necesidad de tener una sólida gestión de riesgos, mucho efectivo, la voluntad de invertir incluso cuando el futuro no está claro y grandes personas".

Jeff Immelt, director ejecutivo de GE

La gestión de equipos es una gran parte de cualquier organización, pero dentro de la economía web impulsada por API, esto es aún más importante. Con tantos trabajadores remotos, a veces ubicados a medio mundo de distancia, la capacidad de inspirar, liderar y, lo que es más importante, organizar define a los líderes exitosos y, por lo tanto, a las organizaciones exitosas.

Asimismo, poder identificar las debilidades dentro de la organización permite realizar sacrificios y conformar grupos de trabajo más ágiles. Reestructurar equipos, poder delinear de manera gerencial las responsabilidades del grupo de trabajo y delegar las tareas correctas a las personas adecuadas son elementos enormes que deben hacerse correctamente para aprovechar las fortalezas de cualquier equipo.

Ningún gerente puede funcionar por sí mismo. Detrás de cada trabajo, hay un Wozniak, y en el espacio moderno, es más a menudo un requisito que un propietario de producto API efectivo sea ambos.

En términos de consideraciones sobre el conjunto de habilidades, el conocimiento y la experiencia con conjuntos de herramientas que permiten la colaboración en equipo en este espacio son clave. El conocimiento de soluciones de mensajería como Slack puede ser muy beneficioso, y tener experiencia con sistemas de distribución de tareas como Trello también. Incluso adoptar IDE de colaboración en línea como Squad puede significar la diferencia entre el fracaso o el éxito del equipo.

Experiencia

“Hay pros y contras de la experiencia. Una estafa es que no puede mirar el negocio con un par de ojos nuevos y tan objetivamente como si fuera un nuevo CEO. Despídete un viernes por la noche y entra el lunes por la mañana como si una empresa de búsqueda te pusiera allí como líder de cambio. ¿Puede ser objetivo y hacer un cambio audaz? "

Andrea Jung, directora ejecutiva de Avon

La experiencia es otro punto nebuloso a considerar en equilibrio con otras cualidades. Si bien es tentador pensar que la experiencia significa éxito, esto es algo así como una atribución errónea: la experiencia también puede significar simplemente tiempo invertido y, a veces, es posible que desee un novato en lugar de un experto.

Este es un juego de equilibrio. Demasiada experiencia puede dar lugar a sesgos para una solución o elección determinada, y puede dar lugar a implementaciones de memoria que solo cambian ligeramente de una versión a otra. Tener demasiada experiencia también puede conducir a la complacencia y, en algunos tipos de personalidad, a la arrogancia, los cuales permiten que los fracasos constantes pasen desapercibidos.

Asimismo, tener muy poca experiencia también puede tener efectos dañinos. Los enfoques innovadores de un recién llegado pueden no estar basados ​​en la realidad y pueden conducir a algunos fracasos costosos. Además, si bien un novato puede estar más orientado a la creatividad, los desarrolladores o gerentes más nuevos también pueden carecer de experiencia crucial, lo que hace que las lecciones aprendidas tengan un precio.

Lo que realmente quieres aquí es una mezcla. Un buen gerente de producto puede tener mucha experiencia, pero debe tener la mente de un novato, dispuesto a tomar riesgos y hacer cosas fuera de la caja. Deben estar dispuestos a pensar en grande y, sobre todo, estar dispuestos a fallar.

Cumplimiento de los objetivos comerciales

Este no es un concepto nebuloso y, de hecho, podría ser el consejo más concreto de este artículo. El propietario de su producto API debe ser propietario del producto y, por lo tanto, ser responsable y estar al tanto de los objetivos comerciales que se le han asignado.

El propietario de un producto tiene una posición única en el sentido de que se encuentra a caballo entre el mundo del desarrollo y los negocios. Si bien pueden ver los detalles íntimos de ambos lados, deben poder ver la imagen más grande y dónde encaja el producto en esa imagen. Deben ser capaces de orientar el proyecto de tal manera que promueva la consecución de los objetivos empresariales, equilibrados por supuesto con todos los demás atributos de esta lista.

Busca comprender la audiencia de desarrolladores

Finalmente, y quizás lo más importante, un propietario de producto debe comprender íntimamente a su audiencia . Un producto no tiene valor sin una base de usuarios, un caso de uso y sin deseo de implementación; por lo tanto, el propietario de un producto API debe estar familiarizado con todos ellos.

Como punto, aquí, el propietario de la API debe atender la API, su marketing y su enfoque para promover tanto las mejores experiencias de desarrollador como de usuario . Esto incluye todo, desde una hermosa documentación hasta un alcance básico , desde códigos de error hasta distribución de código; todo debe estar diseñado para ayudar a construir una comunidad.

En pocas palabras, el propietario del producto API debe actuar como el nodo unificador entre varios puntos diversos dentro de la comunidad, abordando la analítica, los procesos del equipo de desarrollo, el marketing y las ventas, y la experiencia del usuario, con el objetivo final de satisfacer a la base de clientes a cualquier costo. y lograr las metas que desean.

Contratación interna versus externa

Si bien puede parecer fácil considerar a un candidato en función de los conceptos presentados aquí, hay una variable que no es tan fácil de responder: la pregunta entre contratar internamente o externamente .

Por un lado, hay un valor definitivo en la contratación de personal interno . El personal interno ya está íntimamente familiarizado con la solución y el lenguaje; esto ahorra tiempo de desarrollo y definitivamente ayuda cuando se trata de documentación y otras prácticas. Por otro lado, esto también conduce a los problemas de los que hablamos anteriormente cuando se trata de experimentar sesgos, y en este caso, la sangre nueva puede ser tan poderosa como la vieja.

Outsourcing para Jump-Start

Un tema restante es la posibilidad de subcontratar el puesto como un método temporal para impulsar el desarrollo o el marketing de API. Esta se está convirtiendo en una táctica mucho más común a medida que pasan los años y se ha utilizado con gran efecto para el desarrollo de API. Esta estrategia puede permitir un desarrollo inicial rápido, haciendo que el proyecto despegue. Dicho esto, hay algunos problemas.

El principal de esos problemas es que la subcontratación ignora el valor de los veteranos . Tener un gerente probado a largo plazo es muy importante y no se puede ignorar en aras de una solución rápida. Si bien tener demasiada experiencia puede ser un problema, como se dijo anteriormente, cuando se trata de poner en marcha un programa, tener un administrador probado puede ayudar a brindar información predecible sobre la respuesta que puede esperar de la comunidad.

Con todo esto en mente, nuestro consejo sería el siguiente: comenzar con la subcontratación es un enfoque válido, pero debe usarse con moderación. Cuando se usa, siempre que sea posible, un acuerdo debe venir con la advertencia de que el gerente, después de haber demostrado su valía a través de una iteración y lanzamiento exitosos, se convierte en un elemento permanente en el equipo.

Conclusión

Esperamos haber ayudado a iluminar todas las diversas cualidades que hacen a un gran propietario de producto API , o al menos, con una rúbrica sólida con la que juzgar a los posibles candidatos. Si bien no hay forma posible de cubrir todas las habilidades, advertencias y cualidades posibles, las que hemos discutido en este artículo deberían servir como una base sólida para comenzar.

Publicar un comentario

0 Comentarios