Eme de Madurez

17 03 2010

Llevo tiempo sin escribir nada, mil perdones, pero es que un pequeño mocoso a llegado a casa y mi tiempo disponible tiende a cero. Vamos, que he sido padre por segunda vez y el blog, las actividades extra y mis ojeras han pagado las consecuencias.

Y aprovechando las circunstancias, voy a comentar algo de lo que me estoy dando cuenta, ahora que soy padre “segundizo”, pero que puede resultar obvio: Cuando tienes tu primer hijo, la improvisación y la adaptación reinan en tu vida: no hay planificación ni horarios y las tareas más triviales se vuelven una aventura.Bebé

Situación típica: vas a cambiar un pañal, ya tienes al niño preparado y “en bolas”, y de repente te das cuenta que te has dejado el pañal limpio en la otra habitación. No puedes dejarle solo porque se cae, así que le agarras en volandas (culo al aire) y le llevas a la otra habitación para coger el pañal limpio. Lo más normal es que entre el tiempo que tardas, el cambio de temperatura, y la postura, al niño le entren ganas de mear, así que ya tienes tres problemas: 1) limpiar al niño y ponerle el pañal (problema original), 2) cambiarte tú porque a tu hijo le ha dado por regarte 3) limpiar el suelo y/o pared. Aunque pueda parecer cómico, los que seáis padres entenderéis que cuando te pasa, te entra de todo menos risa.

Sin embargo, la experiencia sirven para algo, así que pasados unos meses (o cuando tienes otro hijo), estas cosas están más que planificadas y la ejecución es perfecta: preparas todos los enseres, te aseguras que no falta nada, coges al niño, le cambias rápidamente, colocas al niño otra vez en la cuna y recoges todo. Perfecto.

Está claro que la diferencia entre uno y otro es la madurez como padre. El padre inmaduro improvisa y se adapta a las circunstancias, y el padre maduro planifica y ejecuta sin salirse del plan.

Si extrapolamos la vida como padre al mundo de la empresa, veremos que es muy parecido. Una empresa inmadura (lo que se suele conocer por startup), tiene que improvisar y adaptarse para sobrevivir: se adaptan al mercado (porque no consiguen vender lo que esperaban), adaptan su tecnología (porque no es tan últil como se pensó), adaptan el modelo de negocio, en definitiva: se mueven rápido para sobreponerse a los imprevistos.

Sin embargo, una empresa madura, no tiene esa necesidad de adaptación continua: tienen claro el modelo de negocio, tienen claro el mercado en el que operan, tienen claros sus procesos de trabajo… en definitiva, planifican su trabajo y después lo ejecutan (siempre con matices, porque una empresa, por muy madura que sea, tiene que adaptarse continuamente a los cambios del mercado, y si no, que se lo digan a algunas en tiempos de crisis).

Llegados a este punto, creo que se ve claramente a donde quiero llegar: no construyas el edificio antes de tener claro dónde lo quieres. No tiene sentido construir un montón de procesos definiendo la forma de trabajar en la empresa (estilo CMMI), cuando todavía posiblemente no sabes cuanto tiempo seguirás haciendo ese tipo de trabajo. Lo más probable es que pasados unos meses, tengas procesos para hacer X, cuando en realidad has acabado haciendo Y. Es mejor establecer lo mínimo, introducir prácticas concretas y sencillas, e ir modificándolo y asentándolo conforme la empresa vaya madurando. Es decir: partir de la agilidad, para llegar a cierto nivel de procesos, y no al revés.

Anuncios

Acciones

Information

4 responses

30 03 2010
Carlos

Hola José Manuel, enhorabuena por tu segunda paternidad. Cuando voy a una compañía realizo normalmente lo que yo llamo una lista de preguntas de aproximación. Son preguntas sencillas, que pueden parecer “tontas”, pero que sorprendería ver en ocasiones las respuestas.

Una de las preguntas más habituales que realizo es ¿Qué es en tu compañía un proyecto? Fácil no? Pues no, un proyecto pueden ser muchas cosas, desde un diseño, planificación y ejecución de un programa estratégico de desarrollos a un mantenimiento de un aplicativo sencillo. Definir claramente lo que uno hace no es tan facil.

De ahí viene lo que tu comentas, “Si no sabes aún que es lo que haces, no definas procesos para hacerlo”, o como habrás leido en algunos sitios “Si no sabes donde estás, ningún mapa ayudará a guiarte”.

Desde el punto de vista CMMI, si ves las prácticas del área OPF, la primera cuestión que plantea es ¿Qué necesidades tengo en la organización? (en cuanto a procesos se entiende). Osea, que lo primero que te aconseja el modelo es que mires para dentro desde la óptica del conocimiento que ya tienes de tu organización, y a partir de ahí comiences a pensar que procesos tengo que definir.

Hasta aquí todo fácil, no? Ahora vamos a verlo desde el prisma del profesional de calidad o de procesos o como queramos llamarlo.

Desde el punto de vista de la mejora de procesos (o su definición, teniendo en cuenta que en algunas compañías el área de procesos es un erial), debes aplicar la visión de que es un proyecto más.

Si volvemos al área de proceso OPF, ves que el conjunto de prácticas que el modelo ha definido son como una EDT de un proyecto (evalúa e identifica las mejoras, planificalas y desarrollalas y por último despliégalas).

Como bien comentas, al principio defines unos procesos que una vez implantados posiblemente no se ajusten a tus necesidades (evalúa porqué la práctica OPF SP 1.1 o la OPF SP 3.2 fallaron, algo pasó).

