Gestión de proyectos y paellas

Este post comenzaba su vida como un comentario en respuesta a otro comentario de Antonio Quiros en un post en el que, al hilo de un artículo suyo, yo escribía sobre CMMI y la madurez. Me encanta que mi blog se convierta, gracias a la participación de Antonio y otros expertos y desarrolladores, en una tribuna libre en la que discuitir y comentar uno de los temas que mas me apasiona de la informática: la gestión de proyectos.


Bueno vayamos al grano…


Antonio en su comentario, dice que ‘no ve necesidad el debatir la validez de metodologías como CMMI’, este es el punto que menos comparto de su comentario. En mi opinión es imprescindible cuestionar un modelo de desarrollo de software y gestión de proyectos que no esta dando frutos. Bueno, si que está dando frutos al SEI y a los consutores SCAMPI y a quienes venden certificadiones. Uso el termino vender con toda consciencia, obtener un certificación CMMI solo es resultado de una inversión económica, de nada más. Toda empresa que lo intenta y ‘afloja la gallina’ consigue su certificación, luego no es un factor diferencial. Sobre mi conocimiento de como funcionan las certificaciones ISO, que Antonio cuestiona, decir que trabajé en calidad durante una parte de mi carrera (en industria no en desarrollo de software, pero las lecciones aprendidas se aplican) y que en todas las empresas por las que he pasado he sufrido el ‘sistema de calidad’. Todos tenemos certificaciones ISO (u otras) y todos sabemos como se consiguen.


A parte de estos frutos, tras muchos años hablando sobre la familia CMM siempre que voy a una presentación sobre CMMI (poniendonos puristas deberiamos decir CMMI for Software Development), desde hace años, los ponentes, empiezan con la misma ppt, una mostrando estadísticas sobre cuantos proyectos de desarrollo de software fallan. ¿Qué ha hecho CMMI en todo este tiempo por mejorar el desarrollo de software? Nada. Si duda hay que cuestionar un modelo que sigue tropezando en las mismas piedras una y otra vez: no involucra al cliente, no entiende que las personas no los procesos son la clave en desarrollo de software, no asume que si algo es cierto es que el software cambia, y sigue aproximando el modelo de vida de ciclo de desarrollo desde una clara visión en cascada, asumiendo que se pueden conocer los requisitos a priori. Todos estos son errores ciertos, repetidos una y otra vez, que CMMI, RUP y otras metodologías no ágiles siguen cometiendo versión tras versión. Nada está más en contra del sentido común que perseverar en el error.


Aunque quiza estos errores no sean achacables completamente a CMMI, que en esencia no es la pesima idea en la que se suele convertir, MSF for CMMI Process Improvement es un ejemplo, sino a cómo se realizan la implantaciones de CMMI. CMMI o RUP son modelos tan complejos, que cuando se implantan se acaban convirtiendo en un proceso en cascada porque, en la práctica, es la única manera de atajar la complejidad impuesta por la burocracia que estos modelos generan. Tienes que cubrir ciertas areas, con independencia de que sean de valor o no para tu proyecto, y recolectar evidencias de que las cubres y eso conlleva un esfuerzo que para nada repercute en el avance real del proyecto. No sirve de nada generar documentación y diagramas que la experiencia nos dice que van a acabar obsoletos, debemos centrarnos en construir software que se ejecuta sin errores, acepta el cambio sin un esfuerzo inviable y cubre las necesidades desde el cliente. Nada aporta al cliente que tu hagas una extensísima documentación de analisis y que cubras mil formularios para recolectar evidencias solo con el afán de recolectarlas para el auditor SCAMPI, quien es el único, que en alguna ocasión va a leer esta documentación, y el único que no sabe que cuando la lee ya está obsoleta. Ya escribí en dos ocasiones ( Por qué no me gusta UML y Documentando software y… más motivos por los que UML no es la solución) sobre la escasa utilidad que tiene esta aproximación a la documentación. Las metodologías ágiles tampoco son una bala de plata, pero si son una aproximación diferente a la que lleva fallando unos cuantos años y en mi opinión si algo necesita esta industria es una nueva visión.


La base de estos errores está muy enraizada en la escuela de pensamiento clásica sobre gestión de proyectos. El resumen de este pensamiento es asumir que un proceso de desarrollo excelente es lo que garantiza un desarrollo de software excelente. Antonio en su comentario expone algunos de los argumentos clásicos de esta escuela de gestión de proyectos: ‘si pongo los ingredientes de una paella en la mesa y a diez personas delante, la probabilidad de que salga una buena paella será más alta si junto a los ingredientes pongo una receta que si no la pongo’ o ‘un procedimiento es por definición una serie de pasos que nos permite hacer un proceso repetible. Seguir un procedimiento demostrado válido para gestionar proyectos nos da más garantías que no seguirlo. ¿Preferirias que te operase un medico siguiendo un procedimiento aprobado mundialmente? o por el contrario ¿prefieres la lotería y cruzar los dedos para que la forma de trabajar del cirujano, su sentido común y experiencia le digan como tiene que operar’.


