O Aurora Stay* nasceu como a evolução tecnológica de um dos grupos hoteleiros mais exclusivos da América Latina, unindo o charme de um hotel boutique a uma experiência digital altamente personalizada. Pensado para hóspedes que valorizam design, conforto e autonomia, o projeto exigia soluções digitais à altura.
Nosso desafio na Thoughtworks era claro: transformar essa visão em entregas reais dentro das condições definidas para o projeto. Para isso, adotamos uma abordagem ágil, estruturando o trabalho para manter um fluxo contínuo de entregas e gerar valor para a cliente.
Neste artigo, compartilho os bastidores e os aprendizados dessa jornada, mostrando como decisões sobre estrutura de times, divisão de responsabilidades e planejamento tornaram isso possível.
O início complexo e a virada do projeto
Transformar a visão do Aurora Stay em entregas reais não foi um caminho linear.
É natural: todo time que começa a trabalhar junto, ou passa por uma grande reformulação, atravessa uma fase de atrito antes de encontrar seu ritmo. A literatura chama isso de storming, e o nosso projeto não foi exceção.
Para superar essa fase, tivemos que mudar a nossa forma de trabalhar. Do lado do Aurora Stay, a cliente passou a contar com pessoas de produto e tecnologia dedicadas a acompanhar o projeto de perto e traduzir sua evolução para o corpo diretivo.
Do lado da Thoughtworks, reorganizamos os times e assumimos o compromisso de entregar uma visão mais completa da experiência e do andamento do projeto, com marcos claros. Dessa reorganização, identificamos três necessidades:
Revisar a evolução do produto e o plano de entrega;
Dividir os times por frentes de valor/contexto;
Dar mais visibilidade à entrega das funcionalidades ao longo do tempo.
A seguir, exploramos como cada uma funcionou na prática.
1. Evolução do produto e plano de entrega
Em projetos de escopo fechado, tempo e custo costumam ser definidos de antemão. No Aurora Stay, o desafio era trabalhar de forma ágil dentro dessas restrições.
Para atingir essa agilidade, mantivemos os prazos acordados, mas mudamos a forma de organizar as entregas. Em vez de deixar o software inteiro para o final, transformamos as grandes entregas em “épicos” e fatiamos as funcionalidades em etapas menores, capazes de gerar valor desde o início.
Esse formato permitiu usar o produto em funcionamento para validar e ajustar regras de negócio que ainda não estavam previstas no início. Também abriu espaço para repriorizar o escopo: alguns itens inicialmente considerados essenciais perderam relevância ao longo do projeto e foram direcionados para o backlog.
Com os grandes blocos definidos, criamos um mapa visual de tudo o que precisava ser entregue nos meses seguintes. Chamamos esse mapa de “roadmap” porque o termo facilitava a comunicação dentro do time e com a cliente, embora sua estrutura não seguisse o modelo tradicional de um roadmap orientado a objetivos por período.
2. Divisão dos times por frentes de valor
Depois de mapear as entregas, o próximo passo era definir como as pessoas trabalhariam em torno delas. Agrupamos as funcionalidades em contextos comuns, que chamamos de frentes de valor, e, com base em conceitos de domain-driven design (DDD), estruturamos os times em torno de domínios específicos do negócio.
Com as frentes definidas, distribuímos as pessoas de acordo com sua senioridade e afinidade com cada contexto. A estrutura final ficou assim:
Dois times alinhados à frente de valor:
Time 1: Foco na parte financeira e de vendas.
Time 2: Foco na hospitalidade e contas de hóspedes.
Infraestrutura: atua conforme a demanda dos dois times de valor; backlog próprio, priorizado em conjunto com os times de desenvolvimento.
Design: atua de forma colaborativa na execução do backlog dos times, com seu próprio backlog integrado às frentes de valor.
Integrações com parceiros: entende, requisita, facilita e antecipa integrações e possíveis bloqueios com os parceiros do Aurora Stay.
Essa divisão reduziu a carga cognitiva das pessoas, aumentou a autonomia e permitiu entregas fim a fim. Os times passaram a entregar uma funcionalidade mínima viável (MVF) a cada iteração, sem depender de outras frentes para fechar o ciclo, resolvendo itens contratuais enquanto o produto evoluía e gerava valor contínuo para a cliente.
3. Visão da entrega das funcionalidades ao longo do tempo
Para dar visibilidade ao andamento do projeto, utilizamos uma estrutura visual de “colmeias” que mostrava o que já havia sido entregue, o que estava em desenvolvimento e o que ainda precisava ser feito.
Essa visão orientava as reuniões de alinhamento. Além de mostrar o progresso geral, permitia concentrar o planejamento no mês em curso e antecipar preocupações, riscos e possíveis gargalos. O mapa compartilhado deu ao time e à cliente uma visão comum do progresso e apoiou a tomada de decisões com base em dados reais.
A percepção do time: ganhos e aprendizados
Perto do fim do engajamento, enviamos um formulário para avaliar a percepção do time sobre o trabalho realizado, a visão do produto e a estrutura de trabalho adotada. Aqui estão alguns dos resultados:
Clareza e alinhamento de visão
Os resultados apontaram para um alto nível de alinhamento: 100% das pessoas disseram ter uma visão “clara” ou “muito clara” do produto e avaliaram que seus colegas também estavam alinhados.
Além disso, cerca de 88% relataram ter uma compreensão boa ou ótima das prioridades do projeto, enquanto todas as pessoas indicaram que o contexto da conta era compartilhado de forma frequente ou contínua.
Os dados sugerem que a divisão dos times por contexto, combinada à transparência da liderança nas decisões, contribuiu para criar uma compreensão compartilhada sobre o que estava sendo construído e por quê.
A eficiência da estrutura de times
A divisão por frentes de valor também foi bem avaliada: aproximadamente 88% das pessoas consideraram a estrutura eficiente ou muito eficiente. Entre os principais ganhos percebidos estavam a redução da carga cognitiva e o maior foco em objetivos específicos.
Apesar do sucesso da reestruturação, os feedbacks nos trouxeram lições importantes de melhoria contínua:
O momento da virada: a primeira metade do projeto foi percebida como confusa, com regras de negócio pouco claras. A divisão por domínios poderia ter sido implementada desde o início do engajamento.
Distribuição de carga: um dos times concentrou muitas responsabilidades, indicando que uma subdivisão poderia ter distribuído melhor a carga de trabalho e de liderança.
Equilíbrio de perfis: momentos de desequilíbrio entre demanda e capacidade geraram sobrecarga. Uma alocação com mais pessoas desenvolvedoras backend poderia ter evitado esses picos.
De forma geral, o time demonstrou satisfação com a colaboração entre design, produto e desenvolvimento ao longo do projeto.
Conclusão
A jornada com o Aurora Stay reforçou que, mesmo em cenários de alta complexidade, é possível entregar valor continuamente com times bem estruturados.
Um dos principais aprendizados foi que entregas incrementais não servem apenas para “bater marcos”, mas para identificar e corrigir desalinhamentos cedo. Para que isso funcione, é preciso respeitar a carga cognitiva das pessoas, definir responsabilidades com clareza e organizar o trabalho em torno dos domínios do produto.
No fim, foi essa combinação de estrutura, clareza e ciclos curtos de entrega que permitiu ao projeto ganhar ritmo e alcançar seus objetivos.
*Aurora Stay é um nome fictício que foi usado para preservar os termos de NDA com a cliente.
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.