archivo

Archivo de la etiqueta: The Mythical Man Month

Comenta Frederick Brooks en su libro “The Mythical Man Month” que: “La mayoría de la documentación falla en que se da muy poca visión global. Se describen los árboles, se comentan la corteza y las hojas pero no hay un mapa del bosque”.

Estoy bastante de acuerdo con esa afirmación ya que resulta complejo obtener una visión global del sistema simplemente con la lectura de la documentación del proyecto porque como dice Brooks la información está segmentada y se describe con más o menos detalle cada uno de esos segmentos pero no el funcionamiento en conjunto de todos ellos.

Y todo esto en el caso de que haya alguien que revise la documentación de manera más o menos concienzuda, porque esa es otra, se pueden invertir innumerables horas de trabajo en tratar de hacerla con la mayor calidad posible, pero al final hay personas que tienen que leerla y entenderla y no suele haber gente con mucho tiempo y/o paciencia para iniciar sobre ella un proceso iterativo de revisión y mejora.

Esto es un problema importante cuando se desarrolla basado prácticamente en exclusividad en la documentación y no se suple esa carencia a través de la comunicación con personas que puedan ofrecer la información necesarias para cubrir los huecos en la misma lo que provoca generalmente problemas de coherencia en el sistema y aspectos funcionales a los que el desarrollador da una solución sin entender realmente qué lugar ocupa esa funcionalidad dentro del sistema.

La solución, como comento en el párrafo anterior, es la comunicación y además (y en lo posible) en explicar lo que tiene que hacer el sistema y las expectativas del usuario a quien no haya tenido la oportunidad de conocerlo, algo que generalmente (y desgraciadamente) no se suele hacer.

Todas las medidas que supongan un obstáculo a la comunicación entre los componentes de un equipo de trabajo o entre equipos de trabajo diferentes suponen una resistencia importante al proyecto de desarrollo de software.

Se pueden establecer ciertas reglas orientadas a conseguir un mayor orden y una comunicación más eficiente pero es necesario evitar todas aquellas que creen entre personas y equipos que den lugar a que la comunicación sea mayoritariamente asíncrona (cuando no prácticamente inexistente) provocando un distanciamiento entre los equipos (no se trata de un hecho físico ya que pueden estar distanciados equipos que incluso trabajan en la misma sala), la aparición de antipatrones como: “Arrojar al otro lado del muro y que las funcionalidades se desarrollen o las decisiones se tomen sin contar con toda la información disponible lo que dará lugar a unos mayores costes debido al más que probable incremento del número de iteraciones necesarias para tener el producto.

A veces la comunicación se deteriora por conflictos entre personas o entre equipos que provocan que como medida de autodefensa se pongan como un escudo que dificulta o impide la comunicación. Por el bien del proyecto y de las personas que participan en él este tipo de situaciones hay que atajarlas cuanto antes y no dejarlas ir porque cuando se entra en enfrentamientos personales los mismos no terminan por arte de magia cuando acaba el proyecto.

También los gestores cuando no tienen una visión global tienen mucha que ver con el aislamiento de los equipos de trabajo.

Frederick Brooks en su libro “The Mythical Man Month” comenta lo siguiente: “Entonces, ¿cómo se comunicarán los equipos unos con otros? De tantas formas como sea posible”.

Llegado un momento se toma la decisión de hacer una nueva versión de un sistema de información porque se entiende que está obsoleto tecnológicamente (resulta complicado encontrar desarrolladores para ese lenguaje de programación, el sistema de gestión de base de datos o el servidor de aplicaciones ha quedado sin soporte, etc…) o porque el coste de mantenimiento es muy alto y es necesario hacer modificaciones sobre funcionalidades ya existentes o el desarrollo de otras nuevas, etc…

Ese producto de partida conseguía su propósito y era utilizado de manera productiva por los usuarios y por la organización (lo cual no quiere decir que todo su camino para llegar a esa situación fuera sencillo o que nunca hubiera problemas).

Este antipatrón surge cuando se quiere aprovechar el nuevo sistema para incluir todas (muchas) las “cartas a los Reyes Magos” que usuarios, gestores y desarrolladores habían estado guardando todos estos años (más otras que se le ocurran sobre la marcha).

Una mala selección de las mismas dará lugar a un nuevo sistema que habrá sobrepasado con creces el presupuesto de partida, sin que exista un incremento de valor proporcional, mucho más grande que el que realmente se necesita, igual o más complejo de mantener que el anterior, en el que que tendrá problemas a la hora de implantarse porque será mucho más difícil de utilizar y administrar y con una más que probable importante tasa de errores y deficiencias funcionales de partida.

Arreglar esta situación es muy complicado, en algunos casos casi que lo más recomendable es empezar de nuevo.

A todo esto hay que añadir que el sistema anterior pesará como una losa sobre los desarrolladores porque los usuarios (los del día a día, más que aquellos que han intervenido en la definición de la nueva versión) siempre lo tendrán como referencia y lo estarán comparando continuamente y además, y sobre todo, los gestores verán como procesos que antes se desarrollaban de manera eficiente ahora cuesta más trabajo hacerlos, con el consiguiente coste económico que eso tiene, y pedirán cuentas por no tener un retorno de la inversión a la altura del desembolso realizado. Todo esto creará una situación de presión y unas prisas que poco bien harán para la mejora paulatina del sistema.

El término “Efecto segundo sistema” fue utilizado por primera vez por Frederick Brooks en su libro “The Mythical Man-Month”.