No seré yo quien este en contra de seguir un proceso, lo que estoy en contra es de pensar en un proceso de desarrollo como en una receta. Las recetas están bien siempre que sepas exactamente cual es el plato que quieres hacer y siempre que tu cliente este de acuerdo en cual es la receta a utilizar. El problema es que en los procesos de desarrollo de software eso no ocurre casi nunca. Tenemos clientes que no saben que quieren comer, que no van a decidir si quieren la paella de marisco hasta que vean  la de carne, es más antes de ver la de marisco ni sabian que es lo que querian. Tengo algunos clientes que odian los pimientos y unos cuantos realmente enamorados de ellos, otros son alergicos y no puedo ponerlos en sus platos. En este entorno el jefe de concina (lease jefe de proyecto) no tiene más opción que tratar de contar con un equipo que no necesite una receta, que sea capaz de hacer la paella que el cliente quiere en base a unos fundamentos ferreos pero sin seguir unos pasos totalmente marcados (es mala práctica hechar azucar a la paella por ejemplo). Y además debemos dotarles de las herramientas que necesitan, básicamente, si no hay pollo, como jefes de proyecto (perdon de cocina), tenemos que conseguir uno (eliminar el impedimiento), porque sino nada podrá hacer nuestro equipo, por mucho que tengamos una metodología cinco estrellas certificada por la Nasa. Solo tener un excelente equipo nos salva, y tener cierto proceso, que apoye al equipo, que evangelize en las buenas prácticas, que no encorsete la creatividad y que no hunda al equipo bajo una montaña de burocracia. Mi abuela hace una excelente paella, por supuesto, sin receta. Es más dudo que dos veces seguidas ponga exactamente los mismos ingredientes y el mismo tiempo de cocción. No hay recetas, ni procedimientos ‘aprobados muldialmente’ para garantizar una gestión existosa de un proyecto, el motivo es simple, ¡cada proyecto de desarrollo es radicalmente diferente!. Esto es simplemente una ‘verdad verdadera’ que nadie que trabaje en esta industria puede negar… la tecnología es diferente, el cliente es diferente, el equipo de desarrollo es diferente, etc…


Tampoco el desarrollo de software es comparable a la cirugia, todas las operaciones de, digamos por ejemplo, transplante de riñon son iguales. Solo algunas se complican, y en ese caso solo salvará al paciente la agilidad del cirujano y su equipo para actuar de manera creativa y basada en excelentes prácticas: no vale olvidarse de la esterilización o de poner anestesia, por mal que vaya la operación. En gestión de proyectos no puedes olvidarte de la calidad, o de realizar integración contínua o de tener un gestor de fuentes organizado o de mantener la legibilidad del código. El problema es, que en los proyectos de desarrollo de software, las cosas, nadie puede negarlo, siempre se complican, con independencia de la metodología que se utilize. Es que desarrolla software es una tarea muy compleja, mucho más compleja que ninguna otra. Un solo error, en una sola línea de código y los resultados son miles de usuario sin poder acceder a la web de comercio electrónico de tu principal cliente. Por lo tanto el punto es: ¿Si sea cual sea la metodología los proyectos se complican, por qué elegir una metodología pesada? Elegir una metodología pesada, de partida, solo garantiza que es probable que tu pesado proceso no te ayude, sino te entorpezca. Cada vez menos gente en la industria del software discute esta aproximación. 


Lógicamente, no usar metodología alguna no es la solución. No hay peor metodología que ninguna. En Peopleware hay un capitulo excelente dedicado a las metologías con mayúsculas y a por qué no es buena idea confiar en ellas, básicamente pone el valor en las buenas prácticas. Ni siquiera estoy seguro que de una metodología ágil sea la solución total, pero si estoy seguro que no molesta tanto a los desarrolladores como una pesada y a menudo incluso les ayuda. Tendemos a olvidarmos de que la principal labor de una metodología es ayudar a los desarrolladores a hacer su trabajo, porque ellos hacen el trabajo duro. Propongo a los gerentes que han decidido implantar una metodología pesada tipo CMMI o RUP que salgan de sus despachos, y hagan el siguiente ejrecicio: Coger al primer desarrollador que encuentren, y depués de dejarle claro que su respuesta no influirá para nada en sus posibilidades de conseguir un aumento a fin de año hacer la siguiente pregunta: ¿Qué opinas de nuestra metodología?. No olvideís que quien principalmente sufre las carencias de una metodología son los desarrolladores. Luego pueden buscar un equipo de desarrollo ágil y hacer esta misma pregunta. Si no conocen ninguno, tienen las puertas abiertas en el proyecto en el que yo participo para hacer esta misma pregunta y comparar las respuestas.


