Los modelos no tienen la culpa

Estamos invadidos por una ola de modelos, estándares y certificaciones. Las siglas marean a cualquiera: CMMI, TSP, PSP, COBIT, ITIL, TOGAF, MAAGTIC, PMBOK, SWEBOK, BABOK, ISO/IEC 12207, 15504, SCRUM, XP, Kanban, Lean, UML, BPMN, por mencionar solo algunos. Yo misma me declaro culpable de agregar a MoProSoft, ISO/IEC 29110 y KUALI-BEH.

Crear, a los que voy a llamar modelos para simplificar, es un trabajo de comunidades de interés que tienen el objetivo de rescatar y compartir las mejores experiencias de las prácticas del cada vez más amplio espectro de la influencia de TI. Para los que no fueron involucrados en su elaboración saber escoger el que le convenga es un reto mayor.

Parecida exuberancia se observaba con los lenguajes de programación en los años 70’s y 80’s. La torre de Babel fue tapizada con nombres de lenguajes de programación de los cuales hoy en día nadie se acuerda, salvo abuelitas como yo. Ver Figura 1. La búsqueda de la forma más fácil de expresar las soluciones de diversos problemas computacionales fue la causa de esta exploración.

Cuando llegué a México hace treinta años, ofrecí mi primer curso en la Maestría en Ciencias de la Computación en el IIMAS-UNAM titulado “Programación estructurada en Simula-67”. Todavía conservo mis apuntes de este curso y la lista de asistentes. Simula introdujo por primera vez el concepto de clase, objeto y herencia pero como el concepto de programación orientada a objetos todavía no se acuñaba usé el de “estructurada” por estar a la moda de entonces.

Una de las tareas de mis alumnos fue estudiar y exponer los siguientes lenguajes de programación: MODULA, PLITS, PASCAL, ADA, ALGOL, EUCLIDES y EDISON. Hoy nadie programa en ellos, sin embargo en su tiempo fueron los eslabones que ayudaron a llegar a Java, C#, PHP, Ruby o Phyton, aunque usted no lo crea.

El estudio de Simula-67 y los demás lenguajes ayudó tanto a los alumnos como a mí, a formar criterios para seleccionar al más adecuado al contexto que uno enfrenta y aprender más rápido nuevos lenguajes.

Quiero aprovechar la lección aprendida sobre la abundancia de los lenguajes de programación para sugerir la “receta” de lidiar con la abundancia de los modelos. Las preguntas más importantes que se necesitan responder son:

1. ¿Cómo comprender a los modelos con menos esfuerzo?
2. ¿Qué criterios ayudarán a seleccionar el modelo que me convenga?
3. ¿Cómo adoptarlo con el provecho real?

A continuación van mis sugerencias de respuestas a estas preguntas:

Comprender a fondo tantos modelos y estándares es una locura. Requiere de mucho esfuerzo y tiempo y los que están en la pelea diaria no lo tienen. Por lo tanto, mi primera sugerencia es que si te llamó la atención alguna de las abreviaciones, que mencioné al inicio, o alguna otra que te quieren vender como el remedio para tus dolencias, primero acude a Internet (buscando fuentes independientes como, por ejemplo Wikipedia) para conocer lo que significa la abreviación de cada uno, su propósito, alcance y a quien está dirigido.

 Comprendidos estos elementos, analiza el contexto de tu organización o el personal y selecciona los candidatos que te suenen ser prometedores. Por favor no te guíes solamente por las convocatorias de financiamiento. Tener financiamiento es maravilloso, pero lo más importante es elegir lo que realmente apoye tu crecimiento como organización o personal.

 Una vez seleccionado el o los modelos, trata de conseguir la documentación completa y original que lo describa. Estos documentos suelen ser gorditos y aburridos, por eso te doy unas pistas para que eficientes su lectura: primero, lee la descripción de la estructura general de los elementos que componen el modelo para confirmar que efectivamente se adecuan a tu contexto. 

Luego revisa los propósitos y/o objetivos de estos elementos. Por ejemplo, en las área de procesos de CMMI revisa “specific and generic goals” y en MoProSoft los propósitos y objetivos de los procesos. Si no los comprendes por completo busca las definiciones de los conceptos en los documentos, en el Internet o usa la intuición femenino-masculina.

 Te sugiero que esta revisión se haga en equipo (en caso de organizaciones) o individualmente para analizar honestamente cuales de los objetivos actualmente se cumplen y cuales consideran de que deberían de cumplirse para que la organización (o la persona) progrese. Esta auto-evaluación aportará criterios para decidir si la adopción del modelo revisado puede aportar valor real o no. Hacerlo con la(s) cabeza(s) propia(s) es muy importante, nadie sabe mejor que tú lo que necesites para perfeccionar tu profesionalismo o beneficiar a tu organización.

 La selección de un modelo es apenas una parte, lo mas importante es su adopción. Sobre este tema podría escribir una telenovela. Me han contado pocas historias de “amor” y muchas de “villanos”.  Los modelos ágiles no se libran de eso, es suficiente con revisar los comentarios sobre sus mitos en Internet.

 Por falta de espacio, me restrinjo de darles un consejo más. No hay que perder de vista que la adopción de un modelo significa el cambio de “usos y costumbres” para lograr el beneficio de la organización o persona. Esto, en los términos de moda de hoy, se llama buscar le competitividad. El chiste está en lograr el cambio verdadero y no una “estrellita” fugaz.

 Los modelos no tienen la culpa. Los culpables de sus fracasos son los que los eligen sin saber para qué, los que los implementan pensado en cumplir con el “examen” de la certificación más que en el beneficio de ellos mismos. También hay culpa de los que aplican el “examen” tomando los modelos como “chalecos” a poner a todos por igual.