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!

11 comentarios sobre “Gestión de proyectos guiada por la intuición, o por qué gestionar proyectos es tan difícil”

  1. El principal problema de la gestión de proyectos es que no se gestionan. Es España es más facil llegar a gefe de proyecto por ser simpatico que por tener conocimientos tecnicos. Y hay muchos gestores que la única metrica que conocen son las horas que estás sentado en la silla.

    La metodologia más usuara en las empresas, es, si tengo 4 aplicaciones, contrato a 4 chavales y le doy una a cada uno. Y cuando no salga el trabajo ya le echare la charla.

    Gestionar un proyecto informatico no es más dificil que construir un edificio, un puente o una operación a corazón abierto. Lo dificil es construir un edificio sin saber para que sirven los cimiento.

  2. Bastante de acuerdo con tu post en líneas generales, salvo en la parte de los bufferes. Dices que la realidad y la ciencia demuestran que no es así y mencionas la Ley de Parkinson como si fuese una verdad universal, cuando sólo es una coña. Como se que te gusta Peopleware, te recomiendo que te releas la parte en la que habla de eso. 😉

  3. @Andrechi: comparto en gran parte lo que dices, es cierto que muchos de los gestores de proyectos que hay por ahí no solo no tienen formación sobre el tema, sino que además no han leído ni un solo libro sobre el tema ni les interesa lo más mínimo.

    @alberto: la Ley de Parkinson es una verdad universal. Cierto es que es una verdad empírica más que una ley en sentido estricto. Pero no se puede negar su validad y el hecho de que la recomendación es no usar bufferes y que usar bufferes casi nunca se traduce en mejor cumplimiento. Ojo con no confundir buffers con rangos de incertidumbre. Tendré que releer Peopleware, por que la verdad no recuerdo ni que trate este tema. Gracias por el apunte.

    Un saludo.

  4. Hola:

    He leído pacientemente tu entrada y me he sentido retratado.
    Somos una pequeña empresa donde somos 3 programadores ¿Analizar? ¿Diseñar? ¿Probar? Uff!, no tengo tiempo. Si analizado no programo, si diseño no programo, si pruebo en exceso no programo…
    Si busco información en Internet o me compro un libro siempre estoy haciendo una apuesta personal por algo que no sé si va a funcionar. No tengo capacidad de criterio, cuando un fallo supone un error fatal para la empresa.
    ¿Cuál podría ser una solución para pequeñas empresas con pequeños proyectos? ¿Cuál es la solución para pequeñas empresas en el que una equivocación supone irremediablemente una perdida de dinero y quién sabe qué más…? ¿En las que no tenemos ningún «gurú» al que pedir respuestas definitivas?
    Es simplemente que me parece que no todo son consultoras y grandes empresas, y que sin embargo hay mucha empresa pequeña que suda la gota gorda para llegar a entregar sus proyectos… y todo eso sin olvidar que por favor te saques alguna certificación Microsoft para poder vacilar al cliente 😉
    En serio, ¿Una recomendación? ¿Una apuesta? ¿Programación extrema? ¿Metodología ágil? ¿Un libro «grande» para «pequeños» como yo?
    Espero haber expuesto bien mi problema que seguro será el de muchos.
    Muchas gracias y muy buena entrada.

  5. @Sergio: La verdad es que es un camino dificil. Solo se aprende a base de cometer errores. Los libros y la formación ayudan a cometer menos. Usar un marco de trabajo, el que sea, que pone puertas al campo, te protege de ti mismo y te obliga a relizar una serie de actividades es algo bueno. Puede ser XP, Scrum, MSF… o ese marco te le pueden dar técnicas com TDD, BDD, ingración continua, etc… Lo único que no funciona es confirmarse, no tratar de mejorar continuamente y fiarse de la intuición.

    Un trampa en la que caemos es en la de no buscar el tiempo que es necesario invertir para mejorar la situación.

    Mejorar exije invertir. Si no inviertes, no mejoras, y si no mejoras, no puedes invertir… la pescadilla se que muerde la cola. Pero es necesario romper ese círculo vicioso. Muchos equipos lo han hecho y han logrado mejorar como trabajan y sobre todo su satisfación en el trabajo y su satisfación con lo resultados obtenidos.

    Tu ves un problema el ser un equipo pequeño, no lo es, es una ventaja. Las inercias son mucho menores, es más fácil el ciclo de inspección y adapción, de prueba y error. La velocidad a la que realizas ese ciclo es lo más importante. Hay que equivocarse rápido, no perseverar en el error: http://geeks.ms/blogs/rcorral/archive/2009/03/12/velocidad-de-iteraci-243-n-vs-calidad-de-iteraci-243-n.aspx

    No hay balas de plata, elige una metodología, una técnica o una herramienta y busca la excelencia en su uso. De buscar la excelencia solo puede salir mejora. Eso si, estate atento, si algo no funciona tras cierta inversión desiste y busca otra cosa. Es tan importante hacer la suficiente inversión como saber cuando parar de invertir.

    Un saludo.

    P.D.: Lamento que el reMix me haya ganado la partida 😉

  6. Estoy totalmente de acuerdo con tu post. Y es una visión que he tenido siempre. Y es que la intuición nos suele engañar muchas veces.
    Quizás por que mi orígenes son la ciencia, y en concreto la física, tengo esta visión.
    Eso ya les paso a los científicos hace mucho tiempo pensando que con la intuición podrían descubrir todo lo que ocurre en la naturaleza. Hasta que empezaron aparecer las teorías cuánticas o teorías del caos.
    Creo que la mayoría de la gente monta modelos en su cabeza que son lineales, es decir si con dos personas tardo 2 semanas con 4 tardo 1. Pero es falso, creo que si hubiera que modelizar un proyecto informático se asemejaría mas a un sistema caótico.
    Un sistema de este tipo es muy sensible a las condiciones iniciales o a cualquier perturbación en el sistema. Imaginemos el tiempo meteorológico, la economía. Es solo predecible en periodos muy cortos de tiempo, y ademas suelen medir tendencias.
    Por eso metodologías ágiles funcionan muy bien en proyectos informáticos, por que solo estiman en periodos cortos de tiempo, y se realimentan. Lo que permite ir corrigiendo las estimaciones obtenidas a partir de los resultados generados.
    La verdad que me gustaría recibir opiniones sobre esta idea. Creo que es un campo que da mucho juego. Me refiero la economía dio un gran avance cuando se empezaron a usar en serio modelos matemáticos y científicos. Quizás en la informática deba pasar algo parecido.

  7. Comparto en gran parte lo que dijiste Rodrigo.

    Creo que la intuición no explica a ella sola porque uno comete los errores que mentionaste pero estoy fuera de tema. Màs que la intuición, hay este reflejo natural de repetir sin adaptar.

    Me explico. Diría que el modelo en cascada no funciona porque en el desarrollo, no podemos separar el diseño y el desarrollo y el cambio es ineludible. Es lo que la mayoridad de los jefes de proyecto ignoran. Cometen este error de repetir el modelo taylorista. Porque? Serguramente porque este modelo es facil de repetir y es lo que se hace en otras actividades de la misma empreza. Desarrollar un software es una actividad muy distinta. Lo sabemos por experiencia. Cuando se construye un edificio, se separa el diseño de la implementación, que si puede tener sentido. Una vez que hemos construido las 10 primeras plantas, es dificil de volver atràs y el «up-front design» evita unas trampas. En este caso, el modelo en cascada puede ayudar. Sin embargo, no se adapta al desarrollo de software porque al andar se hace el camino.

    Muchas gracias por tu articulo!

  8. Jo, acabas de matarme con este artículo. 🙁

    Vamos a ver. Tengo 28 años. Informático. Llevo trabajando desde 2005. Como programador. Varios lenguajes. Los últimos dos años he subido «meteóricamente» a jefe de proyecto. Tengo de hecho 2 proyectos que gestiono, donde no programo vamos. El caso es, que aparte de la asignatura de gestión de proyectos de la uni, que básicamente me han enseñado lo de la cascada o modelo V, no tengo experiencia. Simplemente me estoy guiando por mi intuición (y lectura de artículos como este).

    El caso es, que me veo en una contradicción. Si sigo una metodología, no me va a valer (por ejemplo la cascada) y si sigo mi intuición tengo un ratio de probabilidades de cagarla bastante alto. ¿¡Qué hago!? Estoy un poco como Sergio, en llevo un grupo de 2 a 4 personas. En general me ha dejado un poco desnortado el post.

  9. Muy buenas caballero

    Coincido en todo lo que dices salvo en un pequeño detalle, aunque quizá sea algo mas lingüístico que otra cosa. Creo que no utilizas bien el término intuición.

    Creo que con intuición te refieres a lo racional, a lo fácil, a lo que parece más lógico a primera vista… es decir, a la solución ideal, a lo que deja el papel precioso y de cumplirse a rajatabla sería digno de ser publicado como caso de éxito e imitado como ejemplo a seguir… pero eso nunca sucede, no nos engañemos.

    Al final me he liado y he escrito un post (http://notjustcode.wordpress.com/2011/01/19/una-forma-diferente-de-empezar/), y lo peor es que es el primero de un blog que pensé en empezar hace tiempo, jejeje

    Thanks 🙂

Responder a rcorral Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *