Defina dono
Uma pessoa ou fornecedor responsavel por decisao, execucao ou validacao.
Responsabilidades tecnicas
Quando todo mundo acha que alguem cuidou, o risco ja esta instalado.
Use este mapa para definir donos tecnicos de dominio, deploy, banco, conteudo, campanhas, seguranca, IA e incidentes sem transformar a empresa pequena em uma estrutura pesada.
Como pensar
Responsabilidade tecnica nao e cargo. E clareza sobre decisao, execucao e validacao.
Em times pequenos, a mesma pessoa pode ter varios papeis. O problema nao e acumular. O problema e nao saber quem decide, quem executa, quem valida e onde fica o registro.
Registre limite
O que pode mudar sozinho, o que precisa aprovar e o que exige rollback.
Revise depois
Incidente, fornecedor novo ou mudanca critica devem atualizar o mapa.
Mapa de responsabilidades
Areas que precisam de dono claro.
Cada area abaixo mostra perguntas de dono, sinais de ausencia de responsabilidade, rotina minima e evidencias esperadas.
Dominio, DNS e e-mail
Dominio e e-mail parecem detalhes administrativos, mas uma mudanca errada em DNS, MX, SPF, DKIM ou proxy pode derrubar site, formulario e recebimento de mensagens.
Perguntas de dono
- Quem pode alterar Cloudflare, Integrator, DNS, MX, SPF, DKIM e registros mail?
- Quem valida se uma mudanca no site nao afetou as caixas do dominio?
- Quem guarda o historico de alteracoes importantes?
- Quem acompanha propagacao e status do dominio depois de uma virada?
Sinais de falta de dono
- Registros sao alterados por tentativa
- E-mail para de funcionar depois de mudanca no site
- Ninguem sabe qual entrada antiga pode ser removida
- Nao existe print ou registro do antes/depois
Rotina minima
Manter um mapa simples de registros, provedores, finalidade de cada entrada e responsavel por mudancas.
Evidencias esperadas
Registros DNS, status proxy, MX/SPF/DKIM, resposta HTTP, teste de envio/recebimento.
Deploy, VPS, containers e proxy
Quando deploy depende de memoria individual, cada publicacao vira risco para rotas, containers, variaveis, proxy, SSL e rollback.
Perguntas de dono
- Quem aprova e executa deploy em producao?
- Quem conhece containers, portas, redes, Nginx e variaveis?
- Quem decide rollback quando a validacao falha?
- Quem acompanha logs logo depois da publicacao?
Sinais de falta de dono
- Pipeline passa, mas ninguem valida rotas reais
- Rollback e discutido somente depois da falha
- Variaveis de ambiente nao estao documentadas
- O mesmo erro de rota volta a cada publicacao
Rotina minima
Definir responsavel por pre-deploy, publicacao, validacao pos-deploy, logs iniciais e rollback.
Evidencias esperadas
Commit publicado, imagem/container, rotas validadas, logs Nginx/backend, plano de rollback.
Backend, APIs e banco
APIs e dados concentram regra de negocio, performance, integracoes e risco de indisponibilidade. Sem dono claro, erro 500 e lentidao viram tentativa e erro.
Perguntas de dono
- Quem responde por contrato de API, status HTTP, validacao e erros esperados?
- Quem revisa migracoes, consultas, indices e backup?
- Quem conhece consumidores internos ou externos da API?
- Quem confirma causa raiz quando erro ou lentidao aparece?
Sinais de falta de dono
- Ninguem sabe qual consumidor usa uma rota
- Consulta lenta e tratada aumentando servidor
- Migracao roda sem plano de restauracao
- Erro 500 e corrigido sem registro de causa
Rotina minima
Manter mapa de APIs criticas, dados sensiveis, backup/restauracao e evidencias de performance.
Evidencias esperadas
Endpoint, payload mascarado, status HTTP, consulta, backup, tempo p95.
Frontend, conteudo e SEO tecnico
Paginas novas, links internos, schema, sitemap e busca interna influenciam experiencia, indexacao e percepcao de valor editorial.
Perguntas de dono
- Quem valida se uma pagina nova aparece no mapa do site, busca interna e sitemap XML?
- Quem revisa title, description, canonical, schema e links internos?
- Quem confirma responsividade e ausencia de sobreposicao visual?
- Quem decide se o conteudo responde uma pergunta real antes de monetizar?
Sinais de falta de dono
- Pagina publicada fica escondida
- Schema nao corresponde ao conteudo visivel
- CTA comercial aparece antes de contexto suficiente
- Busca interna nao encontra conteudo novo
Rotina minima
Usar uma validacao editorial antes e depois de cada pagina nova, incluindo descoberta, SEO tecnico e UX.
Evidencias esperadas
URL, canonical, schema, sitemap, busca interna, links internos, print mobile.
Formularios, campanhas e monetizacao
Lead, UTM, Google Ads, AdSense, Tag Assistant, e-mail e pagina de destino precisam trabalhar juntos. Se ninguem e dono, clique vira dado perdido.
Perguntas de dono
- Quem valida formulario depois de deploy?
- Quem acompanha UTM, origem, evento de conversao e recebimento de e-mail?
- Quem decide mudanca em URL final, segmentacao ou orcamento?
- Quem confirma que monetizacao nao prejudica conteudo e navegacao?
Sinais de falta de dono
- Contato chega sem campanha
- Google Ads mostra clique, mas nao conversao
- Formulario salva, mas e-mail falha
- Mudanca de pagina acontece sem testar tag
Rotina minima
Validar formulario, UTM, evento, e-mail e pagina de destino antes de mexer em lance ou pedir revisao.
Evidencias esperadas
Contato recebido, UTM, Tag Assistant, evento, e-mail, log backend.
Seguranca, acessos e segredos
Senha, token, acesso a servidor, DNS, banco, e-mail, Git e painel de campanha precisam de dono, revisao e limite de permissao.
Perguntas de dono
- Quem pode criar, remover ou revisar acessos?
- Quem rotaciona segredo exposto?
- Quem sabe onde cada variavel sensivel deve ficar?
- Quem valida que a aplicacao funcionou depois de trocar segredo?
Sinais de falta de dono
- Conta compartilhada vira padrao
- Senha real aparece em documento ou repositorio
- Acesso antigo continua ativo sem dono
- Automacao usa permissao maior que o necessario
Rotina minima
Revisar acessos e segredos em ciclos mensais, com registro de responsavel e escopo minimo.
Evidencias esperadas
Lista de acessos, servico afetado, segredo rotacionado, teste pos-rotacao, permissao revisada.
IA, documentos e fontes internas
IA aplicada sem fonte, dono e permissao claros pode responder com documento errado, dado sensivel ou contexto desatualizado.
Perguntas de dono
- Quem e dono de cada fonte usada por IA ou RAG?
- Quem revisa atualidade, permissao e limite de uso?
- Quem define perguntas de teste e resposta esperada?
- Quem aprova uso de IA em fluxo sensivel?
Sinais de falta de dono
- Documentos duplicados entram na base
- Fonte antiga parece verdade atual
- Dado sensivel entra no prompt sem criterio
- Resposta de IA nao aponta fonte nem incerteza
Rotina minima
Manter mapa de fontes com dono, data, permissao, uso permitido e revisao humana.
Evidencias esperadas
Fonte, dono, data, permissao, perguntas de teste, revisao humana.
Incidentes, suporte e aprendizado
Incidente sem dono vira repeticao. Alguem precisa fechar impacto, causa, comunicacao, prevencao e mudanca na rotina.
Perguntas de dono
- Quem abre e fecha registro de incidente?
- Quem decide severidade e comunicacao?
- Quem confirma causa raiz e acao preventiva?
- Quem atualiza checklist, playbook, indicador ou documentacao depois?
Sinais de falta de dono
- Incidente termina quando o sistema volta, sem aprendizado
- A mesma falha retorna com outro nome
- Acoes preventivas ficam sem prazo
- Ninguem sabe se a rotina mudou depois
Rotina minima
Fechar incidentes com impacto, linha do tempo, causa confirmada, acoes preventivas e dono da proxima revisao.
Evidencias esperadas
Impacto, linha do tempo, causa confirmada, acao preventiva, responsavel, prazo.
Modelos de operacao
Responsabilidade muda conforme o tamanho da empresa.
O mapa precisa caber na realidade. Uma empresa de uma pessoa tecnica, uma empresa com fornecedor e uma equipe pequena precisam de combinados diferentes.
Empresa com uma pessoa tecnica principal
A mesma pessoa costuma cuidar de codigo, deploy, dominio, e-mail e suporte. O risco e tudo ficar na memoria.
- Registrar mapa minimo de dominio, deploy, banco e e-mail
- Separar acesso administrativo de rotina operacional
- Criar checklist pos-deploy e registro simples de incidente
Atenção: Priorize documentacao curta e reutilizavel. O objetivo e reduzir dependencia de memoria, nao criar reuniao.
Empresa com fornecedor ou freelancer
Parte do conhecimento fica fora da empresa. O risco e o contrato terminar e levar junto contexto de servidor, deploy e regras.
- Definir quais acessos sao da empresa e quais sao do fornecedor
- Exigir entrega de evidencias, rollback e documentacao minima
- Manter responsavel interno para aprovar mudancas e guardar contexto
Atenção: Fornecedor pode executar, mas a empresa precisa manter propriedade de dominio, contas, repositorio e dados.
Empresa com equipe pequena
Ha mais de uma pessoa tecnica, mas as fronteiras ainda sao informais. O risco e cada um assumir que outro cuidou.
- Separar donos por area: deploy, banco, conteudo, seguranca, campanhas e suporte
- Criar revisao pos-incidente sem culpa
- Usar gestao de mudancas proporcional ao risco
Atenção: Nao transforme tudo em comite. Basta deixar claro quem decide, quem executa, quem valida e quem registra.
Perguntas comuns
Clareza de dono reduz improviso.
Quando a responsabilidade fica clara, mudancas, incidentes, campanhas e revisoes deixam de depender de memoria informal.
Responsavel tecnico precisa ser uma pessoa diferente para cada area?
Nao. Em empresa pequena, uma pessoa pode acumular areas. O importante e explicitar dono, limite de decisao, evidencias esperadas e substituto minimo.
Como definir dono quando existe fornecedor externo?
Separe execucao de propriedade. O fornecedor pode executar deploy ou suporte, mas dominio, dados, repositorio, contas e decisoes criticas precisam ter responsavel interno.
Quando revisar responsabilidades tecnicas?
Revise depois de incidente, antes de mudanca de alto risco, na entrada ou saida de fornecedor e quando uma rotina passa a depender de memoria informal.