Por aquellos tiempos, Lucas (pseudónimo, cualquier parecido con la realidad es pura coincidencia, aunque doy mi palabra que este post se basa en hechos reales) había aceptado una tarea de enorme responsabilidad e importancia para su empresa: lograr certificar al departamento de desarrollo software en un conocido modelo de procesos que empieza por C.
Para lograr tan ardua tarea había muchos problemas que superar, aunque quizá el peor de ellos era aquel del que Lucas era menos consciente, y que era que él no tenía ni idea de cómo implantar modelos de procesos software para desarrollo.
Y con seguridad fue ese desconocimiento el que le hizo ponerse en contacto con una popular consultora, a la que llamaremos Pi (pseudónimo, cualquier parecido con la realidad es pura coincidencia), a la que tampoco pidió muchas referencias, sencillamente porque no sabía que pedirles.
Desde el mismo primer día de proyecto, la consultora Pi llegó a la empresa de Lucas con una metodología que hacía años habían elaborado, y “que habían utilizado decenas de veces para obtener certificaciones con el modelo C”.
La metodología estaba compuesta por decenas de pdfs, que a su vez contenían decenas de palabras, listas, chequeos, etc. Pero no, no era eso lo peor… lo peor era «las que se montaban» cada vez que se obligaba a la gente de aquel pequeño departamento de desarrollo con 10 personas a seguir todos y cada uno de aquellos procedimientos.
Aunque lo logró. Logró lo impensable. Logró que aquellos proyectos de dos semanas pasasen ahora otras dos más completando documentos y listas de chequeo que preguntaban cosas que nunca se iban a cumplir en la empresa de Lucas.
“¿Un error en su software impacta en vidas humanas?” – No. Nosotros solo, y siempre, hacemos portales Web.
“De estos 30 riesgos típicos en proyectos IT ¿cuáles cree que le pueden afectar?” – Ninguno.
“¿Ha completado el PERT del proyecto?” – No!!!!
…
Pero la empresa al final se certificó, justo antes de que Lucas fuera despedido.
Lo curioso es que a Lucas no lo despidieron por haber liderado una implantación de procesos absurda. De hecho, a la vez que le despedían le dieron la enhorabuena por haber implantado la metodología que logró certifcarlos en C. Y tampoco lo despidieron solo, desgraciadamente le acompañaron 4 compañeros.
Fue la hundida productividad del departamento de desarrollo; ella fue la que hizo que no se pudieran soportar los costes de la nueva metodología, y fue ella la que no dejó dinero para mantener a Lucas, ni a algunos de sus compañeros.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
¿Qué nos quieres decir con esto? ¿Que Lucas erró al aplicar la metodología, que hizo mal al aplicarla sin saber lo que ello podría conllevar o que la empresa simplemente quería estar certificada en C sin saber lo que podría conllevar?
Quizás el comentario de más abajo, de Roberto, te aclare tus dudas.
Saludos
Bravo
El caso que comentas es común en la industria, en la que cualquiera se mete a definir e implantar procesos y metodologías para satisfacer la certificación de turno. La empresa (y los proyectos) no tienen que estar al servicio de la metodología, sino al revés.
No se deben implantar metodologías, sino adaptarlas a la realidad, tamaño y riesgos de los proyectos, evaluando uno a uno el impacto de los procesos. No es lo mismo un proyecto de 2 personas que uno de 20. Y no lo deben ser las metodologías que usen.
Se puede pasar CMMI (uy, perdón, lo he dicho) usando métodos ágiles del mismo modo que los proyectos pueden ser altamente productivos y rentables usando variantes de un ciclo en cascada.
Creo que Lucas perdió el norte al tratar de implantar algo, en lugar de pensar primero en satisfacer las necesidades de la empresa (rentabilidad entre otros) y los proyectos (calidad, productividad, y a veces también rigor).
Muy bueno tu post, como suele ser habitual.
Gracias Roberto. Además por la explicación que añades y que complementa el post
pobre Lucas, allá donde va lo despiden 🙂 (a quien me recuerda..)
Excelente post! De más está decir que es algo común que pasa en la industria no sólo con C sino con cualquier otro estándar y cualquier otra rama. Lamentablemente las consultoras, venden certificaciones como churros, aunque quizás ya ahora deberían re-evaluar su estrategia, porque dada la tendencia del mercado ya el certificado no es una «ventaja competitiva» como antes….se va mas allá.
De acuerdo con Roberto, la metodología debe estar al servicio de la empresa, y antes de decidirse ir hacia alguna certificación la pregunta clave es «Para qué»…quiero certificarme?. Saludos.-
Este caso que comentas es más que habitual. Yo me dedico a la mejora de procesos de TI y te das cuenta cuando vas viendo lo que ha pasado con anterioridad en muchos de nuestros clientes, que muchas consultoras se dedican a implantar en todas las compañías por las que pasan un modelo de procesos que ha funcionado bien en una. ¿porqué? Porque creen que replicando el modelo obtendrán el mismo resultado, y claro está esto es totalmente erróneo.
Yo creo en CMMI, pero con una salvedad, hay que aplicarlo con sentido común y no con el sentido de tener 3.000 evidencias de cada artefacto. Al final lo que buscamos es una mejora en el proceso de trabajo que se traduzca en una mejora de nuestra productividad. Y este problema en unas compañías tendrá una solución y en otras compañías tendrá otra.
Enhorabuena por el blog Javier!
Gracias Santiago.
Coincido con lo que dices, que se resume en todo vale si se aplica con sentido común.
Saludis