Seguimos tomando mal los requisitos de las aplicaciones y entregando al usuario productos que le complican la vida en vez de facilitársela. Algunos motivos de que esto ocurra son:
- No sabemos tomar requisitos.
- Desconocemos lo suficiente el negocio.
- Infravaloramos el problema (“si eso son dos if, o dos tablas…”).
- No pensamos en qué valor le vamos a aportar el usuario ni en cómo podemos medir el éxito de la solución en que vamos a trabajar. No pensamos en el medio y largo plazo.
En este podcast de Se-Radio, James Robertson comenta que los requisitos no son tan cambiantes como los programadores pensamos. Lo que pasa es que se entienden mal y cuando llegan al usuario nos pide cambios y creemos que nos ha cambiado los requisitos. Pero es cierto que el negocio de la gente no cambia todos los dias, al menos no tanto como solemos pensar.
Tomar bien los requisitos y guiar el desarrollo de la herramienta en base a los ejemplos concretos que contengan esos requisitos, lleva tiempo. Pero hay algunas pistas que nos pueden ayudar a saber si estamos tomando el camino equivocado. Recuerda que el sentido común va primero que ninguna metodología o técnica.
El test del Office dice:
¿Podemos implementar la solución con unos formularios en MS Access y/o una hoja de calculo?
- Si la respuesta es SI:
– ¿Seguro?, Entonces crea la hoja de Excel o los formularios de Access y entregalos a tu cliente. Le va a costar mucho mas barato que si te pones a programar!!! Si prefieres open source lo puedes hacer tambien con Libre Office :-). Pero si no estas tan seguro…
– Es muy probable que NO estes entiendiendo bien cual es el problema del cliente o lo estes infravalorando.
– Es muy probable que NO hayas hablado lo suficiente con el cliente.
– Es muy probable que NO te hayas puesto en su lugar.
En este punto, pensando que tu programa va a hacer lo mismo que el Office, es mejor que no comiences el desarrollo o que uses esos ficheros de Office para aprender mas cómo trabaja el cliente, y ver qué necesidades le siguen quedando descubiertas. Es decir, si no encuentras mejores formas de comunicación pasale la hoja de calculo y que se ponga a trabajar para que veas qué necesidades le siguen quedando sin cubrir. - Si la respuesta es NO:
Parece que conoces bastante el negocio y que tu solución se está pensando para adaptarse a tu cliente y no al revés. Entonces…
– Un test de aceptación (o una especificación),
> no puede ser algo como… “envio estos datos y en la base de datos me tiene que aparecer esto y aquello en tal tabla”: porque no hacemos programas para guardar datos en tablas. Para eso volvemos a poder usar MS Access, ¿recuerdas?
> no puede ser algo como… “hago click en ese botón y relleno ese campo y …” : porque el negocio del cliente no es pulsar botones. Queremos especificar comportamientos con valor de negocio, nada de botones.
– Si en algún punto hay que añadir una funcionalidad del estilo “Exportar a Excel”, habrá que pensar con cuidado si no estamos cayendo de nuevo en el test del office. Puede ser que NO quieras pintar gráficas con tu programa por ejemplo y que puedas exportar a Excel para que el usuario pinte graficas como quiera. Pero también puede ser que te falte conocimiento sobre el negocio y estés entregando a tu cliente un producto incompleto que no es capaz de resolverle su problema del todo. Y lo que es peor, ese desconocimiento del negocio luego va a provocar falsos “cambios en los requisitos” que van a salir caros.
Estamos acostumbrados a medir el coste de un desarrollo por el tiempo y numero de personas que han trabajado en él. Pero en esos costes nunca metemos la gran carga que supone mantener un código que NO resuelve el problema del cliente y que hay que seguir manteniendo. Es más barato borrar código escrito por alguien que malentendió el problema y volverlo a escribir, que mantenerlo. Pero nadie lo borra porque eso parece tirar dinero a la basura. Sin embargo eso, es lo que a menudo hace que los proyectos se retrasen, que el cliente sufra una “herramienta” que falla más que una escopeta de feria y que no le resulta cómoda de manejar. Y por último, es lo que hace que algunos programadores terminen por odiar su trabajo.
Antes de ponerse a programar hay que tener muy clarito por qué nos ponemos y en qué orden, ¡lo contrario es de locos! Y a ser posible, automatizar esas especificaciones en forma de tests de aceptación.