El Juego de Equipo
Un Marco de Trabajo Remoto
Esta es parte de nuestra experiencia gestionando equipos de trabajo remotos para el desarrollo y soporte de BIMS durante y post-cuarentena. Cómo nuestra operación pudo crecer exponencialmente en el escenario más “inconveniente” y, principalmente: cómo hicimos para sostener ese carga en la que se suponía sería solo una dinámica de trabajo de contingencia. Estos son los enfoques, las metodologías y las herramientas que desarrollamos y adoptamos para lograrlo.
“Cerraremos la oficina un par de semanas”
¿Alguna vez les pasó que súbitamente debieron cerrar sus oficinas y todo su equipo de trabajo debió trabajar de forma remota? Pfff… ¡Claro que les ha pasado! A todos nos pasó, en todo el mundo. El turno de Paraguay llegó a inicios de marzo de 2020. En nuestra empresa, TIVA, adoptamos la medida — más bien la acatamos — el 11 de marzo de 2020. Anunciamos al equipo el cierre temporal de nuestra oficina con un e-mail que rezaba: “Cerraremos la oficina un par de semanas.”. Cerramos nuestro piso en el centro y dejamos nuestra cafetera cool, nuestra mesa de ping pong, el futbolito y nuestra hermosa vista a la bahía guardados para la vuelta. Pero ese cierre no fue temporal, ese día sin saberlo estábamos adoptando una nueva manera de trabajar, una dinámica nueva que resultaría mucho más cómoda y productiva y se terminaría convirtiendo en nuestro modo definitivo de trabajo. Y no fuimos el único caso, el evento mundial e histórico que inició el 2020 transtornó el mundo en muchas dimensiones, y entre ellas: las formas de trabajar. En Octubre de 2021 decidimos cerrar de forma definitiva nuestro piso y dejar definitivamente nuestra cafetera cool, nuestra mesa de ping pong, el futbolito y nuestra hermosa vista a la bahía.
Adoptamos de forma definitiva la modalidad de trabajo remoto porque nos volvimos más productivos al tiempo que trabajamos más cómodos. De esa manera logramos no solo sobrevivir a la crisis económica global más importante que nos haya tocado atravesar, sino hacer que nuestras operaciones aumenten tres veces su tamaño, y más importante: soportar ese crecimiento de manera ordenada y eficaz.
Aquí les cuento cómo lo hicimos, pero les advierto que no les ofrezco una silver bullet o la receta del Dr. Selby, solo les comparto nuestra experiencia y los aprendizajes que nos dejaron.
En mi experiencia laboral conocí personas con un talento natural para la gestión de equipos de trabajo, pero desafortunadamente ese no es mi caso. Este artículo va dirigido a los que, como yo, nacieron sin el don y buscan un método en que apoyarse.
Para el momento de tener que pasarnos a full remote office, ya veníamos haciendo oficina en casa un viernes cada mes y los días de clima difícil o de manifestaciones en el centro por un año o un poco más. El ejercicio nos permitió afinar las metodologías y herramientas que regirían nuestra dinámica de trabajo luego. Para cuando llegó el momento de cerrar la oficina, en TIVA ya llevábamos como un año practicando. Pero ciertamente, pasarnos completamente a la modalidad de trabajo remoto era muy diferente a practicarla esporádicamente.
Un crecimiento inesperado en un escenario “inconveniente”
El año 2020 fue duro para todos en demasiados aspectos. Y el ámbito de los emprendimientos es difícil concebir un escenario más hostil. Nos preocupó, como a todos, en todo el mundo.
Nuestro negocio no era de los negocios que tuvieron que cerrar showrooms y tiendas, pero era del tipo que los tenía de clientes. Eso nos convertía en la segunda pieza de dominó en la fila, así que nos enfocamos en sostener la pieza del frente.
Y se dio un fenómeno insólito: la cantidad de abonados de BIMS no dejó de crecer y cada vez con mayor aceleración.
Recuerdo este tweet de Agosto de 2020, cuando la curva comenzaba a acelerar:
¿A qué se debió? Creo que fundamentalmente a cuatro cosas.
La cosa uno tiene nombre: BIMS+. A fines de 2019 lanzamos este nuevo producto, que no es sino una tienda de aplicaciones en BIMS que permite a nuestros abonados sumar a su suscripción los componentes exactos que necesita, y por el tiempo exacto que los necesita, abonando solo por las características que haya elegido y solo por el tiempo en que estuvieron activas. La grilla incluye más de 400 soluciones desarrolladas por nosotros y por otros desarrolladores que integraron sus productos a BIMS. Esto nos permitió establecer un tarifa de entrada de a penas Gs. 70,000 (al cambio de hoy, menos de US$ 10.00). Dimos un paso importante en el modelo de negocio SaaS y democratizamos el acceso a soluciones de gestión de negocios para los micro, pequeños y medianos emprendimientos… y sin saberlo entonces, en el momento más oportuno.
El segundo fundamento lo encuentro en el nuevo escenario comercial y económico que introdujo restricciones que impulsaron nuevos formatos de comercio, y que a su vez requieren nuevos formatos de soluciones que nos propusimos desarrollar. Las entregas a domicilio tuvieron su auge y desarrollamos una solución para su gestión, simple, rápida y elegante. Estuvo lista en Mayo de 2020. Nos salió tan bien que dos años luego miro aquella primer versión y me sigue encantando.
También lanzamos una solución de autogestión para restaurantes.
Por otro parte: las restricciones de movilidad sumadas a los cierres de oficinas hicieron que la distribución de facturas se volviera un problema difícil esos días. Y esto comprometía seriamente el flujo de dinero de muchas compañías. Al darnos cuenta de esto desarrollamos una alternativa de validez fiscal a la facturación electrónica, un work around válido, dado que esta aún no se liberaba la facturación electrónica en Paraguay.
Y decidimos ofrecer estas características gratis a todos nuestros abonados por varios meses, porque era el momento en que los emprendimientos más necesitaron de innovaciones como estas, y era el momento más oportuno de apoyarnos entre todos.
La tercera base del fenómeno estuvo en el afloramiento de nuevos pequeños emprendimientos. Los restaurantes y la tiendas cerraron, y como muchos comercios pivotaron a servicios en linea y entregas a domicilio. Esto dejó a muchos de los que fueran sus colaboradores en suspensión o cese de sus funciones. ¿Y qué hicieron muchos de estos? Emprendieron. Y la coyuntura tan particular les permitió competir de igual a igual en el mismo mercado de empresas establecidas, que en desventaja debían incluso seguir sosteniendo los costos operativos de una estructura ociosa. Un lomitero en Sajonia, produciendo desde la cocina de su casa, competía en el mismo mercado que los restaurantes más populares de la ciudad antes del encierro. Y qué creen, estos nuevos micro y pequeños emprendimientos se apoyaron en BIMS, nuestro modelo de negocios y el muy bajo setup fee se los permitió. La mayoría de estos emprendimientos han escalado y hoy siguen siendo abonados nuestros.
Y la cuarta causa tuvo que ver con la casi eternamente postergada “transformación digital”, que muchísimas empresas en nuestro mercado debieron acelerar para poder hacer frente a las nuevas condiciones de trabajo y de comercio, para las que BIMS resultó una alternativa completa y muy fácil de adoptar.
En 2020, en el escenario más inconveniente que uno puede imaginar, triplicamos nuestra operación. Y esto demandó una gran capacidad de innovación y de producción, que soportamos sobre el que se suponía sería un formato de operación de contingencia: la modalidad de trabajo remoto.
“Trabajo de Equipo” no es una suma de esfuerzos individuales
En la vigilia del encierro llevamos muchas charlas con directores de otras empresas del rubro sobre cómo gestionar nuestros respectivos equipos de trabajo y nuestro trabajo en este nuevo escenario que se impondría en cuestión de días.
Algunas de las ideas que se llegaron a proponer y que incluso se convirtieron en políticas en algunas de estas empresas incluían cosas como: “Se deberán conectar todos a una videollamada durante el horario de trabajo, y deberán mantener la cámara encendida todo el tiempo”, “Deberán avisar cuando se levanten para ir al baño y al volver”, y otras por el estilo. Claramente muchos no teníamos idea de cómo gestionar nuestros equipos en este nuevo escenario. Yo solo pensaba cuando leía este tipo de reglas en no tendríamos la capacidad o el interés de implementar este tipo de controles. No concebía el estrés de trabajar así.
Estaba claro que teníamos que lograr que el equipo funcionara de manera orgánica, sin llenarlos de controles obsesivos que predecíamos solo introduciría estrés y roces, cuando ya ni siquiera tendríamos el futbolito para limar asperezas. Aunque reunimos un grupo de personas serias y comprometidas, los compromisos y resultados individuales no garantizarían el funcionamiento de un equipo. Se necesita un método y herramientas para que las personas se puedan mover como un equipo integrado impulsando la empresa hacia un mismo objetivo, no como en un bote de remos con remeros desincronizados.
El primer desafío para que los individuos de nuestra empresa comiencen a actuar como equipo, fue establecer una buena comunicación: fluída, asertiva y clara. Pero esa calidad de comunicación no es fácil de sostener en medio de las operaciones, y la modalidad remota lo complica aún más. Imaginen que si ya trabajando en un piso casi completamente abierto, con linea visual hacia cada persona del equipo, que incluso era pequeño, la comunicación era un problema; cuánto más difícil lo sería en una modalidad de trabajo remoto.
Nuestro primer intento en sistematizar la organización de las tareas y la comunicación interna data de hace diez años.
Hubo un tiempo, un tiempo hermoso y muy — demasiado — breve, en que pudimos dirigir todo nuestro esfuerzo hacia la innovación. Y esto nos llevó a lanzar este producto que resultó ser un éxito en el mercado y nos llevó a importantes reconocimientos internacionales. Pero mientras fue ganando tracción en el mercado, con mayor aceleración de la que esperábamos, pronto dividió nuestros esfuerzos entre innovación y operaciones. Desde entonces fue un desafío sostener el equilibrio de nuestra capacidad productiva entre esos dos ejes. Las operaciones tienden siempre a consumir todos los recursos disponibles de la organización y muy fácilmente pueden hacernos perder el norte.
Entonces, allá por el 2012, intentando sistematizar la distribución de nuestras tareas y la comunicación interna desarrollamos un sistema de tickets para documentar todos los requerimientos, las adaptaciones, las mejoras y las correcciones de fallas, y automatizar la comunicación entre los desarrolladores, los implementadores, el equipo de soporte y los propios usuarios a través de un sistema automático de notificaciones vía e-mail. Todos estábamos todo el tiempo muy enfocados en nuestras propias lineas de producción personales donde recibíamos tickets, los procesábamos, los documentábamos maravillosamente y los cerrábamos generando gigabytes de documentación que en realidad nadie leería jamás. Las reuniones de equipo nos molestaban porque pensábamos nos restaban productividad en nuestro enfoque de producción obsesiva, así que las evitábamos lo más que podíamos. Y terminamos cayendo en las más absurdas situaciones en las que uno deshacía lo que el otro hizo una y otra vez, en un bucle infinito. Los esfuerzos individuales no nos llevaban a nada. Hacíamos un sobreesfuerzo continuo sin avanzar, y ahogados en las operaciones perdíamos la capacidad de innovar. Y ¿En qué se convierte una empresa de innovación que deja de innovar?.
Los esfuerzos individuales desintegrados no eran útiles, necesitábamos volver a trabajar como un equipo, comunicados y conscientes de nuestros objetivos y de nuestra misión.
Aunque la herramienta que desarrollamos para la gestión de tareas y comunicación es genial, he aquí la primera lección aprendida: ninguna herramienta sería útil sin una metodología.
Scrum
El marco de trabajo que adoptamos se llama Scrum, y en primer orden viabilizó una comunicación interna efectiva dotándole estructura.
Scrum fue diseñado por Jeff Sutherland y Ken Schwaber ya en el ’93 para implementar los principios del “Manifiesto por el Desarrollo Ágil del Software”.
Aunque fue concebido para proyectos de desarrollo de software, con el tiempo se aplicó en todo el mundo en todo tipo de proyectos.
Yo, como cualquier otro desarrollador de software, conocía la técnica y creía haberla aplicado antes, pero Scrum ciertamente va mucho más allá de una técnica y contempla un conjuntos de principios y enfoques sobre el trabajo en equipo que se implementan a través de los procesos y que Sutherland sustenta formidablemente su libro “Scrum: El arte de hacer el doble de trabajo en la mitad del tiempo” [Sutherland, 2014], y no alardeaba en el título.
Scrum es un término que viene del rugby, y refiere al modo en que un equipo trabaja en conjunto para mover la pelota por la cancha, que hace a una analogía perfecta de lo que pretendíamos: lograr sincronía en los esfuerzos individuales para lograr un real trabajo en equipo.
Scrum reemplaza el enfoque tradicional de desarrollo en cascada de Gantt por un modelo basado en ciclos de desarrollo acotados, que permite la corrección de cualquier desviación en etapas tempranas del proyecto, cuando aún estas correcciones son menos costosas de realizar. Los ciclos reciben el nombre de Sprints. Nuestros sprints duran una semana.
El marco requiere tres actores fundamentales:
- El Scrum Master: Que actúa de facilitador en la dinámica y tiene por función principal eliminar cualquier barrera en el desarrollo del proyecto.
- El Product Owner: Que representa al cliente o el usuario final, cuyo propósito es exponer los requerimientos y defender su correcto cumplimiento. En nuestra organización ejecutan este rol los miembros del equipo de soporte técnico y de implementación.
- El Equipo de Desarrollo: El equipo que desarrollará el proyecto.
Como ya comenté, Scrum facilitó una comunicación interna efectiva dotándole de estructura. Nos permitió a todos estar al corriente del desarrollo y de las operaciones sin un gran esfuerzo comunicacional y sin hacernos perder el hilo de la producción. Y lo logra con cuatro reuniones sencillas:
- La Reunión de Planificación: Que realizamos al inicio de cada sprint para determinar los tickets que se trabajarán en ese sprint y a quiénes serán asignados.
- La Reunión Diaria. También se la conoce por Daily Standup Meeting, en español: “Reunión Diaria a Pie”, porque debe ser una reunión breve, tanto que no amerita sentarse. Acostumbramos hacerla al final de cada tarde y cada miembro del equipo responde estás tres preguntas básicas: qué hizo en ese día, con qué seguirá y si se encuentra con alguna traba. Si se ha reportado una traba, es tarea del Scrum Master facilitar su resolución para que el desarrollo pueda seguir su curso.
- La Demo. Esta reunión la hacemos al final de cada sprint y el equipo de desarrollo presenta todo lo realizado durante el sprint al resto del equipo, incluyendo y fundamentalmente al Product Owner.
- Reinstrospección. Esta reunión se realiza al cierre del sprint y en ella realizamos un análisis de nuestro trabajo en el sprint, y saca a luz las cosas que hicimos bien y las cosas que debemos mejorar, a modo de buscar maneras de mejorar en el siguiente sprint y evitar cometer los mismos errores del sprint pasado.
Y en esos cuatro diálogos se contempla todo lo necesario para trabajar en sincronía, de forma organizada y efectiva.
Planificación
La Planificación Fantástica
Quizá el error más básico, y a la vez común, en la dirección de un proyecto o de un equipo de trabajo es la planificación fantástica; una planificación basada en capacidades irreales.
En nuestra visión de un equipo funcional de forma orgánica que pudiera desenvolverse sin controles obsesivos y difíciles de implementar es fundamental conocer las capacidades reales del equipo y planificar la carga de trabajo en función.
En lugar de controlar horarios y permanencia en estaciones de trabajo, nos enfocamos en medir el rendimiento del equipo y determinar los niveles óptimos. Para esto, es fundamental conocer la capacidad real del equipo de trabajo.
Cómo Medir el Esfuerzo
Pero antes de poder determinar la capacidad del equipo, obviamente es necesario definir una unidad medida para el nivel de esfuerzo que demanda cada tarea. Llamemos a esta unidad de medida “Punto de Esfuerzo”, y es natural que asociemos un punto con una hora hombre.
En el tiempo que llevo liderando equipos de desarrollo me tocó estimar los costos de un sinfín de proyectos, y a mayor tamaño siempre fue mayor el margen de error. Así que lo primero que recomiendo hacer es fragmentar el proyecto en tareas lo más pequeñas posibles, a fin de valorar el esfuerzo de cada tarea independientemente.
A cada tarea le asignamos un puntaje de esfuerzo usando de escala la secuencia de números fibonacci del 1 al 13. En una secuencia de números fibonacci cada número es la suma de sus dos predecesores: 1, 2, 3, 5, 8, 13... ¿Por qué adoptar esta escala? Es que en general somos malos para valorar cuantitativamente de forma precisa el nivel de esfuerzo de una tarea nueva, pero por otro lado nos resulta fácil atinar en una evaluación relativa, en otras palabras: haciendo comparaciones.
¿Si les pidiera precisar el peso de un animal con solo mirarlo, creer poder atinarle? Seguro que no. Pero, ¿Y si les diera en una escala compuesta por otros animales? Por ejemplo:
(1) Lombriz
(2) Ratón
(3) Gato
(5) Perro
(8) León
(13) Elefante
¿Le atinarían al responder entre qué animales se sitúa el nuestro según su peso? Seguro que sí.
Ahora establezcamos una escala similar con los tipos de tareas. Determinemos qué tipo de tareas corresponden a una lombriz (1), y qué tipo de tareas a un elefante (13), y luego a las cuatro especies entre estos. Y al valorar el esfuerzo de una nueva tarea hagamos las comparaciones y asignémosle el valor el techo del margen en que se encuentre esta nueva tarea.
Recuerden que a mayor el esfuerzo que demande una tarea, mayor es el margen de error en su estimación, así que mientras mayores sean los valores en nuestra escala de comparaciones, mayores también los márgenes entre los puntos, por eso adoptamos una secuencia de números fibonacci.
Cómo Determinar la Capacidad del Equipo
La capacidad del equipo podrá determinarse recién al cabo de algunos sprints. Es una medida que debe ir ajustándose de acuerdo a la experiencia de cada ciclo hasta llegar al punto de no requerir más ajuste. Al inicio, estimamos una capacidad en la planificación y se dará una de dos situaciones: el equipo termina de procesar sus tareas antes del cierre del ciclo, o llega al cierre sin haberse podido procesar todas las tareas. Entonces, la siguiente planificación de sprint se ajustará la carga, sintonizando así la carga sprint tras sprint hasta llegar a la medida en que todos en el equipo logran completar sus tareas para el cierre del sprint con el mínimo de tiempo ocioso.
Un trabajo en equipo no es la suma de los esfuerzos individuales, pero la capacidad del equipo sí es la suma de las capacidades individuales. Y las capacidades de trabajo de los individuos de un equipo no es homogénea, aunque pretendamos que tienda a serlo mediante nuestra selección de personal y el entrenamiento y recursos que ofrecemos. Ergo, la distribución de tareas en el equipo tampoco puede ser homogénea, no en una planificación realista. Por lo que es necesario realizar la evaluación de rendimiento por cada miembro del equipo mientras se buscan maneras de fortalecer las capacidades de los rezagados. Y en la planificación deben considerarse las capacidades individuales para asignar una carga total al sprint que sea viable distribuir entre los recursos disponibles según sus capacidades específicas.
Realizar una medición a este nivel, sobre un equipo de tamaño mediano, es inviable sin las herramientas adecuadas. Así que, completando la premisa de la primer lección aprendida: Tanto como ninguna herramienta será realmente útil sin la metodología, la metodología puede no ser aplicable sin la herramienta correcta.
Los Horarios de Trabajo Remoto
Recuerdo que los primeros días del trabajo remoto sin caer en cuenta extendía mi horario laboral varias horas casi todos los días. Consulté a algunos compañeros y les pasaba igual. En la presencialidad era fácil definirnos un horario de entrada y un horario de salida, y ubicarnos en un contexto laboral en esa franja horaria. El home office no nos da ese marco y demanda mayor disciplina de nuestra parte.
El nivel de compromiso que hace que nuestros colaboradores extiendan sus horarios de trabajo para cumplir plazos a primera vista puede parecernos algo bueno, un éxito en nuestra gestión de personal, pero no es así. La práctica frecuente del trabajo fuera de horario solo denota una mala gestión y una mala planificación, y contrario a lo que podríamos pensar, termina impactando negativamente en la producción.
Trabajar fuera de horario, en el contexto del hogar, en desuso de las oportunidades que supone brinda el trabajo en casa, introduce estrés y frustración. Y trabajar en condiciones de estrés y frustración genera roces en el equipo y no se logra la comunicación asertiva y efectiva que se requiere.
No es realista pretender que todos nuestros colaboradores sean hábiles para administrar su tiempo. La empresa debe ofrecer un contexto de trabajo que les facilita una buena administración de su tiempo.
La mayor parte del tiempo, el trabajo fuera de horario se da por uno de estos dos motivos:
- Una planificación fantástica que asigna carga de trabajo por encima de la capacidad de soporte de un trabajador;
- Poca claridad en las expectativas de producción del trabajador.
Ya hablamos de la planificación fantástica y cómo evitarla con una solución metodológica. Pero lograr que los miembros de nuestro equipo estén siempre conscientes de las expectativas de su producción y la organización de su tiempo requiere de metodología pero imprescindiblemente también de una herramienta.
En cuanto a la metodología, la solución fue simple. Ajustamos el horario del Stand Up Daily Meeting al final de la tarde. Entonces, todos nos enfocamos a completar nuestros objetivos diarios para esa reunión, donde evaluaríamos el alcance general de los objetivos y discutiríamos las eventuales trabas. Para la reunión al final de la tarde, es normal que todos hayamos alcanzado nuestros objetivos diarios y estemos listos para cerrar la jornada sin remordimientos ni ansiedad por nuestros objetivos del sprint.
¿Pero cómo logramos ese nivel de monitoreo y medición? Es aquí donde entra a jugar la herramienta.
La Herramienta
Pipelines
Hace diez años lanzamos aquella herramienta para la gestión de tareas en BIMS, la llamamos: Pipelines. No dejó de evolucionar desde entonces, adaptándose a diferentes enfoques adoptados a lo largo de los años para ganar eficiencia en nuestro trabajo y mejor comunicación en nuestro equipo. Con la adopción de Scrum, dotamos a Pipelines de funcionalidades para el soporte de este marco de trabajo.
Este soporte involucró analíticas gráficas y fáciles de interpretar que nos permitió medir la carga y rendimiento del equipo de trabajo, y de cada individuo. De esta manera, cada persona en el equipo tuvo claridad sobre los objetivos del equipo y sus objetivos particulares de producción, el rendimiento del equipo y su rendimiento particular en función.
El Juego en Equipo
La primera gráfica analítica de Pipelines, con el mayor peso visual en toda la pantalla, es un Burndown Chart. Esta gráfica, que es fundamentalmente una gráfica de lineas, expone dos lineas: la primera es una recta que expone la cantidad de puntos pendientes que se espera al final de un día del sprint (rendimiento esperado), su valor inicial es el total de puntos del sprint menos la cantidad de puntos que deberían ser resueltos el primer día, y su valor final es cero; la segunda es una curva que expone la cantidad de puntos pendientes efectivamente día tras día, y la expectativa es que al final del sprint el valor del último punto de la curva sea cero.
Todos en el equipo estamos pendientes de que la curva azul (puntos pendientes a la fecha) se enmarque en el área celeste (cantidad ideal de puntos pendientes), y trabajamos en conjunto para empujarla hacia abajo. Se tornó un juego de equipo hasta entretenido, de alguna manera la dinámica, con una herramienta muy simple, se terminó gamificando.
Y con este juego se dio el fenómeno que estaba buscando: el trabajo en equipo. El chart de arriba corresponde a nuestro sprint actual. Podrán ver que el primer día, aunque estuvimos muy cerca, no llegamos al objetivo. Y en la reunión del final de la tarde se presionó el botón rojo y se plantearon las trabas y todo el equipo se predispuso a apoyar en su resolución, para que el siguiente día la curva azul volviera a meterse en el área celeste.
Claridad en los Objetivos
La siguiente gráfica, menos importante en el contexto del equipo pero más necesaria en un contexto personal muestra la carga asignada a cada miembro del equipo de desarrollo, señalando su objetivo diario y el nivel de cumplimiento. Es la analítica sencilla que tiene por objeto darle claridad a todos sobre sus objetivos y rendimiento rendimiento particulares.
De esta manera cada desarrollador tiene claridad sobre las expectativas de su producción y su alcance. Y no corre el riesgo de caer en la ansiedad que produce la incertidumbre sobre sus objetivos y rendimiento, y apretar innecesariamente el acelerador. De esta manera ayudamos a nuestros colaboradores a organizar su tiempo de trabajo.
El Retrabajo
Ninguna planificación es efectiva si se cae en el “retrabajo”. Por eso, es necesario buscar hacer las cosas bien a primeras, lo cual no significa no cometer errores, sino corregirlos en etapas tempranas, mientras sea más fácil hacerlo, para evitar comprometer el trabajo futuro.
El “retrabajo” es un concepto introducido por Jame Womack, fundador del Lean Enterprise Institute del MIT, que se expone en su libro “La Máquina que cambió el mundo”.
Womack analizó las diferencias que existían en los procesos de manufactura de automóviles de compañías Japonesas versus las Europeas, dada una abismal brecha en su eficiencia, que favorecía a los japoneses. Empresas japonesas como Toyota y Nissan podían producir un automóvil de lujo en 17 horas en promedio con una tasa de defectos de 34.7 por cada 100 vehículos. Cuando en Europa, empresas como Mercedes-Benz y BMW tardaban en promedio 57 horas en producir un vehículo de la misma gama con un promedio de 78.7 defectos por cada 100 vehículos.
¿Cuál era la diferencia significativa en la manufactura japonesa que la hacía tan significativamente más eficiente que la europea? Lo que observó Womack en la planta industrial de Toyota fue algo un tanto insólito: cualquier trabajador podía presionar un botón rojo frenaba toda la linea de producción cuando si surgía algún problema. Y en ese momento todos los trabajadores se congregaban donde la linea se detuvo y no para gritarle al que presionó el botón, sino para trabajar juntos en resolver el problema, cual fuere este. El foco de la producción en Toyota estaba en que el producto llegase al final de la linea de producción sin fallas que corregir. Los japoneses entendieron que resolver cualquier desperfecto cuando el vehículo ya estaba completamente ensamblado, costaría mucho más tiempo, dinero y esfuerzo que detener la linea de producción para corregir los desperfectos que se presentaban de buenas a primeras. Ya los controles de calidad se realizaban en fase de producción. Según las observaciones de Womack:
En las plantas alemanas de invertía mayor esfuerzo en resolver problemas recién creados que el que la japonesa dedicaba a producir un auto casi perfecto a primera.
Reconozco las mismas reglas en mi industria, y dudo que solo se cumpla en la manufactura de automóviles y de software.
Lo que buscamos con los ciclos cortos de desarrollo de Scrum es llegar al cierre de los proyectos con la menor cantidad de fallas posibles, evitar al máximo el retrabajo. Los ciclos cortos de desarrollo nos permiten una evaluación temprana y una igualmente temprana corrección de cualquier desviación.
Igualmente, intentamos llegar al cierre de cada sprint no solamente con la linea azul en cero, sino con la menor cantidad de fallas que nos hagan caer en el retrabajo.
Al inicio, principalmente con desarrolladores nuevos cuyo índice de capacidad aún no estaba bien sintonizado, se daba la situación en que al término del sprint se presentaban productos con muchos errores en el código que luego no eran validados por los equipos de soporte e implementación en fase de testing y terminaban siendo devueltos al equipo de desarrollo para su reprocesamiento en el siguiente sprint. A estos casos los llamamos rebotes y los medimos según los puntos de esfuerzo de los tickets rebotados.
Para incentivar el cuidado de calidad en fase de producción y la prevención de retrabajo incorporamos un monitoreo de rebotes en Pipelines que se expone en el mismo panel de monitoreo del sprint.
Los rebotes son mal vistos en la empresa, pues se reconoce el retrabajo que involucra, y el impacto negativo en la planificación y el compromiso con las fechas de entrega propuestas. Así que ninguno quiere ver su nombre ahí y todos hacemos un primer control de calidad de nuestro producto antes de pasar un ticket a testing.
La analítica que ofrece Pipelines es más completa, y ofrece visibilidad sobre demanda de esfuerzo por clientes y otros atributos. Pero no nos enfocaremos en esos puntos en este artículo.
El Día de la Demo
Nuestros sprints duran cinco días: inician los lunes y terminan los viernes con la Demo. Los configuramos así para que no atraviesen un fin de semana, y pudieran dar pie a la posibilidad de que nuestros colaboradores usen ese espacio para trabajar. Esta es otra solución metodológica para ayudarlos a organizar su tiempo de trabajo. Así que todos los viernes, al final de la tarde cerramos solemnemente nuestros sprints con la demo, que se convirtió en El Evento de la Semana en nuestra empresa, en el que participa toda la empresa, y además nuestros partners nacionales e internacionales y ocasionalmente también clientes.
Nuestra Demo tiene dos partes. En la primera parte cada desarrollador expone las características desarrolladas bajo tickets de tres tipos: Innovación, Mejoras y Desarrollo Contratado. Es decir, todas las nuevas prestaciones de BIMS. Los partners y clientes por lo general dan sus primer retroalimentación con los que vamos moldeando las siguientes versiones. En la segunda parte de la demo participan solo los integrantes de nuestra empresa y se presentan los desarrollos de naturaleza correctiva y de mantenimiento y soporte, relevantes para los miembros del equipo de Soporte Técnico y de Implementaciones, que actúan de Product Owners representando a nuestros usuarios.
Y al cierre de la Demo cerramos formalmente nuestro sprint. Y la curva azul, casi siempre, llega a cero y con un índice bajísimo de rebotes.
Conclusión
Cerramos definitivamente la oficina y nos tiramos de lleno a la dinámica de trabajo remoto. Rentamos un espacio más pequeño y con buena infraestructura para reuniones para los eventuales casos en que alguien del equipo requiera un sitio donde trabajar o para llevar reuniones con clientes, que por nuestro modelo de negocio no son usuales.
El Día del Trabajador del 2021 sería el segundo año sin ofrecerle al equipo el tradicional asado en homenaje, dada la cuarentena sanitaria que nos impedía reunirnos. No queríamos dejar pasar la fecha por segundo año así que decidimos recorrer sus casas para dejarles en persona un kit de asado con unos buenos cortes de carne. Recuerdo haber estado al volante más de 8 horas debido a las distancias, el tráfico y la paupérrima infraestructura vial de nuestra ciudad. No me había dado cuenta antes de lo inconveniente que era la ubicación de nuestra oficina para casi todos. De hecho, dada la tremenda distribución geográfica de las personas en nuestro equipo, ninguna ubicación sería conveniente. Entendí que no valía la pena volver a exigirles la presencialidad. Con una pocas acciones y herramientas, en el merco de una buena metodología, habíamos conseguido trabajar armónicamente de forma remota, e incluso aumentar nuestra productividad. En Octubre de 2021 cerramos nuestra oficina y rentamos un espacio más pequeño para usarlo más que nada de contingencia, para cuando alguno necesitara el espacio para trabajar o para cuando debiéramos recibir a algún cliente, cosa que por nuestro modelo de negocio no es usual. Es gracioso, ahora la presencialidad es la modalidad de contingencia.
