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ção. E os melhores programadores querem que a base de código pareça um todo coeso, completamente lógica e consistente, cobrindo todos os casos de borda.
O orgulho no trabalho é importante para a qualidade e o moral, mas precisamos direcioná-lo para o alvo certo. Se mirarmos em um design ideal perfeito, nunca chegaremos lá. Ao mesmo tempo, não queremos baixar nossos padrões. Como podemos decidir que o que temos é bom o suficiente e seguir em frente?
Ajuda mudar o ponto de comparação. Em vez de comparar com o ideal, compare com a linha de base — a realidade atual dos clientes. Como os clientes resolvem esse problema hoje, sem esse recurso? Qual é a solução alternativa frustrante que esse recurso elimina? Por quanto tempo mais os clientes devem aguentar algo que não funciona ou esperar por uma solução porque não temos certeza se o design A é melhor do que o design B?
Ver que nosso trabalho até agora é melhor do que as alternativas atuais nos faz sentir melhor sobre o progresso que fizemos. Isso nos motiva a tomar decisões sobre as coisas que estão nos atrasando. É menos sobre nós e mais sobre o valor para o cliente. É a diferença entre "nunca é bom o suficiente" e "melhor do que o que eles têm agora." Podemos dizer "Ok, isso não é perfeito, mas definitivamente funciona e os clientes sentirão que isso é uma grande melhoria para eles."
Faça concessões no escopo ao comparar com o cenário base ao invés de um ideal perfeito.
Limites Motivam Concessões
Lembre-se de que a aposta de seis semanas tem um circuit breaker — se o trabalho não for concluído, o projeto não acontece.
Isso força a equipe a fazer concessões. Quando alguém diz "não seria melhor se..." ou encontra outro caso de borda, deve primeiro se perguntar: Há tempo para isso? Sem um prazo, eles poderiam facilmente atrasar o projeto para fazer mudanças que não merecem realmente o tempo extra.
Esperamos que nossas equipes façam concessões ativamente e questionem o escopo, em vez de acumular tarefas e se apressar para concluí-las. Criamos nosso próprio trabalho para nós mesmos. Devemos questionar qualquer novo trabalho que surja antes de aceitá-lo como necessário.
Escopo Cresce Como Grama
O escopo cresce naturalmente. O aumento do escopo não é culpa de clientes ruins, gerentes ruins ou programadores ruins. Os projetos são opacos em grande escala. Você não pode ver todos os pequenos microdetalhes de um projeto até mergulhar no trabalho. Então, você descobre não apenas complexidades que não antecipou, mas todos os tipos de coisas que poderiam ser corrigidas ou melhoradas.
Todo projeto está cheio de escopo que não precisamos. Cada parte de um produto não precisa ser igualmente proeminente, igualmente rápida e igualmente polida. Cada caso de uso não é igualmente comum, igualmente crítico ou igualmente alinhado com o mercado que estamos tentando alcançar.
É assim que é. Em vez de tentar impedir o crescimento do escopo, dê às equipes as ferramentas, autoridade e responsabilidade para constantemente reduzi-lo.
Cortar Escopo Não é Baixar Qualidade
Escolher quais coisas executar e até que ponto executá-las não deixa lacunas no produto. Fazer escolhas torna o produto melhor. Torna o produto melhor em algumas coisas em vez de outras. Ser exigente quanto ao escopo diferencia o produto. Diferenciar o que é central do que é periférico nos posiciona no espaço competitivo, tornando-nos mais semelhantes ou mais diferentes de outros produtos que fizeram escolhas diferentes.
O escopo variável não é sobre sacrificar qualidade. Somos extremamente exigentes quanto à qualidade do nosso código, nosso design visual, o texto em nossas interfaces e o desempenho de nossas interações. O truque é perguntar a nós mesmos quais coisas realmente importam, quais coisas fazem diferença e quais coisas são importantes para os casos de uso principais que estamos tentando resolver.
Martelando o Escopo
As pessoas costumam falar em "cortar" o escopo. Usamos uma palavra ainda mais forte — martelar — para refletir o poder e a força necessários para bater repetidamente no escopo até que ele se encaixe no prazo.
À medida que surgem coisas para corrigir, adicionar, melhorar ou redesenhar durante um projeto, perguntamos a nós mesmos:
- Isso é um “must-have” para o novo recurso?- Poderíamos lançar sem isso?- O que acontece se não fizermos isso?- Este é um problema novo ou um problema preexistente com o qual os clientes já lidam?- Qual a probabilidade de este caso ou condição ocorrer?- Quando esse caso ocorre, quais clientes o veem? É central — usado por todos — ou mais um caso de borda?- Qual é o impacto real desse caso ou condição no caso de acontecer?- Quando algo não funciona bem para um caso de uso específico, quão alinhado está esse caso de uso com nosso público-alvo?
O prazo fixo nos motiva a fazer essas perguntas. O escopo variável nos permite agir com base nelas. Ao talhar e martelar o escopo, permanecemos focados apenas nas coisas que precisamos fazer para entregar algo eficaz de que podemos nos orgulhar no final do prazo.
Ao longo do ciclo, você ouvirá nossas equipes falando sobre “must-haves” (essenciais) e “nice-to-haves” (desejáveis) à medida que descobrem o trabalho. Os must-haves são capturados como tarefas no escopo. O escopo não é considerado “concluído” até que essas tarefas estejam terminadas. Nice-to-haves podem permanecer no escopo depois de ser considerado concluído. Eles são marcados com um Til (~) na frente. Essas tarefas são coisas a serem feitas se a equipe tiver tempo extra no final e coisas a serem cortadas se não tiverem. Geralmente, elas nunca são construídas. O ato de marcá-las como nice-to-have é o martelar do escopo.
Um escopo com um nice-to-have (marcado com um “~”) que nunca foi realizado.
QA é para os Detalhes
Na atual dimensão do Basecamp (milhões de usuários e cerca de uma dúzia de pessoas na equipe de produto), temos uma pessoa de QA. Ela entra no final do ciclo e busca casos de borda fora das funcionalidades principais.
O QA pode limitar sua atenção a casos de borda porque os designers e programadores são responsáveis pela qualidade básica de seu trabalho. Os programadores escrevem seus próprios testes, e a equipe trabalha em conjunto para garantir que o projeto faça o que deve de acordo com o que foi planejado. Isso decorre do fato de dar à equipe a responsabilidade por todo o projeto, em vez de atribuir a eles tarefas individuais (veja o Capítulo 10, Responsabilidade do Repasse de Trabalho).
Durante anos, não tivemos uma função de QA. Depois que nossa base de usuários cresceu a um certo ponto, percebemos que pequenos casos de borda começaram a impactar centenas ou milhares de usuários em números absolutos. Adicionar a etapa extra de QA nos ajudou a melhorar a experiência desses usuários e reduzir o ônus desproporcional que eles criariam para o suporte.
Portanto, pensamos no QA como uma melhoria, não como um obstáculo ou um ponto de verificação que todo o trabalho deve passar. Estamos muito melhores com o QA do que sem ele. Mas não dependemos do QA para lançar recursos de qualidade que funcionem como deveriam.
O QA gera tarefas descobertas que, por padrão, são todas nice-to-haves. A equipe de designer-programador faz uma triagem delas e, dependendo da gravidade e do tempo disponível, eleva algumas para must-haves. A maneira mais rigorosa de fazer isso é coletar problemas de QA em uma lista de afazeres separada. Então, se a equipe decidir que um problema é um must-have, eles o movem para a lista do escopo relevante que ele afeta. Isso ajuda a equipe a ver que o escopo não está concluído até que o problema seja resolvido.
Tratamos a revisão de código da mesma maneira. A equipe pode enviar o código sem esperar por uma revisão. Não há um checkpoint formal. Mas a revisão de código melhora as coisas, então, se houver tempo e fizer sentido, alguém mais experiente pode olhar o código e dar feedback. É mais sobre aproveitar uma oportunidade de ensino do que criar uma etapa no nosso processo que deve acontecer toda vez.
Quando Estender um Projeto
Em casos muito raros, estendemos um projeto que ultrapassa seu prazo por algumas semanas. Como decidimos quando estender um projeto e quando deixar o circuit breaker fazer seu trabalho?
Primeiro, as tarefas pendentes devem ser verdadeiros must-haves que resistiram a todas as tentativas de martelar o escopo.
Segundo, o trabalho pendente deve ser todo ladeira abaixo. Sem problemas não resolvidos; sem perguntas em aberto. Qualquer trabalho ladeira a cima no final do ciclo aponta para uma falha na modelagem ou um buraco no conceito. Incógnitas são arriscadas demais para apostar. Se o trabalho estiver ladeira a cima, é melhor fazer outra coisa no próximo ciclo e colocar o projeto problemático de volta na fase de modelagem. Se você encontrar uma maneira viável de preencher a lacuna, poderá considerar apostar mais tempo nele no futuro.
Mesmo que as condições sejam atendidas para considerar a extensão do projeto, ainda preferimos ser disciplinados e manter o apetite para a maioria dos projetos. O período de cool-down de duas semanas geralmente fornece tempo suficiente para uma equipe com alguns must-haves a mais entregar antes que o próximo ciclo comece. Mas isso não deve se tornar um hábito. Estender para o período de cool-down aponta para um problema no processo de modelagem ou um problema de desempenho da equipe.