Algunas ideas para ir hacia ML2 (1era. parte)

Poner en funcionamiento las prácticas vinculadas a las áreas de proceso de este y de cualquier otro nivel de madurez implica poner en marcha un programa de mejoras que debería ser encarado como cualquier otro proyecto de la organización. Será necesario formular metas claras y realizables, establecer un plan de trabajo creíble, y asignar recursos humanos, tecnológicos y financieros.

Como comentaba en una entrada anterior, una organización de nivel 1 no posee las habilidades básicas necesarias para gestionar adecuadamente sus proyectos. Esto agrega una dimensión extra de complejidad, ya que será muy difícil encarar el programa de mejoras con estas carencias en el área de gestión. Claramente, este es el principal riesgo que deberemos enfrentar al iniciar las mejoras en este tipo de organizaciones.

Otro de los temas más complicados es el relacionado con la gestión del cambio. Las organizaciones tienden a mantener el status quo y a la gente le cuesta mucho salir de su área de confort. Implantar prácticas como las que nos ocupan implicará cambiar costumbres muy arraigadas en la gente. El cambio no ocurrirá simplemente porque a un gerente se le ocurra ordenar “¡Háganlo!”. Deberemos planear concienzudamente cómo gestionaremos el cambio y cómo haremos para que las mejoras introducidas perduren en el tiempo.

Gestionar el programa de mejoras y gestionar el cambio organizacional son, en la práctica, las dos caras de la misma moneda. En definitiva, un programa de mejoras es exitoso porque puede impulsar y sustentar los cambios en la cultura de trabajo de la gente.

Adentrémonos ahora en algunas sugerencias más puntuales.

Las Organizaciones del Nivel Inicial de CMMI-DEV

Una síntesis de las características de las organziaciones de nivel 1

En términos generales, las organizaciones del nivel 1 carecen de un ambiente estable para desarrollar sus productos. Las crisis recurrentes y el caos son tan normales que lo usual para ellas es estar “apagando incendios” todo el tiempo. La gente está constantemente resolviendo los temas “calientes” del momento: incidentes en producción, consultas de los usuarios, respuestas urgentes a licitaciones, actividades de preventa, demostraciones no planeadas, etc. Si queda algo de tiempo, trabajan en sus proyectos de desarrollo.
Es fácil entender, entonces, porqué a estas organizaciones les resulta prácticamente imposible cumplir con los compromisos que contraen con sus clientes y proveedores. En ellas es habitual que los proyectos no cumplan con sus cronogramas y excedan (a veces muy ampliamente) los presupuestos establecidos. La funcionalidad prometida a los usuarios no siempre es entregada en forma completa y la calidad de los productos suele ser bastante dudosa.
Este comportamiento recurrente podría ser adjudicado a que el aprendizaje es prácticamente inexistente en este tipo de organizaciones. Cada proyecto se encara de manera distinta, sin considerar los errores cometidos en el pasado. No hay memoria y, tampoco, una evaluación subjetiva de las propias limitaciones operativas. En este contexto, los resultados (calidad, costos, fechas de entrega...) son muy difíciles de predecir.
Todo por cierta dosis de “pensamiento mágico” que suele manifestar el management: las cosas se harán porque simplemente creemos y decimos que se van a hacer. Es así que se establecen fechas de entrega y presupuestos sin ningún (o con escaso) sustento lógico: cumpliremos con nuestros compromisos simplemente por el hecho de que nos hemos puesto esa meta. Los proyectos (si es que existe el concepto de proyecto en estas organizaciones) suelen ser iniciados sin considerar la disponibilidad de los recursos necesarios para su ejecución. En cierta medida, los gerentes de las organizaciones de nivel 1 suscriben a la “Teoría X”: los empleados son vagos y evitarán trabajar siempre que puedan.[1] Por esa razón deben establecerse metas “ambiciosas” (léase: imposibles de cumplir).
A pesar de todo lo dicho, estas organizaciones pueden tener éxito y desarrollar buenos productos (o, al menos, aceptables). El único problema radica en el costo al que lo consiguen: usualmente, son los gestos heroicos de la gente -que trabaja largas horas sin descanso y, normalmente, gratis- los que permiten cumplir con las metas y los compromisos irrazonablemente establecidos.
En resumen, los problemas más graves de las organizaciones de nivel 1 no son de origen técnico. Claramente, no es una cuestión de proveer más y mejores herramientas de desarrollo. Ninguna de ellas podrá suplir las nefastas consecuencias de una pobre administración de proyectos y de una mala gestión de la organización en general.
Es por estas razones que la transformación de una organización de nivel 1 en una de nivel 2 implica un profundo cambio en la mentalidad de quienes ocupan posiciones de management: directores, gerentes, jefes de sector, líderes de proyecto, líderes técnicos, etc. La manera en la cual realizan las actividades de gestión es tóxica y debe ser mejorada.

