¿Qué Tan Ágil Puede Ser Mi Modelo de Procesos?

“Nosotros somos ágiles por eso no documentamos”…
“Eso va a hacer más lento el proceso”…
“¿Por qué siempre me pides evidencia con una minuta firmada?”…

Estos y muchos otros cuestionamientos similares solemos encontrar quienes nos dedicamos a mejorar procesos de software; por un lado la noción de que los modelos de procesos “clásicos” (CMMi, MoProSoft, PMBOK, ITIL, etc) van a entorpecer o hacer más lentas las actividades del día a día y por otro lado esta percepción de que los modelos de procesos “ágiles” (SCRUM, Lean, Kanban, etc.) significan no documentar. ¿Pero son realmente los modelos “clásicos” unos modelos lentos? O es más bien una inadecuada interpretación de un consultor con poco conocimiento o un evaluador o “Lead Appraiser” con poco criterio para enfocarse a las necesidades de la organización y no solamente a que cubran el modelo/norma o estándar.

Todos los modelos de procesos se pueden convertir en la peor pesadilla para cualquier organización sino se saben interpretar o si se quiere seguir al pie de la letra lo que dicen. Ningún modelo es lo suficientemente completo para cualquier organización, por lo tanto se debe de revisar qué es lo que nos ofrece cada modelo y enfocarlo principalmente a las necesidades de la organización en la que se quiera implementar. Recordemos que los modelos de procesos nos marcan el “Qué” y la organización decide el “Cómo”. Por ejemplo, un modelo nunca te pide que generes tres minutas y que éstas sean firmadas con sangre por todos los involucrados, lo que el modelo pide es que notifiques los planes de trabajo a tus involucrados. Queda a criterio de cada organización decidir la mejor forma de implementar esto de acuerdo a su contexto y necesidades.

Cuando se comience un proyecto de mejora no importando el modelo, norma o buena práctica que se quiera implementar como marco de referencia, se debe de hacer la pregunta: “¿Qué es lo que se quiere mejorar?” Con esto se logrará definir el objetivo para el proyecto de mejora. Si comenzamos el proyecto sin hacernos esta pregunta y en lugar de eso colocamos en el objetivo “alcanzar el nivel x del modelo x” vamos a provocar que toda la implementación esté orientada a obtener “el papel” y nunca la mejora. Es cuando se comienza a volver los modelos lentos, tortuosos y “requeridos porque el jefe lo pidió”. Todo modelo debe de ajustarse a la organización y no la organización al modelo.

Al embarcarse en un esfuerzo de mejora de procesos, el objetivo siempre debe de ser la mejora, nunca el papel. Si se orienta desde un principio el proyecto a mejorar los resultados de la organización, se estará cubriendo las necesidades de ésta y de paso obteniendo el nivel deseado.

Comúnmente me encuentro con implementaciones de modelos que parten de plantillas, productos base o formatos que son provistos por una firma consultora para “apoyar” a la empresa con la definición de sus procesos. Creo que esta práctica es un arma de doble de filo. Si estas plantillas se utilizan como un ejemplo para partir de una idea para comenzar a definir los procesos creo que está correctamente utilizado, pero si por otra parte se utilizan estas herramientas sin una explicación previa, capacitación y revisión de las prácticas existentes en la organización podríamos estar privando a la organización de la creatividad, innovación y libertad para la definición de procesos lo cual será clave para la buena adecuación del modelo. Imaginemos el caso de un líder de proyecto que aprovechando el esfuerzo de mejora quiere modernizar los planes de proyecto usando una herramienta de gestión de proyectos en la nube, con reportes automatizados, actualización en tiempo real … y de pronto se le aparece un documento de texto plano con una portada, índice, capítulo de introducción, alcance, glosario, aprobaciones, etc. que en su conjunto la pura plantilla sin contenido son siete hojas (de las cuales realmente funcionan dos), que requiere de firmas de todos los involucrados del proyecto y para rematar se le dice “solamente con este producto puedes alcanzar el nivel deseado de madurez”. Estoy seguro que en este tipo de situaciones cualquier modelo con el nombre que se le quiera dar se puede volverá en una pesadilla para el líder de proyecto y todo el equipo.

 Por ejemplo, el Modelo de Procesos para la Industria del Software (MoProSoft) nos señala que en su nivel 2 y a lo largo de sus 9 procesos, existen 77 productos de trabajo. Si lo vemos fríamente además estos productos de trabajo se podrían incrementar debido a las evidencias solicitadas de la gestión de los proyectos si consideramos que cualquier acuerdo se puede ver reflejado solamente con una minuta firmada por los involucrados. En este caso en particular MoProSoft en ninguna parte de la norma nos señala que estos productos tienen que ser documentos en texto plano, hojas de cálculo, minutas, etcétera; uno podrá definir cómo llevar estos productos de trabajo y documentar los procesos utilizando las guías de ajuste.

 De la misma manera, el Project Management Body Of Knowlege (PMBOK) del Project Management Institute (PMI) deja muy claro desde su primer capítulo cuando nos dice que una “buena práctica” no significa que todo el conocimiento ahí descrito deba de ser aplicado de la misma forma en todos los proyectos de la organización, sino que es la organización o el líder de proyecto quien debe decidir sobre qué prácticas tomar para cada proyecto.

 Por su parte, en el Capability Maturity Model Integration (CMMi) del Software Engineer Institute (SEI) nos marca en su representación escalonada para el nivel 2 la implementación de 7 áreas de procesos y para el nivel 3 la implementación de 11 áreas de procesos.Si contabilizamos sus sub-prácticas en la constelación de desarrollo, para nivel 3 estamos hablando de 138 sub-prácticas a lo largo de las 18 áreas de proceso. Además de sumarle las 12 prácticas genéricas las cuales tendrían que estar implementadas en las 18 áreas de proceso, lo cual nos da 216 “evidencias” que se tendrían que mostrar. Como vemos, si nos ponemos a contar cada una de las prácticas e intentamos lograr generar una evidencia diferente para cada práctica o práctica genérica terminaremos con un montón de documentos en un servidor de la empresa que lo más probable es que al final del proyecto terminemos tirando a la papelera de reciclaje.

¿Cuál es la clave?

Lo esencial es estudiar el modelo para saber qué áreas de proceso y prácticas se relacionan entre sí. Con esto lograremos que por medio de una sola actividad varias prácticas del modelo al mismo tiempo. Recordemos que CMMi nos dará el qué y la organización propondrá el cómo. Además de que CMMi nunca nos solicita que tengamos minutas firmadas o documentos muy extensos, recordemos que tenemos también las prácticas de “Guías de adaptación”. CMMi nos solicita que llevemos las prácticas pero no necesariamente de la misma forma en todos proyectos (si previamente así lo documentamos).

Se puede considerar que todos los procesos tienen “caducidad”, por lo tanto entre más se automaticen o se utilicen herramientas para su gestión será mejor la forma para que no se “echen a perder” en la organización, ya que de forma automatizada se podría estar renovando.

En conclusión, todo modelo de procesos se puede volver tan ágil o lento como uno quiera, todo dependerá de la adaptación, adecuación e interpretación del modelo que se le quiera dar.

Cuántas veces hemos escuchado que se dice que los modelos “Ágiles” no pueden convivir con los modelos “clásicos”, más bien considero que aquellos que aseveran eso, es porque no han logrado interpretar adecuadamente los modelos “clásicos”.