Close

Velocidade negativa: como elevar o limite de complexidade

Sinais de que sua equipe de software está enfrentando muita complexidade organizacional e como melhorar

Foto de rosto de Andrew Boyagi
Andrew Boyagi

Evangelista sênior


Um dos objetivos mais comuns de uma empresa de engenharia é entregar software de alta qualidade com rapidez.

Dê uma olhada na declaração de visão do CIO ou CTO e escute o que ele tem a dizer. É provável que eles estejam buscando alguma permutação desse objetivo. Embora seja um objetivo comum, há um amplo espectro entre equipes que atingem esse nirvana e equipes presas no purgatório de entrega de software. Algumas equipes estão sempre colocando novos códigos em produção com poucos incidentes ou impacto negativo no cliente, enquanto outras enfrentam dificuldades com lançamentos trimestrais.

Logotipo do Compass.

Teste o Compass grátis

Aprimore a experiência de desenvolvedor, catalogue todos os serviços e melhore a integridade do software.

O que causa essa discrepância de desempenho?


A complexidade na entrega de software é a diferença entre fornecer software de alta qualidade com rapidez ou… não. É a diferença entre tocar o sino da vitória após um lançamento bem-sucedido toda semana e uma equipe de entrega de software desengajada, frustrada porque meses de trabalho na versão mais recente resultaram em seis novos bugs e um rollback.

Compare a velocidade e a qualidade com que as startups lançam novos produtos e funções com as de uma grande empresa estabelecida. Por exemplo, no setor financeiro, as startups de fintech reduziram a participação de mercado de bancos grandes e estabelecidos na última década. Os grandes bancos costumam citar as vantagens injustas das startups de fintech, que operam com menos supervisão regulatória e sem propriedades de aplicações monolíticas legadas para manter. O tamanho menor da equipe permite maior agilidade e a capacidade de se adaptar com base nas necessidades do cliente. Em essência, as fintechs não têm a complexidade dos bancos estabelecidos, o que lhes permite agir mais rápido e com menos riscos. Embora isso possa desacelerar as equipes de software, a complexidade nem sempre é uma coisa ruim.

Rede global
Material relacionado

Domine a dispersão de software

ícone de três anéis
VER SOLUÇÃO

Melhore a experiência de desenvolvedor com o Compass

Complexidade na entrega de software


A complexidade pode ser uma coisa boa: é muito gratificante resolver problemas complicados. Isso motiva as equipes a enfrentar desafios, lidar com problemas difíceis e revolucionar todo um setor. Por outro lado, há um ponto em que a complexidade não é mais a solução de um problema difícil e tem impactos negativos nas equipes de software.

A complexidade organizacional desempenha um papel fundamental na redução da eficácia das equipes de software. O dicionário Collins define complexidade como “o estado de ter muitas partes diferentes conectadas ou relacionadas entre si de uma forma complicada”. Em termos práticos, a complexidade organizacional é o conjunto de informações, dependências, mudanças, outras equipes, ferramentas e solicitações que as equipes de software precisam navegar ao interagir com o resto da empresa.

Níveis mais altos de complexidade organizacional sem dúvida tornam mais difícil fornecer software de alta qualidade com rapidez, porque as equipes passam mais tempo navegando pela empresa do que resolvendo problemas complicados. As empresas em crescimento logo descobrem que as equipes de software atingem um limite de complexidade: o nível de complexidade com o qual as equipes conseguem lidar antes que isso afete a satisfação no trabalho e a qualidade e a velocidade do software produzido. Pode parecer lógico, então, que a redução da complexidade organizacional permita que as equipes se concentrem na solução de problemas complicados, entregando software mais rápido e com maior qualidade. Vamos explorar por que esse nem sempre é o caso.

Impacto da complexidade em uma equipe de software


A introdução de uma arquitetura de microsserviços oferece um bom exemplo do impacto que a complexidade tem nas equipes de software. A definição de complexidade também é uma descrição perfeita de uma arquitetura de microsserviços, “o estado de ter muitas partes diferentes conectadas ou relacionadas entre si de uma forma complicada”. É verdade que os microsserviços permitem que as equipes se movam com independência, forneçam sistemas com mais rapidez e escalabilidade segura — eu sou um grande fã de microsserviços — no entanto, é inegável que eles acrescentam uma complexidade significativa.

Vamos considerar a eficácia das equipes de software da Atlassian durante a jornada de vários anos para adotar uma arquitetura de microsserviços.

No início da jornada de microsserviços da Atlassian, as métricas DORA pareciam ótimas! Pequenos trechos de código facilitaram o teste e a implementação, permitindo que as equipes se movessem com segurança e mais rapidez, e a satisfação no trabalho era alta. Durante essa fase, as equipes colheram os benefícios esperados de uma arquitetura de microsserviços. Embora a complexidade tenha aumentado, a gente não viu nenhum efeito negativo nas equipes.

início da jornada de microsserviços