En definitiva, para iniciar el camino hacia nivel 2 hace falta una gran dosis de humildad para aceptar que no somos tan buenos gestores como creíamos.

[1] La “Teoría X” y la “Teoría Y” fueron propuestas por Douglas McGregor del MIT Sloan School of Management en su libro “The Human Side of Enterprise”

CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.CMM Integration, CMMI, SCAMPI, and IDEAL are service marks of Carnegie Mellon University.

Los cinco niveles de CMMI-DEV

En general, los niveles de madurez suelen explicarse en orden creciente; tomaremos aquí una dirección distinta y los explicaremos exactamente al revés: desde el nivel cinco al nivel uno.

Imaginémonos por un momento que estamos en una organización de nivel cinco. En este tipo de organizaciones, como dijimos en la entrega anterior, los procesos son analizados para eliminar las causas comunes de variación, o sea, aquellas que tienen que ver con la misma naturaleza del proceso, no atribuibles a causas externas. Las variaciones en las salidas de los procesos son al azar, pero se encuentran controladas estadísticamente (podemos predecir los resultados de los procesos con cierto nivel de confiabilidad)

Para poder haber arribado a este nivel, la organización debería primero haber eliminado las causas especiales de variación, aquellas que tienen que ver con causas externas, como por ejemplo falta de entrenamiento del personal, problemas con las herramientas, etc. Este tipo de causas no son aleatorias: Si examináramos los resultados podríamos ver las tendencias que claramente nos indicarían que las variaciones tienen un origen concreto. En una organización de nivel cuatro, entonces, las causas especiales de variación son identificadas y eliminadas.

Para poder llegar a identificar causas de variación necesitamos tener un proceso estándar: difícil sería poner bajo control estadístico un proceso que no se encuentre mínimamente formalizado.
Así llegamos al nivel tres, en el cual los proyectos emplean un proceso productivo adaptado del proceso estándar de la organización. Las actividades técnicas y de gestión son realizadas de acuerdo a políticas, procesos y procedimientos formalizados en algún tipo de estándar organizacional profundamente arraigado en la cultura. La gente está entrenada y dispone de recursos para poder hacer su trabajo. También hay una infraestructura básica (personal, herramientas, etc.) para definir y mejorar el proceso productivo.

Pero para poder arribar a semejante situación es necesario pasar por una etapa previa: difícilmente podamos introducir en una organización prácticas estándar relacionadas con la ingeniería del producto (análisis, diseño, etc.) si no ofrecemos un contexto en donde ellas puedan ser correctamente ejecutadas. Ese es el foco del nivel dos: poner en orden las prácticas relacionadas con el manejo elemental de los proyectos.

En el nivel dos, los proyectos de la organización siguen algún tipo de proceso para realizar las actividades relacionadas con la gestión del proyecto (planificación, control), para administrar los requerimientos y las configuraciones, y para medir y analizar la calidad de los productos y el desempeño de los procesos. También hay prácticas de aseguramiento de la calidad que permiten garantizar que cada proyecto sigue sus propios estándares.
En el nivel dos no importan tanto las técnicas y los métodos que empleemos para desarrollar y construir nuestros productos y servicios: Lo importante es que podamos tener un mínimo de capacidad de gestión de proyectos.

Y así llegamos al nivel uno: La situación aquí es caótica. No tenemos procesos (no al menos en el sentido del modelo) y la performance de los proyectos depende profundamente de la buena voluntad y la capacidad de la gente.

CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.CMM Integration, CMMI, SCAMPI, and IDEAL are service marks of Carnegie Mellon University.

Procesos estadísticamente controlados

Continúo publicando algunos extractos del texto en el que estoy trabajando.

Uno de los principios fundamentales de la calidad total –sobre los cuales está basado CMMI-DEV- es el de control estadístico de procesos. Según él, la variabilidad de un proceso puede ser controlada y, por consiguiente, sus resultados pueden ser predecibles[i]. Que los resultados de un proceso sean predecibles no quiere decir que sean idénticos, sino que estos variarán dentro de límites conocidos.

