Velocidad negativa: cómo elevar el límite de complejidad

Alcanzar el límite de complejidad puede parecer inevitable, pero hay algunos indicadores de que los equipos se están acercando a su límite. Antes que nada, debo decir que no existe una métrica absoluta que te indique cuán cerca estás del límite de complejidad, pero los siguientes indicadores pueden ayudarte a identificar en qué punto te encuentras.

El indicador más claro de que un equipo ha alcanzado el límite de complejidad es cuando dedica más tiempo a analizar la complejidad organizativa que a resolver los complicados problemas en los que debe centrarse. Las tendencias en las métricas de DORA sobre los plazos de los cambios (velocidad) y de la tasa de errores de cambios (calidad) muestran si los equipos pierden o ganan velocidad a lo largo del tiempo. Aunque hay otros factores que influyen en estas métricas, son un buen indicador de la eficacia de los equipos.

La satisfacción de los desarrolladores es otro indicador de la complejidad organizativa a la que se enfrentan los equipos de software. Más que ningún otro perfil de puesto, a los desarrolladores les encanta dedicar su tiempo a resolver problemas complicados y, al mismo tiempo, detestan las tareas innecesarias que se interponen en el camino. La baja satisfacción de los desarrolladores es un buen indicio de que la complejidad organizativa es un problema para tu equipo de software.

Cuando las empresas se dan cuenta de que sus equipos se ahogan en la complejidad, suelen poner en marcha un "proyecto de simplificación" con el objetivo de restablecer la simplicidad en su organización. La simplificación es una estrategia perdedora por dos razones: la complejidad aumenta más rápido de lo que cualquier organización puede simplificar su entorno, y estos "proyectos de simplificación" funcionan en el mismo entorno complejo que pretenden simplificar.

Un punto de partida habitual para la simplificación es reducir el número de aplicaciones mediante el desmantelamiento o la consolidación siempre que sea posible. El desmantelamiento de una aplicación requiere que el equipo conozca todas las dependencias ascendentes y descendentes, sepa quién usa la aplicación, cómo reemplazar la funcionalidad, dónde y cómo se archivarán o migrarán los datos, y haga frente a muchas otras complicaciones que surgen con este tipo de trabajo. Lamentablemente, la importante inversión de esfuerzo necesaria para hacerlo no se ve recompensada con una reducción igualmente significativa de la complejidad. Hay un límite en la cantidad de aplicaciones que una empresa puede retirar sin afectar a la principal experiencia empresarial o de usuario, pero no hay límite en cuanto al número de nuevos componentes de software que los ingenieros pueden crear. En los 12 meses que se tarda en desmantelar una aplicación, es probable que se hayan creado cientos de microservicios nuevos. Dado que un entorno tecnológico saludable crece con el tiempo, no es práctico mantener en él un número fijo de aplicaciones o componentes de software para reducir la complejidad.

Los proyectos de simplificación suelen incluir la reelaboración de la estructura organizativa para eliminar la complejidad del flujo de comunicación. Las estructuras organizativas menos complicadas involucran a equipos grandes y jerárquicos con todo el personal ubicado en el mismo lugar. Las estructuras organizativas más complicadas involucran a equipos pequeños, distribuidos y autónomos. La ley de Conway demuestra que es probable que los equipos jerárquicos grandes produzcan aplicaciones monolíticas, mientras que los equipos pequeños y distribuidos probablemente produzcan aplicaciones mediante arquitecturas modulares, como los microservicios. Los patrones de arquitectura modular, como la arquitectura de microservicios, permiten producir software de alta calidad a gran velocidad, lo que significa que una estructura organizativa más compleja tiene más probabilidades de conducir al éxito. Si bien "simplificar" la estructura organizativa facilita su comprensión, es contraproducente para el objetivo final del proyecto de simplificación.

La simplificación es importante y vale la pena, pero es mejor incorporarla como mejora continua para los equipos de software (y los equipos de equipos) que como una actividad única. La simplificación puede retrasar el momento en el que se alcanza el límite de complejidad, pero no devolverá a la organización las aceleradas libertades de las que se disfrutaba en un entorno de empresa emergente.

Para volver a la eficacia de los equipos de software, las organizaciones deben elevar el límite de complejidad. Elevar el límite de complejidad significa aumentar la complejidad organizativa a la que puede enfrentarse cada equipo antes de que esto afecte a la satisfacción laboral, y a la calidad y la velocidad con las que el equipo lanza el software.

La ingeniería de plataformas es un concepto importante a la hora de elevar el límite de complejidad de una organización. Los equipos de ingeniería de plataformas sólidos se centran en reducir la carga cognitiva de los equipos de software al abstraer la complejidad organizativa de su trabajo diario. Cuando se implementa correctamente, la ingeniería de plataformas permite a los equipos reequilibrar la mayor parte del esfuerzo que dedican a resolver problemas complicados y dedicar menos tiempo a analizar la complejidad organizativa.