Velocidade negativa: como elevar o limite de complexidade

Atingir o limite de complexidade pode parecer inevitável, mas há alguns indicadores de que as equipes estão se aproximando do limite. Vou começar dizendo que não há uma métrica absoluta que diga se você está perto ou não do limite de complexidade, mas esses indicadores podem ajudar você a ter uma noção.

O indicador mais claro de que uma equipe atingiu o limite de complexidade é quando ela passa mais tempo lidando com a complexidade organizacional do que resolvendo os problemas nos quais deveria se concentrar. Analisar as tendências do DORA de tempo de espera para mudanças (velocidade) e da taxa de falha para mudanças (qualidade) mostra se as equipes aumentam ou diminuem a velocidade com o tempo. Embora existam outros fatores que influenciam essas métricas, elas são um bom indicador da eficácia da equipe.

A satisfação do desenvolvedor é outro indicador da complexidade organizacional que as equipes de software estão enfrentando. Mais do que qualquer outro perfil de função, os desenvolvedores adoram gastar tempo resolvendo problemas complicados e detestam tarefas desnecessárias que atrapalham o trabalho. A baixa satisfação do desenvolvedor é uma boa indicação de que a complexidade organizacional é um problema para a equipe de software.

Quando as empresas percebem que as equipes estão se afogando na complexidade, é comum que elas iniciem um “projeto de simplificação”, com o objetivo de restaurar a simplicidade na empresa. A simplificação é uma estratégia para perder por dois motivos: a complexidade aumenta mais rápido do que a empresa pode simplificar o ambiente, e esses “projetos de simplificação” operam no mesmo ambiente complexo que pretendem simplificar.

Um ponto de partida comum para a simplificação é reduzir o número de aplicações desativando ou consolidando sempre que possível. O descomissionamento de uma aplicação exige que a equipe compreenda todas as dependências iniciais e posteriores, quem usa a aplicação, como substituir a funcionalidade, onde e como os dados vão ser arquivados ou migrados, além de lidar com uma série de outras complicações que surgem com esse tipo de trabalho. Por infelicidade, o investimento significativo no esforço necessário para fazer isso não é recompensado com uma redução também significativa na complexidade. Há um limite para a quantidade de aplicações que uma empresa pode desativar sem afetar os negócios principais ou a experiência do usuário, mas não há limite para a quantidade de novos componentes de software que os engenheiros podem criar. Nos 12 meses necessários para desativar uma aplicação, é provável que centenas de novos microsserviços tenham sido criados. Como um ambiente tecnológico saudável cresce com o tempo, não é prático manter o ambiente em um número fixo de aplicações ou componentes de software para reduzir a complexidade.

Os projetos de simplificação costumam incluir a reformulação da estrutura organizacional para remover a complexidade no fluxo de comunicação. As estruturas organizacionais menos complicadas envolvem grandes equipes hierárquicas com todos no mesmo local de trabalho. As estruturas organizacionais mais complicadas envolvem equipes pequenas, distribuídas e autônomas. A lei de Conway mostra que grandes equipes hierárquicas talvez produzam aplicações monolíticas, enquanto pequenas equipes distribuídas também podem produzir aplicações usando arquiteturas modulares como microsserviços. A produção rápida de software de alta qualidade é possibilitada por padrões de arquitetura modular, como uma arquitetura de microsserviços, o que significa que a estrutura organizacional mais complexa tem maior probabilidade de levar ao sucesso. Embora “simplificar” a estrutura organizacional facilite a compreensão, ela é contraproducente para o objetivo final do projeto de simplificação.

A simplificação é importante e vale a pena, mas é melhor quando incorporada como melhoria contínua para equipes de software (e equipes de equipes) em vez de uma atividade única. Ela pode fazer com que o limite de complexidade demore a ser atingido, mas não vai restabelecer para uma empresa as liberdades desfrutadas em um ambiente de startup.

Para retornar à eficácia da equipe de software, as empresas precisam aumentar o limite de complexidade. Elevar o limite de complexidade significa em essência aumentar a complexidade organizacional que cada equipe pode enfrentar antes que isso afete a satisfação no trabalho e a qualidade e a velocidade com que a equipe lança o software.

A engenharia de plataforma é um conceito importante ao tentar elevar o limite de complexidade de uma empresa. Equipes fortes de engenharia de plataforma se concentram em reduzir a carga cognitiva das equipes de software, abstraindo a complexidade da empresa do trabalho diário. Quando implementada como deveria, a engenharia da plataforma permite que as equipes reequilibrem a maior parte do esforço para resolver problemas complicados, com menos tempo gasto na complexidade organizacional.