Open Prefácio por Jason Fried

Prefácio por Jason Fried

A maneira como uma equipe trabalha tem uma influência enorme no que ela pode realizar. O processo, os métodos, as práticas, a abordagem, a disciplina, a confiança, o estilo de comunicação, o ritmo. O modo como — o jeito que as coisas são feitas — é fundamental e essencial.

Você frequentemente ouve as pessoas dizerem que "a execução é tudo", mas isso não é bem verdade. Na verdade, muitas vezes é bem errado.

Quando se trata de trabalho em projetos, e especificamente desenvolvimento de software, executar algo de maneira errada pode destruir a moral, desgastar equipes, corroer a confiança, travar engrenagens e arruinar a máquina do progresso de longo prazo. Então, sim, está "feito", mas a que custo? Ao fazer, o que fizemos conosco? Realmente temos que fazer isso novamente, repetidamente mês após mês, ano após ano?

Quantos projetos você participou que gostaria de fazer novamente? Quantos projetos se prolongaram, acumularam-se no final e esgotaram as pessoas? Quant

Open Agradecimentos

Agradecimentos

Jason Fried e David Heinemeier Hansson, fundadores do Basecamp, plantaram muitas das sementes para este livro. Ele é baseado nos valores deles, pela cultura do Basecamp e por quinze anos de tentativas e erros colaborativos.

Bob Moesta e Chris Spiek fizeram contribuições fundamentais. Este livro não teria sido concluído sem a ajuda deles.

As palestras de Yaneer Bar-Yam no New England Complex Systems Institute ajudaram-me a estruturar o método.

Os experientes designers e programadores do Basecamp testaram, experimentaram e aperfeiçoaram essas técnicas ao longo dos anos para entregar projetos reais. O esforço deles torna este um livro de prática, não de teoria.

Open Introdução

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:

• Os membros da equipe sentem que os projetos se arrastam indefinidamente, sem fim à vista.
• Os gerentes de produto não conseguem encontrar tempo para pensar estrategicamente sobre o produto.
• Os fundadores se perguntam: "Por que não conseguimos lançar recursos como fazíamos antigamente?"

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, éram

Open Princípios da Modelagem

Princípios da Modelagem

Quando modelamos o trabalho, precisamos fazê-lo no nível certo de abstração: nem muito vago e nem muito concreto. Os gerentes de produto frequentemente erram em um desses dois extremos.

Wireframes São Muito Concretos

Quando líderes de design vão direto para wireframes ou mockups de alta fidelidade, eles definem muitos detalhes muito cedo. Isso não deixa espaço para a criatividade dos designers. Um amigo colocou desta forma:

Eu dou um wireframe para meu designer e então digo a ele: "Eu sei que você está olhando para isso, mas não é isso que eu quero que você desenhe. Quero que você repense!" É difícil fazer isso quando você está entregando algo tão concreto.

Especificar demais o design também leva a erros de estimativa. Por mais contraintuitivo que pareça, quanto mais específico o trabalho, mais difícil pode ser estimar. Isso porque fazer a interface exatamente como deve ser po

Open Estabelecendo Limites

Estabelecendo Limites

O primeiro passo para modelar é estabelecer limites sobre o que estamos tentando fazer. As conversas que temos serão completamente diferentes se as pessoas pensarem que estamos falando sobre uma pequena melhoria ou um redesign completo.

A conversa sobre a criação de um recurso sempre começa com uma ideia inicial, como "os clientes estão pedindo notificações em grupo." Antes de todos nós mergulharmos fundo discutindo maneiras de resolver isso, devemos primeiro estabelecer alguns termos amplos na discussão para torná-la produtiva.

Definindo o Apetite

Às vezes, uma ideia nos empolga imediatamente. Nesse caso, precisamos moderar a empolgação verificando se realmente poderemos investir tempo nela ou não. Se não pararmos para pensar sobre o valor da ideia, todos podemos nos precipitar muito rapidamente, seja comprometendo recursos ou tendo longas discussões sobre soluções poten

Open Encontrando os Elementos

Encontrando os Elementos

Agora que temos as restrições de um apetite e o problema que estamos resolvendo, é hora de passar de uma ideia em palavras para os elementos de uma solução de software. Podem existir dezenas de maneiras diferentes de abordar a solução para um problema. Portanto, é importante que possamos nos mover rapidamente e explorar muitas ideias diferentes sem sermos arrastados.

