Las dependencias son el mayor enemigo de la entrega
Aprende a no sufrir bloqueos
Las dependencias son uno de los obstáculos más problemáticos a la hora de desarrollar software (como la complejidad y la deuda técnica). Cada vez que nos vemos bloqueados por un agente externo, otro equipo o nuestros propios compañeros, hace que perdamos foco y que nos separemos del contexto. Tener dependencias es como encontrarnos con una valla que tenemos que saltar para poder continuar. Y a veces saltarla hace que te tropieces y resulta doloroso.
Cuando tienes dependencias en tu flujo de creación corres el riesgo de tener bloqueos. Cualquier caso de no poder continuar porque “estoy esperando a algo” indica que podrías haber seguido con tu trabajo si no fuera por esa dependencia, cosa que atrasa la entrega de nuevas funcionalidades a nuestros clientes.
Hay varios tipos de dependencias, entre miembros de nuestro equipo, con desarrolladores de nuestro stack o incluso con negocio.
Dependencias entre miembros del equipo
Las primeras dependencias con las que nos podemos encontrar son las que tenemos dentro de nuestro propio equipo. Dependencias entre desarrollo y diseño, dependencias entre backend y frontend o dependencias incluso entre desarrolladores del mismo stack.
Estas dependencias pueden tener muchos orígenes, pero la mayoría de las veces se manifiestan con tener que esperar a que alguien acabe algo.
Si no puedes empezar a desarrollar la página web porque el diseño no está del todo acabado, estás retrasando la entrega del producto. Si no puedes implementar el cliente que hace las peticiones a backend porque los endpoints aún no están acabados, estás retrasando la entrega. Si no puedes refactorizar una parte del código porque un compañero está trabajando en ese mismo código y tienes que esperar para refactorizarlo después, estás retrasando la entrega.
Las dependencias no son siempre inevitables y hay que intentar establecer medios para poder sortearlas de la mejor forma posible. Como poner una escalera sobre la valla para saltarla sin caerte.
Estando dentro de un mismo equipo aquí la solución es muy sencilla (y esencial): comunicarse.
Y es que la mayoría de los bloqueos y dependencias en un equipo se pueden resolver con solo levantar la mano y hablar las cosas:
- Si quieres empezar a desarrollar el producto, pero el diseño no está acabado, habla con el diseñador para ver qué cosas ya están claras y por las que puedes empezar mientras él acaba el resto.
- Si backend está aún trabajando en los endpoints que necesitas, hablad para definir un contrato con el que estéis de acuerdo para que tu puedas empezar a implementar usando mocks y así cuando estén los endpoints sea solo probar y listo.
- Si un compañero y tú vais a tocar la misma parte del código y quieres refactorizarlo para seguir, habladlo y pairearlo o pensad la mejor manera de hacerlo para que ninguno de los dos se quede de brazos cruzados.
Comunicación, tan fácil como necesaria.
Dependencias entre miembros de un mismo stack
Otro tipo de dependencias que he visto es el de miembros de una horizontal (o stack) que pertenecen a diferentes equipos.
La autonomía de los equipos es esencial para escalar y desarrollar producto de la mejor forma posible, pero la comunicación y los acuerdos sobre como trabajamos dentro de una empresa son necesarios para compartir aprendizajes y llegar a puntos en común que promuevan la colaboración entre los diferentes equipos.
Es por eso que es común que desarrolladores de un mismo horizontal (frontend, backend, data) se comuniquen para compartir experiencias, cosas aprendidas y fallos que les gustarían que otros no cometieran.
En algunos casos he visto, por ser pocos integrantes o no tener pares en sus equipos, que se revisen el código entre ellos. Esto es positivo, por una parte, pero puede ser una dependencia problemática por la otra.
Si no hay más desarrolladores del mismo stack en el equipo es interesante que miembros de otros equipos especializados en esa rama de desarrollo revisen los cambios y puedan comentar sobre ellos. Eso fomenta un mayor criterio de calidad e incluso una reducción de silos de conocimiento entre equipos. Sin embargo, depende como lo implementes puede resultar un bloqueo claro para el desarrollo.
Por ejemplo, si hacemos que esta revisión de los cambios por miembros de otros equipos sea obligatoria, ¿Qué pasa si no están disponibles? Pues que nos quedamos bloqueados sin poder continuar.
Entonces, ¿cómo hacemos para poder obtener los beneficios que tiene la revisión entre pares de un mismo stack si no tengo a ninguno en mi mismo equipo?
Hay dos cosas importantes en estos casos: comunicación y reglas. La primera de ellas es obvia pero muchas veces se da por sentada o no se le hace mucho caso. Si existe una buena comunicación con el resto de los integrantes de tu horizontal, las revisiones pueden no ser necesarias, ya que compartiréis valores y una forma de trabajar común que hará que el desarrollo sea homogéneo en la empresa.
La segunda es necesaria cuando la primera no es suficiente para garantizar cierto nivel de calidad sin causar bloqueos. Dentro de la autonomía de los equipos debe de haber ciertas reglas para evitar el caos. La clave está en definir el mínimo número de reglas viable para garantizar la autonomía y aplicarlas estrictamente.
En resumen, hablad las cosas continuamente y definiros unas pautas que os permitan trabajar de forma autónoma sin bloquearos, pero cumpliendo con la calidad que buscáis. Y recordad que la comunicación puede tomar muchas formas, como reuniones periódicas, pairing, talleres y aprendizajes continuos (hago énfasis sobre el pairing que es maravilloso).
Dependencias entre diferentes equipos
A parte de las dependencias que pueden surgir dentro de tu equipo o entre compañeros de stack, también hay otro tipo de dependencias a nivel organizacional que causan bloqueos y pueden hacer que el desarrollo de nuevas funcionalidades se vea afectado y atrasado.
Estoy hablando de las dependencias que pueden surgir entre diferentes equipos de una misma empresa y que muchas veces surgen de un proceso lineal o de necesidades que tiene un equipo sobre otro.
El problema de este tipo de dependencias es que, al contrario que con las que surgen dentro del equipo o de tu horizontal, los diferentes equipos que participan en ellas pueden tener objetivos muy diferentes. Y demasiadas dependencias transversales significan que nadie puede cumplir por sí mismo y la gente siempre está esperando algo.
Un ejemplo claro que he vivido en mi entorno profesional es cuando varios equipos comparten un proceso en cascada que genera datos que van necesitando otros equipos. Por ejemplo, en un e-commerce nos podemos encontrar con un equipo que se dedica al canal de venta y genera los pedidos que entran al sistema. Luego podemos tener equipos de aprovisionamiento, preparación y entrega que necesitan esta información para poder trabajar. Del mismo modo, estos equipos que beben de los datos del e-commerce rio abajo también puede que generen datos que necesiten entre ellos, como puede ser el equipo de preparación que requiere datos sobre el stock que genera el equipo de aprovisionamiento, o el equipo de entrega de pedidos que necesita saber que pedidos se han preparado para ser entregados.
Esta situación genera una matriz de dependencias que hace que todos los equipos necesiten algún dato de los otros y esto puede llevar a problemas cuando las interfaces o los datos cambian siguiendo las necesidades de cada equipo.
¿Cómo resolverlo? Pues aquí entra otra vez un gran trabajo de comunicación. Acordar los contratos y los datos que ofrecen las interfaces públicas de cada equipo puede mitigar algo el problema, sin embargo, sin una comunicación continua entre los equipos el desastre está asegurado.
Para otro tipo de bloqueos, como el que un equipo necesite que otro haga algo, asentar las expectativas es esencial. Alinear las necesidades de cada equipo con los objetivos de los demás hará que todo el mundo se suba al barco y no haya frustraciones y malentendidos cuando un equipo está bloqueado por otro.
Finalmente, mencionar que las dependencias entre equipos puede ser un olor de que los alcances de los equipos pueden estar mal definidos. Si un equipo se solapa mucho con el contexto del otro las dependencias surgirán orgánicamente y serán difíciles de mantener a raya. En estos casos hacer una revisión de que parte del producto y del negocio cae sobre cada equipo puede ayudar a resolver muchos de estos problemas.
Dependencias con negocio o con terceros
El último tipo de dependencias que voy a comentar es el que se generan con el negocio o con terceros como servicios externos o incluso el estado.
Muchas veces ocurre que ciertas partes del producto o del desarrollo se ven afectadas por decisiones que aún no se han tomado. El negocio está deliberando si el cambio va para adelante o no, hay una ley que están por aprobar, pero aún no es definitiva, nuestro proveedor de búsqueda cambiará las condiciones y no se ajustará a nuestro caso de uso.
Eventos y decisiones que están en el aire y que generan incertidumbre que evita que el desarrollo fluya de una manera correcta.
En estos casos, lo mejor es desbloquear las partes seguras para seguir aprendiendo e iterando, y mantener abiertas las opciones para cuando se tomen las decisiones que se tengan que tomar y se dé luz verde a lo bloqueado.
De nuevo (y sé que me repito, pero es que es muy importante), en estos casos la comunicación es esencial (aunque a veces con entidades como el estado no sea del todo viable). Si hacemos un buen trabajo asentando las expectativas con negocio y con los servicios de terceros será más fácil seguir adelante cuando la incertidumbre desaparezca.
TL;DR
Las dependencias representan un gran desafío para la entrega eficiente de software. Estos obstáculos, ya sean dentro del equipo, entre miembros de un mismo stack, entre equipos diferentes o con factores externos como el negocio o terceros, pueden generar retrasos significativos en la entrega de funcionalidades a los clientes.
La comunicación continua se erige como la herramienta fundamental para mitigar estos bloqueos, ya que permite establecer acuerdos, compartir aprendizajes y anticiparse a posibles obstáculos. La autonomía de los equipos es esencial, pero debe ir acompañada de reglas mínimas para evitar el caos. Además, la revisión entre pares, la definición clara de contratos y una cuidadosa alineación de objetivos entre equipos son prácticas clave.
En última instancia, la resolución efectiva de dependencias implica no solo sortear vallas, sino también construir puentes sólidos de comunicación y colaboración entre todos los involucrados en el proceso de desarrollo.