En más de 20 años de experiencia en la industria de desarrollo de software he observado que, en la industria, la mayoría de los proyectos de software en empresas tanto transnacionales, gubernamentales o pequeñas, certificadas en CMMI, MoProsoft o que usan enfoques ágiles, lo único que se enfocan (en su mayoría) es en codificar, generando un gran interés por las herramientas, técnicas o lenguajes más novedosos y que prometen que facilitar esto para “generar valor”. Las personas están siempre buscando que hay de nuevo en lenguajes más rápidos, más eficientes, sencillos de utilizar o que características de “punta” ofrecen para poderse utilizar.
Esta carrera tecnológica, ha existido siempre desde el inicio de la computación, siempre habrá cosas nuevas que en poco tiempo serán remplazadas, como se estableció en la Ley de Moore. Sin embargo, si observamos la realidad de los proyectos de software que también inició con la carrera tecnológica, el éxito de los proyectos de software es muy bajo desde siempre (actualmente < a 30% según Standish Group) con independencia de metodologías de desarrollo, lenguajes de programación o bases de datos más novedosas. ¿Por qué sucede esto?
Recientemente en una clase de Maestría, con la finalidad de que vieran, desde mi punto de vista la razón, les pedí un análisis a los alumnos sobre los procesos del Project Management Body of Knowledge, el famoso PMBoK, que se compone de 10 Knowledge Areas (áreas de conocimiento) y que contiene 47 Procesos, cada uno de los cuales tiene un conjunto de entradas, un conjunto de herramientas y técnicas que son utilizadas para transformar las entradas en un conjunto de salidas.
Comparto los resultados aquí:
Considerando la totalidad de los procesos la Herramienta que más es promovida a utilizarse por el cuerpo de conocimiento de la administración de proyectos es el famosísimo “Juicio de Experto” con 59.57% de apariciones, y el segundo lugar “Reuniones” con el 36.7%
Sin duda esto nos puede dar una idea de porque los proyectos de software fallan, seguimos haciendo artesanía, con muy buenos lenguajes y tecnología, pero no se puede considerar como un proceso ingenieril, ya que aún se depende de las personas que lo programaron porque no hay documentación adecuada, ni elementos cuantitativos o procesos ingenieriles que permitan darle continuidad, todo son opiniones de “expertos”.
Hace unos día vi una película “Moneyball 2011”, en esa película, un equipo de beisbol que pierde la serie mundial y su jugador estrella es comprado por otro equipo, por lo tanto el equipo tiene que hacer una reconstrucción, para lo cual el General Manager (Brad Pit) hace una reunión (justo como en el PMBoK) para preguntarle a los expertos (señores de edad avanzada con años de experiencia en el beisbol) ¿a quiénes contratarían?, este equipo de expertos esgrimiendo argumentos “subjetivos” abordan a varios jugadores hablando de cualidades no cuantificables y completamente subjetivas, aunque válidas desde su propia perspectiva. Hasta que el General Manager les hace un gesto de cansancio y desesperación. (ver escena1)
Al ver esta escena automáticamente me remonté a las reuniones de seguimiento de proyectos que he visto donde se menciona que el proyecto va retrasado porque ha habido cambios de alcance, porque es complejo un requerimiento, etc., o reuniones técnicas de equipos de desarrollo, donde se menciona que quizá es el manejador de base de datos, o que el lenguaje no permite hacer ciertas cosas, pero que un lenguaje nuevo “x” ya lo resolvió, o que el requerimiento no estaba claro, etc. Al parecer lo que importa es quien hace los comentarios más sobresalientes en términos de la moda de lenguajes o metodologías, quién puede demostrar que sabe más “subjetivamente” aunque nunca lo haya implementado, quien tiene una buena idea, o al menos quién convenza a los otros (usualmente el de mayor jerarquía), pero en realidad “NADIE PROPORCIONA DATOS” estandarizados que el encargado CIO, Project Manager, Líder de proyecto o Scrum Master, puedan usar de manera comparativa para la toma de decisiones.
En la trama de la película, el General Manager en la búsqueda de talento, va a negociar con un equipo el traspaso de algunos jugadores en una reunión de varias personas, recibe varias negativas, pero se da cuenta que las respuestas finales son consultadas con una persona al fondo de la reunión que es una persona joven de edad, contrastando con la situación que el tenía en su equipo.
Al salir de la reunión lo va a buscar y lo cuestiona de que hacía o cómo lo hacía. Este personaje le comenta que hay una falla epidemiológica en el juego, que hace que la gente de grandes ligas administre mal a sus equipos, se enfocan en comprar jugadores y no en comprar victorias (igual que en el software, muchas veces los CIO’s tratan de comprar lo más nuevo para solucionar las cosas, cuando los problemas son mucho más de fondo), para comprar victorias necesitan comprar carreras, y para esto se necesita tener los datos de qué jugadores generan más carreras, no quienes son mejores o más famosos a la vista de los “expertos”, los datos son crudos. (ver escena2)
Finalmente, este personaje se va a trabajar con el General Manager y a partir de los datos que genera hace una ecuación de predicción que identifica cuántas carreras deberían de permitir y generar, así como cuantos juegos deberían de ganar para llegar a la postemporada, con este objetivo y con la información de los jugadores de cuántas carreras generan o cuanto batean, etc., pudo armar un equipo con pocos recursos que le permitió llegar a la postemporada (ver escena3), finalmente no la ganó pero cambió la forma de ver el beisbol.
En el desarrollo de software lo que hemos estado proponiendo desde hace ya 14 años con el uso de métricas formales de software, es este cambio de paradigma, donde se pueda estimar los proyectos correctamente, hacer un seguimiento cuantitativo real de costo tiempo, alcance, que se pueda conocer la productividad, evaluar la calidad, la capacidad de planta de una fábrica de software, el nivel de producción de software en un momento dado, etc.
Sin embargo, muchas empresas y CIO’s solo lo ven como una moda u otra metodología más, que sin duda es más costosa de llevar a cabo correctamente, especialmente comparando con una metodología que puedes leer en una revista o libros de Sanborns y como todo es subjetivo puedes hacerte experto y/o promulgarte como experto, porque no hay forma de medirlo, en el caso de las métricas necesitas tener un enfoque ingenieril, conocer de matemáticas estadística y manejo de unidades, implica si o si utilizar medidas, alguien dijo “El nivel de madurez de una disciplina depende de la calidad de sus métricas”.
Si quieres cambiar la forma de tomar las decisiones de tus proyectos, e incrementar el éxito de estos, cambia la forma de hacer las cosas. www.spingere.com.mx