¿Por qué escalar de abajo hacia arriba? Cómo las interacciones de los equipos deben afectar la estructura organizativa

Hola a todos, estoy feliz de estar aquí hablando sobre las interacciones entre equipos y el importante papel que desempeñan en la escalabilidad adecuada y la reorientación de los procesos. En los próximos 20 minutos, hablaré un poco sobre los equipos como medios de entrega, las interacciones entre equipos y la importancia de DDD para un flujo rápido. ¡Empecemos!

Entonces, la primera pregunta es, ¿por qué? ¿Por qué es importante el diseño organizativo y las interacciones entre equipos? Bueno, el Sr. Mel Conway observó un patrón de comportamiento que terminaría convirtiéndose en una ley. La ley de Conway es la observación de que el diseño de cualquier sistema está significativamente afectado por la estructura de comunicación de la organización que lo desarrolló, y es una consecuencia del hecho de que dos módulos de software A y B no pueden interactuar correctamente entre sí a menos que el diseñador e implementador de A se comunique con el diseñador e implementador de B. Por lo tanto, la estructura de la interfaz de un sistema de software mostrará necesariamente una congruencia con la estructura social de la organización que lo produjo.

Esto tiene un impacto significativo en cómo se construye el software, especialmente si se adoptan microservicios y un diseño más orientado al dominio, y esto está directamente relacionado con los fragmentos organizativos que las empresas suelen tener. El problema con los fragmentos organizativos es que proporcionan una vista única del equipo, con la relación entre los equipos y las líneas de reporte, pero por lo general los patrones de comunicación no son de arriba hacia abajo en la línea de reporte, son paralelos y a lo largo del fragmento, lo que hace que la eficiencia de la comunicación sea clave para los equipos efectivos. Iremos a donde sea necesario para resolver nuestros problemas, y esta creatividad y método de resolución de problemas debe ser aprovechada en beneficio de la organización, no restringida a las líneas de reporte.

Entonces, ¿cómo podemos resolver los problemas de los fragmentos organizativos? El pensamiento en problemas es un enfoque holístico que se repite constantemente, siempre tratando de optimizar el conjunto, considerando el flujo general de trabajo, identificando cuellos de botella y eliminándolos. Y ahora volvamos a nuestro punto inicial de la comunicación. Los cuellos de botella organizativos comunes son estructuras de equipo ocupadas, mala comunicación y ritmo lento de entrega, y creo que todos hemos pasado, si no todos, por algunos de ellos. El objetivo general es que la arquitectura admita la capacidad de los equipos para completar su trabajo desde el diseño hasta la implementación, sin requerir una comunicación de alta capacidad entre los equipos. ¿Y supongo que esto es el nirvana de la organización, verdad? Esto significa que cada organización debe entender qué arquitectura de software se necesita antes, y aquí van en letras mayúsculas, antes de organizar los equipos. De lo contrario, los paquetes de comunicación y los incentivos en la organización terminarán dictando la arquitectura de software, algo que no queremos. Y aquí volvemos al tema de la comunicación. Cuanto más adaptemos los equipos a la arquitectura deseada, y no al revés, más contenida y mejorará la comunicación, mejorando la eficiencia de los diseños de equipo al eliminar la sobrecarga del caos de la comunicación. Reorganizar o escalar una empresa, basándose en esta suposición, aunque obvia, es un desafío para la jerarquía, ya que está intrínsecamente relacionado con las necesidades de colaboración e interacciones de los equipos, su capacidad para ser flexibles y adaptarse al cambio, y los dominios y límites de carga cognitiva del equipo. La carga cognitiva es el límite de cuánta información puede retener una persona, o en este caso un equipo al unir a todos los miembros, en un momento dado.