Mova-se na Velocidade Certa

Duas coisas nos permitem avançar na velocidade certa nesta etapa.

Primeiro, precisamos ter as pessoas certas — ou ninguém — na sala. Ou estamos trabalhando sozinhos ou com um parceiro de confiança que possa acompanhar nosso ritmo. Alguém com quem possamos conversar de maneira abreviada, que tenha o mesmo conhecimento prévio, e com quem possamos ser francos enquanto pulamos entre as ideias.

Segundo, precisamos evitar o nível errado de detalhe nos desenhos e esboços. Se começar

Open Riscos e Armadilhas

Riscos e Armadilhas

Lembre-se de que estamos estruturando o trabalho para um período de tempo fixo. Podemos confiar na nossa experiência de que os elementos que detalhamos no capítulo anterior são realizáveis dentro do prazo (seis semanas). Mas precisamos olhar mais de perto, porque basta um ponto fraco no conceito para descarrilar tudo. Suponha que apostemos no projeto e uma equipe o assuma. Se eles encontrarem um problema inesperado que leve duas semanas para resolver, terão queimado um terço do orçamento!

Ainda pior, às vezes você encontra problemas que não apenas atrasam o projeto — eles parecem não ter solução. Uma vez apostamos em um projeto para redesenhar a forma como apresentamos projetos aos clientes na tela inicial do Basecamp. Assumimos que o designer resolveria isso; não fizemos o trabalho na fase de planejamento para validar se uma abordagem viável existia. Quando o projeto começou, descobrimo

Open Escreva o Pitch

Escreva o Pitch

Agora temos os elementos de uma solução e mitigamos os riscos do nosso conceito ao ponto de estarmos confiantes de que é uma boa opção para entregar a uma equipe. Mas o conceito ainda está em nossas cabeças ou em alguns desenhos difíceis de decifrar no quadro branco ou no nosso caderno. Agora precisamos colocar o conceito em uma forma que outras pessoas possam entender, digerir e responder.

É aqui que dizemos “Ok, isso está pronto para ser redigido como um pitch”. Neste capítulo, vamos passar pelos ingredientes de um pitch e mostrar alguns exemplos completos de projetos reais no Basecamp.

O propósito do pitch é apresentar uma boa aposta potencial. É basicamente uma apresentação. Os ingredientes são todas as coisas que precisamos para capturar o trabalho feito até agora e apresentá-lo de uma forma que permita às pessoas que priorizam os projetos fazer uma aposta informada.

Existem cinco ingredi

Open Apostas, Não Backlogs

Apostas, Não Backlogs

Agora que escrevemos um Pitch, para onde ele vai? Ele não vai para um backlog.

Sem Backlogs

Backlogs são um peso grande que não precisamos carregar. Dezenas e eventualmente centenas de tarefas se acumulam, que todos sabemos que nunca teremos tempo para fazer. A pilha crescente nos dá a sensação de que estamos sempre atrasados, mesmo que não estejamos. Só porque alguém achou que uma ideia era importante há um trimestre, não significa que precisamos continuar olhando para ela repetidamente.

Backlogs também são grandes desperdiçadores de tempo. O tempo gasto constantemente revisando, organizando e mantendo ideias antigas impede todos de avançarem nos projetos oportunos que realmente importam agora.

Algumas Apostas Potenciais

Então, o que fazemos em vez disso? Antes de cada ciclo de seis semanas, realizamos uma mesa de apostas onde os stakeholders decidem o que fazer no p

Open A Mesa de Apostas

A Mesa de Apostas

Agora que temos algumas boas apostas potenciais na forma de pitches, é hora de tomar decisões sobre quais projetos agendar.

Ciclos de Seis Semanas

Comprometer tempo e pessoas é difícil se não conseguirmos determinar facilmente quem está disponível e por quanto tempo. Quando as pessoas estão disponíveis em diferentes momentos devido a projetos sobrepostos, o planejamento de projetos se transforma em um jogo frustrante de Tetris no calendário. Trabalhar em ciclos simplifica drasticamente esse problema. Um ciclo nos dá um tamanho padrão de projeto tanto para modelar quanto para agendar.

Algumas empresas usam ciclos de duas semanas (também conhecidos como “sprints”). Aprendemos que duas semanas são muito curtas para realizar algo significativo. Pior do que isso, ciclos de duas semanas são extremamente custosos devido ao overhead de planejamento. A quantidade de trabalho que se consegue em du

