Browsing articles in "Calidad de Procesos"

Sin slack time no hay espacio para la mejora

Quienes estamos interesados en la mejora continua, entendemos la importancia de disponer de espacios para reflexionar. En esos espacios identificamos cambios y diseñamos experimentos pero, lamentablemente, no siempre somos capaces de aprender de nuestras experiencias. Muchas veces, resulta necesario también disponer de tiempo para dejar fluir las decisiones ya tomadas, las acciones realizadas, y así permitir que los aprendizajes maduren y las nuevas ideas germinen. Un entorno propicio para que esto suceda es el slack time.

Slack time: Tiempo holgado que habilita realizar actividades no pautadas.

slack-time

Existe la idea de que el tiempo que no estamos “cumpliendo con nuestras tareas” no estamos generando valor al negocio, lo que muchas veces nos hace sentir culpables si hacemos explícitos los momentos slack. Como consecuencia del miedo o vergüenza que nos genera hacerlos visibles, los tomamos sin conciencia, dado que voluntariamente o no, no nos es posible ser productivos todo el tiempo. Así, los espacios slack quedan camuflados e inconscientes y resultan menos efectivos de lo que podrían ser si fueran oficiales.

La propuesta es mantener espacios slack validados, acordados y lícitos, y realizar un esfuerzo por limitar que la vorágine del día los devore. Resulta necesario entonces, disponer de una adecuada gestión del tiempo para poder estar ordenados, y así tener herramientas para proteger con conciencia esos espacios.

img_20161122_155401

Son muchos los beneficios de poder tener espacios slack: empezando por la satisfacción de pasar tiempo realizando una actividad que disfrutamos y que podemos compartir con nuestros compañeros (momentos kairos!), lo que da lugar a que personas y equipos de trabajo fluyan mejor en sus tareas. También propicia la confianza, dado que hay espacio para que los temas ocultos -que en otros contextos no tiene espacio para salir- emerjan. Adicionalmente, cambiar el foco de atención propicia el espacio adecuado para que una serendipia ocurra (descubrimiento o un hallazgo afortunado e inesperado que se produce cuando se está buscando otra cosa). Así, la claridad para resolver un problema en curso podría llegar durante una una caminata al sol. En Kleer, actividades como meditar a medio día, tocar el piano o dedicar unos minutos a una siesta reparadora, son algunos ejemplos de nuestros espacios slack.

Existe el riesgo de hacer un uso engañoso del slack time, utilizándolo como medio de procrastinación (postergar algo que estamos negados a hacer). De esta forma, lejos de aliviarnos, podemos quedar enganchados con “eso otro” que todavía no hicimos, y dado que no estamos plenamente presentes en el espacio de slack, no podemos aprovechar la máximo sus beneficios.

Otro ejemplo de organización que promueve el slack time es la empresa FDV Solutions, con instrumentos musicales y diversidad de variaciones de Cubos Rubik dando vueltas por la oficina, festejos de cumpleaños después del almuerzo el último viernes de cada mes, las siestas en los puff y las gloriosas sesiones de masajes de 15 minutos!

foto-438

Encontrar el mejor momento del día para tener nuestro espacio slack puede convertirse en una búsqueda en sí misma. Una opción es planificarlo para el final del día, con la doble función de servir como motivador para avanzar en las tareas y dar cierre relajado a la jornada laboral. Una alternativa es planificar espacios slack al inicio o durante la jornada, a modo de intervalo de descanso para arrancar renovados el siguiente desafío que nos toque abordar. En algunos casos es una buena opción ya tener planificado qué vamos a hacer en nuestro espacio slack. También puede ser una buena idea simplemente escuchar “qué es lo que nuestro cuerpo y la mente necesitan hacer” (tal vez resultado también de la sincronización con nuestro reloj biológico) que puede resultar en salir a dar una vuelta, tocar algún instrumento, coordinar algún juego en equipos o mirar algún video inspirador.

La invitación es a empezar a tener momentos slack hoy mismo, y explorar los momentos del día y contextos en los que mayores beneficios se perciben!

Enlaces relacionados:

Medir

Medir es una actividad muy-bien-vista por los altos directivos de muchas organizaciones. Ni hablar cuan alentada es si el resultado de la medición es expuesto utilizando un montón de amontonados y diminutos numeritos representados por extravagantes gráficos.

La primera distinción que se me ocurre respecto este punto está asociada a diferenciar datos de información. Wikipedia define a información como un conjunto organizado de datos procesados, que constituyen un mensaje que cambia el estado de conocimiento del sujeto o sistema que recibe dicho mensaje. Personalmente, los datos descriptos en el párrafo anterior no generan en mi ninguna de estas cosas.