El problema es que cuando las metodologías no ayudan, molestan y esto daña la moral del desarrollador, que en lugar de poder concentrarse en su trabajo, se tiene que concentrar en que la metodología no le moleste. Y no debemos olvidar que numerosísimos estudios llegan a la conclusión de que nada afecta más a la productividad de un equipo de desarrollo que la moral y la motivación de los desarrolladores.


Si comparto con Antonio su comentario sobre la carencia de profesionales realmente formados en gestión de proyectos. Es un problema grave. La universidad no prepara en temas relativos a la gestión de proyectos, al menos desde una prespectiva moderna y actualizada de la gestión de proyectos. Otro problema grave es que las certificaciones más reconocidas, estilo PMI y similares, están basadas en la gestión de proyectos clásica, guiada por un plan. Pero esto está cambiando: la certificación de mayor crecimiento y reconocimiento en los últimos años es la de Scrum Master. Esta certificación tiene el mismo escaso valor que el resto, pues cualquiera con el dinero suficiente la puede conseguir, pero su crecimiento, quizás resultado de su orientación completamente práctica, sin duda es señal de un cambio claro de tendencia en la gestión de proyectos en los últimos años.


Invitio a todos los lectores de este post a discutir los temas que trato. Si algo tengo claro sobre la gestión de proyectos es que no hay más verdad absoluta que la máxima de que las personas son lo que marcan la diferencia de un proyecto a otro. El resto esta abierto a discusión y esta discusión siempre es enriquecedora.

