Desarrollo de software. El mercado de los requisitos
Lo he dicho muchas veces y lo mantengo, es fundamental cerrar los requisitos en cualquier proyecto de desarrollo de software. Esa etapa es muy importante, como también lo es la definición de los casos de uso (aunque hasta hace poco tiempo, no los tenía en consideración).
Por ello, hay que dedicar el tiempo necesario a realizar estas tareas, ya que por mucho que se invierta, se recuperará después. Por tanto, se trata de deslizar esfuerzos (no necesariamente se requiere un coste adicional para reforzarlas, aunque si fuera necesario la inversión tendrá retorno, siempre y cuando se encuentre dentro de unos márgenes razonables y el trabajo esté bien hecho, tanto por el proveedor como por parte del cliente y de los usuarios) a estas etapas tempranas porque las posteriores se encuentran totalmente condicionadas por estas.
Los requisitos tienen sentido siempre y cuando se cierren con el cliente, es decir, que el cliente sea consciente de qué significa cerrarlos (que no es otra cosa que un compromiso entre las partes, un compromiso serio). Pero el cierre debe ser flexible ya que en las etapas posteriores del desarrollo, sobre todo cuando se empiezan a ver los primeros resultados de la aplicación (por parte del cliente) y cuando se está en plena construcción (por parte del desarrollador), se apreciarán mejoras interesantes respecto a las especificaciones iniciales, errores, funcionalidades que son prescindibles y otras que son complicadas de implementar.
Si se fuera absolutamente rígido respecto a los requisitos acordados, tendríamos un sistema que dejaría insatisfecho al cliente o incluso que tuviera algún aspecto importante sin implementar, sin que eso asegure unos resultados económicos para el proveedor, ya que lo mismo se ve obligado a desarrollar módulos complejos y costosos que van a tener escasa utilidad.
Es por eso por lo que llegará un momento en el proyecto donde se abrirá el mercado de los requisitos, donde cliente y proveedor se pondrán de acuerdo para cerrar el catálogo definitivo que definirá el conjunto de tareas a realizar antes de dar por terminado el proyecto (teniendo en cuenta que después será necesario un mantenimiento en la inmensa mayoría de los casos). En ese mercado tocará cambiar requisitos especificados en el análisis por otros no contemplados, la negociación en muchos casos no será fácil ya que cada parte defenderá sus intereses, habrá aspectos donde el acuerdo sea más sencillo y otros donde sea prácticamente imposible.
En función del proyecto, de su trayectoria, de los interlocutores, del tipo de cliente, del tipo de proveedor, el posicionamiento de ambos, se tomarán unas decisiones u otras con respecto a los aspectos en los que no se haya alcanzado un acuerdo, pudiendo intervenir personal de niveles superiores de ambas partes, de manera que se asuman en el proyecto ninguna, algunos o todos. Lo que quede fuera se ejecutará en el mantenimiento (o lo mismo funcionalidades que parecían interesantes al final no lo son tanto y no se realizan nunca o más tarde).
Jummp 