Uno de los problemas que se advierten, a veces demasiado tarde, en el desarrollo de aplicaciones es el de confundir una necesidad con una solución. Cuando un usuario o cliente plantea un problema a resolver, en ocasiones, y normalmente sin quererlo, lo que nos está trasmitiendo es una forma de solucionar su problema, no el problema en sí.
Esto es peligroso, porque si finalmente se materializa lo que se nos ha pedido, y esto no se ajusta a lo que se necesitaba, el resultado puede desembocar en algo totalmente fallido o en un desarrollo que hay que parchear continuamente desde el momento en el que se le entrega.
Discriminar entre una necesidad y una solución no es fácil, porque las fronteras entre ambas cosas son difusas. Por ejemplo, se puede pedir desarrollar una aplicación web que haga algo, y durante el desarrollo o en la implantación descubrir que las funciones están bien descritas e implementadas y que el fallo está en haberlo concebido como una aplicación web.
Además las necesidades son de muy diversa índole: funcionales, operativas, rendimiento, usabilidad, etc. Para todas ellas hay que tener en cuenta cuándo su planteamiento se queda en el terreno de la necesidad o forma parte de la solución.
También es un error llevar las cosas demasiados lejos, y entrar en discusiones interminables sobre lo que es una necesidad y lo que es una solución. En algún momento hay que tomar decisiones y comprometerse. El hecho mismo de decidir el desarrollo de una aplicación para resolver algo, se puede considerar como una solución más que el planteamiento de una necesidad.
Lo que sí ayuda, es tener claras cada una de las decisiones que se han tomado, para que en caso de tener que revisar lo que se está haciendo saber qué cosas hay que replantearse.
Esto que planteo en el contexto del desarrollo software se puede aplicar a todo. De hecho, se trata de algo más general aplicado al desarrollo software.
