Idea valiosa 2: cuantificación de incertidubre

La gestión de riesgos es un tema que parece simple y no muy revelador a primera vista. En lo personal, debo confesar que la presentación tradicional sobre gestión de riesgos no me resulta muy interesante. Resumiendo, existe riesgo cuando existe la posibilidad de perdida o daño. Gestionar los riesgos en un proyecto significa hacer una lista de esas posibilidades, darles un valor de ocurrencia, un valor de impacto y definir planes de acción para mitigarlos. Bueno, resumiendo bastante.

Pero existe un enfoque para analizar los riesgos que me resulta muy práctico y valioso. Muchos de los riesgos de un proyecto convergen en un hecho concreto: no se finaliza el proyecto a tiempo. Puede ser que las personas no estaban capacitadas como se esperaba, que la funcionalidad a desarrollar fue más difícil de lo esperado, que componentes externos se entregaron tarde o cosas por el estilo. Pero todo termina en que el equipo de proyecto dijo que iba a tardar 3 meses, y en la noche del último día se da cuenta que no termino. Ese es el gran resumen de los riesgos de un proyecto de software.
Este concepto está muy bien presentado en el libro Waltzing with Bears: Managing Risk on Software Projects de Tom DeMarco y Timothy Lister. Es lo que ellos llaman la cuantificación de la incertidumbre. Y ponen un ejemplo muy claro. Supongan que llamamos a un consultor para que analice nuestro proyecto y nos dice:

“Escucha, simplemente no hay chance de terminar esto antes de principio de año – cero. La fecha más probable para entregar un producto aceptable es inicio de abril próximo. Aún esta fecha no es tan segura. Probablemente no quieras comunicar ninguna fecha antes del primero de mayo. Al menos con una fecha en mayo o más tarde tienes una probabilidad de cumplir mejor que cincuenta-cincuenta. Si quieres una fecha donde no tengas posibilidad de entregar tarde, vas a tener que irte hasta fines de diciembre próximo.”

Representando la situación gráficamente, obtenemos un diagrama como este:

Este es un diagrama de riesgo donde el area bajo la curva representa la probabilidad acumulada de finalizar en una fecha dada. Si un tercio del area total se acumula a la izquierda del 1 de abril, la probabilidad de terminar antes de esa fecha es 0.33. El area total bajo la curva es 1.

Este es un gráfico revelador porque asocia el riesgo a las fechas. Uno puede observar como aumenta el riesgo a medida que las fechas son mas agresivas. Esto parece muy natural pero no lo es tan comun encontrar gente que actúe en consecuencia. Siempre vemos que la persona que pide la fecha de estimación intenta obtener la fecha más cercana posible, como si esto no incrementara el riesgo o como si las consecuencias no lo afectaran. Pero esa no es la realidad. En nuestro caso, si la persona con poder de decisión sobre el proyecto define que la fecha a comunicar será el 1 de abril, entonces debe estar preparado para entregar tarde, porque existe el 66 % de probabilidad que así suceda. ¿Está realmente dispuesto a afrontar ese riesgo?
DeMarco y Lister utilizan el gráfico para explicar un aspecto repetido hasta el cansancio en los proyectos de software:

“Una queja común que managers comparten con nosotros es que 'la fecha más temprana mencionada automaticamente se transforma en la fecha de entrega'. Publicar el hallazgo del consultor que 'no hay posibilidad de entregar antes de principio de año' puede ponerte en una posición donde el 1 de enero es entonces fijada con concreto como la fecha de entrega. Pero en el diagrama de riesgo, el area bajo la curva a la izquierda del 1 de enero es esencialmente cero. Esto dice que la posibilidad de terminar antes de la fecha de entrega es nula. La patología de definir una fecha de entrega como la fecha más temprana mencionada garantiza esencialmente que la fecha no se cumplirá.”

Idea valiosa: el cono de incertidumbre

Mucho del material que leo usualmente tiene pequeñas ideas que me hacen pensar. Tal vez es una frase, un párrafo, un concepto, algo que hace que el tiempo invertido en leer valga la pena. Hay veces que la simpleza de esas ideas me entusiasma.
Me parece que es una iniciativa útil comenzar a incluirlas en el sitio. No son genialidades necesariamente, algunas tal vez ya son tan conocidas que suenan más bien a sentido comun o conocimiento general, pero en algún momento, para alguna persona, han sido de gran valor. Y tal vez lo sigan siendo para algún lector. No esperen la fórmula de la Coca-Cola, solo pequeñas ideas.
Basta de presentaciones, comencemos a revisar estas ideas valiosas. La primera: el cono de incertidumbre:

