Oferecido por
Transformação foi sem dúvida o desafio que sempre encontrei em cada empresa por onde passei: transformar arquitetura, o jeito de desenvolver software, de tomada de decisão, de modelo operacional, de sourcing e muito mais.
O mercado, as empresas e todos os tipos de organizações são compostos em sua unidade mais básica por humanos e como tal precisam o tempo todo se movimentar para permanecerem vivas, ativas e perseguidoras de seus sonhos. Nos dias atuais (e ainda mais acentuado por este momento de pandemia que nos privou muito do mundo físico) as grandes empresas tradicionais querem ser digitais (no seu mais amplo sentido), as que conseguem êxito querem ser como as nativas digitais, que por sua vez crescem e querem voltar a se comportar como start-up que foram um dia. Logo, é possível que o leitor imagine que uma vez estando em uma startup não existiria o desafio de se transformar o tempo todo, dando lugar ao genuíno e natural desafio de simplesmente crescer, certo? Não, ledo engano!
Escalar nunca é somente escalar, requer algo mais que simplesmente crescer. Voltamos então a tal da transformação, assim como nas grandes empresas só que com outras motivações. Empilhar mais do mesmo pode ser fatal para start-ups em fase de scale-up que querem ter vida longa e sustentável enquanto organização de tecnologia. As dores do crescimento são grandes para empresas que crescem em muitos casos três dígitos ao ano e, comparando novamente a nós humanos, são oriundas da necessidade do corpo em se transformar para aguentar um tamanho maior que vem pela frente. Começo hoje então a escrever sobre uma série de transformações necessárias às start-ups, scale-ups ao longo de sua jornada no que tange ao robustecimento do seu corpo de tecnologia.
Uma área de tecnologia de uma start-up muitas vezes nasce sendo a própria empresa e resumindo-se a uma mesa com dois engenheiros e um fundador em busca de um MVP. As coisas indo bem (e o dinheiro entrando), logo essa mesa ganha mais dois ou três devs, que daqui a pouco ja não cabem em uma mesa e novas destas aparecem ao lado, e mais outra e outra e quando se percebe já não cabe mais em uma sala ou um andar. Este ciclo virtuoso do crescimento traz mais atenção de investidores e fundos e junto com este fenômeno maravilhoso muita necessidade de se transformar. Sim, aquela start-up já é uma adolescente, ou melhor uma scale-up, e decisões importante caberão ao seu CTO.
Um dos primeiros desafios que surge é especializar o time em funções que até então eram executadas pelos engenheiros do time. Aquele engenheiro que até então “era bom em tudo” e fazia de tudo um pouco continua “sendo bom em tudo”, mas não consegue mais fazer tudo aquilo que se espera dele. O tamanho do desafio de cloud engineering por exemplo já requer alguém especializado, segurança da informação já não consegue ser tratada totalmente descentralizada apesar de toda a prática DevSecOps nos times. Pronto, chegou a hora em que temos que falar sobre as diferentes trilhas de carreira do time tech.
Criar estruturas verticalizadas por especialidade sempre provoca o receio do time (principalmente os engenheiros mais antigos e polivalentes) em “engessar”, perder agilidade, burocratizar e outros termos mais que sempre remetem a perda de velocidade e de um ambiente mais autônomo. E estão certos! Por isso, esta verticalização de especialidades deve ser feita com todo o cuidado que merece, mantendo o que chamo da teoria da centralidade mínima necessária; ou seja: todo o poder e liberdade deve ser preservada “na ponta”, que quer dizer nos times, nas squads, tribos ou seja lá o nome que se dá à organização multidisciplinar que entrega software em produção. Para que a centralidade seja realmente a mínima necessária, alguns modelos fazem muito sentido por conseguirem preservar a agilidade sem abrir mão de padrões importantes a um grupo e engenharia de software sustentável:
Uma competência organizada na forma hub and spoke significa criar uma camada mínima de engenheiros/especialistas chamada de hub como uma estrutura central para desempenhar as atividades normalmente comum a todos times (como por exemplo a construção do pipeline de desenvolvimento e deployment que todos os engenheiros usarão para entrega de seus microsserviços) que por sua vez se comunica diretamente com profissionais distribuídos nos times (spokes) que desempenham suas tarefas de forma descentralizada e alinhadas ao contexto específico daquele time que tem certamente particularidades de negócio, arquiteturais entre outras.
Existem alguns casos onde a competência é tão fortemente acoplada a uma outra “competência irmã” que faz sentido não manter nem um pequeno hub centralizado para evitar maiores rupturas que prejudiquem a entrega de software. É o caso por exemplo das competências de arquitetura de solução, arquitetura de aplicação e o desenvolvimento em si. Estruturar uma área de arquitetura de soluções pode gerar uma sensação ruim de perda de autonomia pelos engenheiros que codificam reduzindo a responsabilidade saudável do time pela entrega final de valor. Neste caso então o mais recomendado seria estruturar chapters ou guilds com o grupo de engenheiros que trabalham mais próximos do refinamento dos épicos em soluções para que regularmente se reúnam para discutirem e definirem padrões arquiteturais, fazerem os alinhamentos necessários e tomarem decisões importantes a arquitetura e ao negócio. Não há dúvida de que se perde um pouco da sensação de domínio, mas ganha-se muito no sentimento de accountability do time e, se bem liderado pelos chapters leads capacitados para tal missão consegue-se resultados surpreendentes.
Nas próximas edições da coluna vamos falar sobre outros desafios igualmente importantes na jornada de crescimento de organizações de tecnologia no que se refere a arquitetura, modelo operacional, inovação e tudo mais neste sentido.
Até a próxima!
Bruno Martins
