8 lecciones que aprendí trabajando como líder técnico

Si bien este sitio se llama Crónicas Freelancer, gran parte de lo que vuelco aquí también proviene del aprendizaje de varios años de trabajo en áreas de desarrollo de software. Así que aquí enumeraré algunas lecciones que aprendí trabajando como líder técnico.

Siempre digo que es preferible trabajar primero en un área de sistemas o de desarrollo antes de pasarse al modo freelancer. Se puede aprender muchísimo en ese tipo de entornos y sí, luego aprovechar todo ese conocimiento para forjar un camino propio.

Lo que viene a continuación son algunas lecciones aprendidas de trabajar como líder técnico y también un poco como programador y como líder de proyectos. No tienen un orden en particular y se refieren tanto a temas técnicos como a otros más genéricos.

Dar libertad a los programadores para elegir los tickets

Una vez armados los sprints y después de la planning, descubrí que es mejor que los programadores vayan tomando los tickets que prefieran, en el orden que crean conveniente. Incluso, es mejor dejar que se los repartan libremente si se trabaja en equipo.

Esto les da suficiente libertad para que se ordenen por su cuenta y hace que no estén fastidiosos.

Pero además, se puede ir más allá y hacerlos participar de la selección de tickets del backlog antes de armar el sprint. Por supuesto, siempre habrá que tener en cuenta primero las prioridades que considere el product owner.

Los fines de semana interrumpen el trabajo

Hay que considerar que los fines de semana son topes que hacen que el flujo de trabajo se interrumpa. Son necesarios para recuperar energías pero retomar una tarea un lunes, luego de haberla dejado incompleta el viernes tiene un costo importante en tiempo de desarrollo y en la calidad de resolución.

La mejor manera que encontré para evitar este problema es hacer sprints que duren una semana. De esta forma, se comienza un lunes y se termina un viernes y ya la próxima semana se comienza de nuevo con la cabeza fresca y enfocando todo en el próximo sprint.

Lo difícil y riesgoso, al principio

A veces uno se tienta a comenzar con lo más fácil para ganar confianza. Sin embargo, es preferible poner las historias de usuario más complejas y riesgosas siempre en los primeros sprints. De esta forma, si llega a haber alguna complicación, se está a tiempo de tomar algún tipo de acción.

No hay que exagerar en este paso y cargar toda la complejidad de una aplicación en un único primer sprint. La idea es distribuir las historias de usuario más complicadas en los primeros dos o tres sprint, siempre de mayor dificultad a menor y completando cada uno de estos sprints con tareas menores.

En algún punto, estas tareas menores funcionan como pequeños respiros para los programadores.

¿Mucho cansancio? Tickets cortos y fáciles

Es buena idea mechar un sprint difícil con un sprint más fácil o, tickets difíciles con tickets más fáciles. Lo ideal es que la parte fácil quede para hacer cuando menos energías hay.

De todos modos hay que tener mucho cuidado si las energías están al mínimo porque cuando un programador está cansado todo lo que toca puede terminar en desastre, incluso si se trata de problemas relativamente fáciles de resolver.

¿Cómo medir las energías del equipo? Yo creo que eso se percibe al estar en contacto con el grupo en el día a día. Además de hablar con cada integrante, se puede ir viendo el código que escriben o el tiempo que pasan resolviendo una tarea puntual.

Integrar el código tan a menudo como se pueda

La idea de integrar seguido el código no es ninguna novedad. Se trata de una recomendación bastante conocida, pero parece ser que hasta que uno no termina integrando a mano y sufriendo, no lo aprende.

Como mínimo, la integración de distintas ramas debería hacerse al menos una vez por semana. De esa forma se previenen problemas mayores.

En cuanto a integrar de forma manual, cuando me desempeñaba como líder técnico, era una actividad que prefería hacer personalmente antes que delegarla a algún programador. Salvo que fuera una parte puntual en la cual un integrante del equipo tuviera más conocimiento.

Pero bueno, como reza el refrán: más vale prevenir que curar. Integrando seguido se evitan estos problemas.

Pruebas, pruebas y más pruebas

Si se toca mucho código y no se prueba lo que se va haciendo, a la larga se termina rompiendo algo. Ir tocando código a ciegas no es una buena idea por más que uno crea que está haciendo todo bien.

En el caso de estar trabajando con un equipo hay que asegurarse que los desarrolladores vayan realizando pruebas de lo que programan.

En cuanto a las pruebas, estas no necesariamente tienen que ser pruebas unitarias. Aquí no me estoy refiriendo a un concepto técnico puntual, sino a la manera de trabajar sabiendo que cada acción sobre el código repercute en una función específica del programa.

Por lo tanto, alcanza con modificar el programa y ver el resultado. Pero ese resultado tiene que verse y comprobarse también que ninguna otra parte del programa haya sido afectada.

Estimación de proyectos a fin de año

No es lo mismo estimar un proyecto al comienzo del año que al final. Sobre el final del año hay menos energías, están las fiestas y la gente entra en una especie de letargo que los hace rendir menos.

Por lo tanto, esto hay que tenerlo muy en cuenta a la hora de realizar una estimación en cuanto a duración de proyectos. También en el momento de cargar los tickets en los sprints.

Tomarse todos los días de vacaciones

Como workaholic que soy se me han ido días de vacaciones o me los he tomado al borde de perderlos.

Lo cierto es que descansar es también parte de trabajar. Cuando uno está más descansado y con la mente despejada puede rendir más y la creatividad alcanza su máximo.

Además, uno no siempre sabe qué le puede pasar en el futuro. Puede venir un cambio de empleo que haga que los días pendientes de vacaciones queden en la nada. O también puede pasar que uno busque tomarse las vacaciones en determinado momento del año, pero justo surja un proyecto que se lo impida.

Por lo tanto, lo mejor es tomarse todos los días de vacaciones y si es posible, hacer un viaje a algún lugar interesante para conocer y recargar energías.

En síntesis

Todo lo que has leído fueron algunas de las lecciones que aprendí al trabajar como líder técnico. Al día de hoy estos valiosos conocimientos los sigo aplicando al día a día tanto cuando trabajo solo como cuando me toca formar parte de un equipo.

Espero que alguno de estos ítems te hayan hecho tomar conciencia sobre alguna de las distintas dimensiones que tiene el desempeñarse como programador.

Gracias por leerme.

¡Hasta la próxima!

Fuente foto principal:

Arnold Francisca