Temprano en mi carrera profesional comencé a tener contacto con las estimaciones y con peticiones completamente inesperadas relacionadas con estas:

- ¿Cuánto llevaría hacer un sistema de contabilidad típico? - me preguntó mi jefe una vez al pasar, casi como quien habla del clima.
- Ehh...¿qué?
- Si, un sistema de contabilidad sin nada extraño, lo básico. ¿Cuanto tardaríamos en hacerlo?
- Mmm, no sé... ¿Vamos a hacer uno? Digo, ¿quien va a trabajar en eso? - preguntaba yo desorientado, sin mencionar que no tenía (ni tengo) la menor idea de qué es un sistema de contabilidad típico.
- No, eso no importa. Considera que podrías contar con los recursos que hagan falta. La pregunta es ¿cuanto tiempo nos llevaría hacerlo?
- Aja... Eh, pero... eh ¿no sé?

Si, lo admito, no fue uno de los momentos de mayor lucidez en mi carrera. Sólo faltaba que se me cayera un hilo de baba por la comisura de los labios para completar la cara del perfecto bobalicón.
Esta petición me resultaba tan inesperada y desconcertante que era imposible para mí dar respuestas medianamente lógicas. Simplemente no entendía de que me estaba hablando. ¿Qué respuesta podía dar?

Steve McConnell presenta en Rapid Development, adaptado de Boehm, el cono de incertidumbre:

"Para cualquier conjunto dado de características, la precisión en la estimación puede mejorar sólo de la misma manera que el software mismo se torna más refinado."

Este gráfico es simple. Cuando estamos definiendo el producto inicialmente las estimaciones de esfuerzo y costos pueden ser ir desde 0.25x a 4x. Estas estimaciones sólo pueden ir mejorando a medida que se conoce más sobre el producto. Así, las diferencias van disminuyendo hasta converger en un punto al final del proyecto.
La calidad de las estimaciones esta atada en gran parte a la información que se tenga sobre el producto a estimar. Con poca información, las estimaciones pueden tener grandes desviaciones.
Considerando el gráfico, para un producto que requiere 10 staff/months para desarrollar, en la etapa inicial de definición, las estimaciones optimistas pueden decir 2,5 meses y las pesimistas 40 meses.
Esa era la respuesta para mi jefe: "El sistema de contabilidad típico le puede llevar a una persona entre 2 meses y 3 años. No lo digo yo, lo dice Barry Boehm."

Mejores prácticas

Modelos de madurez de mejora continua como CMM parten de la premisa que la calidad del proceso utilizado para construir un producto define en gran parte su calidad final. Sin aceptar esta premisa, es poco útil discutir si el modelo es bueno, malo, o inocuo. Aceptando que este principio es merecedor de atención, se puede analizar algunos efectos colaterales del uso de CMM y algunas reacciones de las personas en su implementación.

Como las características del proceso son tan importantes cuando tomamos este enfoque, es lógico que una vez adoptado el mismo, miremos con una lupa los rastros del proceso, las evidencias que el uso de procedimientos y herramientas definidas dejan en su camino. Así uno captura estos rastros, los clasifica, los guarda, los cuenta, y analiza cual es el estado actual y cómo se puede mejorar. Para la persona que analiza un proyecto de desarrollo de software desde la perspectiva del proceso, las métricas, los rastros, las evidencias son la realidad. Son estos elementos los que dibujan el perfil del proyecto, a veces saludable, a veces agonizante, a veces ordenado, a veces caótico.

Las evidencias y los rastros no surgen en la ejecución de un proyecto necesariamente como las olas vienen con el mar y las golondrinas con la primavera. Muchas veces el rastro que algo sucedió en proyecto sólo queda porque es un agregado ajeno al fin específico de una tarea. Muchas veces este rastro o evidencia se debe generar como una extensión de la actividad, variando su camino natural con el fin de otorgar información relevante para otra audiencia.

Así dadas las cosas puede suceder que un proyecto ejecute un proceso efectivamente pero que no deje rastros. Tomemos un ejemplo porque la dicusión se torna muy abstracta. Supongamos que estamos utilizando Scrum como metodología. Una práctica de Scrum es la Daily Scrum meeting:

Cada equipo se junta diariamente para una reunión de estado de 15 minutos llamada Daily Scrum. Durante la reunión, el equipo explica que ha terminado desde la última reunión, que va a terminar antes de la próxima reunión, y que obstáculos tiene en su camino.

