reflexiones sobre la cosa esta de los proyectos
Es algo que ocurre en prácticamente todos los proyectos por los que paso. Nos quejamos de que los clientes no saben nunca lo que quieren, pero ¿es esto siempre así? Creo que estamos tan acostumbrados a ese modo de pensar que no siempre salimos de la caja para ver las cosas desde otro ángulo.
Si el cliente no sabe lo que quiere o no lo tiene demasiado claro, creo que sería la tarea del analista de negocio acompañar al cliente en el trabajo de dilucidar y concretar las necesidades del cliente para plasmarlas en una serie de requerimientos. Quizás cuando nadie tiene las cosas claras, ni el cliente ni los consultores / programadores externos, lo que en realidad está ocurriendo es que nadie ha vinculado el proyecto a un objetivo de negocio concreto y significativo. Nadie ha expresado en términos exactos y mensurables el objetivo del proyecto.
El papel del analista de negocios no es solamente el de acudir a reuniones a “recibir palos” o a tomar requisitos como el taquígrafo de un juzgado. Realmente, lo que debe hacer es ser capaz de orientar al cliente y de saber decir no cuando sea necesario.
Un ejemplo común sería “queremos que el sitio tenga un aspecto moderno”, frente a “queremos un sitio que cumpla con los estándares de usabilidad y que atraiga un 20% más de tráfico estando bien posicionado con técnicas SEO.” Este último objetivo es mucho más mensurable y concreto para todo el mundo que el primero. Pero para llegar aquí muchas veces hay que hacer un trabajo previo con el cliente que, por desgracia, tiende a considerarse “poco productivo.” Y es que existe una innegable cultura de la urgencia por ambas partes, cliente y consultor externo, por empezar a generar código desde el día uno, como si ese fuera el único “deliverable” o lo único que importa. Si se hace esta tarea previa de análisis y se toma la vía de concretar todos y cada uno de los objetivos es difícil no refinar el producto y acabar teniendo algo que se acerca mucho más a lo que el cliente quiere y necesita realmente.
Esto nos lleva a la importancia que puede tener en muchos casos la creación de “mockups” iniciales o prototipos como herramienta de análisis y definición de requisitos. Y no hay que tener miedo a hacer ofertas a precio cerrado por unos mockups o prototipos antes de empezar o como parte inicial del proyecto. El valor indudable de estos recursos es el de no tener que rehacer partes mucho mas significativas del desarrollo posterior.
Además, a partir de estos prototipos es bastante más facil hacer una “ingeniería inversa” para obtener requisitos de negocio. Tras esto, es más fácil conseguir cerrar un acuerdo con los requisitos exactos que se van a plasmar. Es más fácil definir una gestión del cambio, es más seguro para el contratado definir cuantas revisiones dentro de coste se pueden afrontar, porque se conoce mejor el coste de cada una de estas piezas. Este es el mejor valor añadido que puede aportar un analista que tiene el margen suficiente para hacer su trabajo, porque por desgracia no siempre es posible hacer las cosas de esta manera, por esa cultura de la urgencia que todos padecemos, que a veces no nos permite ni evaluar las herramientas con las que tenemos que trabajar, aunque ese es otro tema.
Y si el cliente finalmente no escucha, es terco, o quiere una solución de 60000 euros por 15000, solo hay dos opciones, o decir que no, o darle una solucion de 15000. Pero primero se debe hacer los deberes.
