O dia em que a metodologia ágil fez mais sentido.

Durante mais de 25 anos atuando como gerente de projetos, sempre me senti confortável trabalhando com planejamento detalhado, cronogramas completos e uma abordagem tradicional de gestão. Foi assim que cresci profissionalmente.

Sempre gostei de organizar todas as etapas antes do início da produção, prever riscos, definir responsáveis e acompanhar rigorosamente o cronograma.

Confesso que, por muito tempo, olhei para as metodologias ágeis com certa desconfiança.

Até que um projeto me mostrou que não existe metodologia melhor. Existe a metodologia mais adequada para cada contexto.

Há alguns anos, fui contratado como Gerente PMO por uma empresa de educação corporativa para conduzir um grande projeto para um banco digital.

A proposta parecia relativamente simples: desenvolver um programa de onboarding para a equipe responsável pelo atendimento dos clientes de alta renda.

Mas bastaram poucos dias para percebermos que o desafio era muito maior.

O conteúdo não estava estruturado.

As informações estavam espalhadas entre manuais, procedimentos internos e conhecimento dos especialistas da empresa.

Além disso, o projeto previa diferentes formatos de aprendizagem, como e-learning, vídeos, infográficos, estudos de caso e materiais complementares, distribuídos em três níveis de experiência dos colaboradores. Na prática, isso representava dezoito entregas diferentes.

Durante a reunião de kick-off, passamos um dia inteiro levantando informações com diversas áreas do cliente para entender tanto os produtos quanto o perfil extremamente específico desse público.

Ao voltar para a empresa, reunimos toda a equipe multidisciplinar para transformar aquele universo de informações em um plano de produção.

Foi quando surgiu o primeiro problema.

Nossa coordenadora de produção simplesmente não conseguia elaborar um cronograma detalhado.

E não era falta de competência. Era porque ainda não existiam respostas suficientes.

Como definir datas precisas para etapas cuja própria solução ainda dependeria das descobertas feitas durante o desenvolvimento dos storyboards?

Enquanto isso, surgiu o segundo desafio. Ao revisar o manual de identidade da empresa, descobrimos que todo o material produzido precisava atender aos requisitos de acessibilidade, incluindo legendas e Libras para os vídeos.

Esse esforço adicional não havia sido previsto durante a negociação comercial.

Ao mesmo tempo, recebi uma ligação da diretora da empresa. Ela explicou que o projeto precisava ser entregue rigorosamente dentro do prazo, pois toda a equipe receberia um bônus caso conseguíssemos cumprir o cronograma.

A responsabilidade aumentou consideravelmente.

Naquele momento, percebi que insistir em um planejamento tradicional seria um erro. Não porque a metodologia estivesse errada, mas porque o projeto ainda possuía muitas incertezas.

Foi então que decidimos mudar completamente nossa forma de trabalhar e adotamos o Scrum.

Montamos um cronograma macro para o cliente e passamos a organizar a produção em sprints. Cada etapa era planejada, executada, validada pelo cliente e refinada antes da seguinte.

As validações passaram a acontecer continuamente.

O planejamento deixou de ser um documento fechado para se tornar um processo vivo.

Dedicamos aproximadamente um mês ao planejamento inicial.

Nos três meses seguintes, evoluímos sprint após sprint, validando as entregas continuamente até a conclusão do projeto.

No final, entregamos todas as dezoito unidades de aprendizagem dentro do prazo, com excelente avaliação do cliente e sem comprometer a qualidade das entregas.

A equipe recebeu o bônus.

O cliente ficou satisfeito.

E eu saí desse projeto com um aprendizado que carrego até hoje.

Durante muitos anos ouvi discussões sobre qual abordagem era melhor: Waterfall, Scrum, Kanban…

Hoje penso diferente. Projetos previsíveis continuam funcionando muito bem com abordagens tradicionais. Mas, quando as incertezas são maiores do que as certezas, tentar controlar tudo desde o primeiro dia pode atrasar exatamente aquilo que queremos entregar.

Naquele projeto, o Scrum não foi uma tendência nem uma obrigação.

Foi simplesmente a ferramenta certa para resolver o problema certo.

Desde então, nunca mais enxerguei metodologias como uma questão de preferência, mas de contexto.

Talvez essa tenha sido uma das maiores lições da minha carreira.

Depois de mais de 25 anos gerenciando projetos, descobri que experiência não significa fazer tudo da mesma forma. Experiência significa saber quando adaptar a abordagem para entregar o melhor resultado.

Compartilhar
foto do autor

Alexandre Collart

Alexandre Collart atua há mais de 30 anos no mercado de educação corporativa, e-learning e comunicação digital, sendo reconhecido por sua experiência na criação, gestão e implementação de projetos de aprendizagem para empresas de diferentes segmentos e portes, com foco em desenvolvimento de pessoas, disseminação do conhecimento e soluções educacionais alinhadas às necessidades do negócio.

SAIBA MAIS

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

whatsapp