Entonces, ¿cuál es el objetivo aquí con esta maniobra, cómo podemos mejorar la estructura e interacciones del equipo? Para empezar, debemos pensar en los equipos como organismos vivos dentro del ecosistema, con individualidades que responden a motivadores crecientes. Estos motivadores suelen ser una referencia de tres elementos, y son autonomía, dominio y propósito, que cuando se habilitan dentro de responsabilidades claramente delimitadas, permiten calidad y velocidad de trabajo aumentadas. ¿Por qué? Hago esta pregunta muchas veces. Bueno, cuando los equipos están débilmente acoplados y altamente cohesionados, significa que son autónomos en el contexto en el que trabajan, un contexto que está restringido en responsabilidades y adaptado a su carga cognitiva, limitando los esfuerzos de cambio, aumentando así el enfoque y la calidad. Es posible que hayas escuchado estos términos antes y se aplican de la misma manera. El acoplamiento suelto es cuando los componentes no tienen dependencias fuertes con otras empresas, y la alta cohesión es cuando los componentes tienen responsabilidades claramente delimitadas y sus elementos internos están fuertemente relacionados. Por lo tanto, estos conceptos se aplican de la misma manera en todos los escenarios. Además, el conjunto claro de dominios de responsabilidad rechaza la mentalidad de `hábil en todo, maestro de nada`, evita que los equipos tengan que lidiar con solicitudes y prioridades de múltiples fuentes. En resumen, los paisajes de equipo adecuados que ponen a los equipos en primer lugar influyen positivamente en los límites de responsabilidad, la velocidad de entrega, la calidad del trabajo y la autonomía, lo que a su vez impacta directamente en el software que los equipos producen. Basado en la ley de Conway, el libro Team Topology menciona dos conceptos fundamentales que ayudan a utilizar los paisajes de equipo para repensar los fragmentos organizativos de la empresa, y los conceptos son las Topologías Fundamentales y los Modos de Interacción. En resumen, ¿cuáles son las mejores topologías en las que los equipos pueden trabajar? Los autores sugieren cuatro topologías fundamentales que van desde equipos orientados al negocio hasta equipos orientados a la plataforma.

Tenemos un equipo alineado con el flujo, que se alinea con un flujo de trabajo de generalmente un segmento de un gran dominio empresarial. Tenemos los equipos habilitadores que ayudan a los equipos alineados con el flujo a superar obstáculos, y también detectan capacidades faltantes. También tenemos equipos de subsistemas complicados, donde se requieren matemáticas, cálculos o experiencia técnica significativa. Y por último, pero no menos importante, tenemos el equipo de plataforma, que es un grupo de otros tipos de equipos que proporcionan un producto interno convincente para acelerar la entrega de los equipos alineados con el flujo.

Dado que la comunicación e interacción entre los equipos son los aspectos más críticos del pensamiento organizativo y estratégico, para permitir que estas topologías de equipos interactúen adecuadamente, se sugieren algunos modos de interacción como se presenta en la siguiente diapositiva. Y nuevamente, volviendo a los problemas de comunicación con los que comenzamos, ¿cómo pueden colaborar y comunicarse de manera efectiva los equipos? Existirán dependencias, cuanto menos, mejor, pero existen y no podremos hacerlas desaparecer. ¿Cómo podemos simplificar nuestras vidas? ¿Cómo podemos comunicarnos para construir una buena estructura de equipo? En el libro, nuevamente, los tres modos esenciales de interacción entre equipos son los siguientes. lo que significa trabajar estrechamente juntos con otro equipo, que es el impulsor de la innovación y el descubrimiento rápido, pero tiende a difuminar los límites. Es un modo de comunicación muy bueno para el descubrimiento rápido de cosas nuevas que evita costosas transferencias entre equipos. También tenemos el modo de X como servicio, lo que significa consumir o proporcionar algo con una colaboración mínima, lo que mantiene responsabilidades claras con una entrega predecible, pero necesita una buena gestión de productos. Es una excelente opción cuando hay una necesidad de que uno o más equipos utilicen un componente compartido que se puede proporcionar como un servicio. Y por último, pero no menos importante, la facilitación, lo que significa ayudar o ser ayudado por otro equipo para eliminar impedimentos, lo que detecta y reduce las brechas en las capacidades. Es bueno cuando uno o más equipos se benefician de la ayuda activa de otro equipo que facilita o incluso asesora algún aspecto de su trabajo.

