Um sistema pode estar publicado e ainda não estar pronto para ser operado pela empresa. Se somente o desenvolvedor sabe recuperar uma falha, criar um usuário ou explicar uma rotina, a entrega continua dependente de conhecimento informal. A passagem para operação organiza essa transferência de responsabilidade.
Este guia apresenta um roteiro para empresas contratantes e equipes de desenvolvimento. Ele não define garantias contratuais universais. O que está incluído, os prazos e as responsabilidades precisam ser acordados entre as partes. O objetivo é transformar “sistema entregue” em uma condição verificável de uso e continuidade.
1. Defina o que será entregue além das telas
Liste aplicação, código, configuração, dados, documentação, acessos e materiais de treinamento pertinentes ao projeto. Cada item deve ter responsável e critério de aceite. Um link para o sistema não comprova entrega de todos esses elementos.
Também diferencie o que pertence à empresa e o que depende de licença ou serviço de terceiro. Bibliotecas, provedores e componentes podem possuir condições próprias. A documentação deve identificar dependências relevantes e como elas afetam a continuidade, sem afirmar propriedade irrestrita sobre qualquer elemento utilizado.
O escopo inicial deve explicar o que não está incluído. Operação de infraestrutura, atendimento a usuários e evolução funcional podem ser serviços distintos do desenvolvimento. A clareza reduz expectativas incompatíveis e ajuda a empresa a planejar sua capacidade interna.
2. Nomeie papéis e canais de responsabilidade
Quem administra usuários? Quem decide uma mudança de regra? Quem recebe um alerta? Quem pode autorizar uma intervenção em produção? Essas perguntas precisam de resposta antes da saída do período de implantação.
Uma mesma pessoa pode assumir vários papéis em uma empresa pequena, mas as responsabilidades continuam distintas. O operador que usa o sistema todos os dias não necessariamente deve aprovar uma mudança que afeta cobrança ou acesso de todos os clientes.
| Papel | Responsabilidade típica | Evidência de preparo |
|---|---|---|
| Responsável de negócio | Priorizar regras e aceitar entregas | Critérios de aceite conhecidos |
| Administrador | Gerenciar usuários e configurações | Procedimento testado |
| Suporte operacional | Receber e classificar ocorrências | Canal e roteiro definidos |
| Operação técnica | Diagnosticar e recuperar serviços | Runbooks e acessos apropriados |
| Fornecedor | Atuar no escopo contratado | Limites e canais documentados |
3. Organize acessos sem compartilhar segredos em documentos
O pacote de entrega deve informar onde os acessos são administrados e quem possui autoridade para concedê-los. Não coloque senhas, tokens e chaves privadas em apresentações, e-mails amplos ou arquivos versionados.
Use mecanismos apropriados de guarda e compartilhamento. A empresa precisa controlar as contas essenciais e conhecer o procedimento de recuperação. Dependência de uma conta pessoal do fornecedor pode comprometer continuidade e auditoria.
Revise permissões temporárias usadas durante o desenvolvimento. Retirar um acesso exige planejamento para não interromper integrações legítimas. O objetivo é deixar apenas o necessário, com responsáveis identificados, e não remover credenciais de forma indiscriminada no dia da entrega.
4. Documente o que a operação realmente faz
Documentação útil começa pelas tarefas: cadastrar usuário, corrigir informação, tratar uma integração pendente, revisar uma autorização e consultar um relatório. Cada procedimento deve explicar pré-condições, passos, resultado esperado e como reconhecer uma exceção.
Evite manuais que apenas descrevem cada botão sem explicar o processo. Uma tela pode ser intuitiva e ainda exigir conhecimento sobre a regra de negócio. O manual precisa preservar esse contexto e apontar quem decide quando a situação não está prevista.
Mantenha exemplos com dados fictícios e referências à versão. Se o sistema muda, a documentação afetada precisa ser revisada. Uma data de atualização deve representar trabalho real de conferência, não uma troca automática no rodapé.
5. Prepare procedimentos de recuperação
Um runbook descreve como reconhecer um problema e quais ações autorizadas podem ser tomadas. Deve incluir sinais, verificações, limites, retorno e encaminhamento. Não é uma lista de comandos para executar sem diagnóstico.
As práticas de resposta a incidentes publicadas pelo Google SRE são uma referência para organizar coordenação e comunicação. A aplicação precisa de procedimentos proporcionais ao seu risco, à equipe e ao contrato, sem copiar uma estrutura maior do que consegue manter.
Teste recuperação em ambiente e escopo autorizados. Existência de backup não comprova restauração. Da mesma forma, um procedimento que depende de uma credencial desconhecida não está pronto. Registre o teste, seu resultado e o que ficou fora da verificação.
6. Treinamento deve demonstrar autonomia
Uma apresentação assistida não prova que os usuários conseguem executar suas tarefas. Organize exercícios representativos: registrar uma operação, tratar uma exceção, corrigir um erro permitido e localizar ajuda. Observe dificuldades e revise material e interface quando necessário.
Separe treinamento de operador e administrador. Quem administra precisa entender impactos de configurações, permissões e dados. Não entregue controles amplos apenas porque a pessoa sabe utilizar as telas do dia a dia.
Registre dúvidas recorrentes e responsáveis por responder. O objetivo não é exigir que todos memorizem tudo, mas permitir que encontrem orientação confiável. Uma base de conhecimento bem organizada reduz dependência de explicações particulares.
7. Exemplo: implantação de um portal de atendimento
Considere um portal com usuários internos, clientes e integrações. A equipe de desenvolvimento apresenta o fluxo ideal, mas a operação pergunta o que fazer quando um convite não chega. Essa situação precisa de procedimento: verificar estado, destinatário, permissão e tentativa anterior antes de reenviar.
Outro exercício envolve um cliente que mudou de responsável. O administrador deve conseguir atualizar o acesso sem expor dados a uma pessoa não autorizada. O treinamento revela se a regra está clara e se a interface oferece informação suficiente.
Na passagem final, a empresa recebe material, acessos sob seu controle, canais de suporte e pendências conhecidas. O sistema pode estar utilizável mesmo com melhorias futuras, desde que elas estejam registradas e não sejam confundidas com funções já entregues.
8. Defina aceite por cenários e evidências
O aceite deve relacionar requisitos a testes e resultados. Uma lista genérica de funcionalidades é insuficiente quando o valor depende do fluxo completo. Inclua exemplos de permissão, integração, cancelamento e recuperação pertinentes ao projeto.
Pendências precisam de severidade, impacto, responsável e encaminhamento. Não esconda limitações em uma observação vaga. Ao mesmo tempo, não trate qualquer sugestão futura como defeito impeditivo. Os critérios devem ter sido acordados e aplicados de maneira consistente.
Para preparar cenários, utilize o briefing editável da A2CR. Ele ajuda a organizar usuários, regras e condições de sucesso antes de converter a entrega em uma discussão sobre aparência de telas.
9. Planeje o primeiro período de operação
Após a publicação, acompanhe o uso real e as ocorrências previstas no contrato. O trabalho inicial pode revelar dados ou comportamentos que o ambiente de teste não reproduziu. Registre aprendizados e separe correção, orientação e nova demanda.
Defina quando a responsabilidade muda de implantação para operação regular. Sem esse marco, usuários e fornecedor podem manter expectativas diferentes sobre disponibilidade e escopo. A continuidade melhora quando a empresa sabe como pedir ajuda e como uma mudança será avaliada.
Checklist de passagem
- Listar entregáveis além das telas publicadas.
- Identificar dependências e condições de terceiros.
- Nomear responsáveis de negócio e operação.
- Colocar contas essenciais sob controle apropriado.
- Guardar segredos fora de documentos comuns.
- Documentar tarefas, exceções e decisões.
- Testar procedimentos de recuperação autorizados.
- Executar treinamento com demonstração de autonomia.
- Relacionar aceite a cenários verificáveis.
- Registrar pendências e transição para suporte regular.
Checklist para usar com sua equipe
Baixe o checklist editável em CSV e registre a conferência, o responsável e as observações da implantação.
Perguntas frequentes
O código-fonte elimina a dependência do fornecedor?
Ele pode ajudar na autonomia, mas não basta. A continuidade exige documentação, ambiente reproduzível, dados, acessos e capacidade técnica. Também é necessário compreender licenças e serviços externos utilizados.
Toda documentação precisa ser extensa?
Não. Ela precisa permitir executar e manter o que foi entregue. Procedimentos curtos, exemplos e diagramas podem ser mais úteis que um documento longo que ninguém consegue atualizar.
Uma pendência impede qualquer aceite?
Depende de seu impacto e dos critérios acordados. O importante é tornar a condição explícita e não declarar uma função pronta quando ela ainda depende de trabalho necessário para cumprir o escopo.
Para organizar uma entrega com continuidade, conheça a metodologia A2CR e reúna os cenários que sua equipe precisa operar sem depender de explicações informais.
Autoria: Agência A2CR. Preparação editorial: 12 de novembro de 2026. Exemplo hipotético; direitos, suporte e garantias dependem dos instrumentos específicos do projeto.