Open Faça Suas Apostas

Faça Suas Apostas

Observe Onde Você Está

Dependendo de estarmos melhorando um produto existente ou construindo um novo produto, vamos definir expectativas diferentes sobre o que acontece durante o ciclo de seis semanas.

Isso nos convida a refletir sobre onde estamos no arco do desenvolvimento do nosso produto e apostar de acordo.

Produtos Existentes

Quando adicionamos recursos a um produto existente, seguimos o processo padrão do Shape Up: modelamos o trabalho, apostamos nele e o entregamos a uma equipe para construir. Esperamos que a equipe termine e entregue alguma versão do trabalho modelado até o final do ciclo.

Em um produto existente, todo o código e design existentes que não vão mudar definem um tipo de espaço vazio no qual o novo recurso se encaixará. Modelar e construir é como criar uma peça de mobília para uma casa que já está construída.

Novos Produtos

Novos produtos são diferentes. Enquanto adicionar a um produto existente é como comprar um sofá para uma sa

Open Responsabilidade do Repasse de Trabalho

Responsabilidade do Repasse de Trabalho

Fizemos nossas apostas e agora é hora de começar o próximo ciclo. Como o time começa?

Atribua Projetos, Não Tarefas

Nós não começamos atribuindo tarefas a ninguém. Ninguém desempenha o papel de "encarregado das tarefas" ou "arquiteto" que divide o projeto em partes para outras pessoas executarem.

Dividir o projeto em tarefas logo no início é como passar o pitch por um triturador de papel. Todos recebem apenas pedaços desconectados. Queremos que o projeto permaneça “inteiro” durante todo o processo para que nunca percamos de vista o panorama geral.

Em vez disso, confiamos na equipe para assumir o projeto inteiro e trabalhar dentro dos limites do pitch. A equipe vai definir suas próprias tarefas e sua própria abordagem para o trabalho. Eles terão total autonomia e usarão seu julgamento para executar o pitch da melhor maneira possível.

As equipes adoram receb

Open Conclua Uma Parte

Conclua Uma Parte

Conforme a equipe se orienta, eles começam a descobrir e acompanhar as tarefas que precisam realizar para construir o projeto. É importante, nessa fase inicial, que eles não criem um plano mestre de partes que devem se unir na última hora. Se a equipe completar muitas tarefas, mas não houver "uma coisa" para clicar e testar, é difícil sentir progresso. Uma equipe pode fazer muito trabalho, mas sentir insegurança porque ainda não tem nada concreto para mostrar. Muitas coisas estão feitas, mas nada está realmente concluído.

Em vez disso, eles devem tentar fazer algo tangível e demonstrável logo no início — na primeira semana ou algo assim. Isso exige a integração vertical de uma pequena parte do projeto, em vez de ir trabalhando nas camadas horizontais.

Integre uma Fatia

Podemos pensar nos projetos em duas camadas: front-end e back-end, design e código. Embora tecnicamente falando exis

Open Mapeando Escopos

Mapeando Escopos

No capítulo anterior, começamos o projeto finalizando uma fatia integrada logo no início. Essa prática faz parte de uma técnica mais geral que a equipe pode usar ao longo do projeto.

Organize por Estrutura, Não por Pessoa

Quando solicitadas a organizar tarefas para um projeto, as pessoas muitas vezes separam o trabalho por pessoa ou função: elas criam uma lista para Designers e uma lista para Programadores. Isso leva ao problema que discutimos no capítulo anterior — as pessoas completarão tarefas, mas as tarefas não se somarão a uma parte concluída do projeto cedo o suficiente.

Para dar um exemplo fora do contexto de software, considere alguém organizando um evento de arrecadação de fundos. Eles poderiam criar uma lista de tarefas para cada um dos seus três voluntários e acompanhar o trabalho dessa forma. Mas então não haveria como ver a visão geral de como o evento está se saindo — o que está feito e o

Open Mostre Progresso

Mostre Progresso

Gerentes bem-intencionados não gostam de pedir atualizações de status. É constrangedor, parece chato e fica ainda pior quando precisam fazer perguntas adicionais para entender claramente o que está acontecendo.

Os gerentes prefeririam poder ver o status eles mesmos sempre que precisassem. Vimos no último capítulo como organizar as tarefas em escopos ajuda a equipe a manter o controle do trabalho. Mas isso não ajuda diretamente o gerente. Existem alguns problemas com as tarefas que as tornam insuficientes para avaliar o status.

