Introdução

Este livro é um guia de como fazemos desenvolvimento de produto no Basecamp. Também é uma caixa de ferramentas cheia de técnicas que você pode aplicar à sua maneira ao seu próprio processo.

Seja você fundador, CTO, product manager, designer ou desenvolvedor, provavelmente está aqui por causa de alguns desafios comuns que todas as empresas de software têm que enfrentar.

Dores de Crescimento

À medida que as equipes de software começam a crescer, alguns problemas comuns surgem:

Vimos esses desafios em primeira mão no Basecamp à medida que crescemos de quatro para mais de cinquenta pessoas.

O Basecamp começou em 2003 como uma ferramenta que construímos para nós mesmos. Naquela época, éramos uma consultoria que projetava sites para clientes. As informações se perdiam no telefone sem fio entre o cliente, o designer e a pessoa que gerenciava o projeto. Queríamos que o Basecamp fosse um local centralizado onde todas as partes pudessem ver o trabalho, discuti-lo e saber o que fazer a seguir. Descobrimos que muitas empresas tinham esse problema de "informações escorregando pelas frestas". Hoje, milhões de pessoas em todos os tipos de indústrias confiam no Basecamp como sua fonte compartilhada de verdade.

Três de nós construímos a primeira versão. Jason Fried, fundador do Basecamp, liderou o design. Seu cofundador, David Heinemeier Hansson, programou (e criou o conhecido framework web Ruby on Rails como um subproduto). Na época, eu era um designer web com foco em usabilidade e interfaces de usuário. Executei a direção de design do Jason para recursos chave do aplicativo e colaborei com ele nos detalhes do conceito.

Desde os primeiros protótipos em julho de 2003 até o lançamento em fevereiro de 2004, David trabalhou apenas dez horas por semana. Sabíamos que não iríamos a lugar algum com essas dez horas de programação a menos que as usássemos de maneira inteligente. Nosso intenso foco em "martelar" o escopo para se ajustar dentro de um orçamento de tempo determinado nasceu sob essas restrições.

À medida que o negócio crescia, comecei a expandir minhas habilidades. Trabalhar com David e Ruby on Rails tornou o mundo da programação acessível para mim. Aprendi as técnicas que os programadores usam para domar a complexidade: coisas como fatoração, níveis de abstração e separação de preocupações. Com um pé no mundo do design e outro no da programação, perguntei-me se poderíamos aplicar esses princípios de desenvolvimento de software à maneira como projetávamos e gerenciávamos o produto.

O primeiro teste dessa ideia veio em 2009. Até então, havíamos contratado mais alguns programadores e oferecido quatro produtos separados como software-como-serviço. Queríamos agrupar os produtos em uma suíte integrada com login único e faturamento unificado. Foi um enorme esforço técnico com fluxos voltados para usuários cheios de armadilhas. Além de acertar a arquitetura, tínhamos que interromper os clientes em sua jornada do produto e fazê-los mudar seu nome de usuário e senha por razões que não eram fáceis de explicar. Usei os chapéus de designer e gerente de produto no projeto e prototipei as técnicas de breadboarding e mapeamento de escopo descritas neste livro para gerenciar a complexidade.

Tivemos resultados tão bons que decidimos aplicar as mesmas técnicas novamente em 2012, quando redesenhamos o Basecamp do zero para a versão 2.0. Novamente havia uma grande área de superfície para gerenciar e novamente o processo foi surpreendentemente tranquilo.

Até 2015, tínhamos uma equipe central que havia vivido essas experiências e alcançado um ritmo impressionante. Mas encontramos dificuldades para articular o que estávamos fazendo para novatos no time. Nossa equipe de produto havia quadruplicado e todos trabalhavam remotamente. Isso dificultava a transmissão de nossas intuições. Precisávamos de uma linguagem para descrever o que estávamos fazendo e mais estrutura para continuar fazendo isso em nossa nova escala.

Para gerenciar essa nova capacidade, mudamos de durações de projeto ad hoc para ciclos repetidos. (Levou alguma experimentação para encontrar o comprimento de ciclo certo: seis semanas. Mais sobre isso mais tarde.) Formalizamos nossos processos de pitching e aposta. Meu papel mudou novamente, de design e gerenciamento de produto para estratégia de produto. Eu precisava de uma nova linguagem, como a palavra "modelar" (shaping), para descrever o trabalho de design inicial que fazíamos para definir limites e reduzir riscos em projetos antes de comprometê-los às equipes.

Assim como estávamos melhorando na arte de articular a maneira como trabalhamos para nós mesmos, cada vez mais amigos e colegas começaram a nos procurar para perguntar como fazemos isso. Finalmente, Jason me chamou um dia e disse: Acho que você deveria escrever um livro sobre isso.

Este é o resultado. Você pode pensar nisso como dois livros em um. Primeiro, é um livro de verdades básicas. Quero que ele lhe dê uma linguagem melhor para descrever e lidar com os riscos, incertezas e desafios que surgem sempre que você faz desenvolvimento de produto. Em segundo lugar, o livro delineia os processos específicos que estamos usando para fazer progressos significativos em nossos produtos em nossa escala atual.

Aqui está uma breve visão geral das ideias principais do livro.

Ciclos de Seis Semanas

