Visão geral do curso

Objetivo geral: desenvolver as habilidades de gestão necessárias para conduzir implementações de sistemas de forma independente da plataforma.

Sequência: Módulo 1 → 2 → 3 → 4 → 5 → 6 — segue a ordem natural de um projeto de implementação, do levantamento até o acompanhamento.

Levantamento de Requisitos

Objetivo: sair de uma reunião com o que o cliente precisa, não só com o que ele pediu.

1. Por que esse módulo vem primeiro

Todo o resto do curso depende disso. Se o levantamento sai errado, você mapeia processo errado, o consultor implementa a coisa errada, e o cliente resiste a uma mudança que nem resolve o problema dele. A maior parte do retrabalho em projeto de implementação nasce aqui, não na etapa técnica.

2. Requisito, desejo e sintoma — a distinção que muda tudo

Cliente raramente descreve o problema. Ele descreve a dor, ou pior, já chega com a solução pronta na cabeça. Seu trabalho é separar três camadas:

• Sintoma — o que o cliente sente ou reclama. Ex: “a gente perde muito tempo procurando informação de cliente”.
• Desejo — a solução que ele já imaginou. Ex: “eu preciso de um sistema com busca rápida”.
• Requisito real — o que de fato resolve a causa. Ex: os dados do cliente estão espalhados em 3 lugares diferentes e ninguém sabe qual é a versão atualizada — o problema não é “busca lenta”, é falta de fonte única de verdade.

Regra prática: toda vez que o cliente te der uma solução pronta, pergunte o problema por trás. A solução é hipótese dele. O problema é fato. Você trabalha com fato.

3. Técnicas de entrevista

3.1 Pergunta aberta vs. fechada

Fechada, evitar no início: “Vocês usam WhatsApp para atender cliente?” — só confirma o que você já supõe.
Aberta, usar primeiro: “Como funciona hoje o atendimento a um cliente novo, do primeiro contato até o fechamento?” — deixa o cliente revelar o processo real, com detalhes que você nem sabia perguntar.

Comece sempre aberto. Feche o cerco com perguntas fechadas só depois, para confirmar detalhes específicos.

3.2 Técnica dos 5 porquês

Pergunte “por quê” repetidamente até chegar na causa raiz — geralmente leva 3 a 5 rodadas.

Pare quando a resposta virar algo que você consegue transformar em requisito técnico ou de processo — não precisa forçar até um “porquê filosófico”.

3.3 Perguntas-âncora para toda reunião de levantamento

• Como isso é feito hoje, passo a passo?
• O que acontece quando dá errado?
• Quem mais participa desse processo além de você?
• Se isso não mudasse nunca, o que continuaria doendo daqui a 6 meses?
• Existe algo que vocês tentaram resolver antes e não deu certo? Por quê?

4. Priorização de requisitos

Nem tudo que sai da reunião tem o mesmo peso. Classifique em três níveis:

Isso evita duas armadilhas: prometer tudo (e nunca entregar) ou tratar um “seria bom ter” como se fosse bloqueante.

5. Documentar de forma que o consultor consiga agir

Reporte de levantamento ruim é aquele que obriga o consultor a te chamar de novo pra entender o que você quis dizer. O bom documento responde, para cada requisito:

1. O que é (em uma frase, sem jargão)
2. Por que é necessário (o problema/causa raiz, não o sintoma)
3. Quem pediu / quem é afetado
4. Nível de prioridade (essencial / importante / desejável)
5. Alguma restrição conhecida (prazo, orçamento, sistema legado que precisa continuar funcionando)

Modelo pronto — Documento de Requisitos Levantados

CLIENTE: [nome]
DATA DA REUNIÃO: [data]
PARTICIPANTES: [nomes/cargos]

REQUISITO 1
O que é: 
Problema/causa raiz por trás: 
Quem pediu / quem é afetado: 
Prioridade: [Essencial / Importante / Desejável]
Restrições conhecidas: 

REQUISITO 2
[repetir estrutura]

OBSERVAÇÕES GERAIS DA REUNIÃO:
[qualquer contexto relevante que não virou requisito, mas ajuda a entender o cenário]

Próximo módulo: 02 — Condução de Reuniões, em breve.