Prever y liderar, metodos y caminos

Cuando lideramos, jugamos entre seguir la realidad y tratar de doblarla, una imposibilidad de la que Lao Tse habló largo y tendido, pero aún así lo intentamos, cuando quizás lo que deberíamos hacer es aprender a prever, para poder adaptarnos mucho mejor a un camino que no piensa cambiar por nosotros.

Redundar puestos

Entendamos por qué redundar puestos esenciales, de manera tal que las tareas realizadas por esa gente no queden nunca desatendidas. La cuenta es muy simple, tenemos que pensar cuánto nos cuesta cada día que nos falta esa persona y estimar el riesgo de que deje la compañía, o decida… viajar a Marte, así si redundados esos puestos, podremos estar tranquilos de que no se van a alterar los ritmos de producción de nuestra compañía.

Si bien la redundancia de puestos incrementa de forma obvia el costo, también nos da la oportunidad de mejorar nuestros ciclos de trabajo, modificando y salvando los obvios cuellos de botella en determinadas partes del mismo.

Reconvirtiendo redundantes

Cuando alguien se convierte en suplente de una posición a cubrir, debe estar actualizado sobre las novedades del puesto en el que será reemplazante, pero a la vez podría estar realizando una tarea cercana de manera tal que la redundancia se active en el momento en que se necesite.

Si esto no sucediera y tuviéramos al redundado en un puesto antagónico al que debería cubrir, debemos tener en cuenta la necesidad de una puesta a punto a los conocimientos del recurso previo a que cubra el otro puesto. Por tanto si llegan las vacaciones o nos acercamos a la desvinculación del titular de una tarea tendremos que tener en cuenta la situación y adelantarnos a las necesidades de transferencia de conocimientos al suplente.

Evitar procesos unipersonales

Por mucho que nos tiente y sepamos que todo un módulo puede estar realizado por una sola persona, tenemos que entender por qué es una mala práctica. Cuando la gente realiza una tarea, suele ser modificada por cualquier observador…. como si estuviéramos en la escala de Plank…. física, relatividad…. , alguien nos mira y por ese sólo hecho modificamos la forma en la que trabajamos, no procrastinamos ni dejamos de lado la documentación o las buenas prácticas, ya que alguien más debe compartir y utilizar nuestro código o nuestro proceso.

Si pensaramos cuántas tareas hicimos de forma más cutre sólo porque no era para otros ojos que los nuestros, nos daríamos cuenta que jamás nos pasa en grupo y que si le sucediera a otro nos acercaríamos con una sonrisa paterno-maternalista para explicar un mejor camino. Pero si nos ponemos a pensar, y se nos ocurre que alguien podría leer ese código en el que nos tomamos licencias y libertades…. nos pondríamos colorados.

Pair programming, hasta para gente que no programa o_O

Hay ocasiones en las cuales las cosas simplemente no salen, o que la gente no logra aprender las técnicas de alguien más. Y para esto se nos presenta un método muy interesante y que proviene de un concepto bastante antiguo, por un lado, dos ojos ven más que uno y por el otro, a la vez la paridad de artesano y aprendiz, entre estas dos situaciones está la de llevar un proceso junto a alguien más, ya sea para intentar obtener información de una segunda mirada o para que las personas aprendan una de la experiencia de la otra.

Así incorporamos conocimientos en la práctica mientras un segundo par de ojos nos asiste buscando errores o mejores caminos. O simplemente nos sentamos junto a quien sabe y aprendemos de sus formas de hacer.

Muchas de las tareas que realizamos del día a día son de oficio, es decir que las aprendemos y que cuanto más las realizamos y las comprendemos, mejores seremos llevándolas a cabo. Recorriendo un camino que va del aprendiz al artesano, tendremos suerte si encontramos buenos tutores en el camino, gente que por chance, por experiencia, por necesidad, nos va a contar la forma en la que aprendió a recorrer ese sendero con la menor resistencia posible.

Code Review (para todo el mundo!)

El code review es un método mediante el cual ya sea en programación o en cualquier tipo de actividad, analizaremos el desempeño de un compañero en una tarea dada con el fin de ayudarle a mejorar o evitar errores. Verificaremos que se haya seguido un proceso determinado y si el proceso no existía…. observaremos que esté realizado con los mejores estándares y que quede documentado. Y así como nosotros chequeamos las tareas de alguien más, las nuestras serán también revisadas y hasta tratadas como material a documentar.

Alguien nos dará un feedback de lo que hicimos antes de que aquello que realizamos pase a alguien más, de esta manera las dos personas que se dan feedback habrán aprendido algo nuevo.

Quien va a revisar nuestro trabajo antes de ser entregado es también un guía, ya sea indicando mejores prácticas o siendo una red de contención de errores que no van a pasar a otras instancias, deteniendo el trabajo de otros.

El camino

Comenzamos hablando del Tao, del camino frente a nosotros, ese que no cambia por mucho que empujemos, pero que puede ser recorrido de forma más placentera si podemos prever para dónde va a girar. Hay recetas a montones, que pueden adaptarse a las necesidades de tus equipos, y como en todo en esta vida, será función del guía aprender todo sobre ellas para convertirlas en parte de nuestros patrones, en vehículos que lleven a nuestros equipos del lugar donde se encuentran, al lugar que tan sólo soñaron.

Autor: F. Mesaglio

#Liderazgo #Teamplayers #IT #CTO #Octopus #dirección #comunicación #coaching #equipos