Mel Conway observó que hay una relación muy estrecha entre la estructura de un sistema y la estructura de la organización que lo diseñó.

Según Conway el software tiende a reflejar la estructura de la organización que lo construyó, por lo tanto una organización compleja, ineficiente y lenta, tiende a construir software complejo, ineficiente y lento.

Este artículo, el primero del grupo LeanALM360, nace inspirado precisamente en la ley de Conway y en la observación de todas aquellas organizaciones que tuve la oportunidad de conocer, en mi recorrido como consultor, instructor y coach, para empresas como Sun Microsystems, Red Hat y varias Universidades de la región. Trabajar con clientes de diferentes países (Chile, Perú, Argentina, Uruguay, Bolivia, Paraguay, etc.), pertenecientes a distintas industrias como gobierno, entretenimiento, salud y telecomunicaciones entre otras, me permitió  encontrar en cada una de estas organizaciones problemas similares de performance, disponibilidad, seguridad y usabilidad, que dan como resultado productos deficientes, que no cumplen con las expectativas de los Stakeholders. Inclusive algunos como resultados de proyectos que según sus métricas y objetivos fueron considerados exitosos. Lo interesante es que por más cambios de tecnología, de equipos, de proveedores, de líderes, de metodologías (RUP, Scrum, XP, ITIL, entre otras), estos problemas se vuelven a repetir una y otra vez en el tiempo. Ya es hora de que dejemos de apuntar a que el origen de estos problemas, es el enfoque en cascada o  una tecnología legada considerada obsoleta.

Una de las cosas que más me ha llamado la atención, es que en todas estas organizaciones no existe un consenso de lo que es realmente el producto. ¿Cómo construir algo en forma colaborativa entre equipos de marketing, legales, desarrollo, operaciones y diferentes proveedores, por solo nombrar algunos de los involucrados, si no tenemos claro que estamos construyendo. Nuevamente haciendo referencia a Conway, vemos que el diseño de organización tradicional existente en la mayoría de los casos en la región, trae claros problemas de comunicación y colaboración, que no permiten a los equipos tener una idea clara del producto que deben construir.

También he podido ver un enfoque de proyectos, programas y portfolios, que se encarga de construir el producto por partes, por lo general con diferentes equipos. Increíblemente muchos de estos proyectos que según sus métricas han terminado de forma exitosa, o por lo menos han pasado los criterios de aceptación, en la mayoría de los casos no están alineados con los objetivos de negocio del producto. Entonces, no deberíamos sorprendernos cuando estos productos son parecidos a “Gordon”.

Gordon es el monstruo creado por Victor Franskestein (James McAvoy) y su ayudante Igor (Daniel Radcliffe) en la película de Paul McGuigan con partes de cuerpos de animales, incluyendo la pata de una hiena, la cabeza de un mono y la pata de un perro (película de terror basado en adaptaciones contemporáneas de la novela de Mary Shelley de 1818 Frankenstein).

No menos increíble, y vale la pena recalcarlo, es que estos productos han pasado los test definido por estas organizaciones y hoy se encuentran en entornos productivos siendo utilizados por usuarios y clientes. Tampoco debería causarnos sorpresa, la lluvia de reclamos, debidos a incidentes y problemas, que llegan a diario de estos usuarios y clientes. Reclamos que en su mayoría no son por el aspecto o por las dificultades de usabilidad de estos productos, los usuarios ya se han acostumbrado y hasta han aceptado convivir con ellos. El tema es que además de su complicada funcionalidad y aspecto, tienen enormidad de problemas internos, deficiencias en la construcción. Acaso nos creímos que las mal formaciones de Gordon eran solo externas? Esto es lo que conocemos como deuda técnica, donde necesitamos de todas las horas de nuestros héroes (bomberos) tecnológicos, tanto internos, como de proveedores, para poder resucitar (volver a la vida) a nuestros monstruos (productos) para que vuelvan a hacer de las suyas (dificultarle el trabajo a los usuarios y clientes) resintiendo la productividad de la organización.

Una de las principales metas de LeanALM360 es abordar la deuda técnica, no solo a nivel tecnológico, sino que también haciendo foco en aspectos organizacionales, para que los equipos de producto puedan desarrollar todo su potencial.

 

Si estos temas son de tu interés, podes recibir un mail cada vez que publico, ademas tenes disponible para bajarte el  -> Gift del mesPor supuesto te agradezco que difundas por cualquier red.