El Valor del Software

El Valor del Software

En todos los desarrollos software, hay un tira y afloja con el usuario sobre lo que tiene que hacer el sistema. Una de estas fuentes, de estos tiras y aflojas, son la complejidad de los requisitos software que pide el usuario.

En estas situaciones, en mi opinión, hay que tener cuidado, ya que, si se tira mucho por parte del equipo de desarrollo sobre un requisito, es posible que el usuario, devalue la aplicación tanto, que no quede contento.

Si el usuario está solicitando un requisito que para el es de un gran valor para su trabajo, y finalmente, se modifica tanto ese requisito. Ese requisito no va a portar el valor que esperaba el usuario.

Esto me recuerda a un programilla que desarrolle para una amiga abogada. Este programa contaba a partir de una fecha y un plazo, el día en que vencía ese plazo (dies ad quem). Programar esto, es fácil, pero el valor para el usuario era grande. Pero al poco de ver como la aplicación calculaba el día que vencía el plazo, quiso que el programa se comunicara con su calendario de Google, de forma que le enviase un aviso por correo un día antes de que cumpliera.

Esto se vio pronto que era de un gran valor añadido, ya que ahorraba tiempo, y así, sería más díficil que un plazo se pasase. Pero había una complejidad técnica. Tenía que mirar la API de google. Entonces, tenía dos opciones (al menos en ese momento pensé):

a) Convencer al usuario para que la herramienta  implementara un envio de correo a su cuenta de correo y asi, lo tendría almacenado. La complejidad técnica es menor, ya que en .net esto se hace con unas cuantas lineas.

b) Mirar la API de google y tratar de comunicar el programa, CuentaPlazos, con el calendario de Google.

La opción a) deja al usuario sin centralidad en su calendario toda su actividad. Corriendo el riesgo de bajar el valor de la aplicación, y por consiguiente su uso.

La opción b) , aunque cuesta algo más de tiempo, añade valor a la aplicación, y así lo percibe el usuario.

Con este ejemplo creo que el identificar y mantener los requisitos con más valor para el usuario son fundamentales en el desarrollo software, ya que si no, es posible que no use el futuro software.

En el caso del CuentaPlazos, es posible, que si muestro un calendario con colorines de forma muy vistosa, pero luego, no se comunica con el calendario de google, la aplicación perdería valor para el usuario ya que no se ha implementado un requisito para él fundamental.

Y es que, en definitiva, un software que pide un cliente, debe de satisfacer a dicho cliente, y en el desarrollo habrá que poner los medios para alcanzar dicho objetivo.