Estabelecendo Limites

Estabelecendo-Limites.png

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 potenciais que não levam a lugar algum.

Outras ideias são menos empolgantes e parecem mais um desafio que não pedimos. O cliente quer um calendário; nós não queremos especialmente construir um, mas sentimos que precisamos fazer algo sobre o pedido.

Seja estando ansiosos para começar ou relutantes em mergulhar de cabeça, ajuda definir explicitamente quanto do nosso tempo e atenção o assunto merece. Isso é algo que vale um conserto rápido, se conseguirmos? É uma grande ideia que vale um ciclo inteiro? Redesenharíamos o que já temos para acomodá-la? Só consideraremos isso se pudermos implementar como um pequeno ajuste?

Chamamos isso de apetite. Você pode pensar no apetite como um orçamento de tempo para um tamanho de equipe padrão. Geralmente definimos o apetite em dois tamanhos:

Em casos raros, quando o escopo é tão grande que um projeto de seis semanas não é concebível, tentaremos reduzi-lo diminuindo a definição do problema. Se ainda não conseguirmos reduzir o escopo, separamos uma parte significativa do projeto que podemos modelar dentro de um apetite de seis semanas.

Tempo Fixo, Escopo Variável

Um apetite é completamente diferente de uma estimativa. Estimativas começam com um design e terminam com um número. Apetites começam com um número e terminam com um design. Usamos o apetite como uma restrição criativa no processo de design.

Este princípio, chamado "tempo fixo, escopo variável," é fundamental para definir e entregar projetos com sucesso. Veja este livro como exemplo. É difícil finalizar um livro quando você pode sempre adicionar mais, explicar melhor ou melhorar o que já está escrito. Quando você tem um prazo, de repente precisa tomar decisões. Com uma semana restante, posso escolher entre corrigir erros de digitação ou adicionar uma nova seção a um capítulo. Essa é a tensão entre tempo, qualidade e escopo. Não quero lançar um livro com erros de digitação embaraçosos, então escolho reduzir o escopo deixando de fora a seção extra. Sem a pressão do prazo fixo, eu não faria essa troca. Se o escopo não fosse variável, teria que incluir a seção extra, e não haveria tempo para corrigir os problemas de qualidade.

Aplicamos esse princípio em cada etapa do processo, desde modelar projetos potenciais até construí-los e entregá-los. Primeiro, o apetite restringe o tipo de solução que desenhamos durante o processo de modelagem. Depois, quando passamos o trabalho para uma equipe, o tempo fixo os impulsiona a tomar decisões sobre o que é essencial para o projeto e o que é periférico ou desnecessário.

"Bom" é Relativo

Não existe uma definição absoluta para "a melhor" solução. O melhor é relativo às suas restrições. Sem um limite de tempo, sempre haverá uma versão melhor. A refeição ideal pode ser um jantar de dez pratos. Mas quando você está com fome e com pressa, um cachorro-quente é perfeito.

A quantidade de tempo que definimos para o nosso apetite nos levará a diferentes soluções. Podemos modelar um conjunto completo de colunas de banco de dados na versão mais elaborada, ou simplesmente fornecer uma área de texto na versão mais simples. Podemos redesenhar a página principal para acomodar um novo recurso, ou podemos empurrá-lo para uma tela com menos restrições de design. Só podemos julgar o que é uma solução "boa" no contexto de quanto tempo queremos gastar e quão importante isso é.

Respondendo a Ideias Brutas

Nossa resposta padrão para qualquer ideia que surgir deve ser: "Interessante. Talvez algum dia." Em outras palavras, um "não" muito suave que deixa todas as nossas opções em aberto. Não colocamos no backlog ou em alguma lista de pendências. Damos espaço para podermos aprender se é realmente importante e o que isso pode envolver.

É muito cedo para dizer "sim" ou "não" no primeiro contato. Mesmo que estejamos empolgados com a ideia, não devemos nos comprometer com algo que ainda não entendemos completamente. Precisamos trabalhar na ideia antes que ela esteja suficientemente modelada para apostarmos recursos nela. Se sempre dissermos "sim" às solicitações que chegam, acabaremos com uma pilha gigante de trabalho que só cresce.

É importante manter uma atitude tranquila e um pouco de “poker face”. Não queremos descartar uma ideia que não entendemos. Novas informações podem surgir amanhã que nos farão vê-la de forma diferente. Por outro lado, demonstrar muito entusiasmo imediatamente pode criar expectativas de que isso vai acontecer. Pode ser que não consigamos nos comprometer com isso depois de colocá-lo no contexto de tudo o que queremos fazer.

Reduzindo o Problema

Além de definir o apetite, geralmente precisamos afunilar nossa compreensão do problema.

