archivo

Archivos diarios: noviembre 28, 2012

¿Qué hacemos?, ¿aplicamos un enfoque clásico? Salvo que la naturaleza del proyecto aconseje que sea la mejor opción, no lo recomiendo, porque en este caso los problemas se centrarán sobre todo en el nivel de satisfacción del producto final y además, las solicitudes de modificación de los requisitos por parte del usuario en fases avanzadas del proyecto terminarán también por afectar a la agenda.

¿Y si el enfoque es iterativo incremental?

Vamos a ver en primer lugar las implicaciones que tiene trabajar con plazos predefinidos. Tener en el horizonte esas fechas límites lo podemos asemejar a las fechas límite que tenemos en cada sprint, con la diferencia de que la capacidad de trabajo asumible en cada sprint la define el equipo de proyecto, mientras que la fecha límite del plazo se ha definido sin conocer el alcance y complejidad real del proyecto y probablemente por un tercero.

¿Esto que quiere decir? De base nos comprometemos a cumplir los objetivos definidos en cada sprint, si esto es así, para el plazo especificado tendremos una serie de funcionalidades implementadas y listas para pasar a producción, ahora bien, ¿son las que estaban previstas conseguir en ese plazo? Ahí es donde está el problema y en donde hay que aplicar soluciones.

El product owner debe ser consciente en cada momento de lo que está hecho, de lo que se está haciendo y de lo que se tiene previsto hacer, si sabe que el equipo está trabajando bien, cuando vea que es complicado cumplir los plazos, afinará más en la priorización de las tareas, intentará acertar lo máximo posible en las especificaciones y tenderá a buscar soluciones más simples. Es posible que tenga que sacrificar algunas funcionalidades y retrasarlas a fases posteriores del proyecto, al principio mostrará resistencia, después se dará cuenta que pedir imposibles no lleva a ninguna parte.

El equipo de proyecto probablemente tendrá que ampliarse para poder asumir una mayor cantidad de trabajo y por otro tendrá que intentar ser lo más productivo posible. Ampliar el equipo produce resultados si nos anticipamos lo suficiente a esa demanda y si las personas que entran conocen la tecnología y entorno de desarrollo. Es muy posible además, que el equipo tenga que hacer un sobreesfuerzo. Esto no me gusta y debe ser la última opción porque afecta a las personas y si están cansadas y presionadas sufre también el producto.

Esto tiene implicaciones sobre la agenda, ya que estamos gastando más presupuesto del inicialmente definido para esta fase y evidentemente lo que gastemos de más ahora será dinero de menos que tendremos después. Es el product owner quien debe autorizar esto y lo mejor es que se llegue a una solución de consenso.

Anuncios