Luego, ¿Cual es la estrategia que debiera poner en práctica para que sea posible presentar información en lugar de datos?  Una primera respuesta podría desprenderse de revisar algunas definiciones básicas del universo de las métricas.

  • –      Atributo: Característica mensurable. Por ejemplo el tamaño del sistema o su calidad.
  • –      Medida: Asignación de un valor resultante de una medición a un atributo. Para el atributo tamaño del sistema las posibles medidas podrían ser 5.754 líneas de código, 213 páginas de especificación o 659 horas de desarrollo. Para el atributo calidad de un sistema una posible medida podría ser 27 bugs identificados, 177 casos de prueba ejecutados o 879 horas de testing.
  • –     Métrica: Referencia cuantitativa del modo en que un objeto de medición posee un atributo dado.  Siguiendo con los ejemplos anteriores, la métrica para evaluar la calidad de un sistema podría ser  cantidad de bugs por líneas de código.
  • –    Indicador: Es la interpretación de la métrica. Se construye en función del interés del observador. Por ejemplo, un indicador podría ser nivel de calidad de un sistema que pueda tomar lo los valores: muy buena, buena, media y nula (valores que se definen en en función de la interpretación del resultado de la métrica).

Las métricas e indicadores proveen un alto nivel de visibilidad sobre procesos, proyectos y productos. En particular, si lo que se pretende es exposición de información, el indicador es, sin dudas, la estrella protagónica.

Entonces… usar indicadores resulta una herramienta –muy potente- para presentar información sobre el estado de procesos, proyectos y productos. De ahí a las acciones que se tomen en función de los resultados obtenidos, es un tema muy-mucho-mas-difícil que no faltará oportunidad de discutir en futuros posts.

Ciclo de Deming

También conocido como PDCA (Plan.Do.Check.Act) el ciclo de Deming puede definirse como el circuito canónico para la mejora de procesos. Luego, si lo que se desea es proyectarse hacia el universo en donde mejora continua está a la orden del día, la ejecución sistemática de los cuatro pasos de este ciclo constituye una herramienta poderosa para cumplir ese objetivo.

Los cuatro pasos:

  • Plan: Planificación del proceso. En esta etapa se deben definir los objetivos y la estrategia para cumplirlos. También se confecciona la lista de actividades a realizar y los tiempos asignados para éstas.
  • Do: Llevar a cabo el proceso.  Es muy importante tener visibilidad sobre la ejecución (cómo resulta la experiencia de seguir el plan y cuales son los desvíos identificados, entre otras posibles observaciones)
  • Check: Verificar el proceso. Una vez finalizada su ejecución, es necesario realizar la evaluación del mismo;  comparar los resultados esperados con los obtenidos e identificar oportunidades de mejora.
  • Act: Adaptar el proceso en función del conocimiento adquirido en los pasos anteriores.

Para aquellos que tengan intención de reconsiderar sus procesos apuntando a  una próspera mejora continua para el año que viene, tal vez poner en práctica las sugerencias propuestas por el ciclo de Deming no sea una mala idea. Éxitos -en cualquiera las formas que los deseen- y feliz, muy feliz 2011!

Visibilidad

La falta de visibilidad sobre los proyectos de una organización podría considerarse un escenario equivalente a no disponer de iluminación para inspeccionar como se está cocinando el Volcán de Chocolate en el interior del horno.

En el contexto de desarrollo de software, es posible dirigir la visiblidad sobre un proyecto en tres sentidos; hacia el cliente, hacia la organización y hacia los miembros del equipo.