As Tarefas que Não Estão Lá

Considere uma lista com alguns itens concluídos e nenhum item incompleto restante. Isso pode significar que todo o trabalho está concluído. Mas também pode significar que a equipe sabe que há mais trabalho a ser feito, mas ainda não definiu as tarefas.

Às vezes, uma equipe define um escopo no início do projeto sem preenchê-lo com t

Open Decida Quando Parar

Decida Quando Parar

Quando o fim do ciclo se aproxima, as técnicas que cobrimos até agora colocarão a equipe em uma boa posição para finalizar e entregar. O trabalho modelado deu a eles diretrizes para evitar que se perdessem. Eles integraram um escopo de cada vez, de modo que não há trabalho pela metade espalhado por aí. E todos os problemas mais importantes foram resolvidos, porque priorizaram essas incógnitas primeiro ao sequenciar o trabalho.

Ainda assim, sempre há mais trabalho do que tempo. Entregar no prazo significa entregar algo imperfeito. Sempre há um certo desconforto ao olhar para seu trabalho e se perguntar: Está bom o suficiente? Está pronto para ser lançado?

Compare com a Linha de Base

Designers e programadores sempre querem fazer o melhor trabalho. Não importa se o botão está no centro da página de entrada ou duas páginas abaixo, em uma tela de configurações, o designer dará a ele sua melhor aten

Open Siga Em Frente

Siga Em Frente

Deixe a Tempestade Passar

A entrega de um recurso pode gerar trabalho novo se você não for cuidadoso. Lançamentos de funcionalidades geram solicitações de novas funcionalidades. Os clientes dizem: "Ok, isso é ótimo, mas e aquela outra coisa que estamos pedindo?" Bugs aparecem. Sugestões de melhorias chegam. Todos estão focados na novidade e reagindo a ela.

O feedback pode ser especialmente intenso se o recurso que você lançou mudar fluxos de trabalho existentes. Mesmo mudanças puramente visuais às vezes geram forte resistência. Uma pequena minoria de clientes pode reagir exageradamente e dizer coisas como "Você estragou tudo! Mude de volta!"

É importante manter a calma e evitar reações impulsivas. Dê alguns dias e permita que a situação se acalme. Seja firme e lembre-se do porquê você fez a mudança em primeiro lugar e quem a mudança está ajudando.

Mantenha-se Livre de Dívidas

Pode ser tentador se comprometer a fazer mudanças em resposta ao feedback, mas assim você n

Open Conclusão

Conclusão

Conceitos Chave

O método Shape Up apresentado neste livro é intimamente entrelaçado. Pode ser necessário algum pensamento e experimentação para extrair as peças certas e adaptá-las à sua equipe.

Se sua equipe pode adotar o método de uma vez ou não, espero que a linguagem e os conceitos deste livro tenham lhe dado algumas ideias para aplicar imediatamente:

• Trabalho modelado versus trabalho não modelado (Shaped)
• Definir apetite em vez de estimativas
• Projetar no nível certo de abstração
• Conceituar com breadboards e esboços com marcadores grossos
• Fazer apostas com um risco máximo limitado (o circuit breaker) e honra-las com tempo ininterrupto
• Escolher o comprimento de ciclo certo (seis semanas)
• Utilizar um período de cool-down entre ciclos
• Dividir projetos em escopos
• Trabalho ladeira abaixo versus trabalho ladeira acima e comunicando sobre incógnitas
• Martelar o escopo para separar must-haves de nice-to-haves

Entre em Contato

Adoraríamos saber o qu

Open Como Implementar o Shape Up no Basecamp

Como Implementar o Shape Up no Basecamp

Construímos o Basecamp para implementar o método Shape Up. Em vez de espalhar nosso trabalho por várias ferramentas, o Basecamp centraliza toda a comunicação do projeto, gerenciamento de tarefas e documentação em um só lugar. Veja como o usamos.

Uma Equipe Basecamp para Modelagem

1. Crie uma equipe Basecamp para modelagem. Nós chamamos a nossa de “Estratégia de Produto”.
2. Adicione as pessoas que fazem a modelagem, qualquer pessoa de confiança que dê feedback sobre as propostas e as pessoas que apostam na mesa de apostas. Mantenha esse grupo pequeno e anuncie as apostas mais amplamente em outro lugar (usamos o HQ do Basecamp para isso) quando for a hora de iniciar um ciclo.
3. Publique os pitches como Mensagens no Quadro de Mensagens. Criamos uma Categoria de Mensagem chamada “Pitch” com o emoji de lâmpada como ícone.
4. Use a sala de chat para trocar ideias e coordenar a mesa de apostas entre ciclos. Conduzimos a reunião rea

