Dime qué Desayunaste y Te Diré qué tan Productivo Estarás Hoy

Recientemente me topé en la red con un artículo que, primero me llamó la atención por su título: “Productividad Ágil: Voluntad con enfoque de neurociencias” [1], y luego me cautivó por su contenido.

El enfoque al tema de productividad en Ingeniería de Software, abordado de manera similar como lo hacen las industrias “tangibles”, siempre me ha parecido inadecuado (con todo respeto para mis colegas “creyentes fervientes” en PSP, TSP y CMMI).

La forma en la que las empresas miden la productividad, es a través de un cálculo en el que se realiza una comparación entre los insumos y los productos, donde la eficiencia es lo que representa el costo por unidad de cada producto. [2]

El problema que percibo en la industria de software tiene dos aspectos: por un lado, producir software es un trabajo donde los insumos y la maquinaria se encuentran en el cerebro de un humano y los productos son abstractos, por lo tanto es una industria de lo intangible. Por otro lado, no se ha llegado a definir una unidad del tamaño de software de manera universalmente aceptada. En la prehistoria empezamos con líneas de código (LOCs), luego llegaron puntos por función (FPs), siguieron puntos por casos de uso (que nunca se estandarizaron) y ahora tenemos puntos COSMIC, que podrían ser buenos candidatos por ser estándar ISO, pero dependerá de la aceptación por parte de la industria. Sin la misma medida del tamaño, las definiciones de la productividad son incomparables. Para los que gustan de los albures: en la Ingeniería de Software el tamaño sí importa :( .

¿Y qué tiene que ver la voluntad con todo esto?

En el artículo mencionado al inicio, la autora nos explica que la fuerza de voluntad es la que nos permite tomar decisiones para hacer algo, a veces difícil y no necesariamente muy agradable, pero que al final nos traerá una gratificación.

Díganme, si participar en un proyecto de software no es hacer algo a veces difícil y no necesariamente muy agradable, pero que finalmente algún día nos pagarán. Pero si alguien, como yo, pensaba que la fuerza de voluntad dependía en gran medida de la “zanahoria y el látigo”, estaba muy equivocada. Para tener fuerza de voluntad necesitamos tener suficiente lisina (un aminoácido) que nutre nuestra capa prefrontal del cerebro (figura 1). Y, ¿de dónde viene la lisina? De las proteínas que comemos. Así que, si desayunaste huevitos con frijolitos quédate tranquilo, vas a ser muy productivo, pero si solo comiste pan dulce con café, tu concentración en el trabajo va ser muy cortita :( .

El consejo no es solamente desayunar y comer proteínas para ser productivo. La autora nos da unas pistas de cómo ahorrar la lisina para poder trabajar concentrados por más tiempo durante un día:

• Crear hábitos.
• Usar rituales.
• Trabajar en modo fluido.

Un hábito es algo que sabemos, podemos y queremos hacer. Ir a bañarse después de levantarse es un hábito que sabemos cómo hacerlo, si tenemos regadera, podemos hacerlo y si hay agua caliente, queremos hacerlo :) . La gratificación al final también se siente. Los hábitos requieren muy poca fuerza de voluntad, porque nuestro cerebro reconoce rápido que es algo habitual y lo hacemos sin mucho esfuerzo. Lo malo de adquirir nuevos hábitos es que para que se nos “peguen” necesitan repetirse diariamente por lo menos ¡70 días! Con este dato entendí porque mis propósitos de año nuevo se vuelven tan irreales.

Un ritual es una ceremonia o acción realizada como costumbre. Los rituales nos dotan de energía. Uno de los rituales más bonitos que he encontrado en México es el Día de Muertos, aunque cuando por primera vez vi en el altar del posgrado de la UNAM una calaverita de azúcar con mi nombre en la frente, me asusté. Los rituales y los hábitos son como caminos bien trazados en nuestro cerebro, que no cuesta esfuerzo volver a recorrerlos.

Un modo fluido de trabajo es cuando estás concentrado en una tarea única, interesante, compleja, pero no demasiado, desconectado de tu entorno y en el pico de tu concentración. La resistencia (física) y la paciencia (mental) también ayudan. El modo fluido de trabajar se dificulta cuando la tarea, que tenemos que hacer, no es ni interesante ni compleja, en este caso nos aburrimos rápido y buscamos distracciones para no hacerla. Otro extremo es cuando la tarea es tal vez interesante, pero tan compleja que no sabemos ni cómo empezar. En este caso nos angustiamos, las cosas no salen y podemos caer en el estrés. El estado de estrés (figura 2) nos lleva a perder el foco en el trabajo, lo que causa la mala calidad de los resultados, cuyos defectos tenemos que corregir, lo que nos causa mayor estrés. Y de la gratificación ni hablar, puros regaños. ¿Quién no ha vivido este círculo vicioso?

¿Cómo esto se relaciona con el trabajo de desarrollo de software?

Hábitos

En el caso de las prácticas SCRUM, las reuniones diarias realizadas siempre al inicio del día, a la misma hora, en el mismo lugar, con asistencia de todo el equipo y con las mismas preguntas es un hábito que, bien llevado a cabo, carga a todos con energía necesaria para empezar con mucha voluntad el trabajo (suponiendo que todos desayunaron proteínas :) ). Otro ejemplo de hábito es cuando uno, al terminar una tarea, revisa el resultado antes de entregarlo y hace todo lo que se pide para que otros se enteren que ya la había terminado (por ejemplo, mover la tarjeta en el tablero y/o reportar las horas dedicadas). Avisar que uno había terminado bien una tarea es gratificante ¿verdad?