Planteados los distintos destinatarios, es común que se presentarse una pequeña pero no por eso poco importante dicotomía:

  • Dar el mismo nivel de visiblidad en las tres direcciones
  • Ajustar la información en función del grupo al que está dirigida
  • Las prácticas de Scrum están fuertemente alineadas con la primera de las opciones, defendiendo la transparencia sobre estado del proyecto. Por otro lado, la segunda de las opciones tiene sus incuestionables beneficios, pero se le asocia la desventaja de tener que sumar a la inversión de esfuerzo que requiere generar los informes, el trabajo de adaptarlos.

    Las métricas automáticas proveen una solución cuantitativa concreta para obtener clara visiblidad sobre variables significativas de un proyecto…  Pero claro, una solución tan maravillosa no puede menos que ser cara, difícil de mantener y requerir mucha disciplina por parte todos los miembros del proyecto…

    Una práctica que maximiza la relación costo beneficio en este plano es realizar reuniones de avance periódicas. En dichos encuentros es posible presentar el estado del proyecto, los desvíos respecto a la planificación y la lista de riesgos.  Adicionalmente, reuniones complementarias a las de avance, como el kickoff y el postmortem (o restrospective -como le dicen los ágiles-) también proveen un montón de visibilidad sobre los proyectos y los procesos de la organización.

    Como conclusión,  podríamos decir que resulta central para la salud de nuestros proyectos que los involucrados puedan advertir con claridad el estado actual, hacia donde se dirigen, y cuán bien -o mal- encaminados están. Y en definitiva, lo que cueste esta práctica siempre va a ser un precio menor al costo asociado a que los involucrados en un proyecto no sepan en donde están ni hacia donde  van.

    El cultivo de las buenas prácticas

    Se dice que la confianza se construye durante años y se derrumba en un instante… Con el ejercicio de las buenas prácticas, sucede algo parecido.

    Una buena práctica es aquella que de alguna manera, en alguno de los planos posibles, contribuye con la mejora…  lo cual no necesariamente significa que tenga que estar definida en un modelo de madurez o en un marco de desarrollo de gestión de proyectos (ni la recíproca, es decir,  una práctica propuesta por los distintos modelos no tiene por que ser útil para toda organización) El arte: tener la sensibilidad para identificar, en un contexto determinado,  las que sirven de las que no…

    En el marco del desarrollo de software, resulta muy difícil implementar actividades que favorezcan el proceso de mejora (y esa es la parte fácil). El real desafío -archiReContraSuperDifficile- es mantenerlas. Desde mi percepción, algunas de las razones por las que el ejercicio de las buenas prácticas se va disipando están relacionadas con:

    • –      Si no son adecuadamente implementadas, pueden convertirse en actividades exclusivamente burocráticas
    • –      El retorno de la inversión del tiempo invertido no es claramente perceptible (y mucho  menos en el corto plazo)
    • –      En algunas organizaciones está implantada la idea que se puede ser ágil (dinámico, pro, canchero, alineado con las metodologías de moda) ignorando la metodología tradicional…  sin implementar tampoco prácticas de las metodologías ágiles!

    Entonces… ¿Cuáles son las posibles acciones que se pueden tomar para evitar que las buenas prácticas se vayan diluyendo?

    • –      Elegir, en primer lugar, el subconjunto de actividades con el mayor retorno de inversión, y hacer foco en logar institucionalizarlas
    • –      Institucionalizarlas implica: Capacitar, coachear, seguir, controlar, evaluar, adaptar…
    • –      Identificar con claridad el beneficio para cada una de las personas que participan en la implementación de las distintas prácticas, y comunicárselos…

    Y como dice Antón Pirulero… Que cada cual atienda su juego… y en particular cada organización, sus buenas prácticas!

    Repostería y desarrollo de software

    La receta para preparar un rico volcán de chocolate, es la siguiente:
    Ingredientes: 200 g de chocolate, 40 g de manteca, 4 yemas, 50 g de azúcar, 2 claras. Preparación: Derretir el chocolate con la manteca por un lado, batir las claras a punto nieve (con la pisca de sal) por otro y batir las yemas con el azúcar a punto blanco. Luego mezclar claras con las yemas y finalmente integrar el chocolate. En moldes enmatecados llevar 10 minutos al horno.

    Si la calidad del volcán se gestionara con criterios equivalentes a los que se utilizan para desarrollar software…

    • –      No hubiéramos validado que los huevos estuviesen en buen estado
    • –      El equipo que prepara las claras hubiera pensado que el azúcar se lo ponía el equipo que preparaba las yemas, y el de las yemas, que el azúcar era responsabilidad del otro grupo.
    • –      Batir a blanco las yemas lo hubiéramos considerado un improvement y lo hubiéramos postergado para otra iteración.
    • –      Las claras a nieve las prepararíamos en la licuadora
    • –      Nos daríamos cuenta que es necesario sacar el  volcán del horno al empezar a  sentir el olor a quemado

    Una vez  listo el volcán, al probarlo consideraríamos bugs

    • –     Que tiene un dejo de gusto a rancio
    • –     Que le falta azúcar
    • –     Que se quemó un poco

    Para resolverlo…

    • –     Le rasparíamos los sectores quemados
    • –     Lo espolvorearíamos con azúcar impalpable
    • –     Y le agregaríamos dulce de leche para disimular el sabor rancio del huevo en mal estado.

    El desafío de este blog es arrojar algo de claridad sobre el universo de posibilidades que nos permitirán mejorar la forma en que desarrollamos software.