A resposta é clara: a tarefa para a equipe de AM é muito mais difícil. É verdade que a equipe de AM está participando de sua experiência desenvolvida ao longo do tempo. Mas, ao mesmo tempo, a equipe de AM precisa lidar com uma base de código não muito estável, evitar introduzir regressões sem ter uma rede de segurança de teste decente e criar uma maneira de implantar uma nova versão principal sem criar interrupções.
Vamos dizer. A equipe de AM frequentemente enfrenta um trabalho muito mais difícil do que a equipe do Projeto. Então, por que, se a tarefa da equipe de AM é mais difícil, todos os desenvolvedores experientes trabalham na equipe de Projeto (e agora estão em outro lugar, provavelmente fazendo outra coisa interessante)?
Uma resposta possível: a equipe do projeto precisa estabelecer as bases certas
Uma razão para ter as pessoas mais experientes iniciando um projeto é que, no início, precisamos estabelecer as bases para o que está por vir. Precisamos definir a arquitetura e tomar algumas decisões fundamentais sobre o design da solução, para que seja necessária a experiência certa.
Ao mesmo tempo, no início de um projeto, geralmente temos apenas um conhecimento limitado do problema que somos chamados a resolver.
No início de qualquer projeto significativo, existem muitas incógnitas conhecidas e também muitas incógnitas desconhecidas. Por esse motivo, a arquitetura do sistema sempre deve ser considerada evolutiva. Precisamos estar cientes de que muitas decisões cruciais não podem ser tomadas no início, mas precisam ser tomadas quando o desconhecido começa a se revelar.
As decisões de arquitetura raramente podem ser decididas de uma vez por todas no início de um projeto. Questões críticas de arquitetura podem surgir a qualquer momento na vida do sistema SW. E essas decisões críticas tomadas no início do projeto podem ter que ser revisadas mais tarde – talvez por causa de novos requisitos, talvez por novas tecnologias como a Cloud, talvez por serem simplesmente as erradas para o problema resolver.
Então, sim, é verdade, a equipe do Projeto precisa tomar decisões arquitetônicas. Mas a equipe do AM também precisa tomar decisões arquitetônicas e em um ambiente muito mais complexo.
Você simplesmente não pode fazer o contrário
Embora o modelo clássico de uma equipe forte do Projeto, seguida por uma equipe mais jovem de AM, não seja a mais eficiente no médio prazo, o contrário também não é uma resposta.
A maioria das empresas não pode imaginar ter uma equipe júnior iniciando um projeto e depois fazer a transição para uma equipe mais sênior para manutenção. Não é apenas uma opção.
Um caso de subconsciência
Talvez uma das razões profundas pelas quais pessoas mais velhas iniciam novos projetos com novas tecnologias é que elas gostam de começar coisas novas e brincar com novas tecnologias. Mas, com o tempo, quando o trabalho parece se tornar mais repetitivo, eles simplesmente querem passar para outros desafios.
Isso é bom para a curiosidade tecnológica e para o currículo. Mas isso provavelmente não é bom para a saúde a longo prazo do sistema de SW que eles estão construindo.
Da equipe do projeto à equipe do produto
Em 2006, Werner Vogels, CTO da Amazon, cunhou o famoso “Você constrói, você administra” lema. Ele transmitiu a ideia de que uma equipe responsável por um Produto precisa cuidar dele desde o início até a fase de execução (onde a execução abrange tanto os aspectos de Ops quanto os de evolução).
Simplificando, a mesma equipe é responsável por todas as fases necessárias para que um Produto seja bem-sucedido: projetar, construir, executar, evoluir.
Esse é o modelo adotado pelos gigantes digitais que surgiram na última década, da Amazon ao Facebook e AirB & B. Seu sucesso indiscutível é a prova de que o modelo é o caminho certo na era digital.
Atualmente, um número crescente de pessoas enfatiza a necessidade de passar de uma maneira orientada a projetos de organizar o trabalho para um modelo mais orientado a produtos.
Essa é uma transformação complexa que envolve muitos aspectos de uma organização. Mas para o tópico que estamos debatendo aqui, definitivamente significa que precisamos abandonar a ideia de equipes separadas de Projeto e AM e criar equipes de Produto mais estáveis.
As equipes de produtos precisam ter a combinação certa de pessoas experientes e mais jovens que precisam crescer. Trabalhando em conjunto com os desenvolvedores experientes, os juniores gradualmente se tornam experientes. A rotação controlada é então possível sem alterar a qualidade da equipe.
Conclusão
Na era em que vivemos, na era digital, devemos suspeitar quando ouvimos algo como “E quando o projeto terminar, passaremos para a AM”.
Isso não quer dizer que não haja mais espaço para AM. Ainda existem sistemas legados antigos, geralmente atendendo ao back office, que estão trabalhando de maneira flagrante, que são muito estáveis e que apenas precisam de alguma manutenção.
Porém, quando chega a hora de desenvolver novos recursos digitais diferenciadores, precisamos nos afastar do modelo Projeto / AM e adotar um modelo orientado ao produto.
Nesse modelo, as equipes são projetadas para serem responsáveis por criar não apenas a primeira versão do Produto, mas também executá-lo. E eles aprendem a executá-lo enquanto o desenvolvem ao longo do tempo para garantir que seja relevante para seus usuários finais.
