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, descobrimos que era um problema muito mais difícil do que esperávamos. Nenhum de nós conseguiu encontrar uma solução de design adequada dentro das seis semanas que orçamos. Acabamos abandonando o projeto e repensando-o mais tarde.

Claro que sempre haverá desconhecidos. É por isso que aplicamos as muitas práticas da Parte Três, para que as equipes enfrentem os problemas certos na ordem correta, deixando espaço para o inesperado. Mas isso não significa que não devamos procurar as armadilhas que podemos identificar desde o início e eliminá-las antes de apostar no projeto. Antes de considerarmos seguro apostar, um projeto planejado deve estar o mais livre de armadilhas possível.

Diferentes Categorias de Risco #

Em termos de risco, um trabalho bem planejado se parece com uma distribuição de probabilidade de cauda fina. Há uma pequena chance de que possa levar uma semana extra, mas, além disso, os elementos da solução são suficientemente definidos e familiares, de modo que não há razão para que se prolongue mais do que isso.

No entanto, se houver qualquer armadilha no planejamento — incógnitas técnicas, problemas de design não resolvidos ou interdependências mal compreendidas — o projeto pode levar múltiplas vezes o tempo original para ser concluído. A cauda direita se estende.

Queremos remover as incógnitas e problemas complicados do projeto para que nossa probabilidade seja a mais fina possível. Isso significa um projeto com partes independentes e bem compreendidas que se encaixam de maneiras conhecidas.

Procurando por Armadilhas #

Detalhar os elementos da solução foi um processo rápido e exploratório. Foi mais abrangente do que profundo. Nesta etapa, desaceleramos e analisamos criticamente o que criamos. Perdemos alguma coisa? Estamos fazendo suposições técnicas que não são justas?

Uma maneira de analisar a solução é percorrer um caso de uso em câmera lenta. Dada a solução que esboçamos, como exatamente um usuário chegaria do ponto de partida até o final? Desacelerar e executar o processo pode revelar lacunas ou peças faltantes que precisamos projetar.

Depois, também devemos questionar a viabilidade de cada parte que pensamos ter resolvido. Fazemos perguntas como:

• Isso exige trabalho técnico novo que nunca fizemos antes?
• Estamos fazendo suposições sobre como as partes se encaixam?
• Estamos assumindo que existe uma solução de design que não conseguimos encontrar nós mesmos?
• Existe uma decisão difícil que devemos resolver com antecedência para não atrapalhar a equipe?

Estudo de Caso: Tapando um Buraco #

Por exemplo, quando definimos o projeto de Grupos de Tarefas, introduzimos a ideia de divisores na lista de tarefas:

Gostamos da ideia dos divisores, e a lógica de tarefas soltas versus agrupadas fazia sentido para nós. Mas, quando olhamos mais de perto, percebemos que não abordamos como exibir itens concluídos. No design pré-existente, os itens concluídos mais recentes eram exibidos abaixo da lista. Devemos agora renderizar itens concluídos na parte inferior de cada grupo em vez da lista? Ou devemos continuar exibindo os itens concluídos na parte inferior e repetir o mesmo conjunto de divisores na seção de itens concluídos? Devemos reconsiderar totalmente como lidamos com os itens concluídos?

Isso era uma falha no conceito. Se não a abordássemos, estaríamos empurrando um problema de design profundo para a equipe e pedindo de maneira irrazoável que encontrassem uma solução dentro do prazo. Não é responsável dar à equipe um nó de interdependências e depois pedir que o desatem dentro de um curto período de tempo fixo.

Sabíamos pela experiência que mudar a forma como as tarefas concluídas são renderizadas tem muitas implicações complicadas na experiência do usuário, navegação e desempenho. Para remover a incerteza no projeto, decidimos ditar uma solução no conceito planejado. Deixaríamos os itens concluídos exatamente como funcionavam anteriormente. Em vez de agrupá-los ou segmentá-los, apenas adicionaríamos o nome do grupo a cada item concluído. Ficaria um pouco bagunçado, mas justificamos o trade-off: simplificava drasticamente o problema, e ainda poderíamos mostrar itens concluídos de um grupo na página de detalhes do grupo.

Esse é o tipo de trade-off difícil de decidir quando se está trabalhando sob pressão. Existem muitas razões pelas quais um design diferente ou uma reconsideração mais profunda das tarefas concluídas seria objetivamente melhor. Por que não tentar renderizá-las dentro de cada grupo? Um designer poderia razoavelmente pensar: “Talvez, se eu experimentar um pouco mais com o estilo, possa fazê-los se integrar melhor.” Eles poderiam facilmente perder alguns dias das poucas semanas que têm indo em uma direção sem saída.

Como planejadores, pensamos menos sobre o design final e mais sobre qualidade básica e risco. Com o conceito comprometido, conseguimos manter todos os elementos que tornavam o projeto valioso—os grupos de itens incompletos — e conseguimos cortar um grande risco.

