El Paquete De Trabajo
Que fruta noble el paquete de trabajo. Elemento algo indescifrable de la organización de proyectos, el paquete de trabajo sufre de la misma lógica fallida de los requerimientos: si no los hay, los falsificamos.
Miembro infaltable de propuestas, licitaciones y contratos, el paquete de trabajo es una caja negra con entradas y salidas que vomita entregables de dudosa factoría y arrastra consigo a una cantidad de pobres almas destinadas a penar para hacer que lo que un individuo ha decretado que el paquete de trabajo debe contener sin consultar demasiado con nadie. El mecanismo es algo así:
— Jefe: Armate unos paquetes de trabajo, dale que el deadline es el lunes.
— Subordinado/a: pero, jefe, no sabemos lo que hay que hacer todavía…
— Jefe: eso es lo de menos!
Y ahí va el/la tipo/a a tirar magia con las cajitas negras. Mientras se escriben estas líneas, alguien en el mundo está sentado sacando paquetes de trabajo de la galera como un mago saca conejos: WP1100, WP2100, WP3100, y la consabida marea de documentos. Y lo lindo es que esos paquetes de trabajo inocentes que se escriben cuando se sabe muy poco lo que hay que hacer quedan tallados en piedra durante todo el proyecto porque cambiarlos suele verse como una mala señal.
El paquete de trabajo, bien entendido, puede tener sentido: discretizar el trabajo de forma que esté contenido y sea más manejable y medible. Quién estaría en contra de eso?
Pero el paquete de trabajo tiene que estar alineado a algo y no salir de galeras. El paquete de trabajo siempre, SIEMPRE tiene que originarse desde una Work Breakdown Structure que a su vez nace de una Product Breakdown Structure que es la que refleja la arquitectura FÍSICA de lo que se quiere hacer. Si estamos diseñando una motoneta, la PBS de dicha motoneta será la que alimente la discretización del trabajo necesario para que dicho dispositivo de transporte de dos ruedas vea en algún momento la luz del día.
Y como todavía la inteligencia artificial general no llegó al punto de diseñar cosas (ese día saldremos todos a buscar trabajo), la ingeniería todavía es un asunto entre personas, entonces está el factor gente y como se agrupa. Cuando los grupos de trabajo están alineados con la arquitectura física del coso a producir, estamos todos en Disney porque no hay ambigüedades y es fácil mapear paquetes de trabajo a equipos y a elementos físicos del sistema. Ahora, cuando no lo están, por ejemplo cuando un subsistema está repartido entre varios elementos físicos, nos subimos todos al tren fantasma.
Acá es cuando entre project managers e ingenieros de sistema medio pelo la pudren toda, y no hay certificación PMI o INCOSE que valga porque es más un tema de sentido común y experiencia que lo que un certificado te puede dar. Si armás paquetes de trabajo que no respetan fronteras y no mapean a nada concreto, no esperes nada más que confusión. Y ni hablar de la madre de todas las macanas: armar paquetes de trabajo que atañen a categorías abstractas o dominios que tocan prácticamente todo. El ejemplo clásico: software. En un sistema complejo compuesto por varios subsistemas, muy probablemente haya software en más de un lugar. Y ahí se queman todos los papeles, porque esos paquetes de trabajo entonces están conectados con distintos grupos y subsistemas y terminan como hijos de padres divorciados; un poco con uno, un poco con otro, conflicto, tire y afloje. Años de terapia.
Otra vez me encuentro pidiendo que volvamos a las fuentes y usemos las cosas como se debe. Dejemos de usar los paquetes de trabajo como elementos que dan legitimidad a un proyecto o un contrato sólo porque existen, tal como hacemos con los requerimientos. Los paquetes de trabajo deben dejar de flotar en limbos etéreos y ser el fiel reflejo del sistema que se quiere diseñar, sin olvidar el pequeño gran detalle que la forma en que se agrupa la gente que lo va a diseñar es otro sistema en sí mismo cuya arquitectura no puede ser ajena a lo que se quiere hacer.
###