Muchas veces en el mundo del desarrollo de software (aunque es extensible a otras áreas) nos enfrentamos a proyectos de los que yo denomino de “Cuadrar Círculos“. Son proyectos en los que dentro de la lista de requisitos existen algunos que es difícil (o imposible) cumplirlos a la vez, pero por alguna extraña razón quien define (o paga) el proyecto decide que el sistema a desarrollar tiene que incluirlos sí o sí.
Da igual las razones que expongas para hacer ver que lo que te piden es un imposible o que en resumidas cuentas te están plantando como requisito la cuadratura del círculo. Eres del equipo de tecnología y tienes que conseguirlo que para eso estás ahí. En estos casos me acuerdo mucho del relato “Oír Gilipolleces“, concretamente del pasaje en el que el jefe le pide que desarrolle algo genérico y reutilizable pero a su vez específico.
En ese momento, el equipo de desarrollo se llena de resignación y se pone manos a la obra para diseñar una solución al problema. Normalmente esta decisión errónea lleva a continuas y eternas reuniones que yo llamo “del día de la marmota” (ya hablaré en otro post sobre ellas) en las que tras discutir, pintar innumerables esquemas, darle mil vueltas al problema, valorar cientos de soluciones y dejar secos una cantidad ingente de rotuladores siempre se llega a la misma conclusión: que cumplir todos los requisitos es prácticamente imposible o bien lleva a una solución extremadamente compleja. Además, esta búsqueda de lo imposible consume muchísimo tiempo y esfuerzo para nada.
Este tipo de proyectos son un gran peligro para cualquier organización, porque lo normal es que finalmente el equipo se salte todas las reglas o recomendaciones del departamento de arquitectura de software e implemente una solución compleja, difícil de mantener, con baja calidad y por lo tanto cara. Esto es peor todavía cuando los nuevos requisitos incompatibles se introducen como evolutivos de un proyecto ya implantado. En este caso lo normal es que se haga añicos la arquitectura correcta de la solución y se llene de parches, desarrollados en lo que yo denomino “modo ñapa“, incrementando innecesariamente el coste de mantenimiento.
Evitar estos problemas es a veces muy difícil porque en muchas ocasiones los responsables definir el producto no hacen un exhaustivo análisis de todas las implicaciones que cada requisito conlleva (o lo que es peor, no tienen el conocimiento ni la capacidad necesaria para poder hacerlo) pero tampoco permiten que el equipo de ingeniería proponga modificaciones al respecto… pero de esto último ya hablaré en otra ocasión, que es un tema que da para mucho







Ya está disponible el número 63 de la revista