Evoluir tecnologia seguindo à risca os antigos conceitos de projeto não atende mais o ritmo de mudança que os negócios precisam, estava claro que precisávamos mudar
Trabalhar como projeto para evoluir aplicações de software que não param nunca se mostrou com o tempo algo bastante oneroso e gerador de atrito entre pessoas e áreas nas empresas. Parar para pensar em um escopo fixo que deve ser construído ao longo de meses ou até mesmo anos parece algo como fechar os olhos e correr atrás de um alvo móvel; ou seja, por mais que tenhamos um bom planejamento, apenas acertaremos a direção, mas com alto nível de erro no atingimento da meta. E isso ocorre porque simplesmente o mundo andou desde quando planejamos onde queríamos chegar até a entrega de fato.
A solução é transformar tudo em projetos ágeis?
Projetos ágeis resolvem um objetivo de negócio específico, aquele que se deseja alcançar, bastando adaptar time e entrega para um modelo incremental e iterativo. Mas, e após acabar o projeto, entregar o MVP e demais releases complementares, o que acontece?
O fato é que não é só a questão do “alvo móvel” o problema. Montar e desmontar times para algo que deveria ser constante é no mínimo improdutivo. Os momentos crescentes de produtividade de um time de projeto, baseando-se em estudo de 1965 de Bruce Tuckman, são: forming, storming, norming, e performing. O problema é que justamente quando tudo está performando muito bem e o time está entregando na cadência máxima, o projeto acaba e entra na fase distroying, onde as pessoas são desmobilizadas e numa próxima demanda este ciclo é todo reiniciado. Tuckman chama esta etapa como adjourning.
Este montar e remontar de times representa uma perda enorme de produtividade e custos com:
Ociosidade: geralmente dimensiona-se para cima o esforço de algo que não está refinado ainda, não se tem clareza. Times menores poderiam executar o mesmo trabalho se não se tivesse tanta incerteza antecipada.
Indefinição: a incerteza sobre possíveis novos requisitos técnicos ou funcionais no decorrer da entrega faz o sizing do time (ou valor do projeto, quando terceirizado) carregar uma espécie de seguro para lidar com essas indefinições.
Em resumo, a falta de clareza cobra um custo alto, em todos os sentidos, para as empresas e times de tecnologia.
Mudar para o modelo de “gestão por produtos” é mandatório para sobreviver
Boa parte das empresas percebeu que não dá pra viver somente de projetos ágeis, e muitas ainda estão se transformando para terem times fixos que trabalham como linhas de produtos, que não têm pré-definidos início meio e fim, mas que evoluem continuamente seus contextos funcionais (subdomínios da plataforma) em prol de objetivos de negócio. Muito inspirados pelo modelo Spotify, esses times se popularizaram com o nome de squads (esquadrões) que têm autonomia para evoluir e resolver problemas de negócio e técnicos dentro do seu subdomínio, orientado a metas de curto prazo associadas aos macro-objetivos das companhias
Após anos rodando esse modelo, ficou claro que se tratava de uma enorme evolução: reduziu-se a incerteza embutida nos projetos, os times se especializaram muito em seus contextos, a autonomia permitiu atacar problemas que não eram antes priorizados e muito custo foi economizado com a produtividade gerada. Eu mesmo vivi, há poucos anos, uma redução de 40% dos custos de desenvolvimento quando comparado ao modelo anterior.
Tudo perfeito, então? Nada a mudar? Claro que não. O desafio de evoluir software para uma sociedade a cada dia mais digitalizada, impulsionada pela pandemia e que muda o tempo todo traz desafios que precisam ser atacados pelo modelo atual de gestão de produtos.
O modelo atual de gestão de produtos está limitando os movimentos maiores em muitas organizações, e requer ajustes incrementais
A tão sonhada e benéfica autonomia dos times tem sido uma das maiores armadilhas quando mal interpretada. Considero o conceito de autonomia maravilhoso, mas isso não quer dizer que não precise estar conectado a objetivos maiores e acompanhados — e esse tem sido o problema.
Para iniciativas maiores os desenvolvedores entre os times precisam se falar diretamente pois as soluções mudam, o escopo funcional muda o tempo todo e o modelo de comunicação intermediada se mostra limitador: o dev, ao encontrar algo que precisa de outra tribo, alinha com o seu product manager, que fala com o do lado, que retorna, que envolve o Business para repriorizar algo e volta. Ufa! Cansa só de pensar. Esta dificuldade somada a uma autonomia desconectada de objetivos maiores acima dos times/tribos e à inexistência de uma dinâmica de trabalho (praticas e rituais) que foque na entrega do objetivo de negócio a ser alcançado faz com que o time priorize, com o passar do tempo, somente as famosas low hanging fruits, entregas mais fáceis e auto-contidas, sem tantas interdependências. Só que em muitos casos, como em plataformas digitais maiores mais interconectadas, isso significa não fazer com o tempo as entregas que realmente mudam o patamar do negócio e sim aquelas de crescimento pouco incremental. Para um cenário de empresas exponenciais isso pode ser fatal!
Evoluindo o Product Management e trazendo só a parte boa do modelo projetizado
Para as iniciativas cross, com alta interdependência, derivadas do processo de gestão de portfólio e com um objetivo claro de negócio a ser alcançado tenho visto casos de bons resultados usando o conceito de times de iniciativas, formando um grupo que contém diversos DEVs de cada contexto funcional (tribos/squads) que ficam juntos seguindo os rituais próprios das iniciativas até que a mesma seja entregue. Ao término, o time volta a sua tribo de origem, parte forma um novo time de produto ou um time de domínio que atenderá a múltiplos produtos, algo muito comum em movimentos de transformação onde o negócio precisa pivotar ou em empresas que deixam de ser mono-produto para serem multi-produtos.
Para que a camada de iniciativas cross funcione adequadamente, o time não perca seus vínculos com o seu time de produto de origem (seja para levar a visão da futura solução ou para que o novo produto/solução considere os problemas que estão sendo vividos naquele momento), é super importante criarmos os chamados rituais de sincronismo, para fluir o trabalho e a comunicação mútua entre cada participante e seu time de origem.
Com isso, trazemos para os times de iniciativas cross só a parte boa dos projetos que é o foco na execução e a comunicação diária e direta sobre o objetivo a ser alcançado, eliminando intermediários e evitando que os objetivos maiores percam prioridade nos silos originais. Voltando ao modelo de Tuckman, reduziremos muito, desta forma, a energia empenhada nas fases de forming, storing e norming, maximizando a que mais precisamos que é o performing.
Neste contexto onde velocidade é vital temos que estar atentos pra adaptar tudo o tempo todo. Até mesmo as abordagens consideradas mais novas. Formas consagradas de sucesso no passado não devem ser demonizadas, mas adaptadas naquilo que funcionavam bem e incrementar o novo.
Este artigo foi produzido por Bruno Martins, Executivo de tecnologia conceituado, palestrante, CTO do Olist e colunista da MIT Technology Review Brasil.
Bruno Martins