Agile Software Development with Scrum por Ken Schwaber y Mike Beedle

En este contexto, el siguiente dialogo entre una persona de Proceso y una del proyecto es posible:

- ¿Dónde están las evidencias que se están reuniendo todos los días? ¿Existe alguna minuta de estas reuniones?
- No, en realidad no tomamos minutas de estas meetings.
- Entonces, ¿cómo se yo si ustedes realmente se están reuniendo tal como dice nuestro proceso?
- Podés venir cualquier día a las 9:30 que es la hora de la meeting y vas a ver que estamos todos reunidos cumpliendo con esa práctica.
- Mmm, pero no está en un documento como evidencia.
- Si querés te saco una foto de la meeting con algún miembro del equipo sosteniendo el diario del día, como hacen los secuestradores para dar una prueba de vida.
- ¿Me estas tomando el pelo?
- Por supuesto.

El punto es que las personas que prestan atención al proceso tienen un aprecio especial por la persistencia de información que para otros ojos carece de utilidad, pero a ellos le permiten dibujar esa realidad que quieren mejorar. Ellos no pueden mejorar basándose en comentarios. Hay mucho análisis cuantitativo entre sus funciones que no funcionan bien fundamentados sólo en comentarios como “Estamos bastante bien creo yo“.

Cosiderando este tipo de casos donde se ejecuta un proceso que no deja rastros, es que se comienzan a definir los pasos adicionales ajenos a una tarea para dejar esos pistas que esta gente espera. Por ej. “Todos los días se realizarán reuniones Daily Scrum y se tomarán minutas que dejan constancia de los temas tratados y la duración de la reunión.“

Esa última frase no tiene ningún sentido práctico para la persona que ejecuta la actividad, tiene sentido para la persona que observa el proyecto desde la perspectiva de las evidencias y caracteriza así el proyecto.

Esto es entendible y tiene un fin respetable. Pero no resulta fácil destinar respeto a estas tareas cuando se llaman “mejores prácticas“ livianamente a estos pasos adicionales para generar evidencia.

En el caso de las minutas de reunión, un miembro de un departamento de Calidad podría decir que es parte de las "mejores prácticas" tomar minutas de las reuniones.

No. No lo es.

De hecho, en una situación como la planteada puede ser una mala práctica.

En general, coincido con el pensamiento de James Bach:

No hay mejores practicas. Con esto quiero decir que no hay una práctica que es mejor que todas las otras posible, sin importar el contexto..
Cuando dices que algo es una "mejor práctica, puedes impresionar al principiante, o intimidar al falto de experiencia, pero solo puedes lucir tonto para las personas que creen en la posibilidad de la excelencia.

No Best Practices, por James Bach

Esto puede derivar en nuevos pasos en cada actividad que parecen inútiles y sin sentido, que se hacen sin saber porque, que no tienen contenido porque se hacen siempre igual, un copy and paste constante de reglas que suponen que fuerzan una ejecución más efectiva y solo entorpecen el camino.

También es posible la variante donde se generan los rastros sin que se realice realmente lo que se debe hacer o que no refleje lo que se está haciendo. Por ejemplo, que no se hagan reuniones diarias pero que se generen minutas para que nadie se alarme y diga “¿Por qué no hacen reuniones?“. O que se generen minutas que nada tengan que ver con lo discutido en las reuniones. La esencia de una práctica es completamente cambiada por el uso y por el énfasis en la documentación.

Cada documento que se escribe, cada tarea que se realiza debe tener un objetivo, una audiencia definida. Muchas veces esta audiencia es un departamento de Calidad buscando elementos para mejorar los aspectos del desarrollo de la manera que juzgan adecuada. Y eso esta bien.

Es necesario comprender que muchas veces se requiere dar visibilidad en determinados aspectos a interesados en el proceso para poder mejorar. Necesitan que registre el tiempo asignado a tal o cual tarea. Esta bien, espero que noten en donde podemos mejorar y lo hagamos en el futuro.

Pero es bueno tener algunos puntos en cuenta para mantener cierto equilibrio: los pasos adicionales para generar evidencia adicional tienen un costo y un beneficio. Implementarlos requiere evaluar ambos. Considerar que un documento podría ser evidencia útil en el futuro, no transforma la actividad de completarlo en una “mejor práctica“.

People CMM

