Gestión de proyectos guiada por la intuición, o por qué gestionar proyectos es tan difícil

Tras unos cuantos años participando en la gestión de proyectos de desarrollo de software y ayudando a diversas organizaciones a mejorar como gestionan sus proyectos, he llegado a una conclusión muy curiosa: gestionar proyectos de software es una actividad extremadamente difícil. Continuamente veo aberraciones, errores abismales, errores que llevan descritos décadas en los libros sobre gestión de proyectos, errores que todos los que participamos en la gestión de proyectos cometemos muy a menudo. Observando estos errores, buscando su causa última, lo que nos lleva caer una y otra vez en el mismo error he llegado a una conclusión: la intuición no sirve para gestionar proyectos. La intuición de proyectos esta llena de ideas contra intuitivas, de anti patrones, de soluciones que parecen atractivas y simples y que no funcionan. Un buen gestor de proyectos tiene que luchar continuamente contra su intuición. Solo los conocimientos, las convicciones firmes en principios y fundamentos universales de la gestión de proyectos nos sirve. Y evidentemente la voluntad de defender esos principios, muchos de ellos, insisto, contra intuitivos contra la gente que trata de meter su nariz en la gestión de nuestros proyectos basándose en su intuición, en el siempre se ha hecho así, o en el aquí mando yo…

La lista de trampas que nos encontramos en la gestión de proyectos es inmensa, no me ha costado más de quince minutos pensar en una serie de ejemplos. Esta lista de cosas que parecen funcionar y no lo hacen no pretende ser completa o exhaustiva, simplemente pretende soportar mi tesis de que la gestión de proyectos está llena de trampas, que disfrazadas como soluciones interesantes o verdades absolutas, a menudo se rebelan como errores. Errores que se repiten con demasiada frecuencia. Esta es la gran dificultad de la gestión de proyectos: tener los conocimientos suficientes, el arsenal de respuestas preparado para que cuando algún gestor de proyectos de postal, uno de los miembros de nuestro equipo, un consultor externo u otro que viene con una genial idea, plantea de nuevo una de estas soluciones que llevan una trampa dentro, podamos contrarrestarla con contundencia, con datos y demostraciones que dejen claro que lo que es intuitivo no siempre funciona en lo que se refiere a la gestión de proyectos.

El modelo en cascada. No hay nada más intuitivo que el modelo en cascada, es fácil de explicar, fácil de entender, fácil de implementar, describe perfectamente las actividades claves del desarrollo de software… solo tiene un problema, no funciona.  Aun así es una trampa golosa en la que miles de proyectos mueren atrapados cual moscas ignorantes del peligro. Nunca falta quien defiende este modelo, y es normal, la intuición no dice que si dedicamos suficiente esfuerzo al principio del proyecto para eliminar la incertidumbre todo fluirá después por nuestra cascada de manera limpia y ordenada. Con suficiente planificación y diseño todo fluirá. Pero hay un motivo por el que este modelo nunca a funcionado y nunca va a funcionar: Siempre hay incertidumbre, nunca vas a se capaz de eliminarla toda y en el momento en que esa incertidumbre aparezca por pequeña que sea, el modelo en cascada mostrará sus flaquezas de manera irreversible: la retroalimentación es casi imposible. ¿Que pasa si en tu fase de test descubres que tu arquitectura no da el rendimiento adecuado?. Pues te pasará lo que ha un salmón que remonta una cascada: morirás exhausto sin remedio. Steve McConnell tiene una ilustración en su libro Rapid Application Development que yo procuro traer a mi cabeza cada vez que la tentación de acercarme a un modelo en cascada me ronda la cabeza:

image

Las estimaciones son certezas. Convertir las estimaciones en compromisos o certezas es otra de esas trampas que nos hacemos a nosotros mismos cada poco. Bien cuando damos estimaciones, bien cuando las recibimos. Pensar que somos capaces de estimar con el grado de certeza suficiente, olvidar el cono de incertidumbre es otra de esas trampas habituales. Es imposible acertar sistemáticamente en tus estimaciones, no por que yo lo diga, sino por que así lo demuestra el cono de incertidumbre.

El cono de incertidumbre nos dice, que en el momento en que habitualmente estimamos un proyecto o una tarea, al principio del mismo, es altísimamente probable que nos desviemos. Boehm intuyo esta realidad en 1981 y formuló el cono de incertidumbre que luego fue validado por el Laboratorio de Ingeniería del Software de la NASA. La próxima vez que alguien quiera ignorar el difícil problema de la estimación y convertir tus estimaciones en adivinaciones, dale con el cono en los morros… y dale fuerte.

