Gestionando proyectos se comenten errores continuamente, yo por lo menos he cometido unos cuantos. Publico aquí sólo cinco de ellos, los más importantes o los más confesables según se mire. He metido la pata de muchas otras formas pero había que ponerle algún límite a esta entrada en el blog. Ahí van:
Primero el problema, después la solución
Ese es el orden, primero se identifica un problema y luego se le aplica una solución, no al revés: Es habitual oir hablar de una solución muy guay que luego aplicamos entusiasmados al proyecto. Haya problema previo que solucionar o no. ¿De qué sirve implantar en el trabajo diario el nuevo y sofisticado software para hacer Test Driven Development si realmente estás teniendo un problema mucho más básico con ese proyecto que te trae de cabeza?
Contar los pasos en lugar de mirar el camino
Todos sabemos que en los proyectos se suelen disparar las horas empleadas y que rara vez se cumplen los cálculos hechos en las estimaciones. Nuestra primera reacción suele ser la de supervisar cada hora registrada y hacer complejas gráficas que nos muestren lo bien o mal que vamos con respecto a la estimación pero ¿nos ayuda ésto a terminar antes el proyecto?
Si nos contratasen para llevar una carga desde el punto A hasta el punto B e hiciésemos una estimación según la cual haremos ese trabajo dando 10.000 pasos ¿en qué nos va a ayudar saber que ya hemos dado 5.000? ¿Sabemos dónde estamos o si hemos estado dando vueltas en círculo? ¿No será mejor levantar la vista, mirar cuánto hemos recorrido ya, si el camino realmente lleva a B o si hay algún modo más fácil de llegar allí?
Requisitos fantasma
En ocasiones le pedimos a los miembros del equipo de trabajo que cambien lo que ya han hecho porque ‘así no lo va a aceptar el cliente‘ o porque nosotros pensamos que el producto debe funcionar de otra manera. Nuestro compañero ya hizo una propuesta que ha costado tiempo y esfuerzo. Es mejor que la vea el cliente y dé su opinión. Él decidirá si está bien o está mal. Invertir tiempo en correcciones o mejoras no solicitadas sólo nos va a retrasar la entrega (con esto no quiero decir que no se revise lo que se ha hecho o que no se compruebe si tiene la calidad suficiente antes de mostrarlo al cliente)
Contagiar las prisas
Como jefe de proyecto suelo trabajar en varios a la vez, lo que suele implicar a varios clientes, cada uno con sus necesidades, múltiples fechas de entrega, tensión y mucho estrés. Intento no contagiar este estrés a los miembros del equipo de trabajo y aportar la tranquilidad que pueda. Por supuesto, todos los miembros del equipo deben conocer las fechas de entrega y el trabajo comprometido en cada una de ellas. Añadir prisas al trabajo diario sólo suele traer problemas en la calidad del producto final o cosas que quedan a medio resolver.
¿Puedes hacerlo más fácil?
Uno de los principales errores que se comete en un proyecto es el de comenzar cuanto antes cada tarea sin pararse a planificar los pasos a dar en esa tarea, si realmente es necesaria y, sobre todo, si puede simplificarse de algún modo. Me refiero no solo a implementarla del modo más fácil posible sino a simplificar la tarea en sí. Para ese complejo sistema de interconexión entre múltiples ordenadores ¿no existe ya algún estándar predefinido? Para ese analizador sintáctico ¿es necesario que sepa resolver ecuaciones de tercer grado? No hay tiempo mejor invertido que el utilizado para reducir la complejidad del trabajo a hacer.
Estos son los errores de los que me he dado cuenta hasta ahora. A algunos ya les he aplicado alguna solución, en otros todavía tengo que encontrarla. Seguro que me quedan aún errores nuevos por cometer. En los siguientes enlaces pueden encontrar algunas de las lecciones aprendidas de estos errores:
