Artículo de la serie ¿Que es escalable?, Y que lo es en el desarrollo frontend?.
En este tópico voy a dejar un poco el lado critico, solo un poco, y enfocarme más en la recomendación de algunos hábitos para organizar de forma más eficiente, y también saludable, la vida laboral. Ire tanto a nivel personal, como a nivel laboral y organizativo de equipos, desde qué propuestas podemos tomar para mejorar nuestro potencial como desarrollador, pero también buscar la mejora de nuestro entorno.
Y empezando con el ámbito más personal, una recomendación básica es acostumbrarse a dormir en horas no muy tardes, y en lo posible despertarse temprano. Y digo "acostumbrarse" porque sé que no es un proceso en el que uno dice "A partir de ahora me voy a levantar temprano" y se nos regulariza el reloj biológico, lleva tiempo y a veces cuesta mucho. Y con respecto a eso, están circulando algunos estudios que dicen que nuestro horario biológico de sueño está definido genéticamente, por lo cual hay gente que le cuesta más levantarse temprano por genética. Entiendo la visión que traen estos estudios, pero recursos humanos no arma nuestros horarios de trabajo en base a nuestra disposición genética. Y como para la gran mayoría de los que trabajan en desarrollo, siempre suele haber reuniones por la mañana, por ejemplo la Daily. Entonces, levantarnos temprano de alguna forma u otra lo tenemos que hacer, pero acostumbrarnos a hacerlo puede ayudar a que no sea un proceso tan pesado.
Otra recomendación es no terminar de trabajar justo antes de ir a dormir, sino realizar alguna actividad antes, aunque sea tomar una ducha. Espero que nunca les haya pasado el famoso "en el sueño encontraba la solución de mi error", porque nunca es verdad que la encuentras, es tan solo una ilusión que genera el mismo sueño. Y en mi caso todas esas veces me despierto en mitad de la noche pensando que realmente tengo esa solución, hasta que entiendo que solo estaba delirando. Y es malo que se corte el sueño de esa manera, a veces podemos retomar el sueño, y otras tantas nos desvelamos sin poder conciliar nuevamente el sueño. Y justamente esto suele ser efecto de que nuestra conciencia no se desconecte del contexto de trabajo y continúa procesando cosas.
Recomendación muy repetida (pero que vale la pena recordar), es que cuando tengan tiempo libre, estudien alguna cosa nueva o de un contexto/ámbito/lenguaje diferente, sobre todo para quienes quieran reforzar sus conocimientos como desarrolladores. Cada trabajo nos da muchos conocimientos por los nuevos desafíos y problemáticas que cada uno representa, pero aun así esos conocimientos y conceptos son relativos a ese trabajo, por lo que ver y conocer otras perspectivas pueden ayudarnos a encontrar mejoras en nuestro propio entorno.
A nivel personal esas son las recomendaciones más fuertes que puedo aportar, porque al final de cuentas como desarrollador nos solemos desenvolver en un entorno de trabajo con otras personas, bajo normas y tiempos preestablecidos. Por lo cual los factores, que cambian nuestra rutina, son en su mayoría externos a nosotros. Y por eso, ahora hablaré sobre algunas recomendaciones que doy para la organización de los equipos de trabajo.
Las reuniones, parte fundamental de una organización escalable
Aquí pienso explayarme bastante sobre las reuniones, las cuales son en muchos casos beneficiosas, y en otros absolutamente improductivas. A pesar de que hoy en día ya haya tantos ejemplos de cómo organizar estas rutinas, las grandes empresas tienen en el día a día muchos problemas lidiando con esto. Y por eso voy a hacer una distinción entre dos tipos de reuniones, que las nombraré como reuniones de rutina y reuniones excepcionales.
Empezando por las excepcionales, que son las que menos detalles y críticas voy a hacer. Estas reuniones surgen a partir de una demanda específica, fuera de la rutina, por ejemplo:
- Un bug crítico
- Alinear una tarea muy grande
- Solicitación de ayuda de un compañero
Para estas reuniones, primero tenemos que hacernos la famosa pregunta tan repetida (pero muy necesaria), "¿Esto se podría resolver con un mail/mensaje?". Porque hay que tener en cuenta que las demás personas implicadas, están trabajando en alguna cosa que puede no estar relacionada con lo que yo estoy haciendo, y estaría sacándolos del foco de la tarea que estén ejecutando. Y obviamente se debe tener en cuenta la urgencia del asunto, aunque exista mucha gente que parece no entender muy bien cual es la definición de urgencia.
Obviamente si estamos ante un major outage vamos a llamar por teléfono si es necesario a alguien para que pueda socorrer en esto, pero no antes sin tener un mínimo de contexto de lo que está pasando. Y rápidamente agregando a ese ejemplo encontramos un error muy frecuente. El famoso teléfono descompuesto, en donde al desarrollador le llega que la plataforma no funciona, está todo caído, pero en realidad lo que no funcionaba era un feature fuera de los flujos más críticos.
Realmente es necesario medir la frecuencia y necesidad de estas reuniones, porque tener personas sin hacer nada en una reunión (solo como oyentes) no sirve más que para distraerlos de sus tareas. Si realmente es una urgencia tenemos que tener una idea de a quién llamar, para evitar destruir la productividad en general del equipo.
Ahora, veremos las reuniones de rutina, que en la gran mayoría de los casos son reuniones derivadas de algún marco de trabajo como lo es Scrum, Agile, Kanban, o lo que sea. Y acá voy a parar un momento a hacer una crítica muy dura a lo que hacen en muchas empresas, que es seguir el librito del Scrum/Agile/Kanban/Pirulo Master como si fueran reglas invariables, donde hay una persona que su trabajo es velar por el cumplimiento de esos rituales. No estoy en contra de que haya un Scrum Master/Agile Coach o rol similar, pero no acepto que el marco de trabajo sea fijo y no tenga variación con las experiencias que va teniendo el equipo.
Y voy a traer un ejemplo fácil para entender porque no tiene sentido seguir todo siempre al pie de la letra lo que dicen estas prácticas:
Desde el backlog vemos que todas las tareas son simples cambios de UI, colores, bordes, etc. Todas ya están todas las tareas con puntos, porque se realizó una pre planning, está todo listo, y son tareas muy simples. (Después de esto realmente hace falta refinamiento?)
Se llama a todo el equipo de desarrollo para hacer un refinamiento, donde todos van a leer hasta las tareas que ni siquiera les van a asignar. Todo para chequear que todo esté bien escrito y se entienda. (Usamos 2-4 horas de todos los desarrolladores en cada sprint para hacer esto. ¿No se podrían revisar las tareas redactadas cada uno por su cuenta- cada desarrollador toma la revisión de X tareas -, sin necesidad de dejar de hacer la tarea actual?)
Llegamos a la retro del sprint, llevan estas inquietudes, de omitir los refinamientos cuando no sea realmente necesario hacerlos.
La respuesta que obtuve siempre fue un NO, hasta en algunos casos parecía que me trataban de loco, como si atentara contra la buena organización de la empresa. Otro ejemplo básico y que pasa con frecuencia, si una semana se llena de bugs y soporte, y la mayoría de las tareas planificadas para ese sprint quedan como carry over, ¿Tiene sentido hacer una hacer una planning?, ¿Hacer refinamiento de las tareas del backlog? Si vamos a hacer las mismas tareas que quedaron de carry over.
Y lo que termina pasando, es que si realmente es necesario hacer cada una de las reuniones que son propuestas en los enlatados de Scrum/Agile/Kanban estaríamos dedicando a todos los desarrolladores por lo menos 10 horas de reuniones por sprint(solo planning 2hs, refinamiento 2-4hs, retro 2hs, daily cada 1/2hora). Y estamos hablando sólo de las reuniones ligadas al marco de trabajo, no estamos ni siquiera tomando las reuniones de actualizaciones de la empresa, charlas con otros sectores, etc.
Un poco antes de escribir este artículo descubrí una buena causa que podemos atribuirle a la mala mala implementación que suele hacerse de los marcos de trabajo. Y entiendan que yo hablo del marco de trabajo, el cual es el término y concepto que le corresponde. Siendo un marco de trabajo un conjunto de herramientas que nos ayudará a abordar cierta problemática con mucha más facilidad sin tener que reinventar todo un sistema de organización de 0. Pero cuando vamos a la realidad de las empresas, ellos no hablan de marcos de trabajo, sino que usan el concepto metodologías agiles, y el problema que yo encuentro (como maldito aspirante a filósofo) es el mal uso de la palabra metodología.
Una metodología es una lista de pasos a seguir, como si fueran instrucciones, donde no podemos aceptar el cambio de orden u omisión de alguno de estos. Y darle el carácter de metodología, a lo que en realidad son marcos de trabajo, nos condiciona y obliga a usar enlatados de rituales, los cuales siempre "funcionan" y son inevitables, sin importar el más mínimo aspecto del contexto del equipo que lo lleva a cabo.
Aunque tengo una posición fuerte y encontrada contra la mala implementación de los marcos de trabajo, realmente creo que son muy útiles, y en la mayoría de ellos encuentro muy increible el ritual que suele llamarse "Retro"(Retrospectiva), donde justamente se busca que todos den su punto de vista sobre lo que se puede rescatar de buenas prácticas, y que podemos mejorar de lo que no salió tan bien. Aun así, he visto como en muchas empresas la Retro es muy bien ejecutada, dejando a la vista problemas obvios a resolver y cosas muy buenas que han sucedido, pero no se genera el debido impacto, nada cambia, y se mantiene el status quo de las cosas a lo largo de los sprints.
Un tema que es crítico en cuanto a la organización de los equipos es el micromanagement, del cual ni siquiera voy a decir mucho, porque creo que es parte del sentido común saber que es una práctica abusiva cuando se practica periódicamente. Pero si creo que es interesante que todos(los jefes/líderes sobre todo) estén conscientes del mal/cansancio que genera a nivel mental; además de que en el ámbito del desarrollo solo acaba incrementando el número equivocaciones, ya que la persona presionada a terminar algo lo antes posible tiene muchas más chances de entregar código con errores.
Y ya cerrando quiero agregar, que la organización de la rutina, tanto personal como de un equipo, debe estar fundamentada por preguntas que sirvan realmente para que los demás entiendan lo que se está haciendo, y no solamente justificar diciendo "Así es como funciona Scrum/Agile/Kanban, y así se tiene que hacer". La explicación de los rituales(que no siempre se hace), debe coincidir con la implementación de los mismos.
Las reuniones que están generando más distracción que valor deben ser omitidas siempre que fuese posible. Como ya dije en otros artículos, no existe una receta fórmula perfecta para todos los proyectos/equipos, y eso pasa porque la dinámica va a depender principalmente de:
- El contexto en que se desarrolla el proyecto. No podemos comparar un equipo de trabajo de alguna de las empresas MAANG, con el de una startup de latam, o al de una Pyme(pequeñas y medianas empresas).
- Las personas que constituyan el equipo. Estamos muy equivocados si no tenemos en cuenta que todas las personas están atravesadas por una subjetividad de la que ni siquiera somos conscientes.
Top comments (0)