Conforme Jean Pierre Lessa e Santos Ferreira, CTO e especialista em tecnologia, software e inteligência artificial, a pergunta sobre método costuma chegar invertida. Times discutem qual abordagem adotar antes de descrever o problema, quando é o problema que define qual abordagem funciona.
Gestão ágil e planejamento sequencial não são escolas rivais disputando o mesmo território. São respostas a graus diferentes de incerteza, e a maior parte das organizações convive com os dois tipos de projeto ao mesmo tempo, às vezes dentro do mesmo trimestre.
O que separa um caso do outro não é tamanho, orçamento nem maturidade do time. É onde mora a dúvida principal do projeto, e quanto custa descobrir tarde que a resposta estava errada. As duas medidas mudam de projeto para projeto dentro de uma mesma área.
Quando o requisito é estável e a integração é complexa?
A substituição de um sistema de gestão empresarial tem requisito conhecido antes do início. Emissão fiscal, regra contábil e integração com dezenas de sistemas existentes não admitem versão parcial em produção: ou a operação fecha o mês corretamente, ou não fecha.
Projetos desse tipo pedem sequência, marco definido e simulação antes do corte. A ordem de execução importa porque as dependências são rígidas, e entregar metade não gera aprendizado útil, apenas dois sistemas em paralelo cumprindo a mesma função.
Jean Pierre Lessa e Santos Ferreira aponta que viradas de sistema central e integrações tecnológicas de aquisições ocupam esse campo com clareza, já que o acordo com áreas fiscais, contábeis e logísticas precisa estar fechado antes da primeira linha de código ser escrita.
A incerteza está na demanda, não na técnica
Uma funcionalidade nova de comércio eletrônico é tecnicamente simples e comercialmente duvidosa. Ninguém sabe se o cliente vai usar, em que frequência, nem qual versão converte melhor, e nenhuma reunião de especificação produz essa resposta. A dúvida está no cliente, não no código.
No outro extremo do planejamento sequencial, Jean Pierre Lessa e Santos Ferreira mostra que esse tipo de projeto se beneficia de ciclos curtos, porque a informação que falta só aparece em contato com o uso real, e cada semana de atraso nesse contato é aprendizado adiado.
Aqui, plano detalhado é desperdício com aparência de rigor. Detalhar seis meses de funcionalidades para um produto que será redirecionado no segundo mês consome exatamente o tempo que poderia ter sido usado para testar a primeira hipótese.
O critério que decide: custo de errar e custo de corrigir
Jean Pierre Lessa e Santos Ferreira considera que a escolha se resolve com duas perguntas objetivas: qual o custo de descobrir tarde que a direção estava errada, e quanto custa corrigir depois que a entrega já está em produção? As duas respostas saem do histórico da própria operação.
Custo de correção alto e requisito estável empurram para o planejamento sequencial, com verificação antes da entrega. Custo de correção baixo e demanda incerta empurram para ciclos curtos, com verificação depois da entrega e ajuste rápido. O restante é combinação dessas duas medidas.
Jean Pierre Lessa e Santos Ferreira comenta que o mesmo time pode operar nos dois regimes em projetos diferentes sem contradição, desde que a escolha seja declarada no início e revisada quando a natureza da dúvida mudar.
Modelos híbridos e o erro de misturar rituais
Híbrido funciona quando a divisão é por camada, não por gosto. Marcos contratuais e dependências externas seguem plano sequencial, com data e ordem; dentro de cada marco, o trabalho corre em ciclos curtos, com entrega verificável a cada duas semanas.
O erro comum tem forma reconhecível: reunião diária, quadro de tarefas e ciclo quinzenal convivendo com escopo fechado, aprovação prévia de cada mudança e data imutável definida um ano antes. O time adota a cerimônia e perde o mecanismo que existia para sustentá-la.
Na leitura de Jean Pierre Lessa e Santos Ferreira, o teste do híbrido é a autoridade de decisão: se o ciclo curto não pode mudar prioridade nem devolver uma funcionalidade à fila, o formato é sequencial com vocabulário emprestado, e o acordo com o patrocinador acaba prometendo data e escopo fixos que a execução não sustenta.
Método é escolha de gestão, não identidade de time
Time que se define pelo método defende o método quando ele falha. A conversa migra para a fidelidade ao manual, e a pergunta útil, se aquela forma de trabalho está reduzindo o risco do projeto, desaparece da pauta.
Trocar de abordagem no meio do caminho é sinal de leitura correta, não de fracasso. Projeto que começou com incerteza de demanda e chegou a requisito estável; mudou de natureza, e insistir no formato inicial passa a custar previsibilidade sem devolver aprendizado.
A pergunta que sustenta a decisão é sempre a mesma, e independe de rótulo: o que ainda não sabemos, e qual formato de trabalho descobre isso mais cedo com menos dano? Método que responde bem a isso serve ao projeto. O resto é preferência.
Adicionar um comentário