"Las capacidades de los programadores (y no las necesidades del cliente) conducen los requisitos, sin importar lo que digan los textos de ingeniería de software"

http://blog.pixagora.com/2011/01/ingenieria-aeroespacial-y-desarrollo-de-software/

Cuenta la leyenda que estaba el ingeniero de requisitos tomando los requerimientos para uno de los proyectos importantes de la compañía, cuando el cliente le pregunta si es posible tener dentro de la página que están especificando, un control reloj de tipo análogo en el que él pudiera mover las manecillas y así establecer unas horas que se necesitaba para el funcionamiento de la interfaz.  Dicen que el de requisitos aceptó encantado dicha solicitud al no verle "inconvenientes", pero al momento de entregarla se encontró con el siguiente problema: el desarrollador asignado a esta tarea le comunicó que ese control era todo un proyecto aparte y que le tomaría más del doble del tiempo crear la página con dicho control.

Muy a su pesar, el ingeniero de requisitos tuvo que volver donde el cliente a explicarle el por qué el proyecto iba a costar y demorar más.  Obviamente este no vio con buenos ojos lo que le estaban diciendo y lleno de ira le dijo que eso no era lo que habían acordado, que se lo tenían que entregar como lo había solicitado, dentro del tiempo y presupuesto pactado.  Podrán imaginar cómo terminó la historia, tanto para el ingeniero de requisitos como para el desarrollador.

Para todos los que hemos desarrollado software alguna vez, esta historia es nuestra peor pesadilla: saber que tendrás que hacer un gran esfuerzo adicional gracias a un requerimiento mal tomado; o peor aún, a un compromiso pactado con el cliente el cual no te fue consultado (o al menos con el arquitecto del proyecto) para verificar su viabilidad.  Todas las etapas en el desarrollo de software son indispensables e importantes, pero hay que entender que no es un proceso lineal que asciende en espiral como muchos piensan; sino que es un ciclo de retroalimentaciones y congelamientos de requerimientos constantes que llevarán finalmente al software deseado.

Retomando la frase del comienzo de este artículo, es importante aclarar que no es que lo que desee el cliente no es importante, lógicamente es lo que nos dará las pautas para el modelamiento del sistema; pero no debe de ser la característica más importante al momento de planear las tareas y comprometerse con tiempos y entregas, ya que si usted como gerente no tiene en cuenta el equipo de trabajo con el que cuenta, muy seguramente siempre se verá "colgado" y con un cliente insatisfecho.  A mi parecer, un panorama para nada alentador para usted y su empresa.

Si usted, señor gerente de proyectos de software, hace su planeación de trabajo teniendo en la cabeza qué tipo de habilidades tienen los desarrolladores que trabajan con usted, le aseguro que se ahorrará muchas horas de dolor de cabeza y no generará sobrecarga de sus recursos y aplazamientos.  Y si usted, además de esto, considera el tiempo en la organización, tiempo en el proyecto y conocimiento de los procesos organizacionales de los involucrados en la ejecución, sus estimados serán muchísimo más acertados y su equipo trabajará y rendirá más.

La invitación es pues, a no centrarse solamente en lo que el cliente quiere y como lo quiere, recuerde que muchas veces ni él mismo sabe lo que desea y es su trabajo el de asesorarlo y guiarlo hacia lo que ambos desean: un software funcional y con el mínimo de defectos; eso si, considerando siempre el equipo de trabajo con el que cuenta para realizar dichas tareas, no sea que su cliente quiera adicionar también un control reloj a su aplicación.