Header Ads Widget

Ticker

6/recent/ticker-posts

Arquitectura de la plataforma de personas


 Cuando escribimos sobre API web, inevitablemente nos centramos en una de dos cosas : los aspectos técnicos de la creación de la aplicación en sí, o el mercado objetivo y la base de usuarios que consume la API.

Sin embargo, algo que a menudo se olvida es la red de personas que existe para respaldar el producto. La estructura y cultura de la empresa detrás de una API externa es importante, pero a menudo se pierde entre el empleado promedio que rara vez se encuentra con estas redes de apoyo. En muchos casos (pero no en todos), los equipos de productos API representan entre uno y un puñado de desarrolladores asignados para vigilar la aplicación.

En estos días, las empresas se centran cada vez más en las personas que están detrás del negocio . El resultado de esto es que se anima a los equipos de marketing , ventas, operaciones , soporte y desarrollo a que se interesen activamente en lo que están haciendo otros departamentos.

A pesar de esto, las API que no son productos básicos a menudo siguen siendo un misterio para otros empleados; pueden verse como algo altamente técnico e intocable, o como un proyecto paralelo peculiar con el que a un par de desarrolladores les encanta trabajar.

Cuando un equipo parece actuar en un silo , con otros empleados que tienen muy poca idea de lo que hacen sus API, las implicaciones para su desarrollo son preocupantes; Existe una desconexión significativa entre los equipos de API y el resto de la empresa. A continuación, veremos cómo abordar esto.

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

Más allá de la ley de Conway

La Ley de Conway fue definida por Mel Conway, un famoso científico informático que definió una teoría fundamental sobre la estructura organizativa:

"Cualquier organización que diseñe un sistema (definido en términos generales) producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización".
Mel Conway

Para decirlo de otra manera, "la forma en que nos comunicamos tiene un impacto en las cosas que construimos". Así lo expresó Ronnie Mitra , director de Diseño de API en API Academy, en su charla en nuestra Cumbre de Plataformas 2017:

Ronnie agrega que lo que construimos no puede cambiar por sí solo: “No hemos llegado al punto en el que las cosas que implementamos pueden cambiar porque cambian los requisitos. El cambio solo ocurre porque la gente hace que el cambio suceda. * "

Él enfatiza esto al señalar que todo en una empresa está interconectado. Especialmente en las arquitecturas de microservicios actuales , nuestra estructura de comunicación está integrada en las herramientas que proporcionamos:

Las estructuras organizativas para arquitecturas de microservicios ciertamente siguen la Ley de Conway. Fuente: Arquitectura de microservicios , O'Reilly.

Mitra explica que esta es una razón clave por la que DEBEMOS ser más "empáticos con las personas que crean productos". Sin esa empatía, existe el riesgo de que los desarrolladores de API creen productos que no representan las necesidades de su empresa, sus empleados o sus usuarios.

Abrazar la autonomía

En su charla, Mitra ofrece ejemplos de varias empresas exitosas, incluidas Netflix, Amazon y Spotify, que son campeonas de la autonomía; "Las personas que hacen el trabajo pueden tener autoridad sobre lo que hacen".

Pero hay mucho más en ese proceso que solo impulsar la toma de decisiones de los ejecutivos de nivel C, a quienes Mitra se refiere como arquitectos empresariales, a los desarrolladores de servicios; La idea de la toma de decisiones centralizada frente a la descentralizada es, como cree Mitra, simplificar enormemente las cosas. Tampoco aborda el hecho de que otros empleados pueden ver a los desarrolladores (API) como un silo.

Utiliza un modelo existente de toma de decisiones ...

... para construir un modelo para el mapeo de actividades , el método propio de Ronnie para distribuir responsabilidades y para identificar dónde se necesita talento. En este modelo, podemos ver que la mayoría de las decisiones (y el contexto que las informa) en realidad involucran a varios grupos diferentes de personas. Según Ronnie, este modelo nos otorga una forma de abordar las preocupaciones de control y riesgo al mismo tiempo que brinda cierta autonomía.

Más sobre la cultura empresarial de API: Fomento de una cultura interna de seguridad

API tiene talento

A mitad de su charla, Mitra afirma que "una mayor autonomía requiere un mejor talento". Es difícil discutir con esa afirmación, dado que la experiencia previa proporciona un enfoque más completo para el desarrollo de software (o cualquier otra disciplina para el caso).

Pero, ya sea por presupuestos o procesos de contratación que requieren mucho tiempo, las empresas rara vez tienen la oportunidad de abastecer su lista con solo talento A + ... al menos, no de inmediato. Es por eso que la distribución del talento es fundamental.