12 comentarios sobre “Gestión de proyectos y paellas”

  1. Sin saberlo durante los últimos años y a consecuencia de algunas malas esperiencias con proyectos informáticos, e ido adoptando ciertas tendencias que se parecen mucho a las metodologias agiles que expones, principalmente he adoptado dos reglas básicas, desarrollar pequeños módulos de una aplicación e implantarlos lo mas rapidamente posible, adaptandolos en una fase posterior y buscar esa cercania con el cliente de manera que el desarrollo se haga conjuntamente, y sea lo mas dinámico posible. Esto ha hecho, que los últimos proyectos que he realizado hayan sido un exito, hace aproximadamente un año y gracias a Miguel Jimenez, empeze a estudiar todo este tema de metodologias agiles, y me sorprendi bastante al comprobar que muchas de las cosas que aplico debidas a mis experiencias ahora estan recogidas en estas metodologias agiles, que tan buenos resultados me han dado a mi. Como informático e de reconocer que muy pocas veces me ha importado la metodologia, y que de haberlas conocido antes, muchos de mis proyectos no ubieran fracasado, no solamente en el aspecto del desarrollo si no en la valoración, coste y la forma que debemos aplicar para vender proyectos. La mayoria de las empresas siguen planteando costosos analisis y proyectos interminables que con el tiempo no hacen mas que minar la confianza de los clientes, pues muy pocos son los que logran tener exito, y cuando lo hacen siempre pasan por destrozar a los desarrolladores a los que esprimen al maximo.

    Lo asemejo mucho a los patrones de diseño, si no los conocemos, como saber si la solución que aportamos es la mejor, creo que toda esta información que espones es de vital importancia para todos nosotros, pues entiendo que nuestro trabajo es cada vez mas dificil y especializado.

    Veo en este tipo de metodologias una via para hacer mas facil nuestro trabajo, y sobre todo para lograr que nuestros proyectos sean un éxito.

    Para cuando esa conferencia sobre Scrum????

  2. Vaya, grata sorpresa me llevo… creí que por esta Eh!paña nuestra, lo de CMMI sonaba a chino. Supongo que sólo lo conocen 4 geeks y aplicado en exclusiva al Desarrollo de Software. Una lástima porque aporta una visión interesante para muchos sectores y permite una adopción gradual,… Pero siempre he pensado que el mundo del software es donde peor se desenvuelve aunque curiosamente es donde más pábulo se le da, en los los «states» igual la ocsa esta 50-50, pero fuera de allí, yo creo que su uso exclusivo es en software ¿me equivoco? Es tarde y me voy a mimir, pero trataré de recordar que aquí os debo un post más amplio.

  3. Por cierto, la mejor forma de aprender sobre gestión de proyectos… es trabajar en ellos y leer mucho para tratar de averiguar dónde la fastidiaste la última vez. Porque, amigo mío, si crees alguna vez que un proyecto te ha salido perfecto sólo puede ser por 3 motivos: 1. No tienes ni idea de lo que has gestionado. 2. Nadie tiene ningún interés en el proyecto. 3. En realidad, no es un proyecto.

  4. No comparto esto: «Para cuando esa conferencia sobre Scrum????»

    Que sea WebCast mejor, para que llegue también a LATAM :). Fácil se puede armar una serie, hay que hacer una petición on line :D!

    En cuanto al tema del post, todavía pienso que me faltan muchos proyectos para opinar, pero si tengo claro que usaré lo que me sea útil y me brinde resultados :), como por ejemplo tomar lo mejor que tiene cada uno, hasta vea con cual de todas trabajo mejor :).

    Saludos,

  5. Hola Rodrigo,

    Me uno a la idea de Sergio! Será algo grande poder disfrutar de los conocimientos del gran guru… jejeje

    Ya sabes sigo esperando con impaciencia tu libro de TFS!

    Sobre el post decir que creo que eres el único jefe de proyecto que he oido decir abiertamente que es algo positivo que un desarrollador piense por si mismo.

    El gran objetivo de todos los jefes de proyecto es que sus subordinados «piensen igual que ellos sin tener que decirselo», palabras textuales que he oido dirigidas a mi directamente.

    Sinceramente creo que hay trabajo mas importante a la que dedicar los exfuerzos de un equipo.

    Saludos.

  6. Hola Rodrigo, hace tiempo que quería poner sobre la mesa algunas cuestiones a las propuestas sobre metodologías agiles que haces en tu blog y hoy por fin me he animado a escribir.
    Segun yo lo veo, coincido en la cuestión en la que las metodologias agiles son mejores que las «pesadas». Pero hay que especificar SIEMPRE que depende del tipo de proyecto para que nadie se lleve a engaño. Hay proyectos en los que son imposibles trabajar con estas metodologías o por lo menos yo los desconozco, tal vez me puedas alumbrar en el tema.
    En primer lugar, el 100% de los proyectos en los que trabajo (como gestor de proyectos), son proyectos «cerrados», es decir tienes que presupuestar, tras la toma de requerimientos, cuanto dinero le va a costar el cliente. ¿Como haces esto en una metodología ágil? Este es un tema fundamental, de hecho no conozco ni un solo cliente que aceptase el hecho de empezar un desarrollo sin tener una estimación de esfuerzos y sobre todo costes.

    En segundo lugar, ¿que haces si el cliente o la persona de la que tomas los requerimientos no esta ubicada en el mismo sitio?, ¿y en el caso de equipos dispersos?

    En resumen tal y como yo lo veo es, las metodologías agiles, en particular SCRUM que es la que mas me gusta, esta muy bien en la teoría y define el marco ideal para trabajar en un proyecto de software, pero la realidad no es esta.

    Bueno tan solo darte las gracias por exponer tus experiencias y conocimientos desde tu blog del cual soy fiel seguidor.

    Un abrazo

  7. Hola JavierO:

    Es muy interesante el tema que planteas, de hecho estoy ‘cocinando’ un post sobre este tema, estate atento a mi blog, que dentro de poco lo publicaré.

    Un saludo y gracias por seguir mi blog.

  8. Coincido con JavierO, la mayoría de los proyectos hay que presupuestarlos … y gratis ! La presupuestación es en muchos casos ‘pesada’, no ‘ágil’, ya que implica analizar los requerimientos para que no resulte sobrevaluada. Por otro lado se hace necesario documentar (verificar/validar requerimientos) cuando no se obtiene un real compromiso de los interesados.
    Cómo tratan los desvíos del presupuesto inicial quienes aplican SCRUM ? Cómo resuelven los conflictos con los interesados, que , requisitos cambiantes mediante y paella tentadora,descubren que quieren cangrejo cuando lo que ya tienen en el plato es arroz ?

  9. Aunque llego un poco tarde a la discusión me gustaría añadir que si bien Scrum no aporta nada a la hora de hacer el presupuesto, ninguna otra metodología lo hace; me explico.

    Para hacer un buen presupuesto necesitas saber:

    + Que es lo que el cliente quiere exactamente (posiblemente, ni el lo sepa).
    + Cuanto va a suponer eso (basándote en experiencias anteriores).

    Amigos míos, ahí lo único que sirve es la experiencia, tanto para lo primero, como para lo segundo, si bien este segundo puede venir bien respaldado por una base de datos de tareas y sus tiempos reales (que casualmente, yo obtengo de los story points de Scrum).

Responder a anonymous Cancelar respuesta

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