Skip to content

El jefe de Proyecto Fantasma : Parte 2

En el post anterior conocimos a nuestro personaje y planteamos las siguientes preguntas:

Esto es evitable? si.
Depende solo del Jefe de Proyecto? no.
El Jefe de Proyecto es el único culpable? no.
Puede hacer algo el equipo? si.
Debe cambiar el papel del cliente? si.
Los proveedores pueden hacerlo algo? si.

¿Que debe hacer realmente un jefe de proyecto?

Los primeros pasos en el nacimiento de un plan de proyecto serían:

1. La evolución del Brief.

El brief es ese documento o email con las lineas e ideas base de todo proyecto, puede ser tan corto como 3 lineas o ser un documento de varias paginas, lo importante es saber que no esta escrito en piedra.

Durante el avance del proyecto puede que ese brief inicial ya no tenga mucho sentido, pero se debe respetar su esencia.

El brief debe plantear, las necesidades del cliente, lo que realmente el cliente necesita, lo que el equipo puede ofrecer con lo que sabe y tiene, pero sobre todo plantear un reto hacia donde debería ir el equipo. De esta manera todos saben hacia donde van, como y con que herramientas se cuentan ademas de que se necesitaría para conseguir el objetivo. Sintetizar esto es un arte, toma tiempo pero vale la pena. Ademas si se promete algo al equipo hay que cumplirlo, no prometas una ayuda que jamas llegara por el simple hecho de “motivar”.

2.Preguntar, Preguntar y Preguntar al equipo y al cliente.

Hasta saber todos los detalles de un proyecto incluso cosas que en teoría no debería saber, razones o técnicas de programación, dificultades técnicas, funcionamiento técnico, lenguajes y frameworks utilizados.

En este punto el equipo debe y tiene que explicarlo todo lo mejor posible con el objetivo de informar al Jefe de proyecto de todo lo necesario para que pueda informar al cliente correctamente. Lo peor que puede hacer un miembro del equipo o el propio Jefe de Proyecto es decir – Eso no tengo porque saberlo – o – no es mi/su problema -.
En la reunión inicial siempre digo que

La peor pregunta es la que no se dice.

3. Crear un método o técnica de comunicación.

Por lo general a la gente le cuesta aprender procesos nuevos, pero hay que explicar, respetar y usar ese método hasta el cansancio. Si trabajas con muchos perfiles distintos hay que llevarlos a todos por el mismo camino y con el mismo lenguaje, crear un glosario de términos puede ayudar, pero sobre todo no dejar que nadie se desvíe del método, si usas un sistema de gestión de tareas, GTD, como daylight, wunderlist o teambox, profundizar en su funcionamiento hasta llegar el nivel de poder explicar al equipo como debe usarlo, ahora si aprender a usar la herramienta de gestión genera muchos pasos innecesarios es mejor seguir buscando un método adecuado ya que cada equipo y cada proyecto tiene su propia actitud.

Por ejemplo, en un equipo de desarrollo de software donde todos, incluido el jefe de proyecto lee código los suyo es usar un trac sobre un repositorio, así todo esta enlazado en el mismo. En otros casos donde los miembros del equipo tienen una tarea y capacidades distintas los suyo es encontrar un punto medio, si el trabajo esta mas en gestionar tareas individuales pues un GTD multi usuario vendría mucho mejor.
Personalmente no soy partidario de usar el email como gestor de tareas ya que no creo que sea una herramienta adecuada para ello, a menos que el proyecto dependa mas de comunicación que de la gestión de archivos, datos y tareas.
Aunque se escoja esa herramienta en consenso con el equipo, la decisión final debe estar en el Jefe de Proyecto y escogiendo la que mas fácil le sea manejar.

En ocasiones el Jefe de Proyecto se ve empujado a usar varias herramientas para diferentes niveles de comunicación, una para la gestión con proveedores, para la gestión del equipo y recursos, para la gestión de información con los diferentes niveles de la empresa y otra para comunicarse con el cliente. No recomiendo esto ya que por razones obvias puede llevar al caos pero si no puedes centralizar todo utiliza una sola de ellas para llevar el seguimiento de las otras o recurre al infalible papel y lápiz.

Si implantas una herramienta respetarla y has que la respeten.

4. Plantea objetivos realistas y a corto plazo.

La razón es muy sencilla, no poner una meta eterna o tan lejana que sea casi inalcanzable, con objetivos a corto plazo hay mayor satisfacción en el equipo ya que esa lista de tareas se va reduciendo conforme avanzas, si las tareas duran mas de una semana transformarlo en un objetivo. Jamas propongas metas por el mero hecho de satisfacer al cliente, es mejor decir la verdad que hacer la pelota y luego fallar incumpliendo una fecha.

Si usas el método SCRUM usar objetivos a corto plazo ayuda, aunque tampoco te salva.

Los objetivos tampoco tienen porqué estar relacionados sólo con el proyecto, pueden plantearse objetivos de conocimiento del equipo para ganar ya sea experiencia en algo nuevo o motivar con un reto al que todo el equipo quiera llegar. Como por ejemplo: Aprender un nuevo lenguaje, Conocer mejor un tipo de servicio o producto, Desarrollar una nueva tecnología o metodología interna.

Continua…


Published by pancho

Publicista renegado con alma de programador y corazón de diseñador. aka: Technical Designer. Escribo fatal, tengo faltas de ortografía y espero me disculpen por ello ;)


Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.


A %d blogueros les gusta esto: