El perfil Paracetamol
Hace algunos años, compartía con un gran amigo y colega del sector varios botellines casi congelados de 1906 en una de las geniales terrazas que hay por Alameda de Hércules en Sevilla. En una de las conversaciones surgió que en su equipo había dos personas que cuando no estaban, el trabajo parecía no salir adelante.
Cuando había algún bloqueo o problema, por mínimo que fuese, el resto de sus compañeros tenían la costumbre de esperar a que llegasen esas personas que, lejos de sentirse “honrados” con su gran medalla de héroes, estaban hasta los mismísimos de que todo aparentemente dependiese de ellos.
Esta fue la primera ocasión en la que utilicé el término paracetamol para describir perfiles que “gozaban” de este rol.
Un perfil paracetamol oculta el dolor del equipo cuando hay problemas, por lo que muy pocas personas en la empresa son conscientes de que estos problemas existen hasta que estas personas no están o se van de la empresa.
El perfil paracetamol es muy distinto a otros perfiles heroicos que se sienten cómodos generando dependencias. Estas personas normalmente suelen ser gente extraordinariamente generosa, autodidacta y disponen de alta capacidad resolutiva. Precisamente por estas capacidades y su actitud de ayuda directa ante los problemas, si no se ponen los medios para detectar su sobrecarga de trabajo y limitarla, las consecuencias podrán ser problemáticas para ellos pero especialmente críticas para la empresa.
Existen formas para evitar que se pueda crear una cultura paracetamol-first en una empresa, las siguientes son algunas que he visto funcionar a lo largo de mi carrera profesional.
Cultura de documentación
Una empresa, sobretodo una empresa que crea productos de software, no se puede permitir centralizar el conocimiento en islas humanas.
Crear una cultura de documentación en la empresa es algo vital para evitar dependencias a nivel de conocimiento.
Esta documentación debe ser fácilmente accesible y actualizada. Y debe cubrir desde aspectos organizativos y de procedimientos de la organización hasta las especificaciones técnicas de cada proyecto.
Metodologías y herramientas de documentación activa a nivel de código o producto de software como BDD (Aplicando StoryBDD y cuidando las narrativas), SBE e incluso Swagger (o Blueprint) son muy útiles para exponer la funcionalidad de los productos de forma automatizada.
A nivel de repositorios, todos los proyectos deberían contar con:
- Un buen Readme con un índice que recoja los siguientes puntos
- Cómo arrancar el proyecto
- Cómo probar el proyecto
- Qué dependencias tiene el proyecto
- Qué versión y requisitos tiene este proyecto
En una empresa dedicada 100% a producto, debería haber una persona dedicada a asegurar esta cultura y gestionar esta labor.
La cultura de documentación no implica sólo documentar los proyectos o formas de trabajo, sino también el consultar la documentación antes de coger el teléfono o levantarse de la silla para interrumpir al compañero.
Este punto es especialmente importante si se trabaja de forma remota, con equipos distribuidos o en proyectos open source.
Medir los cambios de foco y limitar el WIP
En metodologías como Kanban y Scrum el WIP, work in progress, es uno de los conceptos más importantes y que permiten mejorar la eficiencia de un equipo.
Normalmente en los entornos paracetamol-first el WIP no se limita en absoluto, de hecho puede tender al infinito. Es clave que el foco no se diluya en varias tareas simultáneas. Limitar por ejemplo a una o dos tareas concurrentes por cada miembro del equipo suele ser una buena práctica para conseguirlo.
Otra medida útil es medir las interrupciones que tiene cada miembro del equipo. Cuando se hace y se presentan los datos en las retrospectivas al final de cada sprint, muchas veces sobran las palabras.
Hacer partícipe al equipo en las decisiones y diseño de soluciones
En mi opinión, todo desarrollador de software debería tener el skill o rol de arquitectura de software. Hacer partícipe de la visión global a todos los equipos es algo fundamental para que las personas no se queden limitadas o “cómodas” en su nicho.
En SCRUM existe el rol de Scrum Master. Cuando surge algún problema o necesidad de toma de decisión, el Scrum Master no debe lanzarse a solucionar el problema directamente; en su lugar debe guiar al equipo para que entre todos, encuentren la mejor solución, aunque ella o él la tengan clara. Hagamos SCRUM o no, me parece muy interesante esto y creo que es muy valioso para evitar estos perfiles.
Evitar ser líderes paracetamoles
El peor paracetamol es un dueño de la empresa al que le cuesta delegar o un líder que se carga peso de ejecución, ocultándolo al equipo y a las métricas.
Cuando eres el dueño de tu negocio y te apasiona lo que haces puedes caer muy fácilmente en esto y hacer que tu empresa dependa enteramente de ti.
Es importante desconectar y medir la productividad a nivel de entrega de valor cuando tú no estás en tu negocio.
Muchas personas creen que su equipo no es productivo cuando ellos no están físicamente en la oficina, pero la realidad es que no han puesto los medios para que estas personas puedan serlo o no disponen de la suficiente información para poder hacer su trabajo.
Exigir y respetar el tiempo fuera del trabajo
Los perfiles paracetamoles son propensos al workaholismo y por ello es importante que no se extienda una cultura en la empresa en la que se promuevan invertir horas extras o trabajo fuera de un rango horario.
Se suele decir que el máximo productivo de un desarrollador es de seis horas al día. Debería ser un objetivo que durante esas seis horas ese profesional tenga el foco puesto en entregar valor y optimizar la gestión de los proyectos para que esto sea la norma principal.
Todas las herramientas e información deberían ser fácilmente accesibles
Si hay impedimentos para poder disponer de la información o herramientas para realizar el trabajo, por ejemplo si se necesitan utilizar desde una aplicación móvil o fuera de la red local de la oficina, es muy posible que ese trabajo se delegue en otras personas y por lo general, en una cultura paracetamol-first, siempre serán las mismas.
Cultura de trabajo en remoto
No todas las empresas ni personas tienen por qué trabajar con una cultura de remote-first, pero establecer los mecanismos para hacerlo puede asegurar que todos los puntos anteriores se cumplan.
En una cultura remota es clave el medir y gestionar la comunicación de forma asíncrona, cada miembro del equipo debe poder realizar su trabajo de forma autosuficiente y contar con toda la información para poder hacerlo, por lo que no es un buen entorno en el que puedan crearse perfiles paracetamoles.
Originally published at asiermarques.com on June 20, 2018.