Ep. 265 - Do Cronograma ao Roadmap: quebrando a rigidez com entregas de valor

Lucas, consultor especialista na Nower e instrutor na K21, e Brigido, Product Manager com sete anos de experiência na área de produtos em uma empresa de locação de veículos, compartilham o case prático de como saíram de uma visão de cronograma para uma visão de roadmap em um projeto de migração de ERP. A história foi apresentada no SG Rio, junto com o Agile Brasil, e levou seis meses para chegar a um formato funcional de roadmap, com muitas dores aprendidas e superadas ao longo do caminho.

O contexto era uma migração de ERP com vários times envolvidos, mexendo no core da operação da empresa, automatizando processos que em alguns setores eram manuais, como planilhas. A primeira perspectiva para gerir o projeto era o Gantt, a visão de cronograma tradicional, com a leitura de quando a gente vai chegar. O modelo de projeto só acontecia lá: verde, melancia, tudo verde, todo mundo trabalhando, 75%, 97,2%, tudo pertinho de entregar. Mas no final das contas estava cheio de dependências, cheio de problemas para resolver até atingir a data. O cronograma do Gantt não trabalha com dependências, e era esse o principal problema.

Um dos problemas maiores era trabalhar com a famosa data muro, uma data alvo que a gente precisa perseguir. Geralmente, quando se tem uma data muro, se tem pelo menos um objetivo muito grande para ser alcançado nessa data. O problema maior era: o que de fato a gente estava entregando durante esse período? Em alguns meses de projeto, o que de fato a gente ia entregar nessa data muro? Como a gente ia olhar para o valor do negócio que estava sendo entregue nesse período? Outro problema era a falta de comunicação clara com a área de negócios, a área cliente, com uma comunicação mais voltada para o técnico em vez de uma linguagem de negócio durante as reuniões de follow-up do projeto.

A mudança de recepção das pessoas foi positiva. A área cliente comprou a ideia de fazer o acompanhamento voltado para o valor a ser entregue, não tanto a data. Essa parceria gerou engajamento dos times de desenvolvimento junto à área cliente, de entender que até tal dia a gente consegue não talvez entregar o todo, mas entregar uma pequena partezinha que já entrega um pedacinho daquele valor. A visão de roadmap foi fatiada em releases, onde pequenas entregas durante a release já entregavam nem que seja um percentual de valor para a área de negócio, gerando um efeito positivo de confiança de que em algum momento a entrega do valor aconteceria.

O primeiro passo após sair da visão de cronograma foi colocar todos os times numa visão de fluxo, organizados lado a lado. Nesse momento, os times ainda estavam organizados por especialidade: um time de faturamento, um time de contrato, e assim por diante. Quando colocados na perspectiva de fluxo, percebeu-se alta dependência: times terminavam coisas, mas a dependência ainda estava no backlog de outro time, sendo desenvolvida ou no começo de outro time. Também se identificou um desbalanceamento de atividade: times super lotados de trabalho ao lado de times com pouquíssima coisa no backlog, gerando a apreensão de quando o backlog acabasse, o que fazer.

O próximo salto foi sair da visão de fluxo e começar a trabalhar por uma perspectiva de release, a visão de fato de roadmap. A delimitação de objetivos nas releases permitiu que os times, apesar de ainda terem suas dinâmicas de backlog, deixassem de usar o time específico para uma skill e passassem a trabalhar no contexto global do projeto, do valor total. Os times não se apegavam mais ao seu silo. Com a release bem estabelecida, com o valor esperado da entrega em fatias menores, não existia mais o Big Bang, existiam pequenas entregas através de uma release, e os times começaram a medir os esforços direcionados a esses pequenos objetivos.

Duas mexidas simples, mas extremamente impactantes, foram decisivas. A primeira: mudar times de especialidade para que operassem pela visão da release. Para isso, criaram times representados por carros: o time Gol, o time Kombi, e por aí vai. Os times tinham o nome de carros para que entendessem que estavam ali para entregar o ERP, o projeto maior, e não necessariamente trabalhar só por um escopo. O impacto imediato foi que os POs, ao invés de chegar na coordenação dizendo que não dava, chegavam dizendo preciso de ajuda. Com isso, era possível distribuir o backlog do PO sobrecarregado para outros times, equilibrando a carga e minimizando as dependências. A segunda mexida: não dizer mais quando a gente entregava, mas o que cabia até naquela data. A data é extremamente importante, traz segurança, conforto e previsibilidade para o stakeholder. O que não pode acontecer é querer tudo nessa data. A pergunta que mudou foi: o que cabe nessa data?

