La mentalidad “hamburguesa cocinada, hamburguesa vendida”

 
El desarrollo de software es una actividad muy diferente a la producción. Sin embargo, los Directores de Proyectos de software a menudo aplican una filosofía de gestión derivada completamente de los entornos de producción de la era industrial.

Imagine por un momento que usted es el gerente de una franquicia local de comida rápida. Para usted, tendría mucho sentido tomar cualquiera de las siguientes medidas para aumentar la eficacia en la producción:

• Reducción de la tasa de error: Hacer que la máquina (humana) funcione tan suave como sea posible.
• Dirección autoritaria (presionar, castigar, más horas).
• Tratar a los trabajadores como piezas intercambiables de una máquina.
• Ritmo de producción constante: No pensar en lo que supone la transición operativa para ganar velocidad o el tiempo que supondrá cerrar la operación.
• Estandarizar el proceso: Hacerlo todo según el manual.
• Eliminar la experimentación (para eso pagan a los de servicios centrales).

Estas medidas serían razonables si usted se dedicara al negocio de la comida rápida (o a cualquier otro entorno de producción), pero no es así. Usted es Director de Proyectos. La mentalidad de “hamburguesa cocinada, hamburguesa vendida” puede resultar fatal si se dedica al desarrollo de software, o cualquier otro proyecto relacionado con el “trabajo del conocimiento”. Solo le servirá para quitarle la ilusión a la gente y para alejar su atención de los problemas reales.

Este estilo de gestión es completamente opuesto a la efectividad en el tipo de trabajos que debe desarrollar el “knowledge worker”.

Getting the client happy with everything

Effective Project Managers know very well that stakeholders’ management is the most important project knowledge area. A project only finishes when stakeholders have met or exceeded their expectations. That is: when they are happy with the project result.

Each project has many stakeholders, but one of them especially important to manage: the client, the one who pays for it —we should extend this group of special interest with final users, the ones who are to use the product, service or result. 
  
In many service oriented companies is usual that the person who sold the project tries to centralize communication with the client. Effective Project Managers do their best to manage client expectations by themselves with the least intermediation.

If we don’t get client actively interested in our project during execution, or gets surprised or upset with the final result, then our project will be a great failure. 

One boss of mine used to say: “In projects, client has to be happy with everything but the price.” 

But “Getting client happy with everything” is easier said than done, isn't it?

Los problemas de ayer son los riesgos de hoy

 
Como escribió León Tolstoi: “Todas las familias felices se parecen, pero las infelices lo son cada una a su manera”. En nuestra profesión, yo creo que podríamos decir lo siguiente: “Todos los proyectos felices se parecen, pero el drama que se vive en proyectos que fracasan es muy particular”.

Imagine que está comenzando un nuevo proyecto y alguien le dice: “Este proyecto tuyo se parece mucho al que Pedro acaba de concluir, ¿por qué no le preguntas?”.

Usted está ocupado comenzando la planificación. Le parece que este proyecto se ha vendido muy por debajo de coste y plazo. Está descubriendo que hay muchos interesados contrarios al buen fin del proyecto, el alcance no está bien definido, hay mucha innovación y mucho que perder si el proyecto sale mal.

Decide despejarse un poco e ir a ver a Pedro.

En el Corazón de la Planificación

Cuando se hace un análisis post-mortem de un proyecto que ha fracasado, es decir, ha terminado muy tarde, con mucho sobrecoste, mala calidad, etc., y las desviaciones han llegado a tal punto que tanto el cliente como el proveedor declaran que el proyecto ha sido un auténtico fracaso, llegando a veces al extremo de tener que ir a juicio, muchas veces descubrimos que la causa principal es una mala planificación.

Me refiero a esos proyectos que, por ejemplo, deberían haber terminado en 15 meses y duran más de 20, que acaban con pérdidas netas de cientos de miles de euros, o que en el momento de la entrega, el cliente no acepta y por tanto no paga.

El post anterior Fail to Plan is Plan to Fail explicaba la importancia de una buena planificación para la conclusión exitosa de cualquier proyecto. Este post trata de profundizar sobre qué procesos de planificación son, a mi juicio, los más importantes, porque si se hacen mal es como “planificar el fracaso”.

En otras palabras, ¿qué procesos de planificación son causa raíz directa de fracaso, si se hacen mal?

Fail to Plan is Plan to Fail

In their day to day job, Project Managers should master the habit of visualizing about the project. Deliverables are also created twice. Before that deliverables could be tangible, the Project Manager had already imagined them. Before that team members could follow a number of processes and develop many activities, the Project Manager “had already been there”. Starting with the end in mind, in the field of Project Management, means something very specific: planning.

Before insisting about the importance of good planning for every Project (fail to plan is plan to fail), let’s think of what happen when the Project Manager doesn’t have the habit of planning. When you see someone leading a project just doing what customer asks, responding day to day issues and crisis just by reacting. Can you call this to manage a project? 

Retrospectiva del Proyecto Havannah

A continuación tienen un vídeo con un breve resumen de los 5 últimos posts dedicados al caso práctico con métodos ágiles desarrollado en el libro Agile Estimating and Planning, de Mike Cohn.

Espero que les sirva como referente práctico para aclarar conceptos como: iteración, historia, puntos-historia, velocidad, iteration planning, release planning, iteration review, etc. Nada tan efectivo como imaginar estos conceptos en acción en un caso más o menos realista, ¿verdad?

Por favor, no se queden solo con el vídeo, que no equivale a leer el capítulo de más de 50 páginas. Les animo a que compren este buen libro, ideal para comprender mejor los métodos ágiles. Si solo pueden leer una parte, lean el caso práctico desarrollado en el capitulo 23. Si quieren leer este capítulo en español, pueden empezar por aquí.

