Português

Levantamento de Requisitos Que Não Muda no Meio da Construção

São dois dias antes do lançamento. O painel está construído, testado e na fila para a demonstração de segunda-feira. Então o e-mail chega: "Oi, você pode só adicionar mais uma coisa? Precisamos também filtrar por região. E talvez por tempo de casa. Ah, e o CFO mencionou que quer uma visão YoY." Você olha para a tela. Você escreveu um documento de requisitos. Conduziu um kickoff. Enviou as notas da reunião. Nada disso impede a solicitação, porque nada disso é o artefato que previne a mudança.

No papel, a culpa é do BA. Você deixou passar requisitos. Não fez as perguntas certas. Deveria ter previsto que o CFO se importaria com o YoY. A engenharia reconstrói o mesmo gráfico pela terceira vez em duas semanas. As partes interessadas discretamente rebaixam você de "parceiro de confiança" a "processador de tickets". Você começa a adicionar 40% a cada estimativa só para absorver o churn inevitável.

A solução não é mais documentação. É uma documentação diferente, escrita nos primeiros 90 minutos, assinada antes de qualquer ticket ser aberto. Uma página na entrada, uma página na saída, com data, com nome, enviada por e-mail a uma pessoa com autoridade para dizer sim. Todo o resto é teatro.

Esse é o Playbook que uso em toda solicitação interna agora: painel, analytics, ferramenta interna, análise ad hoc. Leva 90 minutos para fazer corretamente. Economiza 2 a 3 semanas de reconstrução por projeto. A matemática não é sutil.

O Formulário de Entrada: Uma Página, Cinco Campos

O formulário de entrada tem uma página. Não cinco. Não oito. Uma. Se passar para uma segunda página, você está permitindo que o solicitante esconda raciocínio vago dentro de um muro de texto. Cinco campos. Se qualquer um dos cinco estiver em branco, o projeto não começa. Isso não é uma diretriz. É a regra.

Campo 1: O Problema. O que está quebrado agora? Não "precisamos de um painel." Isso é uma solução. O problema é "a chefe de CS gasta 4 horas toda segunda-feira construindo um relatório de rotatividade de clientes a partir de três CSVs e os números divergem do Salesforce." Se o solicitante responder "precisamos de um painel" novamente, pergunte: o que o painel permitiria que você parasse de fazer? Empurre até que o verbo seja removido, não adicionado.

Campo 2: A Decisão Que o Output Vai Informar. Todo painel, todo relatório, toda análise existe para informar uma decisão. Escreva a decisão. "Se vamos expandir a equipe de SDR para 12 ou 8 representantes no próximo trimestre." "Se vamos descontinuar o plano legado." "Se vamos realocar o budget de marketing de mídia paga para eventos." Se o solicitante não consegue nomear uma única decisão específica, a solicitação é decoração, não apoio à decisão. O campo 2 é o elemento de eliminação de expansão do escopo mais eficiente do formulário.

Campo 3: A Métrica de Sucesso. Como saberemos que isso funcionou, seis semanas depois? Não "as pessoas usam." Não "é útil." Um resultado mensurável: "O tempo do relatório de CS na segunda-feira cai de 4 horas para menos de 30 minutos." "A decisão de descontinuação é tomada até o final do Q2 com justificativa documentada." "O memorando de realocação de budget de marketing referencia esta análise." O campo 3 é o que você verifica na validação pós-entrega. Se for vago aqui, é impossível medir depois, e o projeto entra silenciosamente no cemitério do "isso importou mesmo?".

Campo 4: Dentro do Escopo. Específico, com marcadores, finito. "Taxa de rotatividade de clientes por mês, por tier de plano, por coorte de cadastro. Filtrado para os últimos 12 meses. Atualiza diariamente." Cinco a oito marcadores no máximo. Se você tem 14 marcadores, não está delimitando um painel, está delimitando uma plataforma.

Campo 5: Fora do Escopo. Esse é o campo que todos esquecem. Liste, explicitamente, o que você não está construindo. "Sem segmentação por região. Sem segmentação por representante de vendas. Sem histórico além de 12 meses. Sem tempo real. Sem exportação para Excel." O campo "fora do escopo" é o único que paga por si mesmo dez vezes. Quando o solicitante voltar na semana três pedindo a segmentação regional, você aponta para o campo 5. Ele nomeou. Assinou. A conversa é curta, objetiva e sem emoção.

