Minha Leitura do Shape Up

2026-07-29

An English version of this article is also available.

Intro

Sempre tive uma grande admiração e interesse pelo Basecamp, principalmente pelo trabalho e pela visão de produto do Jason Fried. Recentemente, resolvi focar esse interesse no estudo do Shape Up, o jeito como a empresa constrói seus produtos.

Após ler o livro^[1] e ouvir alguns podcasts com o Ryan Singer (autor do livro), decidi me dar o desafio de trazer a minha interpretação e o meu resumo do método.

Foi uma tarefa mais difícil do que imaginava. O Shape Up não é facilmente resumido em uma frase de efeito, mas é o resultado do que eu enxergo como várias premissas saudáveis de um time muito eficiente e opinativo sobre como quer trabalhar.

Apesar de um pouco difícil, escrever esse texto foi muito rico pra mim. Me forçou a realmente interpretar e absorver os principais conceitos e ideais do livro, em vez de só repetir seus rituais propostos.

O resultado, aproximadamente 2 mil palavras, não foi escrito de forma fluida e direta. Tive muitos começos em falso e várias outras palavras jogadas fora até conseguir encontrar minha maneira de expor essa metodologia.

Vale destacar que ainda não tive a oportunidade de aplicá-la na prática. Mas percebi que alguns dos seus conceitos (como apetite e uma boa modelagem) já começaram a aparecer no meu dia a dia de trabalho. No final, também faço uma reflexão sobre como seria a aplicação do Shape Up numa equipe muito reduzida e embrionária, um desafio que enfrento hoje no trabalho.

O que é Shape Up?

Shape Up é uma metodologia de produto criada pelo Ryan Singer no Basecamp. É uma forma de trabalho focada na construção de produtos por times pequenos.

O princípio central dessa metodologia é a diferenciação de dois momentos: Modelagem (Shaping) e Construção (Building).

A Modelagem é o momento de olhar pra fora. O objetivo é explorar as demandas e a situação para selecionar os problemas que serão atacados. A modelagem dá forma e escopo aos problemas e possíveis soluções.

O entregável dessa fase é um documento chamado de Modelo de Projeto (Pitch/Package), que contém tudo de que um time precisa para construir a solução proposta.

Essa etapa não se resume só a descrever uma ideia de solução isoladamente. Também não se limita a ser uma exploração conceitual sem “mão na massa”. É o momento de montar um projeto coerente e validado para ser construído dentro de um tempo determinado. Isso inclui conversas com outras áreas, validações de viabilidade técnica e operacional, análise de dados de uso, aprovação dos stakeholders e o que for preciso.

Por isso, são essenciais a participação e a colaboração de Produto, Design e Tecnologia nessa etapa para avaliar e validar os Projetos propostos. É durante a modelagem, não durante a construção, que a viabilidade técnica, as armadilhas e as diferentes alternativas de solução devem ser discutidas e exploradas.

Essa é uma fase síncrona e solta, com muitas conversas, sessões de colaboração e rascunhos ágeis. Deve-se evitar formalizar muito e criar documentos que engessem o pensamento.

É essencial que, nesse período de modelagem, seja discutido e combinado o apetite para o projeto: quanto a companhia quer investir nesse problema?

Se os recursos fossem infinitos, tudo (ou quase tudo) seria desejável, e os escopos tenderiam ao infinito. Mas, no mundo real, os projetos só fazem sentido se forem entregues em determinado tempo. Isso significa que a pergunta do prazo vem antes do escopo.

Afinal, o apetite expressa quanto a organização está disposta a investir naquela iniciativa e se traduz em um prazo. Na maior parte das vezes, é o problema que guia o apetite, não a solução.

Em vez de perguntar “quanto tempo essa tarefa levará para ser feita?” e fazer estimativas usando planning poker, durante a modelagem nós definimos: “Para esse problema, estamos dispostos a investir 6 semanas de trabalho, então qual solução cabe nesse prazo? Existe uma solução de 2 semanas?”

Cada projeto recebe um prazo fixo, que não é estendido. No final do ciclo de construção, o projeto é encerrado e outro é priorizado. Essa seriedade com o prazo faz os times tomarem decisões difíceis durante a implementação e serem eficientes nas suas escolhas.

No mundo real, simplesmente cancelar um projeto é uma medida muito brusca e inviável na maioria das situações. Quando há uma falha na construção e o projeto não é concluído dentro do prazo, o assunto normalmente volta para a etapa de Modelagem. Em vez de estender seu prazo por padrão e criar um buraco negro que suga tempo e recursos, volta-se a debater e explorar o que faltou para uma entrega bem-sucedida.