Open Ajuste ao Seu Tamanho

Ajuste ao Seu Tamanho

Verdades Básicas vs. Práticas Específicas

Para aplicar o Shape Up à sua empresa, é útil separar as verdades básicas das práticas específicas.

O trabalho tem que vir de algum lugar, e dá trabalho para descobrir qual é o trabalho certo. Isso é modelagem. Modelar o trabalho estabelece limites e expectativas mais claras para quem faz o trabalho — seja uma equipe separada ou apenas o seu eu futuro. Se não fizermos concessões antecipadamente ao modelar, o universo nos forçará a fazê-las mais tarde, em uma correria louca quando nos depararmos com prazos, limitações técnicas ou restrições de recursos.

O mesmo é verdadeiro com apostas. Seis semanas podem não ser o prazo exato para sua equipe. Mas as consequências de assumir compromissos vagos ou abertos são as mesmas para todos. Independentemente do período específico que apostamos, devemos ser deliberados sobre o que apostamos e limitar nossas perdas com um circuit breaker.

Na fase de construção, haverá incógnitas a serem t

Open Como Começar a Modelar

Como Começar com Shape Up

Opção A: Um Experimento de Seis Semanas

Você não precisa mudar tudo de uma vez. Se toda a equipe de produto não estiver pronta para fazer uma grande mudança, comece apenas com um único experimento de seis semanas. Estes são os passos a seguir:

1. Modele um projeto significativo que possa ser confortavelmente concluído em seis semanas. Seja conservador e permita tempo extra na sua primeira tentativa.
2. Reserve o tempo de um designer e dois programadores para as seis semanas inteiras. Garanta que ninguém os interrompa durante a duração do experimento.
3. Em vez de uma mesa de apostas formal, simplesmente planeje que a equipe faça o trabalho que você modelou para este experimento.
4. Comece apresentando o trabalho modelado para a equipe, com todos os ingredientes de um pitch. Defina a expectativa de que eles descobrirão e rastrearão suas próprias tarefas.
5. Dedique um espaço físico ou uma sala de chat para a equipe multifuncional para que eles possam trabalhar junt

Open Glossário

Glossário

Apetite

A quantidade de tempo que queremos gastar em um projeto, em oposição a uma estimativa.

Linha de base

O que os clientes estão fazendo sem o que estamos construindo atualmente.

Aposta

A decisão de comprometer uma equipe com um projeto por um ciclo, sem interrupções e com a expectativa de concluí-lo.

Mesa de apostas

Uma reunião durante o período de resfriamento em que os stakeholders decidem quais propostas apostar no próximo ciclo.

Grande Porte

Um projeto que ocupa uma equipe por todo o ciclo e é entregue no final.

Breadboard

Um conceito de UI que define as funcionalidades e suas conexões sem estilização visual.

Circuit-breaker ou Disjuntor

Uma técnica de gerenciamento de risco: cancelar projetos que não são entregues em um ciclo por padrão, em vez de estendê-los por padrão.

Modo Limpeza

_A última fase de construção de um novo produto, onde não modelamos ou apostamos em projetos específicos, mas

Open Sobre o Autor

Sobre o Autor

Ryan Singer trabalhou em todos os níveis do stack de software, desde o design de UI até a programação de back-end e estratégia.

Ao longo de mais de 17 anos no Basecamp, ele projetou funcionalidades usadas por milhões de pessoas e inventou processos que as equipes usam para projetar, desenvolver e entregar as coisas certas.

Atualmente, ele está focado na estratégia de produto: entender o que os clientes do Basecamp estão tentando fazer e como ajustar o produto para atendê-los melhor.

Obrigado pela leitura. Adoraria saber sobre suas perguntas e experiências ao tentar aplicar o método Shape Up. Entre em contato comigo no Twitter ou envie um e-mail para shapeup@basecamp.com.

---

Tradução

Esse livro foi traduzido por Lucas Bittencourt, Country Manager da 37signals. Caso você tenha alguma dúvida, sugestão ou feedback sobre a tradução ou queria conversar em Português sobre o Shape Up ou Basecamp, entre em contato com