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 sala com dimensões fixas, o desenvolvimento de um novo produto é como descobrir onde as paredes e a fundação devem ser para que o edifício fique de pé.
Notamos três fases de trabalho quando construímos um novo produto do zero. Em cada fase, a maneira como modelamos e nossas expectativas sobre como a equipe trabalhará durante o ciclo são diferentes. Essas fases se desenrolam ao longo de vários ciclos, mas ainda apostamos apenas um ciclo de cada vez.
Modo P&D
Nos estágios iniciais de um novo produto, nossa ideia é apenas uma teoria ou um vislumbre. Não sabemos se o conjunto de funcionalidades que imaginamos se manterá na realidade, e as decisões técnicas sobre como modelá-las em código são ainda menos claras.
Isso significa que há muito trabalho preliminar. Podemos decidir, no meio do desenvolvimento de uma funcionalidade, que não é isso que queremos e tentar outra abordagem.
Em outras palavras, não podemos modelar de forma confiável o que queremos com antecedência e dizer: "É isso que queremos. Esperamos entregar em seis semanas." Temos que aprender o que queremos ao construir.
Chamamos essa fase de modo P&D e ajustamos para isso de três maneiras.
1. Em vez de apostar em um pitch bem modelado, apostamos principalmente o tempo em explorar algumas peças-chave da nova ideia de produto. A modelagem é muito mais vaga porque esperamos aprender construindo.
2. Em vez de delegar a uma equipe de construção separada, nossas pessoas mais experientes compõem a equipe. David (CTO) assume o papel de programação e trabalha com Jason (CEO e designer) ou um designer sênior com a orientação de Jason. Isso é necessário por duas razões. Primeiro, você não pode delegar a outras pessoas quando nem você sabe o que quer. Segundo, as decisões de arquitetura determinarão o que será possível no futuro do produto — elas definem os "buracos" nos quais as funcionalidades futuras se encaixarão. Nesta fase, a equipe precisa manter a visão do produto e ser capaz de julgar os efeitos a longo prazo das decisões de design.
3. Por fim, não esperamos entregar nada ao final de um ciclo de P&D. O objetivo é explorar, não entregar. No melhor dos casos, teremos alguma UI e código comprometidos para servir de base para o trabalho subsequente. O objetivo é aprender o que funciona para podermos nos comprometer com alguma estrutura de sustentação: as principais decisões de código e UI que definirão a forma do produto daqui para frente.
Não podemos entregar nada aos clientes com apenas um ciclo de trabalho de P&D. Mas ainda assim não nos comprometemos com mais de um ciclo de cada vez. Podemos aprender com o primeiro ciclo que não estamos prontos para enfrentar o produto ainda. Ou podemos descobrir que nossa intuição estava correta e o produto está se concretizando. Dependendo de como as coisas vão, decidiremos ciclo a ciclo se continuaremos dedicando tempo informal no modo P&D.
Modo Produção
Se continuarmos avançando após alguns ciclos de P&D, eventualmente chegaremos a um ponto onde as decisões de arquitetura mais importantes estão resolvidas. O produto realiza aquelas poucas coisas essenciais que o definem, e a base está pronta para as dezenas de outras coisas que teremos que fazer antes de lançá-lo para os clientes.
Com essa estrutura em vigor, a equipe sênior pode trazer outras pessoas para contribuir. Esta é a transição para o modo de produção, onde trabalhamos em ciclos formais com fases claras de moldagem, aposta e construção. O modo produção é como trabalhar em um produto existente: o precedente estabelecido pelo trabalho de P&D permite que novos colaboradores identifiquem onde a nova funcionalidade pertence e como ela se encaixa no todo.
No modo de produção:
1. Modelagem é novamente deliberada. O trabalho modelado descreve o que esperamos ver ao final do ciclo.
2. A equipe que constrói os projetos não é mais limitada ao grupo sênior. Torna-se possível apostar em múltiplas equipes em paralelo (se houver) e cobrir mais terreno.
3. Entregar é o objetivo, não explorar. Mas como o produto ainda não está disponível publicamente para os clientes, definimos 'entregar' de forma diferente. Entregar significa fazer merge ao código principal e esperar não mexer nele novamente.
Como não estamos entregando aos clientes ao final de cada ciclo, mantemos a opção de remover funcionalidades da entrega final antes do lançamento. Isso significa que ainda podemos ser experimentais. Podemos apostar seis semanas em uma funcionalidade sem saber se a queremos no produto final. Isso não é um problema, desde que estabeleçamos expectativas para a equipe de construção: não podemos prever o que queremos na entrega final, e estamos dispostos a arriscar este ciclo para dar o nosso melhor na ideia.
Modo Limpeza
Na fase final antes de lançar o novo produto, jogamos toda a estrutura pela janela. Chamamos isso de modo limpeza. É uma abordagem livre. Construímos novos produtos o suficiente para aprender que sempre há coisas que esquecemos, coisas que perdemos, detalhes que não estão certos e bugs que surgem ao longo dos ciclos de P&D e modo produção.
Há algo em colocar o dedo perto do botão de lançamento que nos deixa em alerta. De repente, tudo fica "real". Coisas que antes ignorávamos se destacam com nova importância.
É por isso que reservamos alguma capacidade no final para o inesperado. No modo de limpeza:
1. Não há moldagem. O ciclo está mais próximo do espírito do "bug smash" mencionado no capítulo anterior. A liderança permanece no comando durante todo o ciclo, chamando a atenção para o que é importante e eliminando distrações.
2. Não há limites claros de equipe. Todos se envolvem para ajudar como podem.
3. O trabalho é "entregue" (merge ao código principal) continuamente nos menores pedaços possíveis.
Disciplina ainda é importante. Precisamos nos controlar para garantir que estamos trabalhando no essencial, e não apenas adiando o lançamento por insegurança. A limpeza não deve durar mais de dois ciclos.
A limpeza também é a fase onde a liderança toma as decisões da "entrega final". Uma superfície de contato menor em uma versão 1 significa menos perguntas a responder, menos suporte necessário e menos compromisso de manutenção indefinida. Às vezes, precisamos ver todos os recursos funcionando como um todo para julgar o que podemos viver sem e o que pode exigir uma consideração mais profunda antes de lançar para os clientes.
Exemplos
O Calendário de Grade Pontilhada
Construímos o Calendário de Grade Pontilhada (veja Capítulo 2) para o Basecamp, um produto existente. Modelamos o projeto, apostamos seis semanas nele, uma equipe o construiu e depois o entregamos diretamente aos clientes.
Um Novo Produto: HEY
Em 2020, após dois anos de desenvolvimento, lançamos um novo aplicativo e serviço de email chamado HEY. O HEY esteve em modo P&D no primeiro ano de seu desenvolvimento. Uma equipe de três pessoas, Jason (CEO), David (CTO) e Jonas (designer sênior), explorou uma ampla variedade de ideias antes de definir o núcleo do produto. Quase um ano de ciclos de modo produção se seguiu, onde todas as equipes do Basecamp detalharam o conjunto de funcionalidades do HEY. Terminamos com dois ciclos de limpeza e reduzimos significativamente o conjunto de funcionalidades para lançar em julho de 2020.
Para ser preciso, houve alguma sobreposição entre o modo P&D e o modo produção após aquele primeiro ano. O Basecamp era grande o suficiente como empresa para que a equipe sênior pudesse moldar e delegar projetos em modo de produção em partes do aplicativo que já estavam definidas, enquanto continuavam a explorar novos territórios no modo P&D.
Cada aposta no HEY foi feita uma de cada vez. A mesa de apostas não sabia que estariam trabalhando no HEY por dois anos durante aqueles primeiros ciclos de P&D. Gradualmente, ganharam confiança na ideia e desenvolveram um apetite de longo prazo para quantos ciclos estavam dispostos a gastar no HEY. Mas não fizeram compromissos específicos sobre o que entraria nesses ciclos. E sempre estava em pauta a possibilidade de voltar a atenção para o Basecamp, nosso produto existente.
Um Recurso Experimental: Hill Charts
Um terceiro exemplo mostra uma área cinzenta. Quando construímos o recurso Hill Charts no Basecamp (veja Capítulo 13), não tínhamos ideia se ia funcionar ou não. O Basecamp era um produto existente, e parecia arriscado demais apostar em liberar esse recurso experimental para os clientes. Então, enquadramos o projeto mais como uma aposta de modo produção em um novo produto. Moldamos uma primeira versão que era apenas funcional o suficiente para usarmos nós mesmos. Não esperávamos entregá-la aos clientes sem fazer um ciclo adicional nela. Isso foi um risco: apostamos um ciclo, não dois. Se não desse certo, descartaríamos. Se algo mais importante surgisse, talvez nunca agendássemos o segundo ciclo. Mas acabamos nos sentindo confiantes após o primeiro ciclo. Modelamos um projeto para aprimorá-lo, decidimos apostar mais um ciclo e depois o entregamos aos clientes.
Perguntas a Se Fazer
Aqui estão algumas perguntas comuns que você pode ouvir quando as pessoas na mesa de apostas estão debatendo quais apostas fazer.
O Problema Importa?
Assim como nas descrições dos pitches, sempre nos preocupamos em separar problema e solução. A solução não importa se o problema não vale a pena ser resolvido.
Claro, qualquer problema que afete os clientes importa. Mas temos que fazer escolhas porque sempre haverá mais problemas do que tempo para resolvê-los. Então, pesamos os problemas entre si. Este problema é mais importante do que aquele problema agora?
Como as pessoas na mesa julgam os problemas depende de sua perspectiva, função e conhecimento. Por exemplo, um problema pode impactar um pequeno segmento de clientes, mas colocar uma carga desproporcional no suporte. Dependendo da sua exposição ao suporte e em qual aspecto do negócio você está focado, pode pesar isso de forma diferente.
Às vezes, uma solução que é muito complicada ou muito abrangente pode levantar questões sobre o problema. Realmente precisamos fazer tantas mudanças no aplicativo? Entendemos o problema de forma suficientemente específica? Talvez haja uma maneira de restringi-lo para obter 80% do benefício com 20% da mudança.
O Apetite Está Correto?
É bom quando temos uma solução modelada para um prazo razoável, como duas ou seis semanas. Mas ainda podemos debater se vale o tempo. Suponha que um stakeholder diga que não está interessado em gastar seis semanas em um determinado pitch. A negociação pode seguir alguns caminhos a partir daí:
1. Talvez o problema não tenha sido articulado bem o suficiente, e quem apresentou possa adicionar informações à conversa agora para mudar a opinião. Por exemplo: “Sim, isso não acontece com frequência, mas quando acontece, as pessoas são tão vocais sobre isso que realmente mancha nossa imagem.” Ou “Pode parecer trivial, mas o suporte tem que passar por 11 etapas demoradas para chegar à resolução.”
2. Às vezes, dizer “não” ao compromisso de tempo é realmente dizer não a outra coisa. Talvez haja algo na solução ou na implementação técnica que não agrade. Perguntar “Como você se sentiria se pudéssemos fazer isso em duas semanas?” pode revelar que não se trata tanto do tempo. O CTO pode responder: “Não quero introduzir outra dependência nessa área do aplicativo.”
3. Quem está modelando pode simplesmente deixar a ideia de lado se o interesse for muito baixo.
4. Quem está modelando pode voltar à prancheta e trabalhar em uma versão menor (para um apetite mais curto) ou fazer mais pesquisas se acreditar que o problema é convincente, mas não estava bem preparado para apresentá-lo.
A Solução é Atraente?
O problema pode ser importante e o apetite justo, mas podem haver diferenças sobre a solução.
Por exemplo, adicionar elementos de interface à tela tem um custo invisível: abrir mão do espaço. Um botão no canto da página inicial pode resolver perfeitamente o problema. Mas esse espaço é valioso. Se o utilizarmos agora, não poderemos usá-lo no futuro. Estamos vendendo esse espaço barato demais para resolver este problema específico?
Se alguém oferecer uma solução de design imediata, como "que tal movermos esse botão para um menu de ações?", podemos discutir. Mas, em geral, evitaremos fazer trabalho de design ou discutir soluções técnicas por mais de alguns momentos na mesa de apostas. Se nos pegarmos gastando muito tempo em detalhes, lembramos a nós mesmos "ok, não estamos fazendo design aqui" e voltamos ao nível mais alto.
É o Momento Certo?
O tipo de projeto que queremos fazer a seguir pode depender dos projetos que fizemos recentemente. Talvez tenha se passado muito tempo desde que fizemos uma grande notícia com um novo recurso. Ou talvez tenhamos construído muitos novos recursos e sentimos que é hora de resolver algumas solicitações antigas de clientes. Ou, se as equipes passaram os últimos ciclos na mesma área do aplicativo, a moral pode cair se planejarmos mais um projeto fazendo o mesmo tipo de trabalho.
Essas são todas razões pelas quais podemos passar em um projeto, mesmo que esteja perfeitamente modelado e seja valioso. O projeto é ótimo; só não é o momento certo.
As Pessoas Certas Estão Disponíveis?
Como parte do processo de apostas, escolhemos quem especificamente desempenhará qual função em cada equipe. Ou seja, emparelhamos um projeto com uma pequena equipe específica composta por um designer e um ou dois programadores. Temos uma equipe de “Produto Principal” de designers e programadores e selecionamos desse grupo ao planejar as equipes para cada ciclo. A equipe trabalhará junta durante todo o ciclo e, no próximo ciclo, pode ser uma combinação diferente de pessoas.
Projetos diferentes exigem expertise diferente. Talvez precisemos de mais programação front-end neste projeto. Ou esse outro projeto pode convidar a um grande aumento de escopo, então precisamos de alguém bom em redução de escopo.
O tipo de trabalho que cada pessoa tem feito também é um fator. Alguém que fez uma longa série de projetos de pequeno porte pode preferir assumir um grande projeto, ou vice-versa.
E, por fim, sempre há um pouco de Tetris de calendário com a disponibilidade das pessoas. Férias ou sabáticos afetam quais projetos podemos agendar no próximo ciclo.
Vimos algumas outras empresas usarem um modelo diferente, onde, em vez de atribuir os projetos às pessoas, elas deixam os membros da equipe escolherem em quais projetos querem trabalhar. Culturalmente, somos avessos a reuniões extras para esse passo adicional. Mas ouvimos dizer que isso pode funcionar bem para algumas equipes, porque os membros das equipes têm um pouco mais de envolvimento no projeto.
Poste a Mensagem de Kick-off
Depois que as apostas são feitas, alguém da mesa de apostas escreve uma mensagem informando a todos quais projetos estamos apostando para o próximo ciclo e quem trabalhará neles
Jason anuncia as apostas para o próximo ciclo com uma mensagem no Basecamp.