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 duas semanas não vale as horas coletivas ao redor da mesa para “planejar a sprint” ou o custo de oportunidade de interromper o impulso de todos para se reagruparem.
Isso nos levou a experimentar ciclos mais longos. Queríamos um ciclo que fosse longo o suficiente para terminar um projeto inteiro, do início ao fim. Ao mesmo tempo, os ciclos precisam ser curtos o suficiente para ver o fim desde o começo. As pessoas precisam sentir o prazo se aproximando para fazer concessões. Se o prazo for muito distante e abstrato no início, as equipes naturalmente se dispersarão e usarão o tempo de forma ineficiente até que o prazo comece a se aproximar e parecer real.
Após anos de experimentação, chegamos a seis semanas. Seis semanas é tempo suficiente para finalizar algo significativo e ainda curto o suficiente para ver o fim desde o início.
Cool-down
Se executássemos ciclos de seis semanas consecutivos, não haveria tempo para respirar e pensar sobre o que vem a seguir. O final de um ciclo é o pior momento para se reunir e planejar, porque todos estão muito ocupados finalizando projetos e tomando decisões de última hora para entregar no prazo.
Portanto, após cada ciclo de seis semanas, agendamos duas semanas para resfriamento – cool-down. Este é um período sem trabalho programado, onde podemos respirar, nos reunir conforme necessário e considerar o que fazer a seguir.
Durante o cool-down, os programadores e designers das equipes de projeto são livres para trabalhar no que quiserem. Após trabalhar arduamente para entregar seus projetos de seis semanas, eles apreciam ter um tempo sob seu controle. Eles usam esse período para corrigir bugs, explorar novas ideias ou experimentar novas possibilidades técnicas.
Tamanho da Equipe e do Projeto
Além de padronizar a duração de nossos ciclos, também padronizamos aproximadamente os tipos de projetos e equipes em que apostamos.
Nossas equipes de projeto consistem em um designer e dois programadores ou um designer e um programador. Eles são acompanhados por uma pessoa de QA que faz testes de integração mais tarde no ciclo.
Essas equipes passarão todo o ciclo trabalhando em um projeto, ou trabalharão em vários projetos menores durante o ciclo. Chamamos a equipe que passa o ciclo inteiro fazendo um projeto de equipe de grande porte e a equipe que trabalha em um conjunto de projetos menores de equipe de pequeno porte. Projetos de pequeno porte geralmente duram uma ou duas semanas cada. Projetos de pequeno porte não são agendados individualmente. Cabe à equipe de pequeno porte descobrir como organizar o trabalho para que todos sejam entregues antes do final do ciclo.
Agora que temos uma maneira padrão de pensar sobre a capacidade, podemos falar sobre como decidimos o que agendar.
A Mesa de Apostas
A mesa de apostas é uma reunião realizada durante o período de resfriamento, onde os stakeholders decidem o que fazer no próximo ciclo. As apostas potenciais a serem consideradas são novos pitches moldados durante as últimas seis semanas, ou possivelmente um ou dois pitches antigos que alguém especificamente escolheu reviver. Como dissemos no capítulo anterior, não há "grooming", refinamento ou backlog a organizar. Apenas algumas boas opções a considerar.
Nossa mesa de apostas no Basecamp consiste no CEO (que no nosso caso é a última palavra em produto), CTO, um programador sênior e um estrategista de produto (eu mesmo).
O tempo dos C-levels está disponível apenas em pequenas parcelas, por isso há uma atmosfera de "não desperdice tempo" e a chamada raramente dura mais de uma ou duas horas. Todos tiveram a chance de estudar os pitches em seu próprio tempo antes da reunião. Conversas ad-hoc um-a-um nas semanas anteriores geralmente estabelecem algum contexto também. Uma vez que a chamada começa, é tudo sobre olhar para as opções que chegaram à mesa e tomar decisões.
O resultado da chamada é um plano do ciclo. Entre todos os presentes, há conhecimento de quem está disponível, quais são as prioridades de negócios e que tipo de trabalho temos feito recentemente. Tudo isso alimenta o processo de tomada de decisão sobre o que fazer e quem agendar (mais sobre isso abaixo).
As pessoas mais altas na empresa estão lá. Não há um "passo dois" para validar o plano ou obter aprovação. E ninguém mais pode entrar depois para interferir ou interromper o trabalho agendado.
Esse compromisso do topo é essencial para fazer os ciclos funcionarem corretamente. A reunião é curta, as opções são bem modeladas e o número de participantes é baixo. Quando esses critérios são atendidos, a mesa de apostas se torna um lugar para exercer controle sobre a direção do produto, em vez de uma batalha por recursos ou um apelo por priorização. Com ciclos longos o suficiente para fazer um progresso significativo e trabalho modelado que será realisticamente entregue, a mesa de apostas dá aos executivos uma sensação de "mãos no volante" que não tinham desde os primeiros dias.
O Significado de uma Aposta
Falamos sobre “apostar” em vez de planejar porque isso define expectativas diferentes.
Primeiro, as apostas têm um retorno. Não estamos apenas preenchendo uma caixa de tempo com tarefas até que esteja cheia. Não estamos destinando duas semanas para um recurso e esperando por um progresso incremental. Moldamos intencionalmente o trabalho em uma caixa de seis semanas para que algo significativo esteja terminado no final. O pitch define um retorno específico que faz a aposta valer a pena.
Segundo, as apostas são compromissos. Se apostamos seis semanas, então nos comprometemos a dar à equipe as seis semanas inteiras para trabalhar exclusivamente naquela coisa, sem interrupções. Não estamos tentando otimizar cada hora do tempo de um programador. Estamos olhando para o movimento maior de progresso no produto como um todo após as seis semanas.
Terceiro, uma aposta inteligente tem um limite de perdas. Se apostamos seis semanas em algo, o máximo que podemos perder são seis semanas. Não nos permitimos entrar em uma situação em que estamos gastando múltiplos da estimativa original em algo que não vale esse preço.
Vamos examinar esses dois últimos pontos mais de perto.
Tempo Ininterrupto
Não é realmente uma aposta se dizemos que estamos dedicando seis semanas, mas depois permitimos que a equipe seja desviada para trabalhar em outra coisa.
Quando você faz uma aposta, você a honra. Não permitimos que a equipe seja interrompida ou desviada para fazer outras coisas. Se as pessoas interromperem a equipe com solicitações, isso quebra nosso compromisso. Não estaríamos mais dando à equipe seis semanas inteiras para fazer um trabalho que foi moldado para seis semanas de tempo.
Quando as pessoas pedem “apenas algumas horas” ou “apenas um dia”, não se deixe enganar. O momentum e o progresso são coisas de segunda ordem, como crescimento ou aceleração. Você não pode descrevê-los com um ponto. Você precisa de uma curva ininterrupta de pontos. Quando você puxa alguém para longe por um dia para corrigir um bug ou ajudar uma equipe diferente, você não perde apenas um dia. Você perde o momentum que eles acumularam e o tempo que levará para recuperá-lo. Perder a hora errada pode matar um dia. Perder um dia pode matar uma semana.
E se algo surgir durante essas seis semanas? Ainda assim, não interrompemos a equipe e não quebramos o compromisso. O tempo máximo que teríamos que esperar é seis semanas antes de poder agir sobre o novo problema ou ideia. Se o ciclo passar e essa coisa ainda for a mais importante a ser feita, podemos apostar nela para aquele ciclo. É por isso que é tão importante apostar apenas um ciclo à frente. Isso mantém nossas opções abertas para responder a essas novas questões. E claro, se for uma verdadeira crise, sempre podemos frear. Mas crises verdadeiras são muito raras.
O “circuit breaker”
Combinamos esse tempo ininterrupto com uma política rigorosa, mas extremamente poderosa. As equipes precisam entregar o trabalho dentro do tempo que apostamos. Se não terminarem, por padrão o projeto não recebe uma extensão. Intencionalmente criamos o risco de que o projeto — como foi proposto — não aconteça. Isso soa severo, mas é extremamente útil para todos os envolvidos.
Primeiro, elimina o risco de projetos descontrolados. Definimos nosso apetite no início, quando o projeto foi moldado e proposto. Se o projeto valia apenas seis semanas, seria tolice gastar duas, três ou dez vezes isso. Pouquíssimos projetos são do tipo "a qualquer custo" e absolutamente devem acontecer agora. Pensamos nisso como um disjuntor, ou “circuit breaker”, que garante que um projeto não sobrecarregue o sistema. Um projeto que está demorando demais nunca nos congelará ou impedirá novos projetos que podem ser mais importantes.
Segundo, se um projeto não termina em seis semanas, isso significa que fizemos algo errado no planejamento. Em vez de investir mais tempo em uma abordagem ruim, o disjuntor nos força a reformular o problema. Podemos usar a trilha de planejamento nas próximas seis semanas para encontrar uma nova ou melhor solução que evite qualquer armadilha em que caímos na primeira tentativa. Então, revisaremos o novo pitch na mesa de apostas para ver se realmente muda nossas chances de sucesso antes de dedicar outras seis semanas a ele.
Finalmente, o disjuntor motiva as equipes a assumirem mais responsabilidade por seus projetos. Como veremos no próximo capítulo, as equipes têm total responsabilidade pela execução dos projetos. Isso inclui fazer concessões sobre detalhes de implementação e escolher onde cortar o escopo. Você não pode entregar sem tomar decisões difíceis sobre onde parar, o que comprometer e o que deixar de fora. Um prazo rígido e a chance de não entregar motiva a equipe a questionar regularmente como suas decisões de design e implementação estão afetando o escopo.
E os Bugs?
Se as equipes não são interrompidas no ciclo de seis semanas, como lidamos com os bugs que surgem?
Primeiro, devemos questionar nossas suposições sobre bugs.
Não há nada especial nos bugs que os torne automaticamente mais importantes do que todo o resto. O mero fato de algo ser um bug não nos dá uma desculpa para interromper a nós mesmos ou a outras pessoas. Todo software tem bugs. A questão é: quão graves eles são? Se estivermos em uma verdadeira crise — dados sendo perdidos, o aplicativo parando de funcionar, ou uma grande parte dos clientes vendo algo errado — então largamos tudo para corrigir. Mas crises são raras. A grande maioria dos bugs pode esperar seis semanas ou mais, e muitos nem precisam ser corrigidos. Se tentássemos eliminar todos os bugs, nunca terminaríamos. Você não pode lançar nada novo se tiver que corrigir o mundo inteiro primeiro.
Dito isso, ninguém gosta de bugs. Ainda queremos maneiras de lidar com eles. Três estratégias funcionam para nós.
1. Use o período de cool-down: Pergunte a qualquer programador se há coisas que eles gostariam de voltar e corrigir e eles terão uma lista para mostrar. O período de resfriamento entre os ciclos dá a eles tempo para fazer exatamente isso. Seis semanas não é muito tempo para a maioria dos bugs, e duas semanas a cada seis semanas na verdade somam muito tempo para corrigi-los.
2. Leve à mesa de apostas: Se um bug for grande demais para ser corrigido durante o período de resfriamento, ele pode competir por recursos na mesa de apostas. Suponha que um processo de back-end esteja desacelerando o aplicativo e um programador queira mudá-lo de uma etapa síncrona para um trabalho assíncrono. O programador pode argumentar a favor da correção e moldar a solução em um pitch. Em vez de interromper outro trabalho, as pessoas na mesa de apostas podem tomar uma decisão deliberada. O tempo deve sempre ser usado estrategicamente. Há uma grande diferença entre atrasar outro trabalho para corrigir um bug e decidir desde o início que o bug vale o tempo para ser corrigido.
3. Agende um "bug smash": Uma vez por ano — geralmente em torno dos feriados de fim de ano — dedicamos um ciclo inteiro para corrigir bugs. Chamamos isso de “bug smash”. Os feriados são um bom momento para isso porque é difícil concluir um projeto normal quando as pessoas estão viajando ou tirando folga. A equipe pode se auto-organizar para escolher os bugs mais importantes e resolver problemas de longa data no front-end ou back-end.
Essas estratégias nos permitem lidar com bugs de maneira eficaz sem comprometer o trabalho estratégico e as metas de longo prazo.
Mantenha a Lousa Limpa
A chave para gerenciar a capacidade é nos dar uma lousa limpa a cada ciclo. Isso significa apostar apenas um ciclo de cada vez e nunca carregar pedaços de trabalho antigo sem antes modelá-los e considerá-los como uma nova aposta potencial.
É crucial maximizar nossas opções no futuro. Não sabemos o que acontecerá nas próximas seis semanas. Não sabemos que ideia brilhante surgirá ou que solicitação urgente poderá aparecer.
Mesmo que tenhamos algum tipo de roteiro em nossas cabeças em uma escala de tempo acima dos ciclos, mantemos isso em nossas cabeças e em nossas discussões paralelas. A cada seis semanas, aprendemos o que está funcionando e o que não está, o que é importante e o que não é. Não há desvantagem em manter a opção aberta e uma enorme vantagem em estar disponível para agir sobre o inesperado.
E os projetos que não podem ser concluídos em um ciclo? Nesse caso, ainda apostamos apenas seis semanas de cada vez. Suponha que imaginemos um recurso que leva dois ciclos para ser lançado. Reduzimos nosso risco drasticamente ao modelar um objetivo específico de seis semanas, com algo totalmente construído e funcionando no final dessas seis semanas. Se isso acontecer como esperado, nos sentiremos confiantes em apostar nas próximas seis semanas conforme imaginamos. Mas se não der certo, poderíamos definir um projeto muito diferente. Ou poderíamos colocar a coisa de múltiplos ciclos em pausa e fazer algo urgente que surgiu. O importante é que sempre moldamos como será o final daquele ciclo e mantemos nossas opções abertas para mudar de curso.