Lo perfecto es enemigo de lo bueno

Esta célebre frase de Voltaire argumenta que es preferible hacer una cosa con una calidad buena en un tiempo razonable, que algo excelente o perfecto dedicando a la tarea un tiempo excesivo.

Actuar en consonancia con lo dicho en esta frase depende de la forma de ser de cada uno. Si una persona tiene un carácter bastante perfeccionista y reglado, difícilmente podrá obrar en detrimento de buscar la solución fetén.

En el mundo del desarrollo del SW esta disyuntiva entre buscar la perfección o encontrar una solución decente cobra especial importancia y a menudo es preciso decidir entre estas dos alternativas.

Las metodologías ágiles tienen muy presente el razonamiento de Voltaire y procuran enfocar los desarrollos iniciales hacia la problemática general, en vez de perderse en un sinfín de ramificaciones, excepciones o casos singulares que se pueden llegar a presentar en la vida real sobre la materia implementada. Es posteriormente en sucesivas fases evolutivas, una vez la aplicación está en producción y siendo usada, cuando se van abordando estas particularidades que se salen del común denominador.

Por el contrario, las metodologías clásicas abogan más por abordar todos los detalles antes de cambiar de fase. Como consecuencia surgen unas especificaciones más formales y por lo general de mayor complejidad.

Ya comenté en éste artículo que de momento en ingeniería del sw no hay una metodología o unas pautas consideradas correctas, que haya que aplicar sí o sí en aras a obtener los mejores resultados posibles. Sin embargo, sí que creo que gestionar proyectos de forma ágil suele ser la más acertada, descontando excepciones como puede ser el SW crítico.

Siguiendo este criterio de no buscar la solución perfecta y si resolver el problema genérico, existe una máxima que dice que se debería subir una versión a producción tan pronto como se disponga lo mínimo imprescindible para que un usuario pueda trabajar con ella. Seguir esta pauta implica que gran parte de elementos típicos de aplicaciones web como por ejemplo filtros de búsqueda, exportaciones a Excel, listados, estadísticas, plantillas, etc deberían postergarse y no figurar en una primera versión a no ser que sean de necesidad absoluta para el usuario.

La primera versión que se sube a producción se debe centrar exclusivamente en su lógica de negocio evitando al máximo elementos complementarios.

La razón es clara y lo decía Dave Parnas : “Por norma, los sistemas Sw no funcionan bien hasta que han sido utilizados y han fallado repetidamente en entornos reales”. Y subrayo lo de reales, porque hasta que no se ha trabajado en la configuración final y con datos ciertos no se verifica como se ajusta la aplicación respecto a las necesidades del usuario.

Es importante recibir ese feedback de usuario trabajando en real con la aplicación cuanto antes. Eso no exime a que previamente debe haber reuniones varias con los usuarios para la adecuada toma de requisitos y análisis.

No siempre es fácil seguir este criterio. Un usuario preferirá generalmente atar todos los cabos bien antes de empezar a usar la aplicación. Su razonamiento es lícito pero todavía lo es más el descubrir cuanto antes fallos o errores de concepto en la lógica fundamental de negocio.

Cuanto más se tarde en detectar errores en los requisitos principales en la aplicación más complejo será su posterior reparación y peor calidad tendrá el sw final.

Hay que agilizar al máximo la primera puesta en producción y luego demostrar al usuario que la aplicación está viva y se van atendiendo sus peticiones en sucesivas versiones. Estas deberían ser bastante frecuentes en los primeros compases (primer año fundamentalmente desde su nacimiento) e ir paulatinamente espaciando las nuevas versiones conforme pasa el tiempo. Si bien esta es la norma general siempre habrá excepciones y urgencias que lo impidan en casos concretos.

En mi opinión en la Administración Pública todavía se tiene una mentalidad demasiado conservadora. La mínima dificultad o imposibilidad de traducir a la perfección toda la casuística que afecte a la aplicación provoca que se paralicen los desarrollos. Ciertamente la contratación pública no favorece el trabajo desde la perspectiva ágil, ya que se parten de unos requisitos, marcados por los pliegos, que son inamovibles y dificultan sobremanera el rediseño. Como comenté en este artículo, la incertidumbre es inherente al desarrollo sw y por tanto exigir completa inamovilidad en los requisitos es en no pocas ocasiones utópico.

Concluyendo, en el ámbito tecnológico la perfección es un objetivo demasiado difícil de conseguir. Por esa razón conviene plantear una solución que permita trabajar en real a un usuario e ir evolucionándola a su gusto mediante versiones. Si el usuario siente que haces caso a sus demandas y se van atendiendo y corrigiendo de forma progresiva, tendrá una buena impresión de la aplicación pese a que ésta tenga sus problemas y fallos. De esta forma, una aplicación nunca termina y ese concepto a los financieros encargados de elaborar los presupuestos les cuesta demasiado asimilarlo.