É por isso que o Modelo de Projeto não apresenta a solução final definida, mas sim seu formato geral: o que é necessário, quais exigências são indiscutíveis e como a solução se encaixa no todo. Os detalhes da solução serão definidos durante a construção, porque só durante a execução é possível escavar e descobrir todas as pequenas realidades e cantos do produto.

A única exigência de um bom Modelo de Projeto é que contenha tudo de que o time precisa para construir a solução proposta. Mas, normalmente, bons Modelos apresentam:

O problema e por que ele importa
O apetite e o prazo de entrega
A solução, no nível certo de detalhes
Armadilhas que foram mapeadas
O que está fora do escopo

O nível certo de detalhes da solução é uma questão complexa e que depende da situação. Mais arte que ciência. Às vezes, a solução precisará ser muito específica e deixar pouco espaço pra manobra. Outras vezes, os detalhes importam menos, mas o objetivo principal está claro.

Em geral, nós queremos um Modelo de Projeto com um desenho de solução em alto nível. Todos os componentes essenciais foram validados e são viáveis; está claro qual é a silhueta da solução e quais são os requisitos inegociáveis. A forma final e os detalhes serão de responsabilidade da equipe durante a construção, pois confiamos na capacidade do time para entender o problema e tomar as melhores decisões e tradeoffs para entregar o projeto no prazo.

Repare que, durante a Modelagem, não é feita a divisão do projeto em tarefas individuais ou tickets. Isso é responsabilidade da equipe durante a Construção.

Se durante a Modelagem se olha para fora, durante a Construção o foco é pra dentro. Durante essa fase, o time recebe um Projeto claro e bem definido e tem o objetivo de executar a visão. Nessa fase, o trabalho é mais assíncrono e os integrantes do time têm longos períodos sem interrupções.

Eu gosto de pensar nesses dois momentos como uma construção em um terreno físico. Durante a Modelagem, nós definimos o limite externo do território e como o Projeto irá se relacionar com os vizinhos. Durante a Construção, o time já tem os limites definidos e algumas regras de convivência, mas tem liberdade de construir o interior da melhor maneira que julgar possível, com o objetivo de resolver o Problema selecionado dentro do apetite (prazo) definido.

Isso, obviamente, não significa que, durante a Construção, o time pode entregar o que quiser, cortar escopo sem embasamento ou se contentar com baixa qualidade. Afinal, o objetivo, as regras e a forma geral estão definidas. O Shape Up confia no time e lhe dá autonomia, partindo do princípio de que, com essas informações, seus integrantes farão o melhor trabalho dentro das limitações e entregarão o Projeto no prazo, mesmo que precisem enfrentar tradeoffs difíceis durante o processo.

A principal regra da trilha de Construção é: o projeto só é considerado entregue depois de concluído e colocado em produção. Há sugestões de trabalho e organização dessa fase, mas cada time terá seu ritmo e sua forma preferida de trabalhar para entregar a missão dada. E, se a modelagem foi bem feita, o time terá todas as peças necessárias para fazer um bom trabalho.

Durante a Construção, o time deve ter a autonomia para levar o projeto de início ao fim, sem depender de fatores externos. Dúvidas, ajuda e validações pontuais são aceitas, mas, se o time precisa validar um conceito importante ou fica travado por uma demanda de outro time, há uma falha no processo.

Tarefas acessórias, como atualizar documentação ou materiais de treinamento, podem ser feitas durante os períodos entre-ciclos.

Diferentemente do Scrum, que funciona à base de tickets e tarefas, com sprints curtos (normalmente de 2 semanas) e diversas reuniões de planning, retrospectivas e dailies, o Shape Up trabalha com ciclos mais longos e períodos entre-ciclos de reajuste.

No Basecamp, as equipes trabalham com ciclos-padrão de 6 semanas e períodos entre-ciclos de 2 semanas. Os projetos podem ser grandes e ocupar as 6 semanas inteiras (mas nunca mais de 6 semanas) ou menores, com vários projetos alocados no mesmo ciclo.

Durante os ciclos de construção, o time trabalha exclusivamente no projeto alocado, não podendo desviar sua atenção para outros assuntos. Nos períodos entre-ciclos, o time não tem nenhum projeto alocado e pode trabalhar em assuntos pontuais e dar atenção a outras coisas.

É um bom momento de amarrar pontas soltas, realizar tarefas ou atender a pedidos pontuais e se preparar para o próximo ciclo de foco.

No Basecamp, a Modelagem e a Construção são conduzidas em duas trilhas paralelas por pessoas diferentes. Enquanto um time está no ciclo de construção, a liderança estratégica está trabalhando na Modelagem dos próximos Projetos.