Estimar con búferes. Como todos nos hemos visto atrapados por las dificultades de la estimación en un momento u otro y todos hemos sido flagelados por no cumplir nuestras estimaciones en alguna ocasión (pese a que el cono de incertidumbre demuestra que lo normal es no acertar), todos hemos sido victimas alguna vez de otra de esas ideas, que si bien la intuición nos dice que son correctas, la realidad y la ciencia han demostrado como erróneas: estimar con búferes. La intuición nos dice que si añadimos búferes a nuestras estimaciones, nuestro grado de cumplimiento de las mismas mejorará. La tozuda realidad, que a menudo es más compleja de lo que nuestra intuición asume demuestra que esto no es así. Y lo demuestra en forma de ley, la Ley de Parkinson: el trabajo se expande para consumir el tiempo disponible para realizar una tarea. Da igual el búfer que añadas, las tareas laterales, las tareas de investigación, las tareas divertidas, el ruido, todo esto conspirará en tu contra para que consumas el búfer. Además la naturaleza humana nos hará ‘posponer el inicio de la tarea hasta que no quede más remedio que iniciarla’ o lo que es lo mismo ¡primero consumiremos el búfer!. ¿Recordáis vuestros días de estudiantes? Sabías la fechas de los exámenes con meses de antelación… y si la noche anterior estabais estudiando.

Podemos sacrificar calidad para ahorrar coste o recortar plazos. Esta es otra de esas trampas mentales que nos hacemos a menudo. Nos decimos: rebajemos la calidad del software que hacemos, así cumpliremos plazos o reduciremos costes. Parece intuitivo ¿no? Al fin y al cabo todos tenemos en nuestro barrio una tienda de Chinos que demuestra esto, podemos hacer productos de menos calidad más baratos y venderlos como churros. Olvidamos con facilidad o incluso muchos desconocen que en el software también existen costes asociados a la ‘no calidad’ y que son nuestros clientes no nosotros quienes finalmente marcan el nivel de calidad exigido. ¿Habéis intentando mantener o extender software de baja calidad?  ¿Habéis conseguido que un cliente acepte un software que no cumple sus expectativas de calidad? Y es que en el software la calidad no es opcional. Fijaros en el siguiente gráfico que podéis encontrar en la página 69 del ya mencionado Rapid Application Development:

image

En 1991 varios estudios desvelaron que los proyectos que tienen una tasa de defectos más baja son los que logran unos plazos de entrega más cortos. Aun así la mayoría de organizaciones ignoran esta máxima. Increíble ¿no?, una vez más nos estamos dejando engañar por nuestra intuición sacrificando calidad para intentar lograr terminar antes. Dejar la calidad para el final nunca ha sido una buena idea.

Hay muchas otras trampas que la intuición nos pone y de las que ya he hablado en este blog:

No es raro que caigamos en el error de olvidar que no podemos vencer la tiranía del triángulo de gestión de proyectos, o que olvidemos la ley de Brooks y olvidemos que añadir recursos no es una solución que pueda funcionar, o incluso que nos creamos que existen balas de plata, herramientas o técnicas maravillosas que van a hacer que ganemos velocidad de desarrollo.

Lo  peor de todo es que el factor que más influye en el desempeño de un equipo de desarrollo no lo puedes gestionar fácilmente:  la motivación. Es más, la ciencia de la motivación, lo que llevamos décadas pensando que motiva a los desarrolladores se a demostrado, que contrariamente a lo que nos dice nuestra intuición desmotiva y es un elemento tóxico. Te sugiero que visites : Leer antes de motivar… o lo que debe saber todo jefe de proyecto.

Corolario: No eres el más listo. Lo que no ha funcionado a muchos otros no te va a funcionar a ti. La gestión de proyectos es una ciencia llena de trampas, soluciones atractivas que no funcionan, saber detectarlas y luchar contra ellas es el principal trabajo de quien gestiona proyectos.

En el próximo post hablaré de como Scrum evita estas trampas de la intuición estableciendo un conjunto claro de reglas. Saltarse esas reglas es una trampa en la que muchos caen sin darse cuenta de que están ahí para protegerte de ti mismo, de tu intuición errónea, de caer una vez más en ciertos antipatrones.

¡Un saludo!

Evento: Metodologías ágiles con Visual Studio 2010 en la oficinas de Microsoft en Madrid

imageEl próximo jueves, 16 de Diciembre tendré el placer de participar en un evento sobre los temas que más me apasionan, gestión de proyectos, y Team System en las oficinas de Microsoft en Madrid.

Sesión: Metodologías ágiles con Visual Studio 2010 (pinchad en el link para inscribiros)

Cada vez más empresas necesitan encontrar el equilibrio entre control de los proyectos y productividad de sus equipos de desarrollo, las metodologías ágiles proponen un marco de trabajo que nos permite gestionar los proyectos y mejorar la productividad de nuestros equipos de desarrollo sin caer en la temida burocracia. Team System es un marco de trabajo ideal que proporciona de manera integrada todas las herramientas que un equipo ágil puede necesitar. En este evento veremos cómo un equipo de desarrollo puede usar metodologías ágiles junto a Team System para dar un salto importante en su productividad.

Agenda:

Registro y bienvenida
Metodologías ágiles ¿qué son? ¿cómo nos ayudan?
Introducción a MSF Agile 
Introducción a Scrum
Scrum y Team System en el mundo real
Team System: la herramienta perfecta para el desarrollo ágil

Prometo un interesante paseo por las metodologías ágiles y Visual Studio.