Se qualquer um desses cinco campos estiver em branco ou vago, recuse o projeto. Com gentileza. "Não consigo começar sem uma resposta específica para o campo 2. Que decisão isso vai informar? Podemos marcar 30 minutos para descobrir?" Recusar não é grosseiro. Começar com uma solicitação vaga e depois "perder" requisitos duas semanas depois é que é grosseiro.

A Pergunta "O Que Você Faria Com a Resposta"

Essa é a pergunta mais útil no trabalho de BA, e quase ninguém a faz.

O cenário: o solicitante quer um painel mostrando scores de saúde de clientes. Você pergunta, com calma: "Se o score do Cliente X for 72, o que você faria? E se for 45? E se for 88?" Três coisas acontecem.

Se conseguirem responder com clareza ("Acima de 80, sem ação. De 60 a 80, o CSM agenda um check-in. Abaixo de 60, vai para a fila de retenção"), você tem um requisito real. Os números mapeiam para ações. O painel é apoio à decisão.

Se hesitarem e disserem "bem, observaríamos a tendência" ou "depende" ou "discutiríamos na reunião semanal", você tem um requisito de decoração. Eles querem que o número exista, não porque muda o comportamento, mas porque parece responsável acompanhar. Requisitos de decoração representam 60 a 70% das solicitações internas, na minha experiência. Construa-os e ficarão sem uso por seis meses.

Se reagirem com rispidez e disserem "vamos saber quando ver", você tem um requisito de vibes. Pior que decoração, porque o solicitante acredita que suas vibes são uma especificação. Requisitos de vibes mudam diariamente porque nunca foram uma especificação.

O roteiro para fazer a pergunta sem parecer combativo importa. Não diga "isso é útil mesmo?" Diga: "Quero ter certeza de que estou construindo a coisa certa. Me explique o que você faria numa segunda-feira de manhã se abrisse isso e o número fosse [X]. Depois me explique a mesma coisa se fosse [Y]." Você está enquadrando como o seu problema ("quero construir a coisa certa"), não como um interrogatório. O solicitante geralmente responde honestamente porque não percebe que está revelando se o requisito é real ou decorativo.

Se a resposta for decoração ou vibes, você tem três opções. Opção um: recusar educadamente, citando capacidade. Opção dois: construir uma versão menor e mais barata (uma query SQL que podem executar, não um painel completo) e revisitar em um mês. Opção três: ter uma conversa franca sobre se a questão mais profunda é "ainda não sabemos como gerenciar essa coisa", que é um problema de descoberta, não um problema de painel, e provavelmente precisa de uma hora de análise, não de um sprint de engenharia.

Protótipo Primeiro Quando Possível

Antes de qualquer SQL ser escrito. Antes de qualquer ticket ser aberto. Esboce o painel.

Figma funciona. Google Sheets funciona melhor, honestamente, porque permite falsificar os dados e o solicitante pode olhar para eles como olharia para o produto real. PowerPoint com retângulos funciona se necessário. O ponto não é a ferramenta. O ponto é colocar uma imagem da resposta na frente do solicitante antes de comprometer qualquer hora de engenharia.

Uma simulação de 30 minutos elimina aproximadamente 80% do retrabalho que aconteceria durante a construção. Esse número não é exato. É o que observei em cerca de 60 projetos internos nos últimos anos. Às vezes é 95%. Às vezes é 60%. Nunca é abaixo de 50%.

O que acontece na revisão do protótipo é que o solicitante finalmente vê concretamente o que pediu e percebe uma de três coisas. (a) "Ah, na verdade preciso que as linhas estejam na outra ordem." (b) "Achei que queria um gráfico de barras, mas um gráfico de linha com média móvel de 4 semanas é o que estou buscando." (c) "Isso não responde minha pergunta. Preciso ver a segmentação por [coisa não incluída na solicitação original]." As três descobertas são gratuitas em uma simulação no Google Sheets. Num painel já construído, são caras.

O protótipo primeiro não se aplica a tudo. Mudanças no backend, trabalho de integração, limpeza de pipeline de dados, migrações de schema: não há simulação útil de 30 minutos para "precisamos mesclar duas tabelas de clientes". Quando o protótipo primeiro não se aplica, o substituto é um exemplo de output escrito: "Aqui está a linha de dados que você vai receber desta integração. Aqui estão os quatro campos. Aqui está o que cada campo significa em português simples." Exemplos escritos são o equivalente do protótipo para trabalho de backend. Mesmo propósito: identificar mal-entendidos de forma barata.

