Páginas

lunes, 10 de noviembre de 2008

Cómo crear una aplicación web. Fase I. Toma de requisitos

El primer paso de cualquier proyecto que tenga como finalidad construir una aplicación informática es escuchar a los clientes y/o usuarios para saber qué necesitan. En una primera serie de reuniones simplemente  debemos escuchar y tomar notas de las funcionalidades que debe cumplir el nuevo sistema. No debemos juzgar si tal requisito se hará de tal manera o si ese requisito es innecesario. Debemos recordar que el trabajo de crear una aplicación web debe estar orientado a la consecución de los objetivos del cliente, no a la satisfacción de los creadores. La satisfacción de los creadores (arquitectos, jefes de proyecto y programadores) debe ser la de crear un producto sin errores, escalable, on-time y que cumpla al 100% las necesidades del cliente. 

Idealmente, la toma de requisitos debe realizarse antes del presupuesto en tiempo y dinero ya que es imposible presupuestar un proyecto del que no se sabe exactamente qué se desea. La fase de la toma de requisitos debe afrontarse como una coste comercial, ya que es posible que si no se ha firmado el contrato el proyecto finalmente no se gane. En la mayoría de los proyectos para administraciones públicas o grandes empresas donde se convoca un concurso mediante RFP se comete el error de presupuestar a partir de unos requisitos redactados por el cliente de forma poco exhaustiva por lo que es fácil que aparezcan desvíos tanto en tiempo de entrega, funcionalidades o precios desorbitados.

Una vez hemos tomado nota de los requisitos el siguiente paso, ya de manera interna es ordenar esas ideas. Una buena manera de ordenar ideas es crear, repito, de forma interna, una modelo de datos a partir de las decenas y decenas de ideas que el cliente nos ha transmitido. El cliente no tiene porqué saber (según un ejemplo de aplicación tipo Facebook) si los “amigos del usuario” puede ser lo mismo a efectos de programación que un “usuario”. Debemos ser capaces de reducir todas las ideas recogidas en la primera reunión en un modelo de datos (por ejemplo un modelo entidad-relación a alto nivel).

En la siguiente reunión tomaremos el control y a partir de la lectura de nuestro modelo de datos (traducción de cajas y líneas a prosa) debemos ir confirmado con el cliente que esas son las funcionalidades lo que su empresa necesita. En esa misma reunión debemos proponer temas que puedan aportar valor al cliente y basados en nuestra experiencia: integrar aplicaciones de terceros, formas de enfocar la arquitectura de la información, software existente, etc.

Esta fase y dependiendo de la envergadura del proyecto y/o del cliente puede convertirse en iteraciones de reuniones de toma de requisitos con diferentes responsables de áreas implicadas.

2 comentarios:

jfvalenzu dijo...

David,
Muy interesante tu artículo..
en general estoy de acuerdo en muchas de las consideraciones que planteas al hacer una toma de requisitos, pero me gustaría saber
¿en qué momento realizas el presupuesto? considerando que el análisis y la estimación de las tareas puede ser riesgosa y tomar mucho tiempo, conoces alguna manera de saber hasta que punto tus estimaciones pueden abarcar el costo final del proyecto?

David Sánchez dijo...

En una situación ideal el presupuesto final debe realizarse una vez tienes los requisitos. Si estas obligado a presentar presupuesto antes de la toma final de requisitos (aunque nunca es final del todo ;) debe ser tu experiencia en el desarrollo de aplicaciones similares la que te lleve a realizar un cálculo que se avance a lo que el cliente te va a pedir. Cuanta más experiencia en proyectos similares atesores mejor te avanzarás a las necesidades del cliente y seguro que serás tú quien defina buena parte de los requisitos. Sé conservador marcando el precio, pero ajustate para poder ganar el proyecto. NO seas de esos que por vender un proyecto sí o sí hipotecan el trabajo de sus técnicos!! :)