Ajedrez - antoniomartel.com

Archivos por Etiqueta: gestión de proyectos

5 lecciones aprendidas en la gestión de proyectos

Siempre que acabo un proyecto procuro hacer balance de lo que fue mal o de lo que fue bien en él, de lo que intenté y no funcionó o de lo que debo anotarme para no volver a hacer. Incluso cuando el balance final lo he considerado negativo, puede que el proyecto haya merecido la pena si en el siguiente proyecto no vuelvo a cometer los mismos errores.

De algunos de esos balances he extraído aquí cinco de las lecciones más importantes que he aprendido. Algunos son errores de principiante, otros los debería haber resuelto la simple lógica pero no me resultaron tan evidentes cuando estaba en ello. Ahí van:

La agilidad funciona

Es difícil de cuantificar pero desde que comencé a usar Scrum en mis proyectos, el número de horas invertidas por funcionalidad bajó y en mi opinión lo hizo bastante. Simplemente haciendo el seguimiento diario durante 15 minutos, mantener la gráfica del estado del proyecto que nos indica si vamos bien o no y las entregas cada dos semanas nos permitieron obtener el 80% de las ventajas de Scrum. Además, a los clientes parecía aportarles cierta tranquilidad que de forma consistente cada dos semanas se entregara y mostrara lo que se había acordado dos semanas antes. En los meses de julio y agosto, cuando no eran posibles las reuniones, el envío semanal de un simple documento de dos páginas con el porcentaje de realización de cada funcionalidad y dos párrafos explicando el porqué de esos porcentajes, ayudó a recuperar credibilidad en un proyecto difícil (especialmente cuando en septiembre se pudo comprobar que los porcentajes eran reales)

Todo no es positivo en Scrum

Se requiere de bastante más dedicación del Scrum Master de la que tendría si solo jugase el papel de jefe de proyecto. En esos 15 minutos de seguimiento diario te van a contar un montón de dificultades que se necesitan resolver para seguir avanzando. Intentar resolverlas te va a llevar el resto de la mañana.

Por otro lado, tener una entrega cada 2 semanas puede ser agotador. No se puede estar esprintando durante meses. Al cabo de seis meses se termina trotando (y eso con suerte) Es necesario tener esto en cuenta desde la primera planificación.

Por último, y no por ello menos importante, Scrum no es magia. Uses la metodología que uses necesitarás un equipo formado en el trabajo a realizar, dispuesto a arrimar el hombro y con ganas de aportar. Equipos así no crecen en los árboles. Si cuentas con uno, la misión del jefe de proyecto será estorbar lo menos posible.

Incorporar más trabajadores al equipo no consiguirá más que ralentizarlo

Bueno, esto ya se decía desde hace un montón de años en el libro The Mythical Man-Month. Aún así es necesario recalcarlo, no hay excepciones a la regla. No importa lo ajustado que sean los plazos: nueve personas no pueden crear un bebé en 1 mes.

¿Quién es el dueño de todo esto?

Da igual cómo lo llamemos: identificar a los interesados, designar el product owner o hacer partícipes a los stakeholders. Al final necesitaremos saber quién va a validarlo en realidad. Y no me refiero a quién va a firmar la factura. Necesitarás conocer también a quién va a usar el producto. El proyecto sólo será un éxito si después de entregarlo funciona y es útil.

En algún proyecto el director de área nos facilitó toda la documentación, validó las entregas parciales, testeó toda la aplicación y nos felicitó por el trabajo realizado. Lamentablemente, cuando su secretaria acudió a la sesión de formación una semana antes de la puesta en producción nos dijo: ‘Esto no me sirve: esa ya no es la plantilla correcta y necesito recoger datos diferentes de los que ahí pone’. Esto significó una semana de horas extra y esfuerzo adicional además del riesgo de poner en producción un producto que podría ser inestable.

Producto Mínimo Viable

Si ya tienes algo que puede ser útil al usuario, entrégalo, ponlo en producción, sácalo a la venta. No esperes a tener todas y cada una de las funcionalidades terminadas. Si recuerdas el principio de Pareto con sólo el 20% de ellas conseguirás completar el 80% de los usos que tendrá tu producto.

Cuando esté en producción comenzarás a obtener las impresiones de los usuarios. Ellos sabrán con mayor exactitud qué es lo que de verdad necesitan y tú sabrás qué has hecho mal y cómo puedes mejorarlo. Si apuestas por una única entrega final sólo cuentas con una única bala para acertar en la diana (haber hecho esto nos habría ahorrado un montón de problemas con el producto mencionado en el punto anterior)

Estas son mis lecciones aprendidas. Espero que a alguien le sirva de ayuda como lo hizo para mí.

Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

Libro Gestión práctica de proyectos con Scrum

Crédito para gestionar proyectos

En inglés se usa el término soft skill para referirse a habilidades sociales como el trato agradable, el optimismo o la facilidad de comunicación (habilidades útiles en cualquier situación de la vida) En cambio usan el término hard skill para referirse a aquellas técnicas que aprendemos para poder realizar un trabajo: un lenguaje de programación, el plan contable de 2012 o un nuevo procedimiento para detectar la desnutrición hospitalaria.

SCRUM, PMP o cualquier metodología que elijamos, son hard skills. Nos enseñan una forma de trabajar, un conjunto de buenas prácticas y normas a seguir, útiles sin duda, pero si no se ponderan adecuadamente con el otro tipo de habilidades, la gestión de un proyecto y cualquier otra actividad que acometamos estaría seriamente comprometida.

Listados de soft skills necesarias para un gestor de proyectos las podemos encontrar en muchos sitios. Habilidades como el liderazgo, auto-control, capacidades de organización, negociación o comunicación son claramente muy útiles. Yo quiero hacer mención especial a dos que cada vez me parecen más importantes:

Coherencia

De nada vale que comencemos un proyecto con muchas ganas y propongamos al cliente un montón de herramientas de última tecnología, entregas semanales o memorias mensuales si con el paso del tiempo y las urgencias del trabajo diario comenzamos a relajar estos compromisos o la calidad de los mismos. El proyecto se resentirá por la falta de estas entregas pero lo más importante es que comenzaremos a perder la confianza y el crédito que nos ha dado nuestro cliente. Y si se cancela la línea de crédito ya sabemos lo que pasará.
Igual de importante es el crédito que nos dan nuestros compañeros de trabajo. Si prometemos libertad de decisión al equipo y la limitamos siempre que opinamos distinto o si la calidad es importante para nosotros pero deja de serlo cuando hay prisa, los niveles de calidad también dejarán de ser importantes para el resto del equipo. La línea que se ha trazado es cada vez más borrosa y pronto les dará igual hacia dónde se va esa línea.

Transparencia

Ocultar cosas nunca ha sido buena idea. Callar por qué se toman ciertas decisiones y esconder las verdaderas causas de los problemas no nos traerá más que problemas, aunque en el plazo inmediato consigamos escurrir el bulto. 
No es necesario un desnudo integral pero explicar los problemas lo más claramente posible ayudará a mantener abierta nuestra línea de crédito. Si nuestro cliente comienza a intuir que no hemos sido claros y que en cierta forma no fuimos del todo honestos ¿por qué iba a confiar en nosotros cuando le expliquemos que la nueva funcionalidad es demasiado compleja y que necesitaríamos un par de semanas más para completarla?

Suscríbete