Aprovação Formal dos Requisitos: Escrita, com Data, com Nome

Esse é o parágrafo mais importante de todo este Playbook.

A aprovação formal é o artefato. Não o documento. Não a reunião. Não o thread do Slack. O e-mail com o resumo de uma página anexado, enviado ao solicitante e ao gestor dele, pedindo uma resposta escrita que diga "aprovado." Esse e-mail, com o carimbo de data e a resposta, é a única coisa que fica entre você e a expansão do escopo.

A mecânica: escreva um resumo de uma página dos cinco campos. Envie por e-mail (não Slack, não Teams, não um comentário no Jira) para o solicitante e o gestor direto dele. O corpo do e-mail diz: "Conforme nossa conversa de entrada em [data], aqui está o resumo do que estamos construindo, a decisão que informa, a métrica de sucesso, o que está dentro do escopo e o que está explicitamente fora do escopo. Por favor, responda 'aprovado' para prosseguir. O trabalho de engenharia começa no recebimento da aprovação."

Dois motivos para copiar o gestor. Primeiro, o gestor geralmente é quem tem autoridade de orçamento e será questionado sobre "onde foram as horas de engenharia?" se o escopo mudar. Ele precisa ver a solicitação original. Segundo, o gestor também é o mais propenso a adicionar escopo no meio da construção ("ei, já que está nisso..."), e tê-lo no e-mail de aprovação original dá a você o artefato para rebater.

Sim verbal não é sim. Polegar levantado no Slack não é sim. "Parece bom" numa reunião não é sim. Resposta-com-aprovado por e-mail, com data, com solicitante e gestor no thread. Isso é sim. Já perdi argumentos sobre expansão do escopo quando tinha um sim verbal e nenhum rastro de e-mail. Nunca perdi nenhum quando tinha o e-mail.

O rastro em papel com data é a única defesa do BA quando o escopo muda. Essa frase não é dramática. É o único motivo pelo qual esta etapa existe. Sem ela, toda mudança de escopo disputada vira uma disputa de memória, e o BA sempre perde disputas de memória contra solicitantes de maior posição na organização.

Tratamento de Expansão do Escopo: Três Sins, Sete Nãos

No meio da construção, o solicitante quer adicionar algo. Isso vai acontecer. Não é sinal de fracasso. É o estado estável do trabalho interno.

Existem três razões legítimas para expandir o escopo no meio da construção, e sete razões ilegítimas.

Três razões legítimas (você diz sim, com um novo prazo):

  1. Mudança regulatória. Um novo requisito de conformidade chegou que afeta o output. O painel deve mostrar o novo campo ou não pode ser entregue. Sim, e aqui está a nova data.
  2. Bug bloqueante ou problema de dados. Durante a construção, você descobre que os dados subjacentes estão errados, ausentes ou contraditórios de forma que torna a especificação original impossível. Sim, e precisamos pausar para corrigir os dados; a nova data é X.
  3. Surpresa de dependência. Um sistema upstream que você não conhecia (ou que acabou de mudar) significa que a abordagem de integração original está inviável. Sim, e precisamos redesenhar essa parte; a nova data é X.

Sete razões ilegítimas (você diz "sim, e aqui está o novo prazo", mas o prazo é a negociação):

  1. "Já que você está nisso." A parte interessada pensou em algo novo.
  2. "[Pessoa sênior] viu o protótipo e quer..." A revisão do protótipo gerou uma nova solicitação.
  3. "Marketing também quer..." Um novo solicitante está sendo introduzido sorrateiramente no projeto original.
  4. "Seria útil também ver..." Creep de decoração.
  5. "Mudamos de ideia sobre a métrica." O campo 3 está sendo reescrito no meio do projeto.
  6. "Você pode deixar dinâmico?" Hardcoded para parametrizado é uma reconstrução, não um ajuste.
  7. "Só uma coisinha pequena." Essa frase quase sempre é um sinal. Pequena para pedir, grande para construir.

Observe que tanto para razões legítimas quanto ilegítimas, a resposta é "sim, e." Nunca "não." A palavra não faz de você um burocrático. A frase "sim, e aqui está o novo prazo" faz de você um parceiro que simplesmente é honesto sobre o custo.

O template de controle de mudanças abaixo é o que torna "sim, e" aplicável. Sem ele, "sim, e" vira "sim", porque nada está documentado e a nova data silenciosamente regride para a data antiga na cabeça do solicitante.

Template de Controle de Mudanças

Cinco campos. E-mail. Com data. Assinado.