Rituales

No se lo digan a nadie, pero todas las buenas prácticas de los modelos, estándares y libros de Ingeniería de Software son rituales. Qué tal el ritual del Sprint de SCRUM. Ya desde el nombre, carrera corta de atletismo, suena a misterio. Inicia con la reunión de la planificación a dos tiempos en la que participa activamente el equipo de desarrollo y el (igual de misterioso) Product Owner. El sprint tiene una duración corta de entre 2 a 4 semanas, que para el desarrollo de proyectos de software es efectivamente una carrera corta, y termina en la revisión de software con el Product Owner y en la retrospectiva del equipo. Al final del sprint, si todo salió bien, la satisfacción del equipo debería recargar sus energías para aguantar la siguiente carrera, igual de corta, que empieza la semana siguiente. Ni toman en cuenta, que en el atletismo los cuatro sprints de 100 metros se hacen por relevos :) .

Otros ejemplos de rituales son las diferentes técnicas para comprender y especificar a los requerimientos como los casos de uso o historias de usuario. Empiezan con el peregrinar para entrevistar a los diferentes representantes del cliente para comprender qué diablos quieren y qué significa lo que quieren. Continúan con los intentos de expresarlo de alguna forma, que sea de utilidad posterior para guiar al desarrollo. Luego sigue la batalla con los involucrados por la confirmación de que lo que se expresó como requerimiento ellos lo entienden y quieren que sea implementado. Cuando termina este ritual, los desarrolladores se llenan de energía porque, por un rato, piensan que allí terminó la batalla por comprender los requerimientos. ¡Qué ingenuos!

La mala noticia es que en estos rituales los que ahorran lisina son solo aquellos que los han repetido muchas veces, es decir, ya se volvieron sus hábitos. Los que son novatos van a sufrir.

Modo fluido de trabajo

Para trabajar de esta manera en el desarrollo de software, es indispensable que el reto que tenemos que atacar sea acorde con nuestros conocimientos y habilidades. Si se deja una tarea habitual como por ejemplo, documentar un caso de uso o una historia de usuario a un principiante que apenas fue capacitado (o mintió que sabía como hacerlo), se va a sentir muy angustiado y no va a poder hacerlo bien. O al contrario, si dejamos a un analista experimentado una tarea de documentar el requerimiento de “iniciar la sesión”, se va a sentir subutilizado. En ambos casos no van a sentir la satisfacción de su trabajo y la productividad va estar por los suelos.

El consejo final es: usa rituales (procesos) para iniciar el hábito de trabajar con fluidez. Y come proteínas :) .

PD. Esta es mi columna número 50 para la revista Software Guru. Durante más de 11 años repito un ritual de escribirla, que ya se volvió mi hábito y lo hago de manera fluida. Cuando la releo ya publicada me siento muy bien :) . 

Referencias

1. A. Obukhova. “Agile Productivity: Willpower and the Neuroscience Approach”. http://swgu.ru/rg
2. http://definicion.de/productividad