Dossiê Final da Assistência Técnica Conecta
Consolidação da análise construída ao longo das etapas. O objetivo deste documento é permitir que uma equipe de desenvolvimento compreenda o problema, as regras, o escopo, as decisões, os riscos e o que já está suficientemente definido para começar — sem repetir todos os artefatos do percurso.
Ao imprimir pelo navegador, escolha “Salvar como PDF” se quiser arquivar ou entregar uma cópia.
1. Problema e contexto
Origem: Etapa 0Clientes precisam telefonar para descobrir o andamento do equipamento. O atendente consulta papel, mensagens e pessoas e nem sempre consegue responder com segurança. A causa principal identificada é a informação dispersa, registrada de formas diferentes e sem uma situação única e confiável da ordem.
Consequências observadas
- espera e retrabalho no atendimento;
- risco de informação incorreta;
- dificuldade de rastrear aprovações;
- histórico incompleto de peças e mudanças;
- dependência de pessoas e anotações paralelas.
Objetivo da solução
Manter uma referência confiável para o atendimento, registrar as principais decisões do ciclo da ordem e permitir acompanhamento coerente sem digitalizar a desorganização atual.
2. Stakeholders e escopo
Origem: Etapa 1| Stakeholder | Necessidade principal | Conhecimento/decisão relevante |
|---|---|---|
| Cliente | Acompanhar atendimento e decidir sobre orçamento | Experiência de comunicação e decisão |
| Atendente | Abrir, localizar e acompanhar ordens | Entrada, entrega e contato com cliente |
| Técnico | Registrar diagnóstico, reparo e teste | Exceções técnicas e necessidade de peças |
| Gerência | Controlar regras, prazos e operação | Prioridades, políticas e aprovações |
| Estoque | Controlar peças usadas e faltantes | Disponibilidade e movimentação de peças |
| Fornecedor | Atender solicitações de peça quando necessário | Prazo e disponibilidade externa |
Dentro do escopo inicial
- cliente e equipamento;
- ordem de serviço;
- diagnóstico e orçamento;
- aprovação/recusa;
- reparo, teste e entrega;
- situação da ordem e consulta.
Fora do escopo inicial
- folha de pagamento e RH;
- contabilidade completa;
- e-commerce de peças;
- relatórios avançados não ligados ao problema central;
- funções sem origem validada.
Premissa a confirmar: atendentes terão acesso à Internet no expediente. Restrição conhecida: a operação deve continuar nos computadores já disponíveis.
3. Levantamento e evidências
Origem: Etapa 2As evidências foram obtidas combinando entrevistas, observação e documentos. A origem de cada achado deve permanecer registrada; pedido de tela ou tecnologia não é aceito como requisito sem investigar a necessidade que o motivou.
| Achado consolidado | Origem | Tratamento |
|---|---|---|
| Reparo que exige orçamento só começa após aprovação | Gerência + técnico | Regra de negócio crítica |
| Cliente liga para saber andamento | Observação | Problema confirmado |
| Peça usada pode ser anotada fora da ordem | Técnico / estoque | Problema de rastreabilidade |
| Há registros em papel, mensagens e memória das pessoas | Observação + entrevistas | Causa da baixa confiabilidade da situação |
4. Processo AS-IS
Origem: Etapa 3O fluxo atual possui esperas, retorno ao reparo quando o teste falha, encerramento sem reparo em caso de recusa e pontos de informação fragmentada. Os gargalos principais são aprovação, consulta da situação e registro do histórico.
5. Análise estruturada
Origem: Etapa 4O Diagrama de Contexto delimita a Conecta e suas trocas externas; o DFD Nível 0 organiza atendimento, diagnóstico, orçamento e reparo/entrega. Os depósitos conceituais principais são Clientes, Ordens e Orçamentos.
| Elemento | Significado compartilhado |
|---|---|
| Situação da ordem | Estado atual reconhecido do atendimento. |
| Diagnóstico | Conclusão técnica que fundamenta o reparo/orçamento. |
| Decisão do orçamento | Resposta do cliente à proposta: aprovado ou recusado. |
Decisões envolvendo garantia, aprovação e disponibilidade de peça devem permanecer explicitáveis por regra/tabela de decisão quando a combinação de condições ficar difícil de visualizar.
6. Processo TO-BE
Origem: Etapa 5A ordem passa a ser a referência compartilhada. O diagnóstico é registrado uma vez, o orçamento nasce desse diagnóstico, a decisão do cliente fica vinculada à ordem e as mudanças de situação passam a refletir eventos reais do processo.
| Problema do AS-IS | Mudança no TO-BE | Resultado esperado |
|---|---|---|
| Situação pouco confiável | Uma ordem com estado reconhecido | Consulta consistente |
| Aprovação difícil de rastrear | Decisão vinculada à ordem | Histórico e bloqueio coerentes |
| Peça usada sem histórico claro | Registro vinculado ao reparo | Rastreabilidade da execução |
7. Requisitos funcionais, regras e critérios de aceitação
Origem: Etapa 6| ID | Requisito funcional consolidado | Critério de aceitação essencial |
|---|---|---|
| RF01 | Cadastrar cliente e equipamento. | Dados mínimos são registrados e vinculados sem duplicar o atendimento atual. |
| RF02 | Abrir ordem de serviço ligada ao cliente e ao equipamento. | A ordem recebe identificador e situação inicial válida. |
| RF03 | Registrar diagnóstico técnico. | Diagnóstico fica associado à ordem e disponível para gerar orçamento. |
| RF04 | Consultar situação atual da ordem. | Consulta exibe a situação permitida ao perfil/cliente sem expor dados indevidos. |
| RF05 | Gerar orçamento a partir do diagnóstico. | Orçamento pendente fica ligado à ordem e disponível para decisão. |
| RF06 | Registrar reparo, teste e uso de peças. | Histórico técnico fica ligado à mesma ordem e teste reprovado retorna ao fluxo de reparo. |
| RF07 | Registrar aprovação ou recusa do orçamento. | Decisão registra autor/data e altera a situação de forma coerente. |
| RF08 | Registrar entrega/encerramento. | Entrega só ocorre a partir de situação compatível e permanece no histórico. |
Regras de negócio críticas
| ID | Regra |
|---|---|
| RN01 | Reparo que exige orçamento não pode começar antes da aprovação. |
| RN02 | Recusa do orçamento impede início do reparo e encaminha encerramento sem reparo. |
| RN03 | Teste reprovado devolve a ordem ao reparo; não marca a ordem como pronta. |
| RN04 | Mudanças críticas de situação/decisão devem manter autor e data/hora. |
| RN05 | Falha de notificação externa não altera retroativamente a situação real da ordem. |
8. Requisitos não funcionais
Origem: Etapa 11| Área | Condição consolidada | Status |
|---|---|---|
| Usabilidade móvel | A consulta do cliente deve funcionar adequadamente em smartphone. | Conhecido |
| Autenticação/autorização | Perfis internos acessam apenas funções necessárias ao papel exercido. | Conhecido |
| Privacidade | Consulta do cliente mostra apenas dados necessários ao acompanhamento. | Conhecido |
| Auditabilidade | Alterações sensíveis registram usuário, data/hora e mudança realizada. | Conhecido |
| Acessibilidade | Rótulos claros, navegação adequada, contraste e informação não dependente apenas de cor. | Conhecido |
| Desempenho | Limites mensuráveis devem ser definidos com base em necessidade/medição, não inventados. | A definir |
| Disponibilidade/recuperação | Metas e tempos aceitáveis de indisponibilidade/restauração precisam de decisão do negócio. | A definir |
9. Casos de Uso e modelos UML necessários
Casos de Uso: Etapa 7 UML: Etapa 8| Ator | Objetivos principais |
|---|---|
| Atendente | Abrir ordem, registrar decisão, consultar andamento e concluir entrega. |
| Técnico | Registrar diagnóstico, reparo, teste e necessidade/uso de peças. |
| Cliente | Consultar andamento e tomar decisão sobre orçamento. |
| Gerente | Acompanhar operação e administrar decisões/regras de maior privilégio. |
| Modelo mantido | Pergunta que responde | Por que permanece no dossiê |
|---|---|---|
| Atividades | Como uma decisão/funcionalidade flui? | Esclarece aprovação/recusa e retornos. |
| Sequência | Quem troca mensagens em qual ordem? | Ajuda em interações críticas como registrar decisão. |
| Modelo de Domínio | Quais conceitos existem e se relacionam? | Alinha Cliente, Equipamento, Ordem, Diagnóstico, Orçamento e Item de Peça. |
| Estados da Ordem | Como a ordem muda durante sua vida? | Evita transições inválidas e sustenta regras/consulta. |
Estados principais: Aberta → Em diagnóstico → Aguardando aprovação → Em reparo → Em teste → Pronta → Entregue, com alternativas como recusada, aguardando peça, cancelada e retorno ao reparo.
10. Backlog, MVP e Story Map
Origem: Etapa 9| Prioridade | Item | Justificativa |
|---|---|---|
| 1 | Abrir ordem | Sem ordem, o fluxo não começa. |
| 2 | Registrar diagnóstico | Base para orçamento. |
| 3 | Gerar e registrar decisão do orçamento | Libera ou impede reparo. |
| 4 | Atualizar situação da ordem | Ataca o problema central de acompanhamento. |
| 5 | Consulta do cliente | Entrega valor visível e reduz chamadas. |
MVP
- cliente/equipamento;
- ordem;
- diagnóstico;
- orçamento e decisão;
- situação;
- consulta simples.
Depois do MVP
- pagamento integrado;
- notificações automáticas avançadas;
- relatórios avançados;
- IA de triagem.
Story Map
| Receber | Diagnosticar | Orçar | Reparar | Entregar |
|---|---|---|---|---|
| Abrir ordem | Registrar diagnóstico | Gerar proposta | Registrar reparo | Marcar entregue |
| Foto do equipamento | Anexar evidência | Enviar mensagem | Controlar peças | Registrar pagamento |
11. Protótipo e validações
Origem: Etapa 10Fluxos prioritários para prototipação: abrir ordem e consultar situação. A consulta móvel deve pedir apenas os dados necessários, apresentar a situação em linguagem compreensível e não depender apenas de cor.
12. Segurança, privacidade, acessibilidade e integrações
Origem: Etapa 11- autenticação identifica o usuário; autorização limita o que cada perfil pode fazer;
- menor privilégio para Atendente, Técnico e Gerente;
- consulta externa não exibe CPF completo, endereço ou observações internas sem necessidade;
- mudanças críticas precisam de trilha de auditoria;
- notificação pode ser assíncrona e falhar sem alterar o estado real da ordem;
- integrações devem definir dados, erros, autenticação, versionamento e comportamento de falha;
- operações repetidas, como confirmação de pagamento, precisam evitar efeitos duplicados.
13. Viabilidade e riscos
Origem: Etapa 12| Dimensão | Leitura atual | Ponto ainda necessário |
|---|---|---|
| Técnica | Núcleo do MVP é compatível com infraestrutura comum de aplicação web. | PoC/Spike para integrações críticas quando houver fornecedor definido. |
| Econômica | Problema recorrente e redução de retrabalho indicam valor potencial. | Custos reais de desenvolvimento, serviços e manutenção. |
| Operacional | TO-BE reduz registros paralelos e centraliza a ordem. | Validar adoção e treinamento com usuários reais. |
| Prazo | MVP reduz escopo inicial. | Estimar com equipe e capacidade disponíveis. |
| Legal/privacidade | Minimização e controle de acesso já foram identificados. | Validar obrigações específicas do contexto real. |
| Organizacional | Papéis e responsabilidades principais foram identificados. | Definir responsáveis operacionais pelo sistema e pelos dados. |
| ID | Risco | Probabilidade | Impacto | Resposta |
|---|---|---|---|---|
| R01 | Serviço de mensagens indisponível | Média | Baixo/Médio | Registrar pendência e tentar depois. |
| R02 | Usuários não atualizarem a situação | Média | Alto | Simplificar fluxo, treinar e acompanhar. |
| R03 | Perda de dados | Baixa | Alto | Backup, restauração testada e controle. |
| R04 | Pagamento duplicado | Baixa | Alto | Idempotência e auditoria. |
14. Rastreabilidade
Origem: Etapa 12| Necessidade/origem | Requisito | Regra | História/Caso | Interface | Teste |
|---|---|---|---|---|---|
| Cliente não sabe andamento | RF04 Consultar situação | — | Consulta do cliente / UC Consultar andamento | Consulta da ordem | Validar situação visível e acesso permitido |
| Gerência exige aprovação | RF07 Registrar decisão | RN01 | Registrar decisão / UC Registrar decisão | Orçamento | Bloquear reparo sem aprovação |
| Peça usada sem histórico claro | RF06 Registrar reparo/peças | — | Registrar reparo | Execução técnica | Peça permanece vinculada à ordem |
A matriz deve ser expandida para itens críticos, não usada como burocracia automática para cada detalhe.
15. Decisões importantes
Origem documental: Etapa 13Diagnóstico, orçamento, decisão, reparo e entrega se conectam à mesma ordem.
Sem aprovação quando exigida, o reparo não avança.
Só permanecem os que respondem a uma pergunta real e ajudam comunicação/decisão.
Pagamento integrado, automações e IA ficam depois do problema central estar bem resolvido.
Notificação falhar não muda uma ordem pronta para “em reparo”.
Regra, requisito e decisão devem ter referência única e rastreável.
16. Pendências conhecidas
- definir limites mensuráveis de desempenho e disponibilidade com base em necessidade real;
- confirmar a premissa de conectividade e capacidade dos computadores existentes;
- selecionar/validar fornecedores de mensagens e pagamento antes de fechar contratos de integração;
- confirmar se orçamento possui validade e qual regra se aplica;
- definir política de retenção, backup, restauração e responsabilidades pelos dados;
- anexar resultados reais dos testes de usabilidade do protótipo;
- validar obrigações legais e de privacidade no contexto real da organização.
Pendência conhecida não é falha do dossiê. O problema é escondê-la ou tratá-la como fato resolvido.
17. Condições para início do desenvolvimento
Passagem liberada quando
- problema e objetivo estão claros;
- MVP e escopo inicial estão acordados;
- regras críticas não possuem contradição conhecida;
- requisitos prioritários possuem origem e critérios verificáveis;
- estados/transições principais da ordem são compreendidos;
- protótipo dos fluxos de maior risco foi revisado;
- perfis, exposição de dados e auditoria estão definidos no nível necessário;
- riscos e dependências críticas possuem resposta ou experimento planejado;
- integrações de alto risco têm contrato conhecido ou PoC/Spike previsto;
- pendências abertas estão registradas com responsável/decisão futura, sem serem tratadas como requisitos confirmados.
Critério de passagem: não é “saber tudo”; é saber o suficiente para começar a próxima fatia com risco aceitável e capacidade de revisar o entendimento quando novas evidências aparecerem.
18. Entrega para a equipe de desenvolvimento
Este dossiê é a visão consolidada. Os artefatos detalhados continuam nas etapas de origem e só devem ser consultados quando a equipe precisar aprofundar uma decisão, requisito, risco ou modelo específico.
Resumo de passagem
Problema compreendido → escopo definido → processo atual conhecido → solução futura justificada → requisitos/rules testáveis → modelos essenciais → MVP priorizado → protótipo validável → qualidade/integrações analisadas → riscos e pendências explícitos → base pronta para desenvolvimento incremental e revisão contínua.