Um bom briefing de projeto explica quem precisa de ajuda, o que essas pessoas precisam fazer e como é um resultado bem-sucedido. Alguns parágrafos claros, um rascunho simples e um exemplo concreto já nos dão um ponto de partida.
Uso esse contexto para fazer perguntas e definir o trabalho com você antes de propor escopo e prazos. Este guia mostra o que incluir, usando como exemplo um produto de agendamento fictício. As mesmas perguntas valem para um app novo, um bot ou uma funcionalidade em um produto que já existe.
Comece pelo problema e pelas pessoas
Conte quem vai usar o produto, o que essas pessoas tentam fazer e como fazem isso hoje. No nosso exemplo de agendamento: “Os clientes mandam mensagem para a equipe pedindo um horário. A equipe consulta uma agenda compartilhada, envia um link de pagamento e confirma cada reserva manualmente.” Isso explica o trabalho que o software precisa apoiar.
Inclua o resultado que você quer ver. Pode ser menos etapas manuais, um fluxo de agendamento que funcione ou uma forma de o cliente acompanhar o pedido. Se você já mede algo hoje, compartilhe o número. Se não, descreva como seria um bom resultado.
Percorra uma tarefa importante
Escolha uma tarefa que faça diferença e descreva do começo ao fim. Por exemplo: um cliente escolhe um serviço, seleciona um horário livre, paga e recebe uma confirmação. Depois, alguém da equipe pode ver ou cancelar a reserva.
Fale também das exceções. O que acontece se o pagamento falhar, se o cliente mudar de ideia ou se duas pessoas escolherem o mesmo horário? Você não precisa resolver cada caso sozinho. Levantar a pergunta já nos ajuda a descobrir o trabalho antes de assumir um prazo.
Decida o que a primeira versão precisa ter
Separe o que é necessário para uma primeira versão útil do que pode vir depois. Um produto de agendamento pode precisar de um único provedor de pagamento no lançamento, enquanto assinaturas e recompensas por indicação podem esperar. Suas prioridades me ajudam a propor uma versão que já seja útil por si só.
O nome de uma funcionalidade pode esconder várias decisões. Para “contas de cliente”, diga quem pode se cadastrar, o que cada um pode ver, se a equipe tem permissões diferentes e o que acontece quando alguém perde o acesso. Tudo bem deixar esses pontos como perguntas para resolvermos juntos.
Escreva como você vai conferir que uma funcionalidade está pronta. “Enviar e-mails de reserva” abre espaço para expectativas diferentes. Uma verificação mais clara seria: “Depois de um pagamento aprovado, o cliente recebe um e-mail com o código da reserva, a data e as instruções de cancelamento.”
Essas verificações costumam ser chamadas de critérios de aceitação. Oguia do GOV.UK sobre histórias de usuário explica a mesma ideia: descreva a necessidade do usuário e depois liste os resultados que confirmam que ela foi atendida.
Compartilhe o que já existe
Seu site ou app atual, e se as pessoas já estão usando.
Designs, materiais da marca, conteúdos e exemplos de interfaces de que você gosta. Explique o que você gosta em cada exemplo.
Serviços que precisam se conectar ao produto, como pagamentos, e-mail, um CRM ou um bot do Telegram.
Dados existentes que precisam ser migrados, e quem é o dono das contas envolvidas.
Restrições como idiomas necessários, dispositivos, requisitos de acessibilidade ou uma tecnologia já escolhida.
Se você está melhorando um produto que já existe, diga isso logo de início. Uma funcionalidade pode envolver mudanças nos dados, nas permissões e nos fluxos atuais. Revisar o sistema existente faz parte de entender o escopo.
Explique o prazo e quem decide
Se existe uma data de lançamento, conte por que ela importa e o que precisa estar pronto até lá. Uma data ligada a um evento leva a escolhas diferentes de uma data desejada. Uma faixa de orçamento, se você tiver, também ajuda a discutir prioridades antes de eu montar uma proposta.
Indique quem pode confirmar as prioridades e aprovar o trabalho. Fale também das dependências: conteúdo pendente, acessos que estão com um desenvolvedor anterior ou outra equipe responsável por uma integração. Isso pode afetar o planejamento tanto quanto o código.
Como é um bom briefing inicial
Oferecemos serviços com hora marcada. Hoje os clientes agendam por mensagem e a equipe confere a disponibilidade manualmente.
Na primeira versão, os clientes devem escolher um serviço e um horário livre, pagar pelo nosso provedor atual e receber uma confirmação da reserva. A equipe precisa ver as reservas e cuidar dos cancelamentos.
Já temos site, identidade visual e uma conta de pagamentos. Pacotes de assinatura e recompensas por indicação podem vir depois.
Precisamos de ajuda para decidir como cancelamentos e pagamentos recusados devem funcionar. Temos uma data de lançamento preferida, mas queremos combinar o que é realista depois que essas perguntas forem respondidas.
Mesmo esse exemplo deixa coisas a definir: regras de disponibilidade, reembolsos, permissões da equipe e o conteúdo de cada confirmação. Isso é normal. Um briefing inicial dá contexto suficiente para identificar essas decisões.
Um briefing para copiar
Queremos criar ou melhorar: …
As pessoas que vão usar são: …
O problema do processo atual é: …
A tarefa mais importante que um usuário deve concluir é: …
Para a primeira versão, precisamos de: …
Estas funcionalidades podem esperar: …
O que já existe, incluindo designs e integrações: …
Nosso prazo, restrições e faixa de orçamento, se soubermos: …
Vamos considerar um sucesso quando: …
A pessoa que toma as decisões é: …
Deixe uma linha em branco se ainda não souber a resposta. Deixe as perguntas em aberto bem visíveis. Depois que combinarmos o escopo, cada novo pedido deve vir acompanhado de uma conversa sobre o efeito dele no trabalho e no prazo antes de ser incluído.
Você podeenviar seu briefing aqui. Trabalho por escrito, então não há apresentação nem chamada para preparar. Vou responder com perguntas e próximos passos antes de combinarmos o trabalho.