MANUAL M1

M1: LA DIRECCIÓN DE PROYECTOS EN EL SXXI

Cuando se sabe claramente casi todo lo que hay que hacer, es muy eficiente trabajar por lotes: primero todos los requisitos, luego toda la especificación funcional, etc. Ya que nos ponemos a desarrollar el sistema de información en español, hagámoslo también en inglés... Igual que el agua no vuelve hacia arriba en una cascada, una vez se avanza a la siguiente fase, ya no se vuelve a la anterior. Como todo el mundo sabe, este modelo en cascada generalmente no funciona para informática de gestión ni para desarrollos web, pero sigue usándose para desarrollar software de misión crítica –por ejemplo en el sector aeronáutico– , software embebido –sirva como ejemplo el software que puede haber en un coche autónomo–, o bien en productos software con un componente muy alto de requisitos no funcionales, o con un roadmap muy predeterminado, etc. ¿Por qué no sirve el modelo en cascada para la mayoría de proyectos software, dirigidos a usuarios finales que deben utilizarlos para realizar determinadas operativas? Sencillamente, porque es muy difícil, si no imposible, cerrar apropiadamente los requisitos del sistema de información. Si trabajamos en cascada y entregamos por primera vez después de 5 meses, lo más probable es que se rechace mucha funcionalidad y haya que asumir mucho retrabajo.

El gran drama del software es que “el cliente no sabe lo que quiere, solo sabe lo que no quiere”, de ahí que sea tan rentable hacer iteraciones frecuentes para demostrar algo funcionando, típicamente cada 2 semanas.

En un plazo de proyecto predeterminado para realizar un trabajo que se visualiza en líneas generales con los requisitos de alto nivel, y con un tamaño de equipo más o menos estable, se puede calcular fácilmente una primera estimación del presupuesto.

En un proyecto real estamos desarrollando una herramienta con ayuda de una software Factory en india. En terminología Scrum, nosotros nos consideramos “chicken”. En el proyecto asumimos los roles de business analyst y project manager. Hablamos con el Product Owner y detrás hay un equipo técnico y el Scrum Master.

47

European Open Business School