El mito de la fase dos

0

Desde los inicios de la gestión de proyectos se han encontrado muchas ocasiones para dividir el trabajo en fases. Dividimos el trabajo de lo que vamos a hacer en fases, de forma que en cada fase nos enfocamos a un problema más simple. Hacer el trabajo en fases, permite reducir la complejidad del problema que tenemos delante y muchas veces nos permite acelerar la entrega de los resultados de las primeras fases.

El desarrollo iterativo no es más que dividir el trabajo en fases pequeñas, muy pequeñas.

Esa es la cara buena de la fases, pero hay una cara mala: la fase dos.

La fase 2, la mala práctica

Arrancamos el desarrollo de una nueva aplicación, y más o menos tenemos claro lo que debe hacer esta aplicación. Empezamos sprint tras sprint a ir entregando cosas. De repente algo complejo se pone delante del equipo y a la hora de hablarlo con los stakeholders, el product owner suelta «esta funcionalidad la dejamos para una fase dos». ¿Os suena?

La realidad es que la intención del que lo dice no es realmente priorizar el trabajo, apuntando a lo que más valor aporta, sino poder olvidarse, temporal o permanentemente, de ese problema. Con suerte, nunca habrá fase dos y nunca tendremos que enfrentarnos a esa funcionalidad.

La fase dos se convierte en un cajón desastre de cosas que no queremos hacer, y que es posible (o probable) que nunca hagamos.

Mi experiencia con la fase 2

La fase 2 es tan antigua como la gestión de proyectos. La he visto como miembro de un equipo y como el comercial de turno le soltaba eso al cliente, que tragaba contento. La he adoptado y se la he soltado yo al cliente. A veces creyendo realmente que luego haríamos una fase 2. Otras, sólo con el objetivo de procrastinar. Y otras con el claro objetivo de «colarsela» y quitarme de en medio un problema sabiendo que nunca llegaría la fase 2.

Lo he visto con desarrollos a salto de mata, con gestión de proyectos al más puro estilo PMBOK, y en desarrollo ágil. La fase 2 es una mala práctica que esta allí, que fue usada, está siendo usada y que seguirá siendo usada.

¿Cuál es el problema de la fase 2?

El problema de la fase 2 es que no está programada para nunca. Cuando la fase 2 es una fase planificada a largo plazo, consensuada con los stakeholders, esto no pasa. Es decir, si sabemos que la fase 2 se hará en Abril, entonces no estamos en este problema. El problema es decir que se hará en otra fase, pero no sabemos cuando será y si se hará. No está bien decir: «lo dejamos para más adelante» sin decir cosas como «será lo siguiente que vamos a hacer» o «esperamos hacerlo en el Q3 de este año».

Un buen product owner (o project manager si todavía gestionas proyectos al estilo clásico) debería tener una visión de lo que va a entrar en los siguientes sprints. Y debería tener esa visión compartida con los stakeholders y el equipo. Si sólo va viviendo el momento, preocupándose de el sprint actual y preparando el siguiente, es cuando la «fase 2» puede hacer estragos.

La tentación del lado oscuro

En cuando «saboreas» el dulzor de la fase 2 es difícil resistirse. Yo he caído bajo sus encantos en el pasado y me siento tentado muchas veces hoy en día. Pero la fase 2 es mala. Es crear una expectativa que nunca se va a cumplir, y eso es comprar bonos para defraudar. Bonos que vencerán en algún momento.

No caigas en el lado oscuro, resiste la tentación evita morder la manzana de la fase 2.

Sobre el autor

Jose M. Huerta

Jose es Gestor de IT en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de desarrollo de software, usando metodologías clásicas, o desarrollo ágil, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable de desarrollo en Palma y Londres.

Sin comentarios