Diseñando el WBS

0

Uno de los grandes conceptos que aprendí de leer la guía del PMBOK® es el WBS, o Estructura de Descomposición de Trabajo. Pasé de una simple lista de todas las tareas a realizar en el proyecto a obtener una estructura organizada del mismo. El WBS se convierte en centro de casi todo lo relacionado con la gestión del proyecto. Pero, en seguida que te propones crear tu primer WBS te surge la duda ¿Cómo lo organizo? Tras mucho pensar, y consultar lo publicado por PMPs de renombre, he llegado a la conclusión de cómo debe ser un buen WBS.

En este artículo expongo la estructura que tendría que tener un WBS, en especial los de desarrollo de software, y lo que creo que no debe ser.

Qué es el WBS

Antes de empezar veamos la definición de WBS que nos proporciona la guía del PMBOK®:

La Estructura de Desglose del Trabajo (EDT) es una descomposición jerárquica, orientada al producto entregable del trabajo que será ejecutado por el equipo del proyecto, para lograr los objetivos del proyecto y crear los productos entregables requeridos.

Viendo esto me llaman la atención un concepto que consideraré clave en todo este artículo: “orientada al producto entregable”. Es decir, el WBS debe estar orientado a los entregables del proyecto. Si tenemos claros los entregables y los podemos agrupar en paquetes de trabajo, seguro que nada se nos quedará en el tintero y las probabilidades de dejarnos fuera del alcance planificado algo se reducirán.

Es decir, los grandes bloques en los que se dividirá el WBS deben estar orientados a los entregables. Esta manera de atacar el problema también es la recomendada en la publicación del PMI “Practice Standard for Work Breakdown Structures” en donde también recomienda definir el alcance del proyecto en términos de los entregables y utilizar esos entregables para la descomposición del trabajo en el WBS.

En un proyecto tendremos tareas o actividades orientadas a estos entregables, que nos caerán jerárquicamente debajo de su entregable o grupo de entregables. Por otro lado tendremos actividades o tareas transversales o de soporte, como pueden ser la gestión del propio proyecto, el soporte o garantía post-entrega o tareas o gastos que deben mantenerse durante la ejecución del proyecto (como un posible alquiler si éste fuese un gasto directo del proyecto). Estas actividades transversales descansarán fuera de las ramas de los entregables.

Veamos como aplica este concepto a un proyecto de desarrollo. Tendremos los grupos de entregables muy relacionados con los bloques de código o componentes del software a desarrollar. Por otro lado tendremos las tareas de gestión y soporte transversales en otro paquete de trabajo.

Hacer la casa por el tejado

O en este caso sería justo al revés, hacerla desde el suelo. Lo que no tenemos que hacer es empezar a valorar todos los trabajos a realizar y entonces empezar a agruparlos por un criterio de afinidad. Un ejemplo sería, todas las tareas de análisis juntas, todas las de programación juntas, todas las de test juntas, etc.

Si lo hacemos así es más que probable que perdamos de vista lo que hay que entregar y nos dejemos algo fuera de la ecuación. Además es muy probable que algunas tareas difíciles de estimar (como las fases de análisis o toma de requisitos) se fusionen en una grande, todavía más complicada de estimar. Si lo hacemos por entregable, valoraremos el tiempo de análisis de cada parte del software, si lo clasificamos por afinidad, es muy fácil que lleguemos a lanzar las pedradas típicas del sector como “un mes para la toma de requisitos del proyecto”, ¡ni la pitonisa Lola, vamos!

Las tareas a realizar vendrán de analizar cada grupo de entregables, desde mi punto de vista es la mejor manera de no dejarse ninguno fuera.

Cada loco con su tema

Otra posible desviación es comenzar la estimación antes de diseñar el WBS. Y en esta línea también es común encargar a los responsables técnicos de cada equipo hacer esa estimación de su parte. Esto no es mala práctica del todo, ya que consigues complicidad y compromiso por los que luego tienen que ejecutar la tarea y evitarás entrar en guerras del tipo “¡Has estimado mal!”. Lo que es mala práctica es después desglosar el WBT por esas especialidades. Es decir, tener un grupo de tareas de arquitectura de BBDD, otra parte de sistemas, otra del programador Java, otra del experto del motor de integración, otra de diseño y maquetación, etc.

Si se hace así se perderá una dirección global y volveremos a dejarnos cosas fuera, además que luego será muy complicado de hacer el seguimiento sobre el WBS.

Cada cosa a su tiempo

Por último, otro error que cometí en el pasado y me di cuenta del error a mitad de proyecto, es hacer el WBS por las fases de ejecución del proyecto. Normalmente los proyectos en los que estoy involucrado tienen una parte importante de gestión del cambio hacia los usuarios, de convencerlos de que el proyecto es beneficioso para ellos. Para ello aplico la estrategia del Quick Win a rajatabla (además de otras). Esto implica tener un prototipo en producción en el menor tiempo posible con aquella parte que más beneficio da a los usuarios. Una vez los tienes de tu lado, todo se hace más fácil. Así tengo varias fases en el proyecto, en las que distintos entregables van evolucionando. Clasificar el WBS según esas fases es un error. El WBS no es una línea de tiempos, en seguida te das cuenta de que los cambios en la agenda te dejan un WBS sin sentido. Y aunque haya una ligera orientación a los entregables, te orientas a las fases de creación de cada entregable, y no a la funcionalidad completa que tendrá al final del proyecto.

Alternativas y dobles clasificaciones

Aunque el WBS sea una estructura jerárquica, nada te impide reordenar las actividades por más de una clasificación. Por ejemplo los códigos que se utilicen para cada actividad pueden estar ordenados por la ejecución en el tiempo planificada inicialmente. Sé que esto va en contra del PMBOK, que te induce a incluir el código del paquete de trabajo como prefijo al código de las tareas, pero no siempre me ha parecido buena idea. Otra opción es que los nombres incluyan unas iniciales que clasifiquen el tipo de trabajo a nivel técnico, la fase del proyecto o cualquier otra clasificación.

Pero lo que no debemos hacer es romper la filosofía de que la clasificación base del WBS debe ser por entregable.

Resumiendo

Considero que la recomendación de PMBOK de orientar el WBS a los entregables es la más válida de todas. En este caso, sea el proyecto grande o pequeño, considero que es la mejor opción.

¿Estás de acuerdo conmigo en que un primer bloque en el WBS llamado toma de requisitos es un error?

PMBOKWBS

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios 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 y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, 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 Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...