5 graves e históricos errores software… derivados de creer que gestionar software es lo mismo que construir cosas físicas

Me comentaba el otro día un compañero que estaba ya harto de escuchar absurdos consejos de compañeros de trabajo que se dedicaban a la arquitectura, la de edificios, sobre cómo se resolverían los problemas de los proyectos software. Consejos que, cómo no, se basaban en aplicar al software los modelos de gestión que utilizan ellos, los arquitectos, los de edificios sí.
Mi visión está muy alejada del anterior consejo. Es más, creo que los principales errores de gestión en proyectos software vienen, justamente, de intentar aplicar modelos de gestión copiados de arquitectos, a ingenieros de caminos, de hardware, etc.
Pensar que construir software sigue principios de construcción de cosas físicas ha provocado los mayores errores en la gestión software, valgan estos 5 tan horrorosos como reales ejemplos:
1 – Medir el avance el proyecto en función del número de líneas de código. Recuerdo una empresa que medían la productividad de sus desarrolladores en función de sus líneas de código por mes. Un clásico, una de las prácticas más absurdas e incompetentes gestionando un proyecto software. Lo curioso es que, aún hoy, la encuentro en algunas empresas. Supongo que a cualquiera le parecerá razonable que si un edificio está más avanzado es porque tiene más metros de ladrillos construido, pero… ¿qué un software esté más avanzado por tener más líneas de código?. Absurdo total.
2 – Los requisitos deben ser inamovibles. Un día me comentó un arquitecto que nuestro problema con el software era que “empezábamos los proyectos con requisitos no cerrados”. Yo le contesté que en su mundo, el de los edificios, cierran requisitos porque pueden, porque los requisitos para hacer un edificio no cambian. Pero lo que demanda un nuevo modelo de negocio no es que cambie… es que nadie lo sabe, y por ello es difícilmente especificable. En software implementamos ideas y no edificios, y las ideas cambian, evolucionan y se matizan. Además, el software puede cambiarse, un edificio no, y eso es una ventaja a saber aprovechar.
3 – El ciclo de vida en cascada. Nunca olvidaré aquella empresa en la que jamás fui capaz de que entendieran que el software se puede construir “por partes” (incrementalmente) e iterativamente. Nadie construiría un puente tomando unos pocos requisitos, haciendo un poco de puente, tomando otros pocos requisitos, haciendo otro trozo del puente, etc. Pero el software si se puede construir así… y eso le otorga una gran ventaja a saber aprovechar.
4 – Para que un proyecto ya comenzado vaya más rápido… hay que añadir más gente al equipo. Otro clásico, en charlas siempre comento varias situaciones reales relacionadas, como la de aquel software llevaba ya más de un año de retraso y el pobre cliente aún se empeñaba en que la solución era meter más programadores. Hasta estaba dispuesto a pagarlos él.  El software no funciona así, porque es una actividad intelectual, no física, y añadir gente a un proyecto retrasado lo retrasa más. Por no extenderme, te dejo este post sobre el tema.
5 – El contrato cerrado o llave en mano. Ya solo lo del “llave en mano” suena a la entrega de llaves del nuevo piso. Este punto es un compendio de los anteriores, al igual que se subcontrata una obra, cerrando requisitos y plazos antes de empezar… igual debe hacerse el software, pero, si los requisitos del software no siempre pueden cerrarse, simplemente porque descubrimos nuevas ideas para el producto según lo construimos… ¿cómo puede funcionar ese modelo? Te dejo aquel post de contrato cerrado, ¿el peor enemigo del software o mal necesario?