En resumen, todos estos conceptos, tanto las topologías fundamentales como los modos de interacción, terminan siendo una regla general cuando se trata de pensar en equipos con acoplamiento suelto y alta cohesión que trabajan juntos en un flujo adecuado de cambios. En este punto, hemos comprendido la importancia de tener una visión clara para el diseño de la arquitectura de software y luego ajustar los equipos como organismos tan efectivos como los límites que se les asignan y las estrategias de comunicación que aplican. También hemos discutido los modos de interacción que mejoran la comunicación, pero ¿qué pasa con la carga cognitiva? ¿Qué pasa con los límites y responsabilidades del equipo? Bueno, Eric Evans, que es un conocido arquitecto de software y autor del libro Diseño Dirigido por Dominios, coincide con la observación de que es difícil lograr un flujo cuando cada equipo depende de una complicada red de interacciones con muchos otros equipos. Cuando los límites de responsabilidad asignados a los equipos no son viables o están mal definidos, resulta en falta de propiedad, desvinculación y una baja tasa de entrega. ¿Hay una solución? ¡Sí! Explorar y validar los límites de responsabilidad, teniendo en cuenta primero al equipo, es lo que discutiremos a continuación. La investigación realizada por Accelerate encontró que las arquitecturas fuertemente acopladas influyen negativamente en la capacidad de tener equipos autónomos con responsabilidades claras. Muchos problemas en la entrega de software provienen de límites poco claros entre equipos y sus responsabilidades, lo cual a menudo se ve opacado por una arquitectura de software con alto acoplamiento entre sus diferentes partes, algo en lo que las arquitecturas monolíticas se complacen. El objetivo final de cada arquitectura es apoyar la capacidad de los equipos para realizar su trabajo con un alto rendimiento, desde el diseño hasta el desarrollo, sin requerir una comunicación de alta capacidad entre equipos, lo cual es más difícil de lograr en una arquitectura monolítica. Pero en el proceso de alejarse del software monolítico, ¿cómo consideramos las necesidades de los equipos? ¿Cómo tenemos en cuenta su perspectiva? Pensamos en los dominios, aplicando una estrategia bien conocida que permite la plena propiedad de los equipos. Exploramos y discutimos el diseño dirigido por dominios y luego evaluamos cómo los equipos se ajustarán a eso. Esto significa, nuevamente, aunque parezca que me estoy repitiendo, pero esto es realmente importante, que la organización debe comprender qué arquitectura de software se requiere antes de organizar los equipos. De lo contrario, como ya se mencionó, los caminos de comunicación y los incentivos en la organización terminarán dictando la arquitectura de software. Pero primero, retrocediendo un paso, ¿qué es un dominio? Sabemos que los buenos límites minimizan la carga cognitiva, ¿verdad? Pero, ¿qué son estos límites? Los límites son líneas conceptuales que envuelven a los dominios, y los dominios son conceptos más amplios que los sitios de software, lo que nos ayuda a pensar en general y utilizar heurísticas comunes. El hecho de que proporcionen una visión del problema que se está resolviendo también facilita asignar complejidad a un dominio, lo que a su vez facilita asignarla a los equipos según su carga cognitiva disponible. Esto permite el diseño dirigido por dominios, proporcionando técnicas de desarrollo de software que abordan tanto la planificación estratégica como el diseño estratégico y técnico, manteniendo la alineación con el negocio, fomentando un lenguaje común y una evaluación adecuada de la complejidad, lo cual en última instancia proporciona beneficios claros, propiedad del equipo, compromiso y un flujo rápido de entrega. Dicho todo esto, pasemos a un escenario de caso real, y hablaré sobre mi ejemplo personal en LX. Entonces, cada empresa necesita una estructura organizativa, especialmente las grandes corporaciones que actúan en varios tipos de mercados en todo el mundo. El negocio de clasificados en línea no es una excepción, y en el grupo OLX hay una unidad de clientes específica para representar el mercado de compra y venta de automóviles, que es la unidad de clientes de motores. Esta unidad representa a compradores y vendedores individuales, con el objetivo de unirlos para realizar negocios. Como puedes imaginar, lo que comenzó pequeño ahora es un gran negocio, donde las personas tienen el poder de tomar decisiones más rápidas y mejores y ofrecer mejores funciones de manera más rápida, con bajos índices de problemas para los usuarios. Con más equipos, mercado y competencia, la arquitectura de software de motores llegó al punto en el que el monolito que sirvió y llevó a la unidad hasta este punto ya no funciona. En algún momento, el monolito obstaculizó nuestra eficiencia para ser aún más rápidos y mejores, y, por ejemplo, el alto acoplamiento y los límites difusos constantemente ponían a nuestros equipos en el camino de los demás, lo que exigía un fuerte compromiso de alineación en todo momento. El progreso de las funciones comerciales también se vio afectado, ya que cada cambio provoca impactos en otros equipos, lo que ralentiza la entrega e incluso la calidad, ya que los impactos de estos cambios llevaban a pequeños pasos de entrega o incluso a un compromiso entre las partes. Por todo esto, el ritmo de entrega también se veía afectado por el monolito, ya que cada implementación tenía una alta probabilidad de detener el flujo debido al alto número de cambios que afectaban a todos los que necesitaban entregar. Reconociendo todo esto y en un esfuerzo por mejorar la independencia y la excelencia, el grupo de equipos que trabajan para impulsar el crecimiento del negocio de los vendedores profesionales a través de la adquisición, gestión y venta de vehículos, decidió poner en marcha un plan para alejarse del monolito reuniendo a un grupo de expertos en diseño dirigido por dominios para ayudar a los equipos a tener una mejor comprensión de los límites de responsabilidad y identificar las necesidades para pasar a una arquitectura desacoplada, permitiendo la autonomía, el trabajo independiente y las responsabilidades definidas. Pero una vez tomada esa decisión, ¿por dónde empezar? Bueno, la planificación estratégica ayuda a comprender cuáles son las inversiones de software más importantes que se deben realizar, qué activos de software existentes se deben aprovechar para llegar más rápido y de manera más segura, y quiénes deben estar involucrados. Esta planificación estratégica implica revisar los dominios actuales, utilizar sesiones de event-storming para definir contextos acotados y mapas de contexto, utilizar entidades, agregados y eventos de dominio para redefinir la arquitectura actual y alinear las responsabilidades de cada dominio con la carga cognitiva actual de los recursos del equipo. Basándonos en este trabajo de DDD, estamos logrando una base sólida para revisar nuestra arquitectura actual alineada con los bloques de construcción de DDD y los principios de modularidad, alta cohesión, bajo acoplamiento y ocultamiento de información. Y al final, reorganizamos nuestros gráficos de tribus de acuerdo con los dominios de los equipos y los modos de interacción, de modo que logremos una baja sobrecarga de comunicación, una toma de decisiones más rápida, una entrega más rápida y de calidad, y permitamos que nuestros equipos tengan autonomía, capacidades de salud mental sólidas y experiencia en los dominios de los que son responsables. En definitiva, nuestro objetivo es escalar y reorganizar nuestro gráfico de abajo hacia arriba, teniendo en cuenta nuestros dominios empresariales y sus relaciones de agregados, para establecer nuestra arquitectura del sistema, que a su vez da forma al panorama de los equipos, que a su vez construye una estructura organizativa que valida los principios de la ley de Conway, para influir positivamente en la velocidad de entrega, la calidad del trabajo y la autonomía, y luego impactar directamente en el software que estamos produciendo. Y eso es todo. Gracias por escuchar.