¿Qué es un Tech Lead? ¿Qué es un Lead Dev?¿Engineering Manager? Todos son roles que una persona puede desempeñar dentro una compañía. Hasta hay vamos bien, el problema viene cuando tenemos que definir las responsabilidades de este rol…
En cada compañía se hace de una manera. Podemos encontrar compañías en la que el career path es público y por tanto conocer cuales son las responsabilidades y/o habilidades que se suponen para dicho rol. Por ejemplo tenemos Patreon Engineering Levels donde definen las habilidades y responsabilidades de cada nivel. También tenemos Medium Engineering Growth Rubric (más visual aquí) donde ponen incluso ponen ejemplos de cada lo que debería hacer una persona dentro de un nivel. Otro ejemplo más de Monzo. En mi caso, el Lead Dev se define como el CTO de un producto encargado de definir la visión técnica para alcanzar los objetivos de negocio establecidos por el Product Owner. La cuestión es ¿qué pasa cuando te dicen: ‘¿te gustaría ser Lead Dev de este equipo?’ o lo más habitual… a partir de X eres el Lead Dev del equipo.
Escribo partiendo de la base de que esto se basa en mi experiencia, por tanto esta todo lo que leas estará sesgado y puede que no cuadre ni en tu compañía, ni con tu manera de afrontar los retos. No pretendo que esto sea una guía ni una receta para ser Lead Dev, ni mucho menos. Sino espero que exponer todo esto me ayude a mí en el futuro o aun mejor que pueda recoger algo de feedback, herramientas o consejos para seguir mejorando.
¿Por dónde empezamos?
Empezamos por formar un equipo, porque personas que trabajan juntas no siempre son un equipo. Según la Wikipedia un equipo tiene que compartir un objetivo común y por tanto lo primero es encontrar ese objetivo, por ello hay que establecer una visión.
Un equipo es un grupo de más de dos personas que interactúan, discuten y piensan de forma coordinada y cooperativa, unidas con un objetivo común. (Wikipedia)
Para mi es importante tener en cuenta los valores de la compañía y ver cómo enlazar visión/objetivo común más valores. ¿Cómo conseguimos esto? escuchando al Product Owner, a los stakeholders, al equipo, al código,… recabando información y datos para armar una visión compartida por todo el mundo En mi caso ayudó mucho que los valores de la compañía son claros y están presentes en las decisiones del día a día. También me basé en el libro Accelerate junto con la charla de Carlos Buenosvinos sobre «Deliveritis aguda» para establecer la idea de que el negocio esta vivo, tenemos que adaptarnos para aportar valor de manera constante y continuada. El mindset debe ser delivery first: subir muchas veces a producción, construir software que nos permitan subir sin alterar el sistema, trabajar con test creando una plataforma robusta.
La idea no es subir 5, 10, 25 veces a producción, lo importante para nosotros es el camino que tenemos que recorrer para que eso suceda. Me explico, para subir más veces a producción es necesario que tengamos ramas muy cortas, test que cubran todas las funcionalidades y regresiones, que esos test sean rápidos y robustos, que nuestro entorno de desarrollo sea estable y lo más parecido a producción, que tengamos un deploy cada vez más automatizado, que colaboremos entre todo el equipo para sacar una feature entre todos en lugar vez trabajar en silos cada uno con su feature.
Para resumir, en mi caso establecer una visión alineada con la visión de negocio y asentada en valores de la compañía ha sido clave, porque en momentos de duda nos ayuda alinearnos y a tomar decisiones siguiendo nuestros principios.
¿Cómo lo hemos hecho?
Me he inspirado mucho en los post de txapala, de flopezluis, de Talento It
he adaptado algunas dinámicas a mi contexto, así que desde aquí. ¡Gracias por compartir!
Hemos empezado documentando entre todos muchas de las «normas» que teníamos hasta definir un «Development workflow»: así antes de abrir una nueva historia, intentamos ayudar a cerrar las que hay en curso. ya sea haciendo code review, pairing, probando o lo que sea que ayude a ir hacia Delivery first. La idea detrás de esto por un lado evitar el «conocimiento juglar«: haciendo que el proceso de desarrollo no sea algo que te contó alguien un día, sino que podamos leerlo, cambiarlo, analizarlo y mejorarlo. Así intentamos que todo el mundo tenga claro cuál es el siguiente paso a la hora de aportar valor a producción.
Por ejemplo, una de las cosas que nos pasaba al principio es que confundimos el «delivery first» con ir rápido, entonces llegaban historias a code review sin los mínimos tests o nombres poco claros. Así que decidimos crear «La linea Mendoza»: lo mínimo necesario que habría que tener en cuenta antes de crear una code review. En nuestro caso son una serie de preguntas y «normar internas» en plan «¿tiene test unitarios?¿tiene test de integración?¿hay traducciones?¿has añadido un params en todos los environments?
Trabajamos haciendo one-to-one semanales para poder charlar en privado con las personas del equipo para ver cómo estamos, para obtener feedback bidireccional, para plantear dudas en un entorno seguro, para establecer miniobjetivos. A medida que nos estamos adaptando, los one-to-one pueden ir cambiando para ser quincenales.
En los one to one nos dimos cuenta de que había conocimiento que no estaba compartido entre todos y que a la hora de irnos de vacaciones podría suponer un problema. Por lo que creamos una Skills Matrix, que no es más que una tabla donde cada columna es una persona del equipo y cada fila las diferentes funcionalidades o areas. Aquí puedes encontrar algunos ejemplos y aquí la que se utiliza en Management 3.0. Para mejorar estos «silos» lo que hemos estado haciendo es reservarnos 1 hora a la semana los viernes para dar pequeñas presentaciones o workshops para compartir ese conocimiento al mismo tiempo tener una documentación escrita de todo.
A nivel de código
Pues esta parte ha sido un poco más complicada… sabes que el código tiene mejora, trabajamos cada día con él pero cuantificar que esa mejora funciona. En nuestro caso nos hemos apoyado en Sonarqube, lanzamos un análisis al principio que nos dio unas métricas. Con esas métricas negociamos con el Product Owner (fue una negociación sencilla, si me lee gracias) para tener un poco de espacio en cada Sprint con el objetivo de «pagar» la deuda técnica.
Lo que hemos ido haciendo es crear pequeñas historias muy acotadas, ya que refactorizar no tiene fin, siempre puedes darle una vuelta más,… con objetivos claros. Al principio ha sido borrar funcionalidad que sabíamos que ya no estaba disponible desde ninguna URL, después ocultar elementos del menu que teníamos la intuición de que no se usaban, e ir trabajando poco a poco para tener una deuda técnica más contenida. Del mismo modo también hemos ido trabajando en tener un entorno de desarrollo robusto, con unos test unitarios rápidos para poder ejecutarlos cada poco tiempo.
¿Qué nos queda?
Como comenté al principio, esto es un camino. El objetivo es aportar valor a negocio en ciclos cortos de forma continuada, por lo que todavía nos queda mucho por recorrer. Solo hemos sentado un poco las bases de cómo nos gustaría trabajar pero todavía nos queda mucho por aprender y mejorar. Tener más métricas aparte de Sonarqube, montar herramientas de análisis estático como https://github.com/phan/phan o https://github.com/phpstan/phpstan, otras herramientas como https://github.com/rectorphp/rector, mejorar la matriz de skills para que todos conozcamos un poco de todo, automatizar los despliegues, seguir pagando la deuda técnica,…
Como conclusión es que nos quedan muchas cosas por hacer y que seguiremos aprendiendo, mejorando y creciendo como equipo.
Otros career paths interesantes:
Jesús L.C. - Apuntes de un aprendiz 