Uma diferença marcante entre o Scrum (e outras metodologias similares) e o Shape Up é a distribuição dos tipos de trabalho ao longo do tempo. Enquanto no Scrum o time planeja e executa ao mesmo tempo, participando de vários rituais recorrentes em tiros curtos, o Shape Up separa esses dois momentos. Durante a Modelagem, há várias reuniões, conversas, “vaivém” de trabalho e menos períodos de foco ininterruptos. É normal também que sejam feitos estudos, análises ou protótipos (códigos de prova de conceito que serão descartados).

Após a definição do Projeto e a passagem de bastão para a Construção, o trabalho fica muito mais assíncrono, com longos períodos de foco ininterrupto e poucas interações com outros times.

Quando não usar Shape Up

O Shape Up se baseia em projetos e em um período claro de Modelagem. É um bom encaixe para trabalhos proativos.

Quando o trabalho é reativo ou depende de sincronia e de execução conjunta com outro time (ou cliente), é melhor usar um método tradicional baseado em tickets/tarefas.

Por exemplo: trabalho de suporte, plantão de correção de bugs críticos ou implementação com clientes. Nesses casos, não há tempo nem clareza suficientes para Modelar o problema e a solução.

Produtos muito embrionários e exploratórios também não me parecem os mais adequados para essa metodologia. Apesar de o Basecamp usar uma versão adaptada, eu tentaria aplicar só a ideologia e os conceitos por trás do Shape Up, mas sem me preocupar com o processo formal ainda.

Adaptações para um time pequeno

Com uma equipe bem reduzida (2 ou 3 pessoas), provavelmente não faria sentido implementar duas trilhas independentes de Modelagem e Construção. Logo, também não acho que a duração fixa dos ciclos de 6 semanas faça sentido.

Provavelmente vamos alternar as mesmas pessoas entre as duas fases. Então, a tendência é que tenhamos ciclos e entre-ciclos com duração variável.

Primeiro, exploramos uma situação e Modelamos o projeto, sem um prazo fixo para essa fase e com o objetivo de fechar um bom Modelo. Nessa fase, não estamos preocupados em construir e executar.

Quando conseguimos fechar e aprovar um Modelo, mudamos o modo de trabalho para a Construção. Nessa fase, dedicamos nosso tempo exclusivamente ao Projeto alocado: “abaixamos a cabeça” e “olhamos pra dentro”. O objetivo é entregar o combinado dentro do prazo.

Após o fim do ciclo, voltamos para o período entre-ciclos e iniciamos assim que possível a modelagem do próximo projeto.

Como somos a totalidade da área, ficar alocados de forma exclusiva em um único Projeto por diversas semanas pode não ser viável. Nesse caso, podemos eleger um dia da semana como “fora do ciclo” e usar exclusivamente esse dia para assuntos fora do Projeto.

Exemplo: podemos abrir a sexta-feira para conversas e tarefas que vierem de outros times, recusando (o máximo que for possível) assuntos fora do nosso foco nos outros dias da semana.

Nesse caso, mais do que seguir os processos, acho que o maior valor está nos conceitos: tentar modelar e validar um bom projeto antes de partir para a construção, deixar claro o apetite e evitar cair na armadilha de criar projetos com escopo infinito.

Resumo e principais termos

Modelagem

Momento de “olhar pra fora”. Contém bastante exploração e colaboração com outros times. Trabalho mais síncrono e com longas sessões de colaboração e ideação. O objetivo é selecionar e dar clareza a um problema, entender qual é o apetite para esse assunto e propor e validar uma solução.

Construção

Momento de foco do ciclo. Ritmo de trabalho mais assíncrono e de convergência. O objetivo é concretizar o Modelo do Projeto e entregar a funcionalidade em produção.

É importante que o time não faça a Modelagem e a Construção ao mesmo tempo. Podem ocorrer em paralelo, mas por pessoas diferentes.

Apetite

O quanto a companhia está disposta a investir num problema/situação. Essa disposição se traduz no prazo que irá guiar o que é possível fazer num projeto. É o apetite que guia o escopo, não o escopo que define o prazo. Com um apetite claro, o time tem liberdade e autonomia, mas é forçado a fazer escolhas difíceis que garantem a entrega dentro do tempo esperado, evitando atrasos, entregas imprevisíveis e projetos sem fim.

Entre-ciclos

É o momento de sair do foco exclusivo do projeto. O time tem a liberdade de olhar para outras frentes e trabalhar em assuntos que não foram modelados, sem precisar justificar o esforço com burocracia ou formalidades.

É um momento de respiro, de amarrar as pontas soltas e de se preparar para a execução do próximo ciclo.

Conteúdo extra

Disponível de graça e online em inglês ou como um ebook na Amazon em português. Eu li o livro em inglês e tomei a liberdade de fazer a minha própria tradução e as minhas próprias adaptações dos termos originais. ↩