Certa vez, um cliente nos pediu regras de permissão mais complexas. Facilmente poderia levar seis semanas para implementar a mudança que ela queria. Em vez de aceitar o pedido ao pé da letra, investigamos mais a fundo. Descobrimos que alguém havia arquivado um arquivo sem saber que o arquivo desapareceria para todos os outros que usavam o sistema. Em vez de criar uma regra para impedir algumas pessoas de arquivar, percebemos que poderíamos colocar um aviso na ação de arquivar explicando o impacto. Isso é uma mudança de um dia em vez de um projeto de seis semanas.

Outro exemplo é a “visualização de calendário” do capítulo anterior. Todo mundo sabe o que é uma visualização de calendário. Mas, ao desmembrá-la, revelamos uma série de desconhecidos e decisões que afetariam drasticamente o escopo. Se quisermos gastar apenas seis semanas em vez de seis meses construindo um grande calendário, como podemos restringi-lo?

Nesse caso, mudamos a pergunta de “O que podemos construir?” para “O que realmente está dando errado?” Claro, um calendário parece bom. Mas o que está motivando o pedido? Em que ponto específico o fluxo de trabalho atual de alguém se rompe sem essa coisa que estão pedindo?

Estudo de Caso: Definindo "calendário"

No caso da solicitação de um calendário, ligamos para uma cliente que pediu essa funcionalidade. Em vez de perguntar por que ela queria um calendário e como ele deveria ser, perguntamos quando ela queria um calendário. O que ela estava fazendo quando pensou em pedir isso?

Ela nos contou que trabalhava em um escritório com um grande calendário desenhado em uma parede de lousa. Seus colegas marcavam quando estavam encontrando clientes nas poucas salas de reunião disponíveis no calendário. Um dia, ela estava trabalhando de casa. Um cliente ligou e pediu para agendar uma reunião. Ela teve que dirigir até o escritório para olhar o calendário da parede. O trânsito estava terrível e, no final, não havia um espaço livre que funcionasse para o cliente dela. Ela poderia ter economizado uma hora no trânsito e muita frustração se pudesse verificar os horários disponíveis no calendário de seu computador em casa.

O insight não foi “computadorizar o calendário” – isso é óbvio. O que aprendemos foi que “ver espaços livres” era a coisa importante para esse caso de uso, não “fazer tudo o que um calendário faz”.

Essa história, e outras semelhantes, nos deram uma base específica e contexto para o design. O Basecamp tinha uma visualização de agenda de eventos. Funcionava para listar prazos importantes e marcos, mas não era bom para agendamento de recursos porque não se podia ver espaços vazios. Reduzimos a necessidade de “fazer tudo o que um calendário faz” para “me ajudar a ver espaços livres para que eu possa agendar algo”.

Ainda não tínhamos uma solução. Mas agora sentíamos que tínhamos um problema específico o suficiente para despertar uma ideia que pudesse se encaixar no nosso apetite. Isso nos levou ao conceito mais simples de “Grade de Pontos” do último capítulo.

E se não conseguirmos identificar um ponto específico de dor ou caso de uso? Nosso apetite também pode nos dizer quanto vale a pena pesquisar. Se não for crítico agora e não conseguirmos entender bem o problema, vamos deixá-lo de lado e trabalhar em outra coisa. Talvez no futuro um novo pedido ou história surja e nos dê uma melhor compreensão do problema.

Cuidado com as “Surpresinhas”

Quando se trata de ideias pouco claras, os piores infratores são os “redesigns” ou “refatorações” que não são motivados por um único problema ou caso de uso. Quando alguém propõe algo como “redesenhar a seção de Arquivos”, isso é uma “surpresinha”, não um projeto. Vai ser muito difícil entender o que isso significa, onde começa e onde termina. Aqui está um ponto de partida mais produtivo: “Precisamos repensar a seção de Arquivos porque compartilhar vários arquivos leva muitos passos.” Agora podemos começar a perguntar: O que não está funcionando? Em que contexto há muitos passos? Quais partes do design atual podem permanecer as mesmas e quais precisam mudar?

Um sinal claro de uma “surpresinha” é o rótulo “2.0”. No passado, cometemos o erro de iniciar um projeto “Arquivos 2.0” sem realmente considerar o que isso significava. Nossa empolgação em melhorar uma grande parte do nosso aplicativo nos dominou. Sabíamos que havia muitos problemas com nossa funcionalidade de Arquivos, mas não perguntamos a nós mesmos o que exatamente íamos fazer. O projeto acabou sendo uma bagunça porque não sabíamos definir o que era “feito”. Conseguimos nos recuperar dividindo o projeto em projetos menores, como “Melhores pré-visualizações de arquivos” e “Cores personalizadas de pastas”. Definimos apetites e expectativas claras para cada projeto e os entregamos com sucesso.

Limites no Lugar

Quando temos essas três coisas—uma ideia bruta, um apetite e uma definição reduzida do problema—estamos prontos para passar para o próximo passo e definir os elementos de uma solução.