Figura 1. Início da jornada de microsserviços

Com os benefícios, uma parte maior da empresa começou a adotar uma arquitetura de microsserviços, o que sem dúvida começou a aumentar a complexidade organizacional. Equipes mais autônomas exigiam mais colaboração, e mais microsserviços significavam mais dependências. O ritmo das mudanças disparou, e todos os sinais indicavam a dispersão de software. O aumento da complexidade fez com que a eficácia da equipe de software diminuísse, indicada por uma queda na velocidade da mudança, e a carga cognitiva se tornou um problema para as equipes de software.

Figura 2. A eficácia da equipe diminui à medida que a complexidade se aproxima do limite

Figura 2. A eficácia da equipe diminui à medida que a complexidade se aproxima do limite

Sem intervenção, a empresa acabou atingindo um limite de complexidade, e a eficácia da equipe de software diminuiu. Os benefícios de velocidade, autonomia e qualidade experimentados no início da jornada de microsserviços foram revertidos, o que causou uma queda compreensível na satisfação dos desenvolvedores. Esses sinais apontam para uma empresa que atingiu seu limite de complexidade. A equipe de software se esforça mais para lidar com a complexidade organizacional do que resolver problemas complicados, o que não é divertido.

atingir o limite de complexidade

Figura 3. A eficácia da equipe regride à medida que a empresa atinge o limite de complexidade

Como saber se você está se aproximando do 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.

A simplificação é uma estratégia para perder


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.

Elevação do limite de complexidade


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.

elevação do limite de complexidade

Figura 4. Elevando o limite de complexidade

A Atlassian criou o Compass, uma plataforma de experiência para desenvolvedores por esse motivo. O Compass ajuda a elevar o limite de complexidade, facilitando que as equipes de software naveguem pela complexidade organizacional por meio do catálogo de componente, métricas e tabelas de pontuação e se concentrem na criação de uma cultura de engenharia saudável. A principal ressalva aqui é que a complexidade organizacional não diminuiu na Atlassian; na verdade, ela continuou a crescer à medida que cada vez mais pessoas da empresa migraram para uma arquitetura de microsserviços. A gente reduziu o tempo gasto pelas equipes de software para lidar com essa complexidade, que é a diferença entre um projeto de simplificação e o aumento do limite de complexidade.

A Atlassian tem mais de 10.000 funcionários e mais de 17.000 componentes de software, mas as equipes de software operam em grande parte com a liberdade de uma startup, lançando software de alta qualidade com rapidez. A chave para o sucesso? Elevar o limite de complexidade para melhorar a eficácia da equipe de software.

Aqui estão duas ações para começar a aumentar o limite de complexidade:

  • Acompanhe e avalie as métricas DORA. Como estão as métricas DORA da equipe? Se você ainda não estiver rastreando essas métricas, elas são disponibilizadas prontas para uso com o Compass.
  • Entenda e avalie a satisfação do desenvolvedor. Como os desenvolvedores estão se sentindo nas equipes de software? A maioria das empresas realiza pesquisas de satisfação dos funcionários. Solicite os resultados, detalhados por área funcional, para obter informações sobre a satisfação do desenvolvedor. As principais perguntas incluem avaliar as seguintes afirmações:
    • Tenho orgulho do que estou lançando
    • A quantidade de estresse no trabalho é controlável
    • Eu entendo como o trabalho que faço contribui para as metas da empresa

Como alternativa, o Compass captura essas informações durante o ritual CheckOps, em que as equipes compartilham como se sentiram na última semana, além de informações sobre o que poderia ter sido melhor.

Elevar o limite de complexidade requer uma combinação de ferramentas, processos e rituais. Uma plataforma de experiência para desenvolvedores como o Compass pode ajudar você a entender a integridade do sistema, mapear dependências e criar rituais contínuos, ajudando a elevar o limite de complexidade e liberando o potencial das equipes de entrega de software da empresa.

Experimente o Compass de graça hoje mesmo.

Andrew Boyagi
Andrew Boyagi

Andrew é líder em DevOps Evangelism na Atlassian, com mais de 20 anos de experiência em entrega de software e gestão de serviços em organizações empresariais. Ele oferece uma perspectiva prática sobre como equipes e organizações podem maximizar os benefícios do DevOps com base em experiências reais.
Antes de ingressar na Atlassian, Andrew foi gerente executivo no Commonwealth Bank of Australia, onde estabeleceu e aperfeiçoou uma função de engenharia de plataforma que apoiou 7.000 profissionais de engenharia. Andrew tem um MBA pela Southern Cross University.


Compartilhar este artigo
Próximo tópico

Leitura recomendada

Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.

Ilustração do DevOps

Comunidade do Compass

ilustração de superação de obstáculos

Tutorial: criar novo componente

Ilustração do mapa

Comece a usar o Compass de graça

Inscreva-se para receber a newsletter de DevOps

Thank you for signing up