Procesos estables
Las características de todos los procesos y productos presentan algún tipo de variación cuando las medimos a lo largo del tiempo. Dicha variación puede tener dos fuentes: la misma naturaleza del proceso (la variación normal o natural del proceso, relacionada con la interacción entre sus distintos componentes –personal, maquinaria, materiales, métodos y ambiente-) por un lado, y las causas relacionadas con alguna causa específica por el otro (las variaciones especiales). La variación normal del proceso (llamada causa común de variación) tiene un comportamiento al azar, pero con un patrón estable y dentro de ciertos límites. Si un proceso presenta únicamente este tipo de variación estaremos ante un proceso estadísticamente controlado.
La variación especial, por el contrario, no tiene un patrón de comportamiento que pueda ser identificado. El impacto de este tipo de variaciones en la performance del proceso y en las características del producto son importantísimos, a tal punto que es imposible predecir los resultados.
Las variaciones especiales no tienen su origen en el proceso, sino en causas externas tales como el medio ambiente, el material de input al proceso, personal no capacitado, métodos o herramientas incorrectamente usados, etc.
Una vez que las variaciones originadas en causas especiales sean removidas, nos encontraremos con un proceso estable (estadísticamente controlado) Una vez alcanzado este estado, podremos optimizar el proceso, reduciendo la variabilidad o “corriendo” la media. Como veremos en las próximas entregas, las organizaciones de nivel de madurez 5 de CMMI se esfuerzan en remover las causas comunes, mientras que las de nivel 4 se enfocan en remover las especiales.


[i] William Florac, Robert Park, Anita Carleton; Practical Software Measurement; CMU/SEI-97-HB-003.

CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.CMM Integration, CMMI, SCAMPI, and IDEAL are service marks of Carnegie Mellon University

Una breve descripción de CMMI-DEV (SM)

Desde hace un par de meses vengo trabajando en un texto introductorio a CMMI que espero publicar este año. Aquí va una primera entrega.

Una breve descripción de CMMI

El Capability Maturity Model Integration (CMMI[SM] de aquí en adelante) es un marco de referencia que las organizaciones pueden emplear para mejorar sus procesos de desarrollo, adquisición, y mantenimiento de productos y servicios. Nacido en el Software Engineering Institute perteneciente a la Carnegie Mellon University (www.sei.cmu.edu), CMMI es la nueva generación de una línea de modelos de madurez que se inició a principios de los noventa con el famoso CMM-SW (Capability Maturity Model for Software Engineering).


Basados en los principios de la calidad total (TQM) popularizados por autores como Crosby, Deming y Juran, estos modelos proponen un conjunto de prácticas que las organizaciones pueden adoptar para implantar procesos productivos más efectivos. Son llamados modelos de madurez porque proponen
adoptar dichas prácticas en forma gradual: primero deben ponerse en práctica áreas de proceso pertenecientes a un nivel determinado, para luego, sobre esta base, introducir las correspondientes al nivel siguiente. Como puede apreciarse en la figura de la izquierda, antes de introducir prácticas de un nivel determinado deben estabilizarse las prácticas del nivel anterior. Es así que, por ejemplo, antes de introducir el área de proceso RSKM-Administración de Riesgos (perteneciente al nivel 3 ó definido) deben estabilizarse las relacionadas con la gestión del proyecto (PP-Planificación del Proyecto y PMC-Monitoreo y Control del Proyecto, pertenecientes al nivel 2 ó administrado).


Un modelo de referencia no es la descripción de un proceso
Llegados a este punto, es importante hacer una aclaración: CMMI, como su nombre lo indica, es un modelo que propone un conjunto de best practices que pueden emplearse para evaluar y mejorar procesos; de ninguna manera debe suponerse que estamos ante la descripción de un proceso. Será nuestro trabajo definir el proceso productivo de nuestra organización –que seguramente tendrá una estructura completamente diferente a la de CMMI- de manera tal que cumpla con los atributos y mejores prácticas propuestos por el modelo.

CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.CMM Integration, CMMI, SCAMPI, and IDEAL are service marks of Carnegie Mellon University

Presentación del blog

¡Hola a todos!

Como ya habrán visto en la cabecera, desde hace unos cuantos años me dedico al tema de calidad y mejora de procesos en organizaciones de IT. Durante todo este tiempo he ido aprendiendo de los aciertos y de los errores, así que la idea es volcar aquí algunos comentarios que puedan ayudarlos a transitar el difícil camino del cambio en las organizaciones.

Seguimos en contacto.

Sergio

Me sumo a la blogósfera...

Finalmente, me sumo a esta movida. Espero ir publicando temas interesantes, relacionados con mi trabajo de consultoría.

¡Hasta pronto!