El mapeo de actividades puede ayudar a identificar cuáles son las decisiones más importantes, pero probablemente ya tenga una idea bastante clara de qué decisiones relacionadas con su API tienen la mayor influencia porque son las que lo mantienen despierto por la noche.

  • ¿Qué idiomas debemos utilizar?
  • ¿Debo crear nuevas versiones o implementarlas continuamente ?
  • ¿La API que estamos creando se adapta mejor al uso público, privado o de socios ?

Y, si realmente quieres ponerte el sombrero de ejecutivo, ¿de dónde saldrá el dinero para hacer X, Y o Z? Responder con éxito a estas preguntas también ayuda a aclarar el propósito de una API y hacerla más accesible para la empresa en su conjunto.

Descubra: la guía definitiva para fijar el precio de una API

Mejorando la eficiencia

En su charla, Mitra menciona un libro titulado Time, Talent, Energy que habla sobre el “arrastre organizacional” o la complejidad accidental de la interacción. En la mayoría de los casos, dice, esto se refiere a reuniones y esas interminables cadenas de correo electrónico que parecen tardar horas en resolverse.

Mitra bromea diciendo que, para la mayoría de los desarrolladores, hablar de mejorar la eficiencia puede dar un poco de miedo. "O me asusta de todos modos", dice. Pero junto con la motivación y la energía, que veremos más de cerca a continuación, el tiempo es un factor importante cuando intentas lanzar un gran producto.

Ya hemos mencionado anteriormente la autonomía, que obviamente es un factor clave para acelerar la producción de API; Cuanto más confíe en el personal para tomar decisiones, más manos podrá estar con ellos. Sin embargo, usar el tiempo de manera eficaz es más que eso.

La idea de sincronizarse con su equipo para mejorar la eficiencia puede parecer casi un oxímoron, ya que la primera implica una serie de reuniones y actualizaciones que pueden afectar negativamente a la segunda. El verdadero truco aquí es encontrar una manera, ya sea usando Slack , limitando sus correos electrónicos a actualizaciones semanales o ejecutando las tareas de todos al comienzo del día, sincronizarse de una manera que funcione para su equipo.

Se necesita una estructura de empresa para tener una API de espectro completo

Motivación y energía

Como señala Mitra, “es imposible que todos tengan el 1% de talento más alto del mundo”. Pero las personas que se preocupan por el trabajo que están haciendo y están entusiasmadas por invertir su tiempo y esfuerzo en él, siempre superarán a las estrellas desmotivadas. Además, también harán que otras personas se emocionen.

Pero consideremos otra forma de hacer las cosas por un segundo. Bill Gates dijo una vez (en) la famosa frase: "Elijo a una persona perezosa para hacer un trabajo difícil porque una persona perezosa encontrará una manera fácil de hacerlo".

Para ser claros, no estamos sugiriendo que exista una forma secreta de construir y mantener una API. Sin embargo, es interesante notar que muchas de las mejores API se crearon para automatizar o simplificar un proceso que de otra manera requeriría mucho tiempo.

Este tipo de relación empleado-empleador requiere una gran cantidad de transparencia: si un empleador no permite que sus empleados, digamos, trabajen desde casa porque no confía en ellos o si un empleado está demasiado preocupado por ser despedido como para explicar cómo lo harían. mejorar las cosas, terminas con historias como esta .

Elimine los silos: evite caminar sobre cáscaras de huevo y use DevOps

Pensamientos finales

Mitra dice que nosotros, como desarrolladores, debemos "comenzar a construir una plataforma de personas que diseñamos de la misma manera que diseñamos nuestros sistemas de tecnología". Todos conocemos el estereotipo: "no molestes al desarrollador cuando tenga los auriculares puestos o antes de tomarse el café". Pero eso funciona en ambos sentidos.

Los desarrolladores deben estar conectados a las necesidades de la organización y sus empleados, así como a las necesidades de los usuarios de la API. Sin ese diálogo, una API querida podría, por ejemplo, terminar cerrada porque todos los demás en el negocio la ven como un pozo de dinero.

Debería ser bastante obvio que la transparencia y la autonomía son vitales para el desarrollo efectivo, de API o de otro tipo, pero para llegar a ese punto se necesita confianza , eficiencia y talento .

En otras palabras, necesita grandes personas que se comuniquen eficazmente entre sí. Y, en ese sentido, la Ley de Conway es tan relevante hoy como cuando fue escrita hace 50 años en 1967.

Publicar un comentario

0 Comentarios