Primeiramente, trabalhamos em ciclos de seis semanas. Seis semanas é tempo suficiente para construir algo significativo do início ao fim e curto o bastante para que todos possam sentir o prazo se aproximando desde o começo, assim eles usam o tempo sabiamente. A maioria de nossas novas features é construída e lançada em um ciclo de seis semanas.

Nossas decisões são baseadas em avançar o produto nas próximas seis semanas, não em microgerenciar o tempo. Não contamos horas nem questionamos como os dias individuais são gastos. Não temos reuniões diárias. Não repensamos nosso roadmap a cada duas semanas. Nosso foco está em um nível mais alto. Dizemos a nós mesmos: “Se este projeto for lançado após seis semanas, ficaremos realmente felizes. Sentiremos que nosso tempo foi bem aproveitado.” Então, comprometemos as seis semanas e deixamos a equipe em paz para concluir o trabalho.

Modelando o Trabalho

Em segundo lugar, modelamos (shape) o trabalho antes de entregá-lo a uma equipe. Um pequeno grupo sênior trabalha em paralelo às equipes do ciclo. Eles definem os elementos-chave de uma solução antes de considerarmos um projeto pronto para se tornar uma aposta. Os projetos são definidos no nível certo de abstração: concretos o suficiente para que as equipes saibam o que fazer, mas abstratos o suficiente para que elas tenham espaço para trabalhar os detalhes interessantes por conta própria.

Ao modelar, focamos menos em estimativas e mais em nosso apetite. Em vez de perguntar quanto tempo levará para fazer um trabalho, perguntamos: Quanto tempo queremos gastar? Quanto vale essa ideia? Esta é a tarefa de modelar: delimitar o problema e desenhar o contorno de uma solução que se encaixe dentro das restrições do nosso apetite.

Tornando as Equipes Responsáveis

Em terceiro lugar, damos total responsabilidade a uma pequena equipe integrada de designers e programadores. Eles definem suas próprias tarefas, fazem ajustes no escopo e trabalham juntos para construir fatias verticais do produto uma de cada vez. Isso é completamente diferente de outras metodologias, onde gerentes dividem o trabalho e os programadores agem como recebedores de tickets.

Juntos, esses conceitos formam um círculo virtuoso. Quando as equipes são mais autônomas, as pessoas sênior podem passar menos tempo gerenciando-as. Com menos tempo gasto em gerenciamento, as pessoas sênior podem moldar melhores projetos. Quando os projetos são melhor moldados, as equipes têm limites mais claros e, assim, podem trabalhar de forma mais autônoma.

Endereçando o Risco

Em cada etapa do processo, focamos em um risco específico: o risco de não entregar no prazo. Este livro não é sobre o risco de construir a coisa errada. Outros livros podem ajudá-lo com isso (recomendamos "Muito além da sorte"). Melhorar seu processo de descoberta deve vir depois de recuperar sua capacidade de entrega. Você pode ter a melhor estratégia do mundo, mas se não puder agir com base nela, de que adianta?

Este livro trata do risco de ficar preso, do risco de se atolarem com o trabalho do trimestre passado, perder tempo com problemas inesperados e não ser livre para fazer o que você quer fazer amanhã.

Reduzimos o risco no processo de modelagem resolvendo questões em aberto antes de comprometer o projeto a um prazo determinado. Não entregamos um projeto a uma equipe que ainda tem armadilhas ou interdependências emaranhadas.

Reduzimos o risco no processo de planejamento limitando nossas apostas a seis semanas. Se um projeto ultrapassa o prazo, por padrão, ele não recebe uma extensão. Esse "disjuntor" garante que não investimos múltiplos do apetite original em um conceito que precisa ser repensado primeiro.

E, por último, reduzimos o risco no processo de construção integrando design e programação desde cedo. Em vez de construir muitas partes desconectadas e esperar que elas se encaixem na última hora, construímos uma peça significativa do trabalho de ponta a ponta desde o início e depois repetimos. A equipe sequencia o trabalho do mais desconhecido para os pedaços menos preocupantes e aprende o que funciona e o que não funciona integrando o mais rápido possível.

Como Este Livro é Organizado

A Parte Um é toda sobre Modelagem (Shaping) — o pré-trabalho que fazemos nos projetos antes de considerá-los prontos para serem agendados. Cada capítulo explica uma etapa específica do processo, desde definir o apetite por uma ideia bruta, esboçar uma solução, até escrever uma proposta que apresenta o projeto potencial. Ao longo do caminho, você aprenderá técnicas específicas — como o breadboarding e o esboço com marcador grosso — para manter o design no nível certo de abstração.

A Parte Dois é sobre Apostas — como escolhemos entre os projetos apresentados e decidimos o que fazer a cada seis semanas.

A Parte Três é sobre Construção — as expectativas que colocamos nas equipes e as práticas especiais que elas usam para descobrir o que fazer. Vamos ver como as equipes descobrem o que fazer, como integram design e programação, como mapeiam o que é conhecido versus desconhecido e, finalmente, como tomam decisões difíceis para terminar o projeto no tempo.

Por último, o Apêndice oferece ajuda para quando chegar a hora de fazer mudanças na sua empresa. Há alguns conselhos sobre como tentar seu primeiro experimento de seis semanas, dicas para ajustar os métodos ao tamanho da sua empresa e orientações específicas sobre como implementar o Shape Up usando o Basecamp.