Últimamente, como la mayoría de ustedes, tuve la rara oportunidad de pasar mucho tiempo en casa, sola con mi cabeza, sobre analizando situaciones del día a día --Gracias COVID-19.

Esto me llevó a notar algo que ya sabía pero en cuarentena se volvió muy evidente: Algunos días son sumamente productivos y otros... no tanto.

Es normal que la productividad, como el humor, tenga variaciones. Pero nunca me había puesto a pensar seriamente qué externos factores la afectan – por eso me sorprendí cuando empecé a reconocer un patrón que iba cambiando según con que equipo me tocaba relacionarme.

Como desarrolladora suelo estar asignada a más de un proyecto a la vez. Estos proyectos tienen diferencias como que framework o tipo de base de datos usan, pero en general las tareas que realizo suelen ser bastante similares. Mis días se pasan entre integrar llamadas a endpoints, usar mucho filter() o reduce(), arreglar paddings y buscar al culpable de ese bendito scroll horizontal.

Todas estas tareas son cosas que disfruto hacer (mentira, odio arreglar scrolls), por lo cual en mi caso la motivación para ser productiva no está relacionada a complejidad o diversión.

Pero hay algo que SÍ cambia drásticamente de un proyecto a otro: el equipo. Y como cada equipo maneja su forma de trabajar puede impactar de manera absoluta la productividad de sus miembros.

Les comparto algunas pequeñas observaciones que hice que quizás los puedan ayudar a entender e identificar potenciales problemas en sus equipos.

Revisiones de código (hechas en un mal momento)

Las revisiones de código (code reviews) son un lugar excelente para sugerir mejoras o soluciones alternativas a la resolución de un problema, pero ¿Qué pasa cuando una persona del equipo recibe estas sugerencias muy cerca de una fecha de entrega? Es importante entender el tiempo que puede llevar implementar esa mejora en relación a la calidad que nos va a generar en el proyecto.

Antes de sugerir un cambio es importante hacerse esta pregunta: - ¿Puede el receptor de la revisión terminar el cambio a tiempo o le estoy agregando una tarea enorme encima de un montón de trabajo sin finalizar? ¿Vale la pena correr el riesgo de que no llegue?

Si la sugerencia implica re-implementar gran parte de la tarea pero el retorno en calidad no es tan significativo quizás sea mejor crear un ticket en nuestro backlog y mejorarlo más tarde. Obviamente esto solo aplica a código que resolvía el problema inicial de una manera apropiada.

Reuniones (dudosamente planeadas)

Si, pensé seriamente en llamar esta sección simplemente reuniones, pero seamos sinceros: a pesar de que no nos gustan son un mal necesario para organizar equipos. El problema empieza cuando no están bien organizadas o cuando sólo participan dos o tres personas mientras todos los demás quedan como espectadores.

En una reunión donde no se tratan temas de interés general, la gente pierde el foco y se cansa mentalmente, y ese cansancio mental suele afectar la productividad incluso después de terminada la actividad.

Para evitar este problema, es importante planear bien las reuniones, con una minuta clara a seguir, y mantenerlas con un máximo de duración de una hora siempre que sea posible. También es importante identificar que discusiones se salen del alcance original y agendar reuniones aparte para tratarlas o conversarlas offline entre las partes involucradas.

Entornos de trabajo rotos

Allie Brosh, la creadora del blog 'Hyperbole and a half' subió una vez una entrada llamada 'Sneaky hate spiral' (la sigilosa espiral de odio) que resume muy bien lo que estoy a punto de describir. (Si no conocen a Allie, haganse el favor de ir a leerla. Ya no escribe activamente pero su blog debería ser considerado un tesoro de la internet)

Situación: Estás listo para trabajar en una nueva tarea, intentás correr el proyecto y recibís un error. Buscás el origen del error pero no es claro. Reinstalás, te das cuenta que es un problema con la base de datos así que conseguís una versión actualizada, volvés a correr el proyecto y *pum* un nuevo error. En algún punto después de dos cafés y quince búsquedas en stack overflow el proyecto finalmente funciona pero no tenés ni idea de cual de las doscientas soluciones que probaste funcionó ni de que se trataba el ticket que querías resolver.

Así que volvés a la documentación, revisás tu tarea y en la primer linea de código BOOM: El endpoint tira 500 ¡Felicitaciones! estás oficialmente en la espiral del odio, mirás el reloj, son las seis. Buenas noches.

Si esta situación no te resulta familiar entonces voy a tener que pedirte el contacto de RHH de tu empresa (es para una amiga). Pero más allá del chiste esta situación es real para mucha gente y puede robarnos días entero de productividad.

Para resolver estos problemas solo queda comunicarse. Es importante que el equipo tenga información si el proyecto tuvo un cambio de dependencias o necesita nueva configuración o datos particulares para funcionar.
También es importante generar ambientes de trabajo sanos donde los empleados no tengan miedo de hacer preguntas. A veces la solución está a un Slack de distancia y nos podemos ahorrar horas de debugging con solo preguntar.

Cambios de prioridad

Es normal trabajar en entornos que requieran un cierto grado de flexibilidad, pero cuando un equipo necesita constantemente cambiar prioridades suele ser síntoma de procesos mal planeados.

Cambiar de tarea nos quita foco y pone un peso extra en nuestro proceso mental, desde un punto de vista meramente productivo es una decisión costosa que debería tomarse solamente cuando la situación realmente lo amerita.

Tener un plan a futuro, que sirva de guía general pero a la vez deje espacio para lo inesperado es una gran inversión en la productividad y salud mental de un equipo.

Generar este tipo de planes puede llevar tiempo y requerir reuniones extra, pero el retorno en orden y eficiencia vale la pena.

Y recuerden: Si todo es importante entonces nada es importante.

Micromanagement

Ah, micromanagement. Se habla tanto de este tema y aún así ahi sigue, vivito y coleando.

Que un manager quiera saber el estado de su equipo es normal y parte de las tareas que a hacen a su puesto de trabajo. Uno necesita saber que está en progreso, que se terminó y que problemas están evitando el avance de las tareas para tomar decisiones y encontrar soluciones.

Pero el micromanagement no se trata sobre información sino sobre control y desconfianza. Y la confianza es de esas cosas que si no es mutua no funciona, por lo cual si un empleado se siente juzgado inmediatamente va a bajar su propia habilidad de confiar en el equipo y la empresa, lo cual es un impacto directo en productividad.

Además, estar constantemente encima de nuestros empleados es realmente costos en tiempos. En vez de perder tiempo 1-1 buscando reportes personalizados es mejor invertir esas horas en generar un plan de acción o crear espacios de comunicación donde el equipo pueda volcar su estado actual sin necesidad de perseguirlos.

Lo importante es la honestidad. Si una persona del equipo parece distraida o no está rindiendo como se espera, lo mejor es preguntar que está pasando. A veces las personas no son conscientes de que algo está afectando su productividad o simplemente no creen que tengan que hablar al respecto.
Es importante generar espacios apropiados para dar y recibir críticas de manera útil y sin represalias. Siempre nos vamos a encontrar avivados, pero la gran mayoría de la gente tiene buenas intenciones y reacciona bien cuando hay un interés genuino en su bienestar.

Con esto se terminan mis observaciones por ahora. Después de notar estos patrones me puse a trabajar activamente en cambiar algunas actitudes y tengo que decir que por ahora el proceso viene siendo positivo. Algunos viejos hábitos son difíciles de romper pero es importante seguir intentando.

Y por llegar hasta acá les dejo este bello regalo:  Allie Brosh - Hyperbole and a Half | Sneaky hate spiral