Cuando una empresa o grupo desarrolla software con mucho ímpetu y poca formación, suceden cosas interesantes. El ímpetu y la energía aseguran que se hará todo lo necesario para terminar los proyectos, por mejorar la manera de trabajar y por mejorar la calidad de los resultados. La poca formación asegura que, en general, las acciones para alcanzar lo recién mencionado sean erradas o mal direccionadas. Así, se forma un ciclo donde la energía fluye y se neutraliza así misma.

Lo que sucede es que es difícil priorizar los problemas y no malgastar esfuerzo cuando hay tantas cosas para arreglar que no se sabe por donde empezar. Cuando nadie sabe lo que debe desarrollar, nadie sabe cuanto falta para terminar, Pepe pisa los archivos de Hugo, los errores abundan como las hormigas en un día de picnic, hay tareas que nadie hace porque son tediosas, el programador estrella reescribe el código de los demás porque no usan notación húngara, el líder de proyecto juega con un Gantt en una nube mientras todos hacen horas extra, y alguien dedica meses a escribir documentos que nadie nunca mirará... ¿Qué se puede hacer? Poner un kiosco... No, mejor pensemos en respuestas que no requieran cambiar de profesión.

En estas situaciones, por lo general, no se manifiestan problemas de desinterés en la mejora. Siempre hay alguien con iniciativa que buscará alternativas como escribir requerimientos, hacer revisiones por pares, aplicar UML o usar Microsoft Project. Pero este torbellino caótico aspira todas estas iniciativas y les quita sentido. Una acción bastante común, por ejemplo, cuando el software que un grupo escribe se desmorona en producción por enésima vez es agregar alguien que haga "testing”. "Nos está faltando testing, eso es lo que nos pasa” piensan mentes bienintencionadas, aunque no del todo acertadas. Así se agrega a alguien al equipo que tomará el software dos minutos después que el grupo de desarrollo dijo que termino (que es un minuto antes que la fecha comprometida de entrega al cliente) y lo testea. Por supuesto, sin capacitación, sin requerimientos, sin tiempos, esta persona es tan útil para mejorar la calidad como el chico que fue a la esquina a ver si llueve (sólo que en este caso, el tester puede tener la culpa de la lluvia).

Estas situaciones no son agradables y son conocidas por la mayoría de las personas que desarrollan software; pero no son exclusivas de esta actividad, aunque este hecho no representa ningún alivio para el que les toca vivirlas día a día. Hay otras personas que enfrentan situaciones similares donde hay muchas cosas para mejorar y las opciones para empezar parecen muchas.

Las empresas de software, mas allá que a muchos le cueste entenderlo, dependen del conocimiento y de las personas que lo poseen para poder evolucionar. Hasta el gerente más ingenuo, llega a un punto donde nota la necesidad de invertir algo para que la gente esté mejor, o para que esté (es decir, que no se vaya). Y aquí sucede algo similar que en el caso anterior, el objetivo parece claro: se desea mantener las personas en la empresa y además que mejoren sus capacidades para que impulse el desarrollo de la empresa. La pregunta es que hacer: eventos motivacionales, regalos de cumpleaños, bonos, premios por productividad, newsletters con información de la empresa, capacitación, definición de plan de carreras, entradas al cine o cenas.

Así como el ingeniero entusiasta tira manotazos al aire intentando mejor su caótica situación con iniciativas de todo tipo, de esa manera está el encargado de RRHH, con sus buenas intenciones, intentando mejorar la situación sin saber muy bien por donde empezar. Pero debe lidiar con particularidades más desafiantes en ciertos aspectos.

Por ejemplo, cuando intenta premiar el buen desempeño como muestra de reconocimiento, con un par de entradas al cine, están aquellos que se sienten manipulados, otros se sienten subestimados, otros piensan que el premio es poco, otros esperan dinero, otros gustan del teatro, y a otros les da lo mismo. Con cada intento de mejorar las condiciones de trabajo y la moral puede suceder lo mismo. Siempre existen escépticos crónicos que encuentran falencias en todo y es desmotivante ver caer una a una las más variadas iniciativas.

En el caso del desarrollo de software existen recursos que ayudan a salir de este estado. Aquí es donde aparece CMM con su rol más valioso a mi entender. Tan valioso que casi se equipara con lo perjudicial que resulta cuando es fuente de inspiración de obsesivos del proceso, almas en búsqueda de evidencia infinita, que combaten su inseguridad con planes kilométricos y cuyo interés por el software parece estar más ausente que gestos de cariño en una película de Steven Seagal. Pero, bueno, ese es otro temaVolvamos a lo valioso... Decía entonces que un gran aporte de CMM es darle prioridad a los problemas, proponiendo objetivos y actividades para resolverlos. Así, cuando el caos es completo nos sugiere:

