10 min leitura • Guide 770 of 877
Melhores Práticas de Comunicação com Cliente
Boa comunicação com cliente constrói confiança e previne surpresas. O GitScrum ajuda equipes a compartilhar progresso, gerenciar expectativas e envolver clientes de forma apropriada.
Ritmo de Comunicação
Atualizações Regulares
CADÊNCIA DE COMUNICAÇÃO COM CLIENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ATUALIZAÇÃO SEMANAL (Padrão): │
│ │
│ FORMATO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ATUALIZAÇÃO SEMANAL DO PROJETO ││
│ │ Semana de 15 de janeiro, 2024 ││
│ │ ││
│ │ CONCLUÍDO ESTA SEMANA: ││
│ │ ✅ Fluxo de autenticação de usuário ││
│ │ ✅ Layout do dashboard ││
│ │ ✅ Design do schema do banco de dados ││
│ │ ││
│ │ EM ANDAMENTO: ││
│ │ 🔄 Integração de pagamento (60% completo) ││
│ │ 🔄 Notificações por email ││
│ │ ││
│ │ PRÓXIMA SEMANA: ││
│ │ • Completar integração de pagamento ││
│ │ • Iniciar módulo de relatórios ││
│ │ ││
│ │ BLOQUEADORES/RISCOS: ││
│ │ ⚠️ Aguardando credenciais de API do provedor de pagamento││
│ │ ││
│ │ STATUS DO MARCO: ││
│ │ MVP: No caminho para 15 de fev ││
│ │ ████████████░░░░░░░░ 60% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TEMPO: │
│ • Enviar no mesmo dia cada semana (ex.: sexta 15h) │
│ • Formato consistente │
│ • Breve é melhor (pode expandir se houver perguntas) │
└─────────────────────────────────────────────────────────────┘
Revisões de Marco
COMUNICAÇÃO DE MARCO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REUNIÃO DE REVISÃO DE MARCO: │
│ │
│ AGENDA: │
│ 1. Demo de features concluídas (15 min) │
│ 2. Discutir próximos passos (10 min) │
│ 3. Coletar feedback (10 min) │
│ 4. Abordar perguntas/preocupações (10 min) │
│ │
│ PREPARAÇÃO: │
│ ☐ Ambiente de demo funcional │
│ ☐ Lista de features concluídas │
│ ☐ Escopo do próximo marco │
│ ☐ Problemas/limitações conhecidos │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RELATÓRIO DE MARCO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ MARCO CONCLUÍDO: MVP Fase 1 ││
│ │ ││
│ │ ENTREGUE: ││
│ │ • Registro e login de usuário ││
│ │ • Dashboard com analytics ││
│ │ • Relatórios básicos ││
│ │ • Design responsivo para mobile ││
│ │ ││
│ │ ADIADO PARA FASE 2: ││
│ │ • Filtragem avançada (per discussão de 10 de jan) ││
│ │ • Exportar para PDF (adicionado ao backlog) ││
│ │ ││
│ │ DEMO: https://staging.example.com ││
│ │ ││
│ │ PRÓXIMO MARCO: Fase 2 (28 de fev) ││
│ │ Foco: Integração de pagamento, gerenciamento de usuário ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Gerenciando Expectativas
Discussões de Escopo
COMUNICAÇÃO DE MUDANÇA DE ESCOPO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUANDO CLIENTE SOLICITA NOVA FEATURE: │
│ │
│ NÃO: │
│ ❌ "Claro, podemos adicionar isso" │
│ ❌ "Isso está fora do escopo" (descartando) │
│ ❌ Prometer sem avaliar impacto │
│ │
│ FAÇA: │
│ ✅ "Deixe-me avaliar o impacto e retorno para você" │
│ ✅ Apresente opções com trade-offs │
│ ✅ Documente a decisão │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RESPOSTA DE MUDANÇA DE ESCOPO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ RE: Adicionando feature de exportar para Excel ││
│ │ ││
│ │ Obrigado pela solicitação. Avaliei o impacto: ││
│ │ ││
│ │ ESTIMATIVA: 3-4 dias de desenvolvimento ││
│ │ ││
│ │ OPÇÕES: ││
│ │ ││
│ │ Opção A: Adicionar agora ││
│ │ • Atrasa Fase 2 em ~1 semana ││
│ │ • Novo alvo: 7 de mar ao invés de 28 de fev ││
│ │ ││
│ │ Opção B: Adicionar à Fase 3 ││
│ │ • Sem impacto na timeline atual ││
│ │ • Disponível meio de março ││
│ │ ││
│ │ Opção C: Substituir feature de baixa prioridade ││
│ │ • Remover exportar PDF, adicionar Excel ao invés ││
│ │ • Sem impacto na timeline ││
│ │ ││
│ │ Deixe-me saber qual opção funciona melhor para você. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CHAVE: Apresente opções, deixe cliente decidir prioridade │
└─────────────────────────────────────────────────────────────┘
Comunicando Atrasos
COMUNICAÇÃO DE ATRASO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUANDO ATRASO É PROVÁVEL: │
│ │
│ TEMPO: Comunique CEDO │
│ • Assim que risco for identificado │
│ • Não no dia antes do prazo │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ COMUNICAÇÃO DE ATRASO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ATUALIZAÇÃO DO PROJETO: Ajuste de Timeline ││
│ │ ││
│ │ Preciso compartilhar uma atualização sobre nossa ││
│ │ timeline da Fase 2. ││
│ │ ││
│ │ SITUAÇÃO: ││
│ │ A integração do provedor de pagamento é mais complexa ││
│ │ que inicialmente planejado. Sua API tem limitações que ││
│ │ precisamos contornar. ││
│ │ ││
│ │ IMPACTO: ││
│ │ Alvo original: 28 de fev ││
│ │ Novo alvo: 7 de mar (1 semana de atraso) ││
│ │ ││
│ │ O QUE ESTAMOS FAZENDO: ││
│ │ • Trabalhando com provedor de pagamento em soluções ││
│ │ • Paralelizando outro trabalho ││
│ │ • Standups diários para minimizar atrasos adicionais ││
│ │ ││
│ │ O QUE PRECISAMOS: ││
│ │ Nenhuma ação necessária de você, só queria manter ││
│ │ informado. Feliz em discutir em nossa próxima chamada. ││
│ │ ││
│ │ Peço desculpas pelo atraso e aprecio sua compreensão. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ESTRUTURA: │
│ 1. Declare a situação claramente │
│ 2. Explique impacto (novas datas) │
│ 3. O que você está fazendo sobre isso │
│ 4. O que você precisa deles (se algo) │
└─────────────────────────────────────────────────────────────┘
Envolvimento do Cliente
Envolvimento Apropriado
NÍVEIS DE ENVOLVIMENTO DO CLIENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ENVOLVIMENTO ALTO: │
│ • Revisões/demos de sprint │
│ • Discussões de requisitos │
│ • Decisões de prioridade │
│ • Testes de aceitação │
│ │
│ ENVOLVIMENTO MÉDIO: │
│ • Atualizações de status semanais │
│ • Revisões de marco │
│ • Revisões de design │
│ │
│ ENVOLVIMENTO BAIXO: │
│ • Standups diários (geralmente apenas interno) │
│ • Detalhes de implementação técnica │
│ • Problemas da equipe interna │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REVISÃO DE SPRINT COM CLIENTE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ REVISÃO DO SPRINT 5 ││
│ │ ││
│ │ PARTICIPANTES: ││
│ │ Equipe: Líder dev, Designer, PM ││
│ │ Cliente: Dono do produto, Stakeholder ││
│ │ ││
│ │ AGENDA: ││
│ │ 1. Demo de features concluídas (20 min) ││
│ │ - Mostrar software funcional ││
│ │ - Coletar feedback imediato ││
│ │ ││
│ │ 2. Discutir próximo sprint (15 min) ││
│ │ - Revisar prioridades propostas ││
│ │ - Obter input do cliente ││
│ │ ││
│ │ 3. Discussão aberta (10 min) ││
│ │ - Perguntas, preocupações ││
│ │ - Necessidades futuras ││
│ │ ││
│ │ RESULTADO: ││
│ │ Prioridades do sprint 6 acordadas ││
│ │ Itens de ação documentados ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Coleta de Feedback
Obtendo Feedback Útil
COLETA DE FEEDBACK:
┌─────────────────────────────────────────────────────────────┐
│ │
│ DURANTE DEMOS: │
│ │
│ FAÇA PERGUNTAS ESPECÍFICAS: │
│ ✅ "Este fluxo corresponde como sua equipe usaria?" │
│ ✅ "Esta informação é suficiente para sua decisão?" │
│ ✅ "O que está faltando nesta visualização?" │
│ │
│ EVITE: │
│ ❌ "O que você acha?" │
│ ❌ "Isso parece bom?" │
│ → Muito vago, respostas pouco úteis │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ TAREFA DE FEEDBACK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Feedback do Cliente: Revisão do Dashboard ││
│ │ ││
│ │ De: Revisão do Sprint 5 (19 de jan) ││
│ │ ││
│ │ FEEDBACK RECEBIDO: │
│ │ • "Filtro de intervalo de data deve ser padrão últimos ││
│ │ 30 dias" ││
│ │ • "Precisa exportar estes dados para Excel" ││
│ │ • "Cores do gráfico difíceis de distinguir" ││
│ │ ││
│ │ CATEGORIZADO: ││
│ │ Correção rápida: Padrão intervalo de data ││
│ │ Backlog: Exportar Excel (escopo TBD) ││
│ │ Design: Cores do gráfico (designer para revisar) ││
│ │ ││
│ │ ACOMPANHAMENTO: ││
│ │ ☐ Adicionar correção de intervalo de data ao Sprint 6 ││
│ │ ☐ Planejar escopo de exportar Excel para priorização ││
│ │ ☐ Agendar revisão de design para cores ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ FECHE O CICLO: │
│ • Reconheça feedback recebido │
│ • Comunique o que fará com ele │
│ • Atualize quando endereçado │
└─────────────────────────────────────────────────────────────┘
Documentação para Clientes
Relatórios Voltados ao Cliente
RELATÓRIOS PARA CLIENTE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ O QUE CLIENTES PRECISAM: │
│ │
│ ✅ Progresso contra marcos │
│ ✅ O que podem ver/testar │
│ ✅ O que vem a seguir │
│ ✅ Quaisquer bloqueadores ou riscos │
│ ✅ Decisões necessárias deles │
│ │
│ O QUE CLIENTES NÃO PRECISAM: │
│ │
│ ❌ Velocidade da equipe interna │
│ ❌ Detalhes de implementação técnica │
│ ❌ Tarefas individuais de desenvolvedor │
│ ❌ Problemas de processo interno │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ VISUALIZAÇÃO DO CLIENTE NO GITSCRUM: │
│ │
│ Use recursos de relatório do GitScrum para compartilhar: │
│ • Progresso de marco │
│ • Features concluídas │
│ • Trabalho futuro │
│ │
│ Configure visibilidade: │
│ • Mostre nível de feature, não nível de tarefa │
│ • Esconda trabalho técnico interno │
│ • Foco no valor de negócio entregue │
│ │
│ RELATÓRIOS REGULARES: │
│ • Status semanal (automatizado se possível) │
│ • Resumos de marco │
│ • Revisões trimestrais │
└─────────────────────────────────────────────────────────────┘