Tenga una estrategia de negocio
Puede parecer una obviedad, pero muchas compañías (sobre todo las pequeñas) que dan sus primeros pasos en la mejora de procesos no tienen demasiado claro para qué lo están haciendo. Nadie debería empezar una iniciativa como ésta sin tener en claro en qué medida apuntala o refuerza la estrategia de la organización.
Antes de avanzar en formalizar un programa de mejoras deberíamos determinar en qué medida éste se alinearía con los objetivos estratégicos de negocio. ¿Nos permitirá reducir costos, aumentar ingresos, mejorar la atención a nuestros clientes?¿Nos dará más flexibilidad, nos hará más ágiles?¿Venderemos más?¿Le resultaremos más atractivos a nuestros clientes? Preguntas como éstas son las que deberíamos plantearnos para determinar si vale la pena o no embarcarnos en un esfuerzo como este.
Genere un ambiente propicio al cambio y a la integración
Las organizaciones suelen transmitir mensajes contradictorios. Si estamos diciendo que cambiar la manera en la cual trabajamos es importante y prioritario, debemos generar un ambiente en donde:
- Las sugerencias e ideas de la gente sean escuchadas (aunque a los gerentes no les guste lo que digan);
- La gente pueda participar en el proceso de cambio;
- La adhesión al cambio sea recompensado (y no penalizado);
- Haya recursos para que el cambio efectivamente tenga lugar;
- La dirección y los mandos medios sostengan el proceso de cambio.
Quienes están en mejores condiciones de identificar y proponer mejoras a los procesos actuales es la gente que está en las trincheras, sosteniendo el funcionamiento del negocio con su esfuerzo personal. Debemos trabajar con ellos (y no contra ellos) si queremos que la mejora se materialice en algo concreto. Ningún programa de mejoras funciona si no se les da participación activa a sus principales destinatarios.
Formalice el programa de mejoras
Como decíamos con anterioridad, las organizaciones de nivel 1 carecen de los mecanismos para manejar adecuadamente sus proyectos, inclusive aquellos relacionados con la mejora de procesos. El primer paso que debería tomar antes de comenzar es establecer un alcance y un plan muy claros, para que nadie sea tomado por sorpresa. Adicionalmente, será necesario establecer una estimación real del esfuerzo y la duración necesarios para cubrir todas las áreas de proceso de este nivel, objetivos a mediano y largo plazo (“¿Cómo seguimos después de alcanzar nivel 2?”), y un mecanismo para administrar el programa de mejoras (roles y responsabilidades, actualización del plan, monitoreo y control, etc.). En definitiva, hay que implementar -en el contexto del programa de mejoras- las prácticas de gestión de proyectos que habremos de implementar como resultado de ejecutar el programa de mejoras...
Muchas organizaciones optan por implementar algunas de las prácticas incluidas en las áreas de proceso OPD (Organizational Process Definition) y OPF (Organizational Process Focus), correspondientes al nivel 3. Esto es bastante habitual y, si bien pareciera ser una medida a contrapelo del modelo, ya que estaríamos implementando algo de nivel 3 antes de las áreas de proceso de nivel 2, es perfectamente aceptable (aunque nada fácil de mantener en el tiempo...)
Algo bastante habitual es encontrar organizaciones completamente obsesionadas con CMMI. Todos sus esfuerzos están puestos en cumplir con los objetivos del modelo, siempre al pie de la letra y con una mínima interpretación. Es así que terminan produciendo procesos extremadamente burocráticos e impracticables, con un mapeo prácticamente uno a uno con las áreas de proceso de CMMI.
De más está decir que esta obsesión, como muchas otras en otros órdenes de la vida, no suele ser demasiado sana. Si bien hay que tener presente al modelo, de manera tal de tener una directriz que guíe nuestros esfuerzos de mejora, deberíamos ponerlo en un segundo plano y enfocar toda nuestra energía en definir procesos que agreguen valor a nuestra organización. Siempre será necesario interpretar al modelo (por ejemplo, cuál es nuestra definición de proyecto vs. la definición de proyecto que propone CMMI) y hacer muchas concesiones para poder poner en práctica sus ideas.
Por otro lado, en general hay otros requerimientos con los cuales los procesos que definamos deberán cumplir. Siempre encontraremos que hay políticas y procedimientos organizacionales con los cuales será necesario cumplir (por ejemplo, cómo formalizar un contrato con un proveedor suele ser algo establecido por el sector de asuntos legales). También nos encontraremos en situaciones en las que será necesario mejorar procesos que no están incluidos en el alcance de CMMI (por ejemplo, la resolución de incidentes en producción), pero que son prioritarios para poder poner orden en el entorno en el cual se ejecutan los proyectos de desarrollo.
Por lo tanto, pensar únicamente en el modelo y especular si cumplimos o no con tal área de proceso de contar con una minuta de reunión más o menos es como estudiar “para zafar”. Si nos sacamos la presión del “examen” de encima, nuestra mente estará mucho más abierta, podremos pensar “fuera del modelo”, y, en consecuencia, el camino será mucho más fácil.
Identifique productos y servicios.
Es bastante difícil comenzar a definir procesos si no tenemos claro cuáles son los productos y servicios que ofrecemos a nuestros clientes/usuarios. A pesar de que probablemente suene raro que alguien no sepa qué es lo que produce su compañía, es bastante común encontrarse con actores con distintas visiones del negocio al cual se dedica la organización. Llegar a un consenso al respecto es sumamente importante, ya que facilita la identificación y mejora de procesos.
En general, las organizaciones de software o de IT en general, además de desarrollar soluciones suelen velar por la atención de incidentes en producción. También atienden consultas de los usuarios respecto a las aplicaciones, los orientan acerca de cómo usar la tecnología en el negocio, apoyan las actividades de preventa, y una larga lista de etcéteras. Está claro que cada uno de estos productos/servicios requieren procesos diferentes. Aún dentro de la misma familia, ligeras variaciones de los mismos productos/servicios podrían requerir procesos diferentes.
Identifique procesos.
A pesar de su opinión en contrario, la organización de nivel 1 para la cual seguramente Ud. está trabajando tiene procesos. Todas las organizaciones los tienen, más allá de su formalización.
Lo que no debería hacerse nunca es comenzar desde cero. Es mucho más fácil observar cómo se hacen las cosas hoy y ver de qué manera pueden mejorarse. A partir de los productos y servicios identificados será mucho más fácil encontrar los procesos empleados por la organización y, a partir de este punto, empezar a trabajar en mejorarlos.
Una de las tantas cosas que se van aprendiendo con los años es que la mayoría de las veces es necesario mejorar procesos que no están incluidos en el alcance del modelo. Un ejemplo clásico es el tratamiento de incidentes en producción: Si no hay un proceso para manejar este tipo de actividades, muy difícilmente pueda trabajarse en mejorar los procesos relacionados con los proyectos. La razón es sencilla: Podemos tener un muy buen proceso para gestionar nuestros proyectos, pero si no hay un proceso para manejar el resto de las cosas que hacemos, rápidamente nos dedicaremos únicamente a trabajar sobre lo urgente (los incidentes, en nuestro ejemplo), dejando de lado las actividades de mediano y largo plazo (los proyectos).
Esto también está directamente emparentado con la teoría de las restricciones [1]: Todos los sistemas, inclusive las organizaciones, tienen solamente un único punto más débil que el resto. Hacia él debería orientarse la mejora.
Defina tipos de proyectos.
Las organizaciones suelen ejecutar distintos tipos de proyectos. Algunos son más complejos o riesgosos, mientras que otros son más rutinarios y sencillos; algunos duran meses o años y consumen centenares de meses-persona, mientras que otros pueden durar un par de semanas y consumir no más de unas decenas de horas-hombre.
El esquema que definamos para administrar los proyectos debe tomar en consideración estas características. Claramente, no será lo mismo, por ejemplo, un proyecto de desarrollo de una nueva aplicación (o de evolución de una ya existente) que un proyecto de mantenimiento de rutina. En el primero de los casos, el enfoque de gestión de proyectos deberá ser más elaborado para poder lidiar con los riesgos y complejidades típicos de este tipo de emprendimientos. En el segundo, probablemente bastará con un método de trabajo más directo.
Queda claro, entonces, que aplicar prácticas demasiado sofisticadas en proyectos pequeños o poco riesgosos generará deseconomías de escala, burocracia innecesaria y, con toda seguridad, resistencia en las personas que deberán gestionarlos.
Definir el proceso para manejar los “grandes” proyectos es relativamente fácil. El problema que enfrentan muchas organizaciones es qué hacer con los proyectos “pequeños”, que suelen ser amplia mayoría en la cartera de proyectos.
Algunas organizaciones han encontrado la solución a este problema “reinterpretando” la definición de qué es un proyecto. En vez de manejar múltiples “mini-proyectos” independientes -lo que claramente implica un esfuerzo extraordinario-, han encontrado mecanismos que les permiten agruparlos en entidades más grandes -proyectos o programas- con el propósito de obtener economías de escala en las actividades de gestión.
Por ejemplo, si sabemos que durante un año necesitaremos realizar mejoras menores a una aplicación, cada una de las cuales llevará poco tiempo y esfuerzo (pero, probablemente, en su conjunto representarán una suma relativamente importante), podríamos definir un proyecto de “mantenimiento”, con un presupuesto y duración fijos y un alcance “variable”: A medida que durante el año nos vayan llegando pedidos de “mejora” de nuestros clientes o usuarios, los manejaremos como unidades de trabajo que deberán ser incluidos en el plan del proyecto.
En algunas software factories el enfoque adoptado es similar. Se establece un contrato de mantenimiento con el cliente, en el cual el proveedor se compromete a tratar pequeñas adaptaciones a uno o varios sistemas bajo determinadas condiciones (horas-hombre, calidad, etc.) y durante un periodo dado. Desde el punto de vista de CMMI, el “proyecto” es este contrato.
En estos casos, las actividades de planificación y monitoreo quedan establecidas a nivel del contrato. Por ejemplo, en vez de un plan para cada una de las adaptaciones solicitadas por el cliente, se mantiene un plan general para todo el contrato. En él habrá al menos un puñado de tareas relacionado con cada uno de los pedidos del cliente, mientras que las actividades de administración del proyecto estarán a nivel general.
Si interpretáramos los objetivos y prácticas de CMMI al pie de la letra, probablemente nos veríamos tentados a definir un proyecto para cada uno de estos “mini-proyectos” que acabamos de mencionar. Cada uno de ellos debería tener, en consecuencia, su propio plan (todos los planes: de administración de requerimientos, de aseguramiento de la calidad, del proyecto en general, etc.). Las actividades de gestión quedarían instanciadas para cada “mini-proyecto”, lo que llevaría a, por ejemplo, generar un informe de avance para cada uno de ellos. Claramente, esto es inviable.
Defina cómo nacen los proyectos (gestión de demanda)
En muchas organizaciones, la inmadurez se refleja no sólo en cómo son conducidos los proyectos sino también en cómo nacen. No es algo común encontrar organizaciones que cuenten con procesos formales para canalizar las necesidades de los clientes/usuarios, evaluarlas, y -finalmente- transformarlas en proyectos que agreguen valor a la organización.
En muchas áreas de sistemas es bastante común encontrarse con usuarios finales que tienen acceso directo a los desarrolladores para hacer sus pedidos, lo que claramente trae graves consecuencias. En primer término, el backlog de temas por atender queda oculto en la agenda de cada departamento o silo organizacional dentro del área de sistemas, o, lo que es peor, en la de algún individuo. En segundo término, los proyectos nacidos de esta manera difícilmente estén alineados con las verdaderas necesidades de la organización, ya que no es posible realizar un análisis estratégico bajo estas condiciones. Por último, es muy difícil balancear la carga de trabajo, ya que algunos grupos podrían estar saturados mientras que otros podrían tener capacidad ociosa.
En las compañías dedicadas al desarrollo de software la situación no es demasiado distinta. Los vínculos entre el área comercial y el área de desarrollo no suelen ser precisamente fáciles, con lo cual es bastante habitual encontrar proyectos que han sido “vendidos” a los clientes sin la más mínima evaluación por parte del resto de los actores de la organización (desarrollo, soporte, etc.)
Si bien este tema no encuentra un correlato directo en el modelo, la experiencia indica que es muy difícil poner orden en los proyectos si éstos nacen de manera descontrolada. Es como pretender que en una fábrica se construya todo lo que se pida: Si no hay un filtro al inicio es altamente probable que la capacidad de producción se vea superada y que cualquier intento por establecer un plan sea en vano.
Las organizaciones que han conseguido resolver estos problemas han puesto en marcha procesos que permiten manejar adecuadamente la demanda de sus usuarios/clientes, de manera articulada con la gestión de las carteras de IT (ver siguiente sección para más información al respecto).
Algunas de ellas han implantado comités de sistemas, cuya función es centralizar los pedidos de nuevos proyectos de IT y facilitar su evaluación. a través de los cuáles deben realizarse todos los pedidos relacionados con proyectos de IT. En general, este comité es el encargado de hacer un primer filtro, en el que se verifica, entre otras cosas, si el nuevo desarrollo requerido está o no alineado con los objetivos estratégicos de la organización.
De manera similar, en las empresas de tecnología informática suele ponerse en marcha un proceso de preventa que se encarga de gestionar la demanda de los clientes y canalizarla hacia equipos encargados de evaluar la posibilidad de ejecutar estos nuevos proyectos.
Establezca un marco de trabajo para la gestión de la cartera de proyectos y para la gestión de proyectos
El tema de IT portfolio management (o gestión de carteras) se ha puesto relativamente de moda en estos últimos años[2]. La idea es que los proyectos y los demás activos de la organización (aplicaciones, piezas clave de la infraestructura, recursos humanos, etc.) sean administrados tan concienzudamente como una cartera de inversiones (de hecho, lo son en la práctica). Por consiguiente, cada proyecto que se quiera encarar en la organización deberá:
- Estar alineado con la estrategia del negocio;
- Hacer buen uso de los restantes elementos en la cartera;
¿Para qué nos sirve la implementación de un proceso de este tipo? A nivel estratégico, está claro: nos permitirá concentrarnos en aquellos proyectos que son importantes. A nivel táctico, el orden general que promueve (los proyectos no cambian permanentemente de prioridad, se balancea la demanda con disponibilidad de recursos, etc.) permite que sean aplicadas prácticas básicas de gestión en los proyectos que incluidos en la cartera. El pretexto de mucha gente perteneciente a organizaciones de nivel 1 es “no puedo planificar porque me cambian las prioridades todo el tiempo”, o bien “planificamos pero siempre ingresan nuevos proyectos que destruyen la planificación que hicimos”. Con este enfoque, al menos las cosas deberían empezar a ordenarse.
Además de establecer un marco para la gestión de la cartera, es obvio que será necesario definir cómo serán administrados los proyectos. En función del tamaño y/o complejidad de los proyectos (ver la recomendación anterior, Defina tipos de proyectos.) será necesario establecer un marco que contemple como se planificarán y controlarán los proyectos. Inevitablemente, será necesario definir un marco de trabajo que permita:
- Estimar esfuerzo, costos y duración sobre la base de los requerimientos identificados (presumiblemente, con distintos grados de precisión según la madurez de la demanda realizada[3]);
- Establecer el ciclo de vida del proyecto, con fases, hitos y entregables;
- Desarrollar un plan de proyecto (incluyendo el cronograma) con el suficiente nivel de detalle para efectuar un control razonable de las actividades;
- Mantener comunicaciones entre el equipo de proyecto y los restantes interesados (usuarios, clientes, auspiciantes, etc.) acerca del avance del proyecto.
- Buscar, evaluar y seleccionar proveedores de productos y servicios necesarios para la ejecución del proyecto.
En definitiva, la organización deberá establecer un marco de trabajo más o menos general que describa cómo serán administrados los distintos tipos de proyectos. Si bien no debería profundizar en los aspectos relacionados con el desarrollo del producto en sí, este marco deberá describir las actividades de planificación, monitoreo y control con el suficiente nivel de detalle como para llevar adelante los proyectos. Si bien su alcance es más amplio, el PMBOK [PMI] es una buena fuente para consultar prácticas más o menos generales que podrían aplicarse en este caso. Volveré sobre este tema en una futura entrega.
Identifique y desarrolle líderes de proyecto
Esta recomendación puede parecer trivial, pero es bastante común encontrarse con organizaciones que tienen muy buenos recursos humanos, pero ninguno (o pocos) con los conocimientos, habilidades y ganas de ser líderes de proyecto.
Esto es lógico, ya que en las organizaciones de nivel 1 el énfasis está puesto en las actividades técnicas, por lo que son más valoradas las habilidades de desarrollo de software (y de lucha contra el fuego) que las de gestión.
Es imposible establecer un proceso de manejo de proyectos si no hay alguien que cubra el rol de gerente, jefe o líder (póngale el nombre que quiera). Alguien tiene que planificar, organizar y controlar los proyectos.
Seguramente, entre sus colaboradores debe haber personas con interés en este tipo de actividades. Entrénelos si es necesario.
No caiga en el error de promover a ese puesto (que no necesariamente debe ser jerárquico, sino más bien funcional) a personas que no estén suficientemente preparadas (lo cual es solucionable) o que no tengan vocación (lo cual es muy difícil de solucionar). El daño que pueden llegar a provocar en el programa de mejoras es enorme.
Establezca prácticas y herramientas de administración de la configuración
Como decía en la sección Administración de la Configuración (CM), esta es, probablemente, una de las disciplinas más difíciles de implementar. Si bien el tema da para escribir un libro entero (hay muchísimos y muy buenos[4]), me gustaría incluir aquí algunas recomendaciones.
Por un lado, es importante que se defina un ciclo de cambio que claramente describa cómo y de dónde se toman (o se crean, en el caso de que sean nuevos) los ítems de configuración (componentes de software, planes, especificaciones, etc.) de los proyectos, en qué lugar se modifican y verifican, y cómo se incorporan a la línea base (en el caso de software, cómo se pone en producción). Este ciclo -probablemente, un procedimiento de bajo nivel- deberá estar integrado al ciclo de vida (o a los ciclos de vida) de los proyectos, al proceso de reparación de emergencia (no incluido en CMMI-DEV, pero probablemente a incluir en CMMI-SRV), y al proceso de despliegue y puesta en producción.
Por otro lado, la implementación de una herramienta que facilite estas cosas es casi fundamental. Quizás la administración de la configuración de los documentos pueda realizarse de manera manual o con un simple administrador de versiones. Pero para gestionar las componentes que forman parte del software, contar con una herramienta parece ser algo imprescindible.
Lo más importante que podría recomendarle es: ¡Empiece pronto!
Inicie un programa de métricas
“Lo que no se mide no es administrado”, reza el viejo adagio. Definir y poner en marcha un programa de métricas que permita obtener un conjunto muy básico de indicadores es de fundamental importancia para poder monitorear y controlar los procesos de la organización y para poder evaluar el avance de la iniciativa de mejoras.
Las métricas definidas deberán estar alineadas con objetivos organizacionales y tendrán que tener metas asociadas. Sin objetivos y metas claramente establecidos es habitual caer en el error de medir aquello que resulta más fácil.
Adicionalmente, la complejidad de iniciar y sostener un programa de métricas radica en al menos tres aspectos cruciales:
- Por un lado, será necesario disponer de un procedimiento más o menos formal para recoger los datos base, consolidarlos, generar las métricas, analizarlas, validarlas y publicarlas.
- Por el otro, debe quedar claro que las métricas tienen utilidad para la organización. Para ello, será necesario describir cómo van a consumirse y en qué contexto. Si las métricas se generan pero no se emplean en ningún proceso o no se toman decisiones en función de ellas, rápidamente perderán su utilidad y, lo que es peor, generarán la sensación de que medir no es una tarea que se tome en serio.
- Por último, la disponibilidad de datos suele ser una de las falencias de muchas organizaciones. Un software de time-reporting o una aplicación de gestión de proyectos pueden ser mecanismos muy útiles para registrar datos y obtener algunas métricas básicas. Generar datos en forma manual y en base a la observación es un trabajo muy tedioso, poco integrado a las actividades del día a día, y muy costoso.
Establezca un marco de aseguramiento de la calidad
Una vez establecidas las políticas, los procesos y los estándares, será necesario monitorear su cumplimiento y tomar acciones correctivas en caso de detectar desvíos. Esto es sumamente importante, ya que le permitirá a la organización institucionalizar los cambios y evaluar los beneficios del programa de mejoras.
Muchas organizaciones se ven tentadas a asignar este trabajo -que puede llegar a ser visto por algunos como algo meramente mecánico- a personal junior o poco calificado para la tarea, algo totalmente desacertado.
El proceso de aseguramiento de la calidad es una pieza crítica, sobre todo en organizaciones que están empezando a dar sus primeros pasos en los niveles iniciales de madurez. A través de él, las organizaciones consiguen que los proyectos y las demás actividades comiencen lentamente a alinearse a los nuevos procesos, estándares y políticas. Será necesario asignar esta responsabilidad a alguien con el suficiente peso político para ser respetado por sus pares y por sus superiores.
En general, las organizaciones implementan este proceso identificando “puntos” de auditoría de calidad en determinados hitos o momentos de los proyectos. En esos puntos se procede a controlar la existencia y adecuación de determinados artefactos (planes, especificaciones, etc.), y a examinar cualquier otra evidencia que permita constatar la adhesión al proceso (minutas de reunión, imputación de horas al proyecto, etc.) Usualmente, el asegurador de calidad dispondrá de checklists para realizar su trabajo, los cuales le ayudarán a determinar qué aspectos evaluar.
Lo que no debe olvidarse es que el proceso de aseguramiento de la calidad (cualquiera sea el nombre que se le asigne) no solamente deberá ser empleado para auditar a los proyectos: hay otras actividades que deberán ser evaluadas, inclusive el mismo proceso de aseguramiento de la calidad.
No se olvide de las prácticas genéricas
En una organización con procesos institucionalizados encontraremos que:
- Las políticas organizacionales se cumplen;
- Se respetan los planes y las descripciones de los procesos;
- Se proveen los recursos necesarios para realizar el trabajo (herramientas, personal y económicos);
- Hay responsabilidades y autoridades claramente asignadas para ejecutar los procesos;
- La gente tiene los conocimientos necesarios para ejecutar los procesos eficazmente;
- Los resultados del trabajo (artefactos, productos) están puestos bajo administración de la configuración;
- Los principales interesados están identificados e involucrados en la ejecución de los procesos;
- Se monitorea la ejecución de los procesos y se toman medidas correctivas de ser necesario;
- Los procesos y sus resultados (servicios, productos) son objetivamente evaluados con el propósito de determinar su adhesión a las descripciones del proceso, los objetivos y los estándares, tomándose acciones correctivas en el caso de detectarse no conformidades.
- Las actividades, el estado y los resultados de la ejecución de los procesos son revisados por la dirección de la organización, tomándose acciones correctivas en caso de ser necesario.
Las prácticas genéricas son las que permiten arribar a una situación como la descripta. Ellas son las que proveen los mecanismos para que la organización emplee los nuevos procesos de manera rutinaria. También son las que proveen los mecanismos de “autocontrol” para evitar caer en los viejos hábitos al producirse algún evento indeseado.No deberíamos olvidarnos de las prácticas genéricas al diseñar nuestros procesos. Algunas de ellas son bastante fáciles de resolver; otras merecerán un análisis más detallado (como por ejemplo la GP 2.9 Evaluar Adhesión Objetivamente en el área de proceso PPQA, o la GP 2.2 Planificar el proceso en el área PP). Lo que no deberíamos hacer es acordarnos de ellas hacia el final del programa de mejoras. Deberían ser una prioridad desde el primer día.
Referencias
[1] http://en.wikipedia.org/wiki/Theory_of_constraints#Software_engineering
[2] Ver por ejemplo, [Kendall] y [Maizlish] para una explicación más detallada.
[3] En función de cómo haya sido definido el proceso de gestión de demanda, puede ser necesario realizar estimaciones preliminares (ordenes de magnitud) antes de que haya un pedido formal de iniciar el proyecto.
[4] Ver, por ejemplo, Configuration Management for Software, de Compton, Conner y Callahan; Van Nostrand Reinhold Company (1994). Un muy buen punto de entrada es http://en.wikipedia.org/wiki/Software_configuration_management