A comunicação com a área de negócio mudou radicalmente. Em vez de falar review, API, tabela do banco de dados, a linguagem passou a ser: nesta release você vai conseguir fazer uma ação na sua tela, você tira um relatório que vai trazer o volume de X coisas que você fez naquela atividade. A área de negócio passou a entender que, daqui a 15 dias, vai tirar o seu relatório, independentemente de quantas APIs por trás. A confiança de que não ia ter naquele momento, mas que em algum momento aquela funcionalidade seria entregue, tornou o processo mais saudável tanto para o time de desenvolvimento quanto para a área de negócio.

Havia flexibilidade nas datas. A gente podia mexer, atrasar um pouco, jogar um pouco mais para frente, para ver com o cliente o que era importante para ele usar naquele momento. Se o Z não der para entrar na data, mas o cliente precisa do Z, a data ia um pouco mais para frente, porque não adianta entregar só XYZ sem o Z se isso não vai funcionar para a operação. O cliente passou a entender essa transparência e a jogar no mesmo time, trazendo a visão de priorização: de cinco funcionalidades, o que é mais importante agora. A frase que guiava o trabalho era: não é sobre fazer o que dá para fazer, é sobre fazer a próxima coisa que tem que ser feita. Às vezes ela é complexa, e se for, a gente fatia. Nem tudo vai dar para fatiar muito fino, e tudo bem.

A perspectiva do PO e do PM nesse cenário era de uma cadência mais saudável das entregas, com o que perseguir no alto nível e no baixo nível. As semanais com a área cliente ficaram mais saudáveis, com mais visibilidade e confiança. A expectativa de será que eu vou ter na data que eu quero deixou de existir, substituída por o que vai ser entregue naquela release, com fatias menores, escopo bem definido e valor esperado.

Sobre a autonomia na priorização: a área cliente, na época, estava um pouco sem processos sistêmicos para basear e evoluir o negócio. Para o time de desenvolvimento e os Product Owners, foi mais fácil sair de um completo zero para um. Eles tinham autonomia para decidir, pois à medida que faziam entrevistas com as áreas de negócio, entendiam a necessidade, transcreviam para uma linguagem mais técnica junto ao time de desenvolvimento e definiam entre eles as soluções voltadas para o sistema. A área cliente precisou se adaptar ao novo formato, saindo de uma planilha de Excel para um processo automatizado no sistema.

Para a gestão visual do trabalho, usaram o Miro. O Jira continha toda a informação, mas era difícil gerar impacto visual com a quantidade de dependências. O Miro servia para que as pessoas da empresa sentissem a dor, percebessem a quantidade de dependência, visualizassem o volume de coisa quase terminando mas não terminando por causa de dependências para trás. Era um jogo combinado: colocar no Miro para dar visibilidade e gerar impacto, mas voltar para o Jira, onde os times trabalhavam. O retrabalho de copiar do Jira e colar no Miro era necessário para gerar o impacto visual e tomar decisões. Se você não está vendo o problema, às vezes precisa deixá-lo explícito. A visão de fluxo para os times não era um problema, pois já funcionava no Jira. O que precisava ser discutido era a visão de negócio, a perspectiva de roadmap.

O ponto alto da apresentação foi o impacto visual e a questão cultural da mudança. O feedback das pessoas no evento elogiou o material, a apresentação e a condução. O aprendizado central é que o modelo apresentado não é um destino final, mas um processo contínuo de experimentação, aprendizado e evolução. A complexidade aumentou, entraram mais times e mais contextos, e a governança precisou ser ajustada. As mudanças sutis, como fazer os times trabalharem pela unidade maior, pelo senso de entrega de valor para a organização e não só para a sua especialidade, foram o que mais impactou as pessoas.