Un error frecuente es creerse de manera sincera, que los usuarios tendrán tiempo/ganas de leer todos esos documentos que especifican los requerimientos del producto de software, que creen que necesitan.

El desarrollador-analista asume (muchas veces… muchísimas veces) que el usuario leerá lo que le envía por correo, el usuario asume (siempre) que todo lo que dijo en las reuniones de definición, era bastante claro y detallado para que –alguien que “sabe del negocio”– lo entienda bastante bien. La mayoría de las veces que presencié esto, ambos supuestos estaban equivocados y en tales circunstancias me han asaltado interrogantes como estas:

1) ¿Es mucho pedir a un desarrollador-analista que intente explicar de manera detallada, en una reunión, cara a cara (aún virtual), lo que ha documentado como requerimientos del producto que cree que satisfará las necesidades del usuario?

2) ¿No es útil ayudar al usuario a entender, visualizar e “interactuar” con el producto en “planos”?

3) ¿No es mejor tener los “peros”, comentarios, realimentación y aún “cambios de idea” por parte de los usuarios (y otros implicados) lo más temprano posible?

4) ¿No le cuesta menos a un proyecto intentar resolver esto, tempranamente, antes de gastar esfuerzo en diseñar/codificar un producto que será destruido por sus usuarios en un momento posterior, al que llamamos “pruebas”?

Mis respuestas a estas preguntas siempre son:

1) Sí. 2) Sí. 3) Sí y 4) Sí.

Lo sabré cuando lo vea

El término que usamos en la industria de software para esto es “Validación de requerimientos”. Independiente de lo que usemos (Casos de uso, User Stories, IEEE830, un estándar propio) para especificar los requerimientos, siempre será necesario validarlos.

Además, tengamos en cuenta que la experiencia –de muchos años, de miles de proyectos y millones (o miles de millones) de horas hombre derrochadas en proyectos que fracasaron– ya demostró que es mejor hacer esto en iteraciones.

El efecto de los usuarios al que llamamos IKIWISI (“I’ll Know It When I See It”) o “Lo-sabré-cuando-lo-vea”, es real, existe, ¿por qué no usarlo a favor del proyecto?.

EOF