ASSUNTO: Solicitação de mudança: [nome do projeto] ([data])

Data da aprovação formal original: [data]
Projeto: [nome]

1. O QUE MUDOU (uma frase): _________________________________

2. POR QUÊ (uma frase: link para a razão legítima ou, se não houver, nomeie a troca):
   _________________________________

3. IMPACTO NO PRAZO (nova data de entrega em AAAA-MM-DD):
   Data antiga: _______
   Nova data: _______

4. IMPACTO NOS OUTROS SOLICITANTES (quais outros projetos atrasam, por quanto tempo):
   _________________________________

5. APROVAÇÃO FORMAL DO SOLICITANTE NA NOVA DATA: Responda "aprovado" para confirmar a nova data.

É isso. Cinco campos. Envie dentro de uma hora após o pedido de mudança de escopo. O solicitante responde "aprovado" ou não responde. Se não responder, o escopo original e a data original se mantêm.

Nunca verbal. Nunca sem data. Nunca "vamos absorver isso." Absorver escopo sem registrar por escrito é como BAs terminam esgotados, culpados e sem conseguir apontar um único momento em que o projeto saiu dos trilhos.

Validação Pós-Entrega: O Check-In de Duas Semanas

Duas semanas após a entrega, você agenda 30 minutos com o solicitante. Uma pergunta: a métrica de sucesso no campo 3 realmente se moveu?

Se sim, registre. Duas frases no seu documento de portfólio, no seu pacote de avaliação de desempenho, na sua autoavaliação de fim de ano. "Construí o painel de rotatividade de clientes para a equipe de CS. O tempo do relatório de segunda-feira caiu de 4 horas para 22 minutos em três semanas após o lançamento (meta: abaixo de 30 minutos). Decisão: a chefe de CS usou o painel para justificar a contratação de +2 CSMs no planejamento do Q3." Esse é o tipo de artefato que promove BAs. Itens vagos de "entregou painel" renovam BAs, não os promovem.

Se não (e essa é a parte que a maioria dos BAs erra), isso não é um fracasso a ser enterrado. É uma descoberta. Escreva: "Construí o painel. Duas semanas depois, a chefe de CS o abriu 3 vezes. O tempo do relatório de segunda-feira não mudou. Hipótese: a decisão subjacente (quais CSMs atribuir a quais contas) está sendo tomada com base em relacionamentos, não em dados, e o painel não aborda o gargalo real."

Esse writeup é ouro. É a entrada para o próximo formulário. É o motivo pelo qual a sua próxima solicitação da mesma equipe será mais precisa, porque você tem dados sobre o que não funcionou da última vez. Fracassos enterrados são desperdício. Fracassos expostos se acumulam como expertise.

O check-in de duas semanas também fecha o loop com o solicitante. Eles se sentem acompanhados. São mais propensos a trazer o próximo problema real em vez da próxima solicitação vaga, porque aprenderam que você se importa com o resultado, não apenas com a entrega.

O Fluxo em 90 Minutos

Do início ao fim, o trabalho inicial é de noventa minutos.

  • 30 minutos: ligação de entrada. Percorra os cinco campos. Faça a pergunta "o que você faria com a resposta". Registre a decisão e a métrica de sucesso.
  • 30 minutos: prototipe a resposta (Sheets, Figma, ou exemplo de output escrito). Envie ao solicitante. Pergunte "é isso que você faria algo numa segunda-feira de manhã?".
  • 30 minutos: escreva o e-mail de aprovação formal de uma página. Copie o gestor. Peça "responda com aprovado". Aguarde a resposta.

Total: 90 minutos. Depois disso, o trabalho de engenharia começa. Durante a construção, qualquer pedido de escopo recebe o formulário de controle de mudanças de cinco campos em até uma hora. Duas semanas após a entrega, você conduz a verificação de validação.

Noventa minutos de disciplina inicial substitui duas a três semanas de churn de reconstrução por projeto. Também substitui a erosão lenta de confiança que ocorre quando as partes interessadas sentem que todo projeto atrasa e sai um pouco diferente. Ambos os custos são invisíveis até que você pare de pagá-los. Uma vez que para, não volta atrás.

O documento não é o artefato. A reunião não é o artefato. O thread do Slack definitivamente não é o artefato. O e-mail com data, nome e aprovação formal é o artefato. Construa o restante da prática em torno de conseguir esse único e-mail, toda vez, antes de qualquer código ser escrito.

Saiba Mais