Bien, algo falló. Y que hago ahora? Pues si ves la práctica OPF SP 3.4 lo especifica claramente; “improvement proposals, lessons learned, measurements, recomendations, etc.” Esto es, aprender y volver a empezar (corregir, mejorar, ampliar). Los procesos no son estáticos, son dinámicos.

CMMI-DEV V1.3
CMMI o CMM lleva 20 años evolucionando, adaptandose a las necesidades del mercado, simplificandose. ¿Qué es lo que hace el SEI? Aplicar OPF en toda su extensión. La versión 1.3 del modelo que saldrá a finales de este año simplifica las prácticas genéricas (que tostón), simplifica y aclara áreas de proceso, (por ejemplo Requierements Management, siempre un área de ingeniería pasa porfin a área de proyectos, con lo que seguramente en la versión 1.4 se integrará en PP y PMC y desaparecerá). El SEI aprende del uso del modelo y se refina.

Y en lo tocante a Agile, ya en la versión 1.3 aparecerán referencias directas a las metodologías ágiles. No conozco aún si habrá alguna práctica específica, que lo dudo, pero si “example work products” típicos de metodologías ágiles. Aquí puedes verlo http://www.sei.cmu.edu/library/abstracts/presentations/What-to-Expect-from-the-Next-Version-of-CMMI.cfm

Como ves, el SEI se ha dado cuenta de la fuerza que tiene para las organizaciones desarrollar mediante metodologías ágiles.

Un saludo y de nuevo enhorabuena!

Carlos.

30 03 2010
JM

Carlos, efectivamente el área de OPF es la encargada del propio proceso de mejora, sin embargo, al estar en el nivel 3, se produce una incoherencia. Las empresas, cuando pasan del nivel 1 al 2, lo hacen sin OPF, a ciegas, y eso desemboca en un “construyo la casa antes de saber dónde la quiero” (o tengo una bonita una casa pero en realidad necesitaba una tienda de campaña) 🙂
Seguramente, cuando se implante el área de OPF se verá que los procesos establecidos no eran adecuados, estaban sobredimensionados (típico error) o eran insuficientes, y entonces, a partir de ahí, sí que entraremos en el ciclo de mejora, pero hasta entonces, necesitamos cierta madurez y agilidad (como empresa, como responsables de calidad, etc.) para vivir sin OPF y no morir en el intento (:

Como dices, la clave está en “desarrollar mediante metodologías ágiles”, SEI se ha dado cuenta, la maquinaria está en marcha, pero tardará tiempo en llegar a las empresas.

Gracias con el comentario, me ha parecido muy interesante!!

JM

30 03 2010
Carlos

Hola José Manuel. No veo tu respuesta pero si la he recibido por mail. Te respondo.

En mi honesta opinión, no es que se produzca una incoherencia en el nivel 2 al no disponer del área de proceso OPF, simplemente que el puñetero modelo te da las pistas en una práctica genérica; GP 2.2 Plan the process.

Si vemos la definición de los diferentes niveles de madurez, a simple vista el proceso definido se alcanza en un nivel 3, y pensamos “que incoherencia”. Esto no es así. El nivel 2 de madurez (gestionado) no se puede desarrollar si no disponemos de documentos (o productos, puede no sea un documento escrito), que soporten el proceso, esto es, un proceso vamos a llamarlo “descrito”.

Para entender esto, si leemos lo que es un proceso gestionado “A managed process is a performed process that is planned and
executed in accordance with policy; employs skilled people who have
adequate resources to produce controlled outputs; involves relevant
stakeholders; is monitored, controlled, and reviewed; and is evaluated
for adherence to its process description.” apreciamos que el modelo habla claramente de process description.

Claro, pero nos preguntamos “En el nivel 2 no existe una práctica GP 3.1 Establish Defined Process” que me solicite disponer de un proceso definido y no dispongo de prácticas que me permitan definir el proceso o mejorarlo (OPF).

La clave, tal y como la interpretó una compañera mía Lead Appraiser cuando tuvo la observación del SEI, esta en la práctica genérica 2.2 Plan the process.

La practica señala que el objetivo de la misma es determinar lo que se necesita para ejecutar el proceso y para alcanzar los objetivos definidos (Recuerda la práctica OPF SP 1.1, definir los objetivos de la organización en materia de procesos). Es decir, GP 2.2 Plan the Process no es poner las actividades definidas en un gantt, son más cosas:

“The plan for performing the process typically includes the following:
• Process description
• Standards and requirements for the work products and services of
the process
• Specific objectives for the performance of the process (e.g., quality,
time scale, cycle time, and resource usage)
• Dependencies among the activities, work products, and services of
the process
• Resources (including funding, people, and tools) needed to perform
the process
• Assignment of responsibility and authority
• Training needed for performing and supporting the process
• Work products to be controlled and the level of control to be applied
• Measurement requirements to provide insight into the performance
of the process, its work products, and its services
• Involvement of identified stakeholders
• Activities for monitoring and controlling the process
• Objective evaluation activities of the process
• Management review activities for the process and the work products”

Si os dais cuenta, son exáctamente las prácticas genéricas del objetivo genérico 2, lo que nos permite institucionalizar el proceso.

Resumiendo, es ahí donde está la necesidad de disponer de un proceso “descrito”. Que esté correctamente descrito dependerá del nivel de alineamiento que se consiga con los objetivos de la compañía (definirlos correctamente es crítico) Ese es trabajo nuestro, ni la práctica GP2.2 ni OPF te asegurarán que defines lo que se necesita.

Saludos,
Carlos.

30 03 2010
JM

Gracias por la info, Carlos. Hoy he aprendido un montón sobre este tema (:

Un saludo

JM

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s




A %d blogueros les gusta esto: