Não é mais novidade de que a indústria de tecnologia encontrou o seu novo acelerador. Segundo dados divulgados pelo GitHub, desenvolvedores usando ferramentas de IA como o Copilot conseguem concluir tarefas até 55% mais rápido. A promessa é clara e sedutora: entregar mais código, em menos tempo, com menos esforço.
Mas poucos se atentam a uma pergunta que deve ser feita antes de sair pagando assinaturas: nós estamos na direção certa para acelerar?
Imagine que durante uma viagem de carro você se depara com uma estrada enorme, sem pavimentação e completamente esburacada. Você percebe que o carro começa a pular loucamente e para não perder o controle ou causar algum dano ao veículo você resolve reduzir e seguir a viagem com 1/4 da velocidade que havia planejado. Nessa situação, você acha que se tivesse um carro com um motor mais potente (como de uma Ferrari) isso te possibilitaria acelerar para manter (ou até aumentar) a velocidade planejada? Se o seu time sofre com prioridades que mudam toda quarta-feira, metas de Planning que são sumariamente ignoradas e dependências eternas de upstream, a IA não vai resolver o seu problema.
Pelo contrário, ela vai amplificá-lo. Acelerar a esteira de desenvolvimento em um ambiente caótico não gera inovação, gera débito técnico na velocidade da luz. E o pior de tudo: a sua empresa provavelmente faz isso enquanto ostenta a etiqueta de "Somos Ágeis".
Neste artigo, vamos dissecar como o "Teatro Scrum" aliado à IA está destruindo a confiabilidade do produto (e o psicológico dos times), e por que o design do fluxo de trabalho é a única forma de pavimentar essa estrada.
A necessidade do "Somos Scrum"
Se você perguntar a 100 empresas se elas usam metodologias ágeis, 99 dirão que sim. No entanto, o State of Agile Report aponta que ano após ano a cultura organizacional e a resistência à mudança (como a falta de alinhamento do negócio) são os maiores obstáculos para o verdadeiro sucesso do Ágil.
Na prática, o que vemos é a proliferação do Agile Theater:
- A Daily vira um interrogatório de status report para justificar horas trabalhadas.
- A Sprint Planning vira uma sessão de ficção científica, onde o time se compromete com um objetivo que será atropelado por uma "demanda urgente do cliente" dois dias depois.
- A Retrospectiva até acontece, mas vira um ritual vazio. Os planos de ação levantados nunca são postos em prática porque "não temos tempo para parar e ajustar agora, precisamos entregar". E o pior, em um ambiente de alta pressão, problemas estruturais do fluxo começam a serem levados para o lado pessoal. Quem não sabe escutar críticas entra na defensiva, transformando o que deveria ser um diagnóstico funcional em uma batalha de egos.
O apego à "etiqueta do processo" cega as empresas para a realidade de suas particularidades. O Scrum foi desenhado para proteger o desenvolvedor de interrupções durante o ciclo da Sprint. Se o seu escopo muda no meio da iteração o tempo todo, você não está fazendo Scrum, você está fazendo uma gestão orientada a caos com boards coloridos no Jira.
Em muitos casos, foi exatamente nesse cenário frágil e estressante que o hype da Inteligência Artificial aterrissou.
O Gargalo Invisível: A Dor do Upstream
Enquanto o palco principal do Agile Theater foca em cobrar a squad de desenvolvimento para entregar mais pontos por sprint, o verdadeiro vilão age nos bastidores: o upstream.
O upstream representa tudo o que precisa acontecer antes que o desenvolvedor possa escrever a primeira linha de código útil. Se as especificações do produto são rasas, se o design muda no meio da iteração, ou se o time depende de aprovações de áreas lentas e burocratizadas, a squad de engenharia fica esmagada.
A realidade de muitas empresas é que o trabalho não flui, ele é empurrado. O desenvolvedor acaba com múltiplos cards bloqueados no Jira, assumindo o estresse de tentar cumprir uma meta irreal que já nasceu atrasada e deficiente em outra área. Neste cenário, o time perde a autonomia e se transforma em uma "fábrica de features" reativa, apagando incêndios e tentando decifrar requisitos pela metade.
E é aqui que a adoção precipitada da IA cruza uma linha perigosa.
Conversando sobre esse assunto com alguns amigos também desenvolvedores, foi surpreendente ver que mesmo trabalhando em empresas de frentes diferentes na tecnologia e de até mesmo países diferentes nos deparamos com problemas muito parecidos. Por exemplo, antes do boom das LLMs, quando um Gerente de Projetos (GP) ou Product Manager não havia mapeado completamente as regras de negócio de uma feature, isso ficava evidente. Ele explicava da forma que podia, e o desenvolvedor ao ler o card conseguia identificar imediatamente o nível de profundidade (ou a falta dela) do escopo daquela tarefa. Era fácil levantar a mão e dizer: "Isso precisa ser entendido melhor com o cliente."
Hoje a dinâmica mudou. Um gerente mal-preparado pega o pouco que entendeu de uma reunião junto com a transcrição, joga em uma IA e pede para "gerar os requisitos" e pensa "Perfeito, trabalho feito". Qual o resultado que você espera sair disso? Na prática o que acontece é que o desenvolvedor recebe um card com 50 linhas de descrição impecável, com Definition of Done (DoD), Definition of Ready (DoR) e critérios de aceite que parecem extremamente profissionais, mas que, na essência, são genéricos e superficiais. Eu particularmente considero "menos pior" receber o próprio prompt utilizado para gerar os requisitos do que ler 50 linhas de algo sem fundamento.
No final das contas, nem quem escreveu o card sabe exatamente o que está pedindo. A IA criou uma ilusão de clareza. E o que acontece na prática? O desenvolvedor é demandado para resolver não apenas a solução técnica, mas para fazer uma engenharia reversa das regras de negócio que deveriam ter sido definidas lá atrás, entre o GP e o cliente.
Pense em quantos processos da sua empresa isso não está acontecendo nesse exato momento. Documentações técnicas, do usuário, definições de requisitos, etc.
IA como Acelerador de Débito Técnico
Vagando pela internet uma vez vi uma citação do filósofo e jornalista Karl Kraus, que em uma crítica ao progresso cego disse: "Se a humanidade está marchando para o abismo, prefiro ir a pé a ir de automóvel."
Dar ferramentas de IA generativa para um time que não tem clareza de suas responsabilidades ou de um fluxo de trabalho saudável é exatamente isso: trocar os pés por um automóvel em direção ao abismo. Se a empresa demoraria 100 dias para despencar desse abismo andando a pé, agora ela chega em 10 dias super motorizada. Se a Planning foi ignorada e o escopo do que precisa ser feito é nebuloso, acelerar o resto do processo significa apenas construir a coisa errada muito mais rápido.
A IA fabrica épicos inteiros, documentações de produto, roteiros de teste e código de forma veloz e volumosa. Mas, sem um planejamento adequado e sem o acompanhamento necessário, a confiabilidade de todo o fluxo de valor despenca. Estudos como o da GitClear comprovem matematicamente a queda na qualidade do software e o aumento drástico do code churn (descarte rápido de código) principalmente em até 2 semanas depois de ir para produção, e esse é apenas o sintoma final de uma cadeia inteira que está doente.
A indústria de tecnologia está criando o que especialistas chamam de uma bomba-relógio de débito técnico e organizacional, onde a velocidade isolada se transforma em um passivo perigoso. O resultado prático nas empresas com esse "Scrum de Fachada" é sistêmico: gerentes perdem o controle do que realmente gera valor, times de QA são soterrados por cenários gerados artificialmente e inconsistentes, e os desenvolvedores herdam requisitos e sistemas que não conseguem manter ou decifrar meses depois.
Mas o problema nunca foi a ferramenta. A IA é um motor fantástico, o problema é tentar usar esse motor para compensar o desalinhamento do volante.
Pavimentando a Estrada: Clareza antes da Velocidade
Lendo este artigo você pode estar pensando: "Nossa, é verdade, vou sugerir imediatamente para que deixemos de usar o Scrum na minha empresa". Diante de um cenário de caos, essa é a reação instintiva de muitas empresas, buscar um novo framework milagroso ou tentar trocar o Scrum por um fluxo contínuo. Porém, apenas alterar a ferramenta de gestão sem reavaliar as equipes é apenas trocar os atores desse teatro.
Antes de pensar no fluxo de trabalho, é preciso dar um passo atrás e resgatar a clareza das responsabilidades funcionais. Se um gerente está terceirizando a criação da regra de negócio para a IA, e o Desenvolvedor está sendo forçado a atuar como analista de requisitos em tempo real para tapar buracos, o problema central é o Design de Time.
Pesquisando sobre como pavimentar essa estrada, me deparei com estudos que convergem no sentido de três pilares estruturais:
O Resgate do Upstream (Product Discovery real): Marty Cagan no livro "Inspired: How to Create Tech Products Customers Love" ele defende que o maior erro das empresas de tecnologia é empurrar requisitos para a equipe de engenharia sem antes investigar e mitigar riscos (Valor, Usabilidade, Viabilidade Técnica e Viabilidade de Negócio). A descoberta do produto não pode ser terceirizada. A IA pode ajudar a refinar textos, mas nunca deve substituir o pensamento crítico e a negociação com o cliente. O papel do gestor de produto não é preencher o Jira mais rápido possível, não é assim que ele vai garantir o prazo que prometeu para o cliente, é garantindo que o problema certo está sendo resolvido. As regras de negócio precisam ser debatidas e aprofundadas por humanos antes de virarem prompts e distribuidas para os desenvolvedores.
Um *Definition of Ready* (DoR) Inegociável: Embora o guia oficial do Scrum fale em refinamento contínuo, a indústria adotou o Definition of Ready (DoR) como um quality gate. No pensamento Lean (do Lean Software Development, que veio do Sistema Toyota de Produção), injetar matéria-prima defeituosa na linha de montagem gera um gargalo catastrófico mais à frente. No desenvolvimento de software, a matéria-prima é o requisito. O DoR é o escudo oficial da equipe técnica para rejeitar "matéria-prima" (cards gerados por IA sem profundidade) antes que ela entre na esteira e vire débito técnico. O time de engenharia precisa ter autonomia para barrar demandas disfuncionais. Um card gerado por IA com 50 linhas de um escopo genérico não pode ser considerado "Pronto para Desenvolvimento". O DoR deve ser um filtro rigoroso de qualidade de requisitos, protegendo a equipe técnica de absorver o caos do upstream.
O Fluxo como Consequência: A literatura moderna de design organizacional prova que tentar forçar um modelo de trabalho sem antes entender a topologia da equipe é inútil. Apenas quando as fronteiras de responsabilidade estiverem claras (onde termina o escopo de Produto e onde começa o de Engenharia) é que deve ser desenhado o fluxo de trabalho. Seja adotando Scrum, Kanban ou princípios do Unfix, o processo deve servir à realidade da empresa, minimizando atritos, carga cognitiva e evitando o retrabalho em progresso. O fluxo deve ser desenhado para reduzir a carga cognitiva dos desenvolvedores, a Lei de Conway afirma que os sistemas de software são cópias das estruturas de comunicação da empresa. Se a comunicação entre Produto e Engenharia está quebrada ou terceirizada para uma IA, a arquitetura do código inevitavelmente refletirá essa mesma quebra e confusão.
Ferramentas de Inteligência Artificial só se tornam verdadeiros superpoderes quando operam sobre uma fundação organizacional sólida. Acelerar a esteira de desenvolvimento sem alinhar quem faz o quê é o caminho mais rápido para o colapso.
Conclusão: Direção antes de Velocidade
Todos queremos percorrer um caminho mais tranquilo da forma mais tranquila possível. A cada nova inovação o ritmo das empresas de tecnologia tem aumentado, o nível da régua tem subido. Trabalhamos na área que mais vive inovações, sempre aparecem novas ferramentas ou novas formas de fazer. Nos apegarmos a uma forma de trabalho somente porque "sempre foi assim" é deixar de lado todas as outras alternativas apenas porque parece ser o mais fácil. A consciência de onde estamos, do porque de utilizar (ou não) cada processo e sabendo onde queremos chegar é o que irá proporcionar um ambiente saudável e próspero.
Antes de exigir velocidade e dar uma pá motorizada para quem já está cavando o próprio buraco, precisamos nos preparar ainda mais. Um processo maduro absorve a inovação, um processo disfuncional é destruído por ela mais rápido ainda.
Top comments (0)