¿Qué es la maniobra inversa de Conway (reverse Conway maneuver)?.

por Publicado el

En este post te voy a explicar que es la maniobra inversa de Conway, y porque te puede ser útil en el diseño de tus aplicaciones.

La primera mención de esta maniobra, la encuentras en el libro: Accelerate:The Science Of Devops. Dice:

 

Our research lends support to what is sometimes called the «inverse Conway maneuver,» which states that organizations should evolve their team and organizational structure to achieve the desired architecture. The goal is for your architecture to support the ability of teams to get their work done-from design through to deployment- without requiring high-bandwidth communication between teams.

¿Qué es la maniobra inversa de Conway?.

La ley de Conway sugiere que la arquitectura de un sistema computacional será un reflejo de como está constituida la organización que produce el software. Por lo tanto, la maniobra inversa de Conway, significa rediseñar la estructura de una organización primero, para que esta se adapte a la arquitectura de software que se desea producir.

Y eso, ¿Cómo me afecta?.

Los rediseños y mejoras de las arquitecturas de las aplicaciones, suelen representar el esfuerzo de uno, o más equipos, incluso de la compañía completa. Es importante trabajar en dos vías, la del software, y la de las personas, con el fin de llegar al estado deseado en ambos. Si trabajas, enfocándote única y exclusivamente en el software, tus posibilidades de fallar se incrementan.

No existen balas de plata.

No hay una respuesta única y correcta para organizar tu equipo de desarrollo correctamente, desgraciadamente, si hay múltiples soluciones incorrectas al momento de organizar la arquitectura de tu organización. Debes de tener cuidado, y estar preparado para el fallo.

¿Qué pasa, si solo modifico la arquitectura del software?.

La respuesta es ambigua. Lo que sucede al diseñar una aplicación sin tener en cuenta la estructura organizacional, es: las posibilidades de éxito pueden verse reducidas. Ya que tiene más peso la estructura organizacional que la del código.

¿Cómo diseño la estructura de mi equipo?.

De nuevo, otra respuesta ambigua. Debes de entender donde están los cuellos de botella. Cuáles son los SILOS de pensamiento, o estructuras organizacionales que impiden el flujo de trabajo. Si tienes una base de datos monolítica, bueno, es posible que solamente una persona sea la encargada de modificarla. Si todos tus equipos terminan consultando al mismo DBA, va a ser complicado cambiar el modelo actual, por uno más desacoplado. En lugar de tener el monopolio del conocimiento en una sola persona, puedes, estructurar tus equipos para que exista un miembro del equipo tome el rol del base de datos. El DBA sería llamado, nada más, como asesor y especialista en casos difíciles.

Otro ejemplo puede ser. Que la entrega de la aplicación se retrasa debido a que la transición entre áreas, es lenta, y llena de rollbacks. Este escenario se da, por falta de comunicación entre departamentos o equipos. Para reducir los tiempos, los equipos pueden tener un asesor del área conflictiva que ayude al equipo a entregar de manera más eficiente. ¿Muchos retornos de QA?; el equipo necesita ayuda para entender que defectos están pasando sin ser vistos por el área de desarrollo. ¿El producto entregado no es el correcto?. Bueno, quizá, los requerimientos no son entendidos correctamente por el equipo de desarrollo. O estos no son levantados correctamente. Se necesita un acercamiento de áreas, o incluso un responsable que sirva de puente de comunicación entre equipos.

Conclusiones.

El desarrollo de software moderno, exige cada vez más trabajo en equipo interdisciplinario. Los sistemas deben de ser diseñados teniendo en cuenta al equipo que les va a dar mantenimiento. Necesitamos equipos generalistas, conformados por una serie de distintos especialistas que permitan facilitar el envío de un buen producto, y el producto correcto.

 

Referencias:

Photo by Marvin Meyer on Unsplash

Gustavo Sánchez
Últimas entradas de Gustavo Sánchez (ver todo)

Publicado por Gustavo Sánchez

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.