Interação entre equipe e cliente

7 Interação entre equipe e cliente

7.1 Composição da equipe

A equipe de desenvolvimento é composta pelos seguintes membros. Todos os integrantes atuam também como Analistas de Requisitos, colaborando na elicitação, documentação e validação dos requisitos ao longo do projeto.

Papel	Descrição	Responsável
Gerente de projeto / Product Owner	Coordena o projeto, facilita as cerimônias ágeis, remove impedimentos, garante a comunicação entre cliente e equipe e controla prazos e entregas.	João G. A. de Melo
Desenvolvedor frontend	Responsável pela interface do usuário, pelo design e pela implementação das funcionalidades no lado do cliente.	Rodrigo Carvalho Barbosa
Desenvolvedor backend / Scrum Master	Implementa a lógica de negócios, integração com banco de dados e APIs.	Luiz Henrique Tomaz Moreira
Desenvolvedor backend	Implementa a lógica de negócios, integração com banco de dados e APIs.	Bruno Ferreira Dornelas
Analista de QA	Garante a qualidade do produto, executando testes de funcionalidade, desempenho e usabilidade.	Leonardo da S. Lopes Júnior
Analista de requisitos	Define os requisitos funcionais e não funcionais do sistema, prioriza o backlog junto ao cliente e garante que os critérios de aceitação sejam atendidos.	Thiago Gomes Pereira de Abreu

7.2 Comunicação

Ferramentas de comunicação

Ferramenta	Finalidade
WhatsApp	Canal oficial para troca de mensagens rápidas e comunicação do dia a dia da equipe: avisos urgentes, links úteis e dúvidas pontuais que não exigem debate complexo.
Google Meet	Reuniões de revisão e planejamento de sprint; videoconferências com o cliente.
Jira	Gerenciamento do backlog, controle de tarefas e acompanhamento do progresso de cada sprint.
GitHub	Versionamento de código.

Métodos e frequência de reuniões

• Reuniões diárias: a equipe realizará check-ins diários para acompanhar o progresso, identificar obstáculos e alinhar as prioridades do dia.
• Revisão de sprint: a cada ciclo de duas semanas, o grupo organizará uma videochamada no Google Meet com o cliente para demonstrar as soluções construídas. É o momento dedicado para que o proprietário avalie o sistema e direcione as próximas necessidades. Todas essas sessões precisarão ser documentadas em vídeo ou em atas linkadas às entregas correspondentes, garantindo a rastreabilidade exigida na disciplina.
• Planejamento de sprint: imediatamente após a reunião com o cliente, os membros do grupo farão o mapeamento da próxima iteração, reavaliando o repositório de requisitos e selecionando as tarefas prioritárias para a quinzena seguinte, com base no último feedback recebido.
• Retrospectiva: fechando o período da sprint, o time fará uma avaliação interna, refletindo sobre as práticas adotadas, identificando gargalos técnicos ou de comunicação e definindo ações corretivas.

Frequência de interações com o cliente

• Encontros quinzenais de homologação: a participação oficial e síncrona de Antônio Marcos acontece no fechamento de cada ciclo quinzenal, concentrando a validação do software em momentos específicos e evitando consumir excessivamente o tempo que ele precisa dedicar ao atendimento presencial na loja.
• Contato assíncrono e registro de evidências: para resoluções rápidas no dia a dia, o WhatsApp será a ferramenta principal. Caso alguma aprovação ou mudança de escopo seja feita por este canal em vez de uma reunião formal, é obrigatório registrar a troca de mensagens na íntegra por meio de capturas de tela.

7.3 Processo de validação

O processo ocorre em três etapas, cobrindo tanto a qualidade interna do requisito/entrega quanto a confirmação de que o produto atende à necessidade real do cliente, reduzindo o esforço operacional da TSI Peças:

1. Definition of Ready (DoR) — verificação interna: o desenvolvimento de uma funcionalidade só inicia quando os requisitos, as regras de negócio (padrões de códigos e aplicação de autopeças) e os critérios de aceitação estiverem totalmente definidos e documentados.
2. Definition of Done (DoD) — verificação interna: a funcionalidade é considerada concluída após finalização do código, integração com o banco, testes internos sem bugs críticos e deploy nos ambientes em nuvem.
3. Testes de aceitação com o cliente — validação externa: ao final de cada sprint, o cliente valida se a entrega cumpre os critérios de aceitação definidos no DoR e atende à necessidade real do negócio. Divergências identificadas resultam em ajustes no backlog da sprint seguinte.

Versionamento

Versão	Data	Descrição	Autor(es/as)
1.0	04/09/2026	Iniciação do documento	Thiago Gomes
1.1	07/09/2026	Preenchimento do tópico 7 e revisão textual	Luiz Moreira
1.2	07/09/2026	Correção dos papéis da equipe e refinamento do processo de validação	Luiz Moreira