Em seguida, quando escrevermos o Pitch para este projeto, destacaremos esse “remendo” específico como parte do conceito. Dessa forma, ninguém no futuro será pego de surpresa por ele.

Declare os limites #

Como todos na equipe querem fazer o melhor trabalho possível, eles naturalmente buscarão cobrir todos os casos de uso e considerá-los necessários. À medida que a equipe se familiariza com marterlar o escopo (veja Decida Quando Parar), isso melhora. Mas ainda é uma boa ideia destacar qualquer caso que você especificamente não está apoiando para manter o projeto dentro do prazo estabelecido.

Por exemplo, trabalhamos em uma ideia para notificar grupos de pessoas no Basecamp. Em vez de marcar cinco programadores um por um, você poderia simplesmente clicar em “Programadores” e eles seriam selecionados para notificação. Ao olharmos para o produto, vimos inúmeras situações em que esse tipo de comportamento poderia fazer sentido. Se permitimos que você escolha um grupo ao postar uma mensagem, por que não ao atribuir uma tarefa ou mencionar pessoas na sala de bate-papo?

Decidimos que, para o propósito do projeto, o valor central era restringir quem notificar sobre uma mensagem. Marcamos explicitamente os outros casos como “fora dos limites” do projeto e focamos no ganho que queríamos: um fluxo mais rápido para postar mensagens.

Reduza #

Pode haver partes da solução que nos empolgaram durante a fase de esboço, mas que não são realmente necessárias. Quando projetamos o recurso de Grupos de Tarefas, achamos que seria ótimo usar cores para identificar os grupos. Sem dúvida, a página ficaria mais interessante com etiquetas de grupos coloridas, e o recurso poderia ser mais útil também. Mas decidimos marcar isso como desnecessário e cortar do cerne do projeto. Podemos mencionar isso para a equipe como algo nice-to-have (algo bom, mas não necessário), mas todos devem partir da premissa de que o recurso é valioso sem essa adição.

Apresente aos Especialistas Técnicos #

Até este ponto, o planejamento foi uma atividade de portas fechadas. Antes de estar pronto para redigir a ideia para compartilhá-la amplamente, você pode precisar de informações sobre algumas partes do conceito que não tem certeza absoluta. Pode haver uma suposição técnica que você precise verificar com alguém que entenda melhor o código. Ou talvez você queira garantir que os dados de uso não contradigam uma suposição que está fazendo sobre o comportamento atual dos clientes.

Este é um bom momento para chamar alguns especialistas técnicos e apresentar a ideia a eles. Comunique que isso é apenas uma ideia. É algo que você está moldando como uma possível aposta, não algo que já está em andamento. O clima é amigável e conspiratório: “Aqui está algo em que estou pensando... mas ainda não estou pronto para mostrar a ninguém... o que você acha?”

Cuidado com a pergunta simples: “Isso é possível?” Em software, tudo é possível, mas nada é de graça. Queremos descobrir se é possível dentro do prazo que estamos planejando. Em vez de perguntar “é possível fazer X?”, pergunte “é possível fazer X em 6 semanas?” Essa é uma pergunta muito diferente.

Explique as limitações de como esta é uma boa solução, dado o prazo, para que eles sejam parceiros em manter o projeto no tamanho que você pretende. E enfatize que você está procurando por riscos que possam explodir o projeto. Não é apenas uma conversa de “o que você acha” — estamos realmente caçando bombas-relógio que possam explodir o projeto uma vez que ele seja comprometido com uma equipe.

Tente manter a flexibilidade. Em vez de escrever um documento ou criar uma apresentação de slides, convide-os para um quadro branco e redesenhe os elementos conforme os trabalhou anteriormente, construindo o conceito desde o início. Siga completamente o conceito que você já elaborou para obter feedback sobre o trabalho já realizado. Depois de cobrir o trabalho que você já fez, abra a discussão e convide-os a sugerir revisões. Tendo visto esse conceito, eles têm algum insight sobre como simplificar drasticamente ou abordar o problema de forma diferente?

Dependendo de como a conversa prosseguir, você poderá validar sua abordagem ou descobrir alguns problemas que o enviarão de volta para mais uma rodada de modelagem.

Mitigando Riscos e Pronto para Redigir #

No final desta etapa, temos os elementos da solução, remendos para potenciais armadilhas e cercas em torno das áreas que declaramos fora dos limites. Passamos de uma solução rudimentar com risco potencial para uma ideia sólida na qual esperamos apostar no futuro.

Isso significa que estamos prontos para fazer a transição de um planejamento privado e obtenção de feedback de um círculo interno para apresentar a ideia na mesa de apostas. Para isso, escrevemos a ideia de uma forma que comunique os limites e detalhe a solução para que pessoas com menos contexto possam entender e avaliar. Esse “Pitch” será o documento que usaremos para buscar recursos, coletar feedback mais amplo, se necessário, ou simplesmente capturar a ideia para quando o momento for mais oportuno no futuro.