Equipos o individuos. Squads o managers. Departamentos o responsables. En la creación de productos digitales no estamos solos. De hecho, debemos (y necesitamos) colaborar entre nosotros para lograr objetivos. “La unión hace la fuerza”, dice el lema de algunos países. Si el trabajo individual precisa en ocasiones de organización, el colectivo lo necesita aun más.
En este capítulo vamos a hablar de organización y de procesos donde puedes participar para aportar más valor al proyecto. A partir de aquí el handbook deja de ser tan filosófico para volverse de nuevo más pragmático, por lo menos en los siguientes cuatro capítulos.
Sincronizar la red
El trabajo en grupo siempre está por encima del trabajo individual. Trabajar con personas conlleva responsabilidades y una de las más importantes es que todo el mundo sepa todo lo que tiene que saber en cada momento. Para eso la difusión de la información es clave, al igual que es clave conocer los diferentes tipos de conocimientos y cómo transmitirlos.
Conocimiento temporal
El conocimiento temporal es información, datos, que son necesarios de conocer ahora mismo por unas situaciones concretas y que dejarán de tener valor con el paso del tiempo. Puede ser, por ejemplo, la existencia de una incidencia o informar sobre algún bloqueo.
Este conocimiento es importante ponerlo encima de la mesa cuanto antes, ya sea en la daily o en algún canal de Slack/Teams, pero no hace falta perder mucho tiempo en su comunicación
Conocimiento evergreen
Por otro lado, el conocimiento evergreen, aquel que no caduca, no tiene tanta relevancia por su urgencia sino por su trascendencia. Puede ser documentación sobre cómo funciona un producto o procesos usados para la toma de decisiones.
Aquí el “cómo” sí que importa. Sintetizar información densa y complicada de digerir es en sí un arte muy valorado en cualquier disciplina. Utiliza para su difusión herramientas donde la información esté accesible al máximo número de personas, como Notion o Confluence.
Detectar la información, saber a quién comunicarla y cómo comunicarla no es un trabajo sencillo, sobre todo si se trabaja en remoto. Captura, entiende y comparte.
Liderar el futuro de la disciplina
En 2012, Spotify se pronunció sobre cómo hacían internamente para que sus equipos de ingeniería funcionasen. Fue un antes y un después, ya que era la primera vez que una Big-Tech se pronunciaba sobre Scrum, hablando de su experiencia y de los cambios que tuvieron que hacer el framework para que se adaptase a sus necesidades.
Estudio de cómo Spotify escala a sus equipos de la mano de Scrum.
Aunque muchas empresa comenzaron a seguir este sistema de squads, tribus, chapters, … pocas se pararon a ver si ese modelo de verdad funcionaba con ellos. Es más Spotify, una década más tarde, rectificó, aunque hay un par de conceptos interesantes: los chapters y los guilds, foros donde personas de una misma disciplina o con intereses comunes debaten sobre el futuro de la misma.
En la práctica estos dos conceptos son muy similares, solo diferenciándose en su área de actuación (los chapters están más centrados en tu equipo/tribu mientras que las guilds pueden formarse alrededor de toda la empresa).
Esto genera dos ventajas muy potentes en los equipos:
- Permite el flujo de ideas y de conocimiento además de la puesta en común de información que puede evitar muchas duplicidades.
- Actúa de pegamento entre los equipos, habilitando foros donde todos pueden expresarse y pueden tomar decisiones que afecten a su disciplina dentro del equipo, la tribu o incluso la compañía.
Si no tienes un chapter de frontend en tu equipo/tribu, propón crear uno, y si ya lo tienes, participa en él con ideas que puedan mejorar el día a día de los ingenieros.
Ayudar a conectar los puntos
Como ingeniero, tienes un conocimiento poderoso que va más allá del desarrollo. Tienes el total contexto de cómo está implementado el producto, sus puntos fuertes y su talón de Aquiles. Conoces por qué zonas puede escalar mejor y que otras piezas necesitan una revisión antes de seguir construyendo encima.
Esta información es valiosísima a la hora de definir roadmaps, establecer deadlines o diseñar interacciones.
Salir de la zona de confort, participar en las reuniones de definición de producto y revisiones de diseños, son gestos que ayudan a encontrar mejores soluciones y a evitar encontrarse con retrasos inesperados en el futuro.
Saber dónde estamos y a dónde vamos
Como ingenieros se tiende a recibir la información de arriba a abajo, es decir, no siempre se sabe cuáles son los objetivos de la empresa, ni del equipo, a medio o largo plazo. Aunque pueda parecer algo con poco valor para el equipo de desarrollo, la realidad radica en que muchos de los problemas de deuda técnica o escalabilidad con los que se va encontrando el proyecto es debido a una falta de conocimiento de los objetivos o de la visión del producto.
Y si, es cierto que no siempre se sabe qué camino se va a seguir a medio largo plazo, sobre todo en etapas tempranas donde el producto no está maduro o todavía no se ha encontrado su Product Market Fit, pero esto no te impide por lo menos estar alineado con aquellos que tienen una visión más largoplacista de hacia donde os vais a dirigir.
Intenta participar en las reuniones definición de objetivos o si no quieres invertir tanto tiempo, pide a tus responsables que te las resuman para no perder alineación con el resto del equipo.
El mundo de los procesos y la organización es muy amplio. Necesitaríamos media vida para entenderlo a la perfección. Sin embargo, si con algo debemos quedarnos, es que los procesos están para romperlos. No me malinterpretes, tienen su utilidad y funcionan mejor que el caos y el desorden, pero muchas veces no son la forma óptima para todo el mundo de resolver un problema.
Abraza los procesos, vívelos y modifícalos para que se adapten a ti, a tu situación y a tu equipo.