Os presento una situación bastante corriente: hemos conseguido un contrato para el mantenimiento de una aplicación web Java, con almacenamiento en una base de datos Oracle, donde se hace un amplio uso de procedimientos almacenados, y una carga fuerte de JavaScript en la capa de presentación. Se trata de un proyecto largo (más de un año) para un equipo pequeño (digamos que el presupuesto no es muy amplio). Hacemos algunos cálculos, pensamos en los escenarios más probables que nos vamos a encontrar y llegamos a la conclusión de que vamos a dimensionar el equipo con tres personas.
Tenemos ahora que pensar en quiénes formarán parte del equipo. ¿Sabéis una cosa? Lo más probable es que la inmensa mayoría de los responsables de proyecto o, al menos, los que suelen completar sus proyectos con éxito, decidirán tener en su equipo a:
- Un desarrollador Java
- Un experto en bases de datos Oracle
- Un programador web con amplios conocimientos de JavaScript
Parece una decisión bastante lógica, ¿no? Pues bien, no es más que la inversión de una regla bastante antigua aunque, a veces, desconocida en el desarrollo de software: la ley de Conway.
Cualquier organización que afronte el proceso de diseñar un sistema de información diseñará uno que copie las estructuras de comunicación de la organización.
O, dicho de otra forma:
La arquitectura de un sistema refleja la estructura del equipo que la diseñó.
Junta a un desarrollador Java con un programador JavaScript y un experto Oracle y tendrás una aplicación en tres capas, posiblemente con procedimientos almacenados en la base de datos y una interfaz rica en el navegador. ¿No quieres procedimientos almacenados? Quita al experto en Oracle del equipo. Organiza un equipo de tres desarrolladores para construir un compilador y tendrás un compilador en tres fases. Estos diseños serán utilizados incluso aunque no sean los más apropiados para el sistema que queremos construir.
Las decisiones sobre la arquitectura del sistema se empiezan a tomar incluso antes de que nadie haya dibujado el primer diagrama ni escrito la primera línea de código: las tomamos cuando decidimos el equipo que queremos para nuestro proyecto.
Se toman cuando menos información tenemos sobre el sistema (justo al principio del proyecto) y las toman las personas que menos conocimientos tienen para hacerlo (los jefes de proyecto).
¿Cómo podemos evitar esto?
En primer lugar, intenta empezar el proyecto con el equipo más pequeño posible. Ten en cuenta que cada persona que añadas al equipo del proyecto supone una carga más en la arquitectura del sistema. Y demasiada arquitectura puede ser incluso más perjudicial para el resultado que tener muy poca arquitectura. Formando un equipo pequeño al principio, estarás tomando las mínimas decisiones sobre la arquitectura final del proyecto.
En segundo lugar, busca los perfiles más generalistas a la hora de formar el equipo en vez de meter a personas con una única (o un reducido número de) habilidades. En este caso, es mejor ese desarrollador Java al que no le importa trabajar en la base de datos y que puede defenderse a la hora de hacer interfaces web que un gurú de Oracle o un ninja del JavaScript. Puede que, con el tiempo, llegues a necesitar esos perfiles, pero te aseguro que es mejor retrasar su incorporación hasta que la arquitectura esté completamente clara.
Como podéis ver, todos los proyectos tienen, al menos, un arquitecto. Uno que decide sobre el diseño del sistema de una forma muy peculiar: sin diagramas ni documentos de arquitectura sino asignando personas al equipo que se va a encargar de construirlo.
Mi recomendación para cualquier jefe de proyecto es que evite en la medida de lo posible convertirse en ese arquitecto. Por el bien de su proyecto.