Quemando las iteraciones del Proyecto Havannah

Quinta y última entrega de la traducción capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, dejábamos al equipo a punto de comenzar la primera iteración de 2 semanas, que habían planificado en 4 historias de 18 puntos. También habían previsto que el proyecto duraría entre 12 y 20 semanas. En este post veremos lo siguiente:

1. El equipo demuestra los resultados de la 1ª iteración (completan 16 puntos de 18) y planifican la 2ª iteración con 3 historias de 18 puntos.
2. Demuestran la 2ª iteración completa al 100% y planifican la 3ª teniendo en cuenta dos nuevas funcionalidades “emocionantes” que ha investigado Diana, de 30 y 35 puntos, respectivamente. Si quieren mantener la planificación en 12-20 semanas, deben renunciar a una funcionalidad emocionante de 30 puntos. Antes de arrancar la 3ª iteración, quedan por quemar 133 story points (más que los 132 que tenían al principio del proyecto, ¿significa esto que van para atrás?).
3. Por último, atendemos a la reunión de revisión de la última iteración del proyecto, finalizado en un plazo 22 semanas, con 2 semanas de retraso sobre la estimación inicial comunicada de 20 semanas, pero a cambio de mucho más valor para el negocio.

En este caso práctico, los métodos ágiles han supuesto una cuantificable mejora del proceso de desarrollo de software, sobre todo comparando con el retraso acumulado del proyecto anterior de 6 meses.

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.

Plan inicial del Proyecto Havannah

Cuarta entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah estaba manteniendo una reunión con una agenda de tres puntos:

1. Planificar la primera iteración.
2. Revisar los resultados de la investigación de mercado.
3. Hacer una estimación preliminar del plan de entregas y el calendario.

El primer punto de la agenda concluyó con el compromiso firme del equipo sobre 4 historias de 18 puntos. A continuación se cubrirán los puntos 2º y 3º, para lo cual es necesario priorizar las 29 historias restantes. Una forma de hacerlo es usar el modelo del profesor Noriaki Kano:

El modelo de Kano sirve para determinar si las características de un producto son obligatorias (insatisfacción si no están), lineales (cuantas más hay, mayor satisfacción producen) o emocionantes (satisfacción si están, pero no hay insatisfacción si no están). El proceso habitual para llegar a estas conclusiones es plantear una encuesta a los usuarios con preguntas funcionales (cómo se sentirían si la característica estuviera presente) y disfuncionales (cómo se sentirían si la característica NO estuviera presente). Una vez se reciben las respuestas, la siguiente tabla permite clasificarlas en 6 categorías: obligatoria, lineal, emocionante, contrario, cuestionable, indiferente.

A continuación se describe cómo transcurre la segunda parte de la reunión.  El resultado de la reunión es que el proyecto durará 7 iteraciones (14 semanas). ¿Por qué? Porque a una velocidad de 18 puntos por iteración, en 7 iteraciones daría tiempo a asumir los 132 puntos previstos en la release. ¿Por qué 132 y no los 146 puntos de todas las historias? Porque el Product Owner no quiere que se dedique esfuerzo a las que resultan indiferentes para el público objetivo (6 puntos) y cree que puede ahorrarse una funcionalidad emocionante de 8 puntos. El equipo ya tiene una estimación para la duración del proyecto, pero el coach insiste en que esta estimación no debería publicarse, sino que es mejor decir que el proyecto durará entre 12 y 20 semanas. ¿Por qué?

Sigan leyendo y lo descubrirán.

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.

Comprometidos como EQUIPO con la primera iteración

Tercera entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah había escrito 32 historias de usuario, que tenían un tamaño de 146 puntos en total. 

En este post, los miembros del equipo dedican dos semanas a terminar otro proyecto mientras la analista Diana comienza la investigación de mercado con una encuesta a potenciales compradores. Al cabo de las dos semanas, el equipo se vuelve a reunir con Carlos, el coach en métodos ágiles, para planificar la primera iteración y comprometerse como equipo para terminar las historias más prioritarias. El resultado es un compromiso firme del equipo sobre 4 historias que miden 18 puntos.

¿Quiere saber cómo se planifica esta primera iteración?

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.
 

Las historias del proyecto Havannah

Continúa la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En este segundo post (véase nota*) veremos la conveniencia de escribir tarjetas físicas y cómo puede organizarse una reunión de brainstorming para hacer que los miembros del equipo vayan deduciendo los requisitos (en forma de user stories). Es recomendable estructurar el brainstorming por temáticas para no dejar ninguna funcionalidad sin analizar.

Casi al mismo tiempo, los miembros del equipo pueden estimar el tamaño o complejidad de los requisitos mediante un juego conocido como planning poker, en el que se estima el tamaño y complejidad de cada historia en unidades llamadas story points.

Estas dos actividades (recopilar requisitos y estimar sus tamaños) son interdependientes porque, a veces, una historia de usuario muy grande hay que descomponerla en varias más manejables.

Una regla básica que hay que recordar es que las historias de usuario deben ser independientes, negociables, valorables, estimables, pequeñas y verificables (Independent, Negotiable, Valuable, Estimatable, Small, Testable -INVEST-).

A continuación se describe cómo transcurre la reunión inicial de análisis de requisitos en un proyecto ágil. Al finalizar la reunión (que puede durar entre 2 y 4 horas), los miembros del equipo del proyecto Havannah habrán consensuado los requisitos con 32 historias de usuario, y también habrá consensuado la estimación del proyecto en 146 story points.

¿Quiere saber cómo se hace?

(*) Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.