- Definir que es lo que hay que hacer.
- Planificar como se va a hacer.
- Verificar el avance.
- No perder las cosas realizadas.

Esta es una gran ayuda y no es ninguna novedad para mucha gente. La novedad para mí, y en definitiva la motivación de estas líneas es mi reciente descubrimiento que para el segundo caso también existe CMM: People CMM.

People CMM es una herramienta que ayuda mejorar aspectos críticos relacionados a las personas en las organizaciones. Emplea el mismo framework de mejora de procesos que el SW-CMM como base para un modelo de mejores prácticas para administrar y desarrollar las personas de una organización. Es decir, cuenta con niveles de madurez del 1 al 5, con áreas de procesos en cada nivel con objetivos, donde el nivel 1 representa la falta de consistencia de la organización en la manera de desarrollar el trabajo.
Según sus autores úcada nivel progresivo de People CMM produce una transformación única en la cultura de la organización equipándola con prácticas más poderosas para atraer, desarrollar, organizar, motivar, y retener a sus empleados.”

Es útil iniciar observando el nivel 2 para ver, según este modelo, donde conviene apuntar las acciones iniciales de mejora, cuales son las bases sobre las cuales las iniciativas de mejora a largo plazo se deben sustentar. Las areas del nivel 2 son cinco: Staffing, Comunicación y Coordinación, Entorno de Trabajo, Administración de Desempeño, Entrenamiento y Desarrollo, y Compensaciones.
Veamos brevemente a qué apunta cada una:

Staffing
El propósito de Staffing es establecer un proceso formal por el cual el trabajo comprometido es equiparado a las personas de una unidad e individuos calificados son reclutados, seleccionados y llevados en transición a asignaciones.
Esta área involucra los procesos relacionados con balancear la carga de trabajo con las personas disponibles, reclutar, seleccionar entre los candidatos para las posiciones abiertas, ingresar y dejar la organización, y traslado a nuevas posiciones.

Comunicación y Coordinación
El propósito de Comunicación y Coordinación es establecer comunicaciones oportunas a través de la organización y asegurar que la fuerza de trabajo tiene las habilidades para compartir la información y coordinar las actividades eficientemente.
El establecimiento de una comunicación efectiva comienza comunicando los valores, políticas, prácticas y otra información importante de la organización a la fuerza de trabajo. Además de esta comunicación top-down, la comunicación bottom-up es estimulada buscando la opinión de individuos sobre sus condiciones de trabajo.

Entorno de Trabajo
El propósito de Entorno de Trabajo es establecer y mantener las condiciones de trabajo físicas y proveer los recursos que permitan a los individuos y grupos de trabajo realizar sus tareas eficientemente sin distracciones innecesarias.
Esta área de proceso refuerza la responsabilidad del management de monitorear las necesidades de entorno y de recursos que afectan la habilidad de la fuerza de trabajo de hacer su trabajo eficientemente.
El management debe tener planes para mitigar los problemas que presenten riesgos serios para la salud, seguridad, o eficiencia.

Administración de Desempeño
El propósito de Administración de Desempeño es establecer objetivos relacionados con el trabajo comprometido contra los cuales el desempeño individual y de una unidad pueda ser medido, para discutirlo contra estos objetivos, y mejorarlo continuamente.

Entrenamiento y Desarrollo
El propósito de Entrenamiento y Desarrollo es asegurar que los individuos tienen las habilidades requeridas para realizar su trabajo y que son proveídos de oportunidades de desarrollo relevantes.
El foco primario de esta área de proceso está en eliminar la brecha que existe entre las habilidades actuales de cada individuo y las necesarias para ejecutar sus asignaciones. Una vez que los individuos tienen las habilidades necesarias para realizar sus asignaciones, ellos pueden enfocarse sus actividades de desarrollo en otros objetivos (personales).

Compensaciones
El propósito de Compensaciones es proveer a todos los individuos de remuneración y beneficios basados en su contribución y valor para la organización.
El sistema de compensaciones debe ser diseñado para motivar y premiar las habilidades y comportamientos que la organización considere vitales para su éxito.

Este es un breve pantallazo del nivel 2. Como en el caso de CMM, existen prácticas, y subpracticas con guías de implementación más concretas en el documento de People CMM.
En estas se puede encontrar sugerencias sobre que deben contemplar los procedimientos relacionados a cada área de proceso.
El documento está disponible en la web en http://www.sei.cmu.edu/cmm-p/version2/