---
title: "Caso de automação do trabalho por um não desenvolvedor após a recusa de reforço de pessoal"
locale: pt
category: case_study
category_name: "Estudo de Caso"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/project-manager-workflow-automation-case-study
published_at: 2026-08-29T05:28:31+09:00
---

# Caso de automação do trabalho por um não desenvolvedor após a recusa de reforço de pessoal

> Este é o caso de um responsável pela gestão de negócios que, diante da falta de pessoal e de padrões e tendo assumido também tarefas de manutenção, eliminou gargalos e iniciou pequenas automações com Claude Code. O ponto central está em mudar primeiro a estrutura de trabalho que gera etapas intermediárias e repetições desnecessárias, em vez de apenas adotar tecnologias para executar as tarefas mais rapidamente.

## Key Points

- O problema maior do que o aumento do volume de trabalho era o fato de a equipe existente ter de criar simultaneamente novos procedimentos e padrões para os entregáveis.
- Mesmo solicitações rápidas de importação e exportação de arquivos geram uma carga de trabalho que supera o tempo real de processamento quando interrompem repetidamente a concentração.
- A primeira melhoria a produzir resultados não foi um programa de automação, mas a mudança do fluxo para que as solicitações não precisassem passar pelo responsável.
- Mesmo quem não é desenvolvedor pode usar IA generativa e ferramentas de programação para criar pequenas automações por meio de um ciclo de descrição do problema, execução, verificação de erros e correção.
- Os alvos da automação devem ser avaliados considerando não apenas a frequência de repetição, mas também o risco de erros, a frequência de interrupções, a possibilidade de padronização e os controles de segurança.

Quem está sobrecarregado por tarefas repetitivas geralmente começa procurando uma forma de executá-las mais rapidamente. No entanto, o ponto de partida mostrado neste caso é diferente. Em uma situação em que era difícil ampliar a equipe, um responsável pela gestão do projeto, em vez de simplesmente acelerar o trabalho concentrado nele, começou reavaliando por que todas as solicitações e revisões precisavam passar por suas mãos.

Este artigo não apresenta as funcionalidades de uma tecnologia de automação, mas analisa o ambiente de trabalho que tornou inevitável iniciar a automação, a primeira melhoria estrutural, o processo de aprendizagem de uma pessoa sem experiência em desenvolvimento e os princípios que podem ser generalizados a partir dessa experiência.

## Ponto de partida do caso: aumentou mais a complexidade do que o volume de trabalho

Originalmente, a equipe era responsável por um projeto de operação de infraestrutura. Já havia um fluxo conhecido para operar os sistemas de maneira estável, responder a falhas e consolidar os resultados mensais. O problema começou quando um novo projeto de manutenção foi acrescentado sem alterar a equipe existente.

Isso era diferente de simplesmente executar o mesmo trabalho em dobro. Ao mesmo tempo que precisava realizar tarefas com as quais não tinha experiência, o responsável também teve de criar os seguintes elementos:

- Quais entregáveis deveriam ser recebidos
- Quais itens deveriam constar nos documentos
- Como definir a ordem de revisão entre a empresa contratada e o cliente
- Como gerenciar a numeração e o cronograma de cada atividade
- Como recolher e relatar os resultados assinados

| Categoria | Operação de infraestrutura existente | Trabalho de manutenção adicionado |
|---|---|---|
| Estrutura de trabalho | Existência de procedimentos operacionais conhecidos | Necessidade de criar novos procedimentos e critérios |
| Principais entregáveis | Resultados operacionais e registros de resposta a falhas | Cronogramas, diários de trabalho, documentos assinados, materiais de inspeção etc. |
| Partes gerenciadas | Foco nas operações internas | Participação conjunta de empresas contratadas, trabalhadores, setores responsáveis e cliente |
| Principal sobrecarga | Operação estável | Inclui definição de padrões, ajuste de cronogramas, revisão, devolução para correção e recolhimento |

O principal fator de sobrecarga foi não apenas o aumento do trabalho, mas também a necessidade de criar a própria estrutura para executá-lo.

## Sem padrões, revisões e devoluções para correção se repetem

Como os padrões existentes para os entregáveis de manutenção não eram suficientes, o responsável criou os formulários e os distribuiu às empresas contratadas. No entanto, repetiam-se em campo problemas como o uso de formulários do ano anterior, a ausência da assinatura dos trabalhadores e descrições imprecisas de ocorrências especiais.

Por exemplo, quando o campo de resultado traz apenas “medida prevista para posteriormente”, o gestor não consegue acompanhar o prazo de conclusão. É necessário devolver o documento solicitando uma data específica e depois verificar novamente a versão corrigida. Isso cria uma estrutura em que o trabalho administrativo de conferir e solicitar correções nos entregáveis se torna maior do que a própria inspeção.

Este caso mostra que a padronização deve vir antes da automação de documentos. Sem um formato de entrada e campos obrigatórios definidos, as ferramentas de automação apenas transferem com rapidez dados ambíguos e incompletos. Ao considerar a automação, primeiro é necessário definir:

1. Os campos que devem obrigatoriamente ser preenchidos
2. Os formatos permitidos para datas e nomes
3. As condições que exigem assinatura ou anexo
4. Os motivos de devolução e o responsável pela correção
5. Os critérios para considerar o trabalho concluído

## Por que solicitações de poucos minutos desorganizavam o fluxo de um dia inteiro

Por motivos de segurança, a entrada e a saída de arquivos externos eram operadas por meio de um canal único, passando por apenas um responsável. O tempo necessário para processar cada solicitação não era longo, mas havia o problema de elas chegarem sem aviso prévio.

Quando uma solicitação chegava durante a concentração no trabalho principal, era necessário interrompê-lo e processar o arquivo. Depois disso, era preciso recuperar mentalmente o contexto da tarefa interrompida. Neste caso, o que aumentava a sobrecarga percebida não era tanto o tempo gasto em cada solicitação, mas a repetida alternância entre tarefas.

Ao procurar candidatos à automação, não basta calcular apenas o tempo de processamento de cada solicitação. Também é necessário considerar os seguintes custos:

- Tempo para verificar a solicitação e determinar sua prioridade
- Custo de alternância ao interromper e retomar o trabalho
- Tempo para perguntar novamente ao solicitante sobre informações ausentes
- Tempo para registrar e relatar separadamente se a solicitação foi processada
- Tempo de espera quando um responsável específico está ausente

Solicitações breves, mas imprevisíveis e repetitivas, podem se tornar um gargalo que afeta significativamente o cronograma geral e a capacidade de concentração.

## A primeira solução não foi automatizar, mas eliminar o caminho

A primeira melhoria para o problema de entrada e saída de arquivos não foi o desenvolvimento de um programa. O fluxo foi alterado para que o solicitante e o cliente trocassem solicitações diretamente por meio do fórum do sistema interno de gestão de projetos.

| Antes da mudança | Depois da mudança |
|---|---|
| Todas as solicitações passavam pelo responsável pela gestão do projeto | Solicitante e cliente processam diretamente no sistema |
| O responsável executava tanto o encaminhamento quanto o registro | O registro do processamento permanece no sistema |
| O trabalho principal era interrompido sempre que surgia uma solicitação | O responsável consulta os registros quando necessário |
| A solicitação podia ser atrasada na ausência do responsável | Os participantes definidos podem verificar no mesmo fluxo |

O princípio obtido aqui é claro. Em vez de executar mais rapidamente uma tarefa sob sua responsabilidade, pode ser melhor fazer com que ela não precise passar por você.

Antes de projetar uma automação, é útil avaliar na seguinte ordem:

1. Esta etapa pode ser eliminada?
2. O solicitante pode inserir ou verificar as informações diretamente?
3. É possível simplificar o caminho usando funcionalidades de um sistema existente?
4. É possível padronizar os critérios de entrada e decisão?
5. É possível automatizar as tarefas repetitivas que ainda restarem?

## O acúmulo simultâneo de várias tarefas simples consolidou a sobrecarga

O fluxo completo de manutenção incluía a elaboração do cronograma, a organização das informações das empresas contratadas e dos trabalhadores, a atribuição de números, o recolhimento dos diários de trabalho, a revisão e assinatura pelo cliente, a digitalização, o relatório de inspeção e a entrega dos resultados a cada empresa contratada. Cada etapa, isoladamente, não era difícil, mas, quando todas se acumulavam, era complicado controlá-las apenas pela memória e pelo trabalho manual.

Essa situação continuou por cerca de três meses. Durante o dia, repetia-se o padrão de responder a solicitações de entrada e saída de arquivos, dúvidas das empresas contratadas, confirmações dos membros da equipe e pedidos do cliente; somente após o horário de saída, quando os contatos diminuíam, era possível processar o trabalho principal acumulado. Era um estado mais próximo de tentar alcançar, com atraso, tudo o que havia ocorrido no dia do que de resolver o problema.

O responsável solicitou a contratação de pessoal de apoio, mas o pedido não foi aceito. Quando se tornou impossível ampliar a equipe, ganhou importância a opção de mudar a forma de trabalho existente. A automação não foi um hobby iniciado por interesse, mas uma resposta decorrente da conclusão de que, com a estrutura de trabalho atual, o mesmo problema se repetiria no mês seguinte.

## Uma demonstração do Claude Code motivou um pequeno experimento

O ponto de virada foi uma demonstração de automação com Claude vista em um evento da sede. Mais importante do que uma tecnologia complexa de desenvolvimento foi constatar a possibilidade de que “esta ferramenta também poderia ser aplicada ao nosso trabalho”. Uma conversa com um colega que participou do evento sobre fazer uma pequena tentativa tornou-se o ponto de partida do trabalho de automação posterior.

Sem experiência em desenvolvimento, o responsável começou perguntando a outra IA generativa como instalar o Claude Code. Ele verificou e executou as orientações e os comandos adequados ao sistema operacional e acompanhou o processo de configuração inicial de outros usuários por meio de vídeos e outros materiais. Não começou somente depois de dominar completamente a teoria da programação.

No entanto, essa abordagem não significa que seja aceitável executar sem questionamento comandos de origem desconhecida. Em dispositivos corporativos, é necessário verificar a política de segurança da organização e as permissões de instalação de software e, sempre que possível, usar os procedimentos de instalação da documentação oficial. Antes da execução, também é preciso verificar se o comando apaga arquivos, altera permissões ou envia dados para fora.

## O processo interativo de resolução de problemas foi mais importante do que o resultado

O primeiro resultado proporcionou a confiança de que “mesmo uma pessoa sem experiência em desenvolvimento pode criar uma automação”. No entanto, neste caso, o aprendizado mais importante estava no processo de criação, e não no programa finalizado.

O desenvolvimento interativo geralmente ocorre no seguinte ciclo:

- Explicar o problema a ser resolvido e o procedimento atual.
- Informar restrições como arquivos de entrada, formato de saída e limitações de segurança.
- Revisar o método e o código sugeridos pela IA.
- Executar com uma cópia ou com dados de teste.
- Explicar novamente as mensagens de erro e os resultados diferentes do esperado.
- Aplicar as correções e validar novamente.

A IA generativa pode sugerir tecnologias ou abordagens desconhecidas pelo usuário, e também é possível pedir que ela explique novamente termos pouco familiares. Por outro lado, as sugestões nem sempre são corretas ou adequadas ao ambiente da organização. Portanto, a IA deve ser tratada não como uma autoridade que substitui o julgamento, mas como um recurso auxiliar que amplia as opções e reduz as tentativas e erros.

## Critérios extraídos do caso para decidir o que automatizar

Nem toda tarefa precisa ser automatizada apenas porque é repetitiva. Avaliar em conjunto os critérios a seguir facilita a definição das prioridades.

| Critério de avaliação | Pergunta a verificar | Significado |
|---|---|---|
| Frequência de repetição | Com que frequência a mesma tarefa ocorre? | Quanto maior a repetição, maior a possibilidade de economia acumulada |
| Regras de processamento | É possível descrever a entrada e o resultado por meio de regras claras? | Quanto mais claras forem as regras, mais fáceis serão a implementação e a validação |
| Frequência de interrupção | A tarefa surge sem aviso e interrompe o trabalho principal? | Mesmo tarefas breves podem se tornar prioridade alta |
| Impacto dos erros | Omissões ou decisões incorretas afetam contratos, segurança ou custos? | Pode ser necessária aprovação humana em vez de automação completa |
| Qualidade da entrada | Os formulários e campos obrigatórios estão padronizados? | Entradas irregulares aumentam o tratamento de exceções |
| Rastreabilidade | É possível registrar quem processou o quê e quando? | Necessária para auditoria e apuração de responsabilidades |
| Possibilidade de mudança | Os procedimentos e formulários mudam com frequência? | Os custos de manutenção também devem ser considerados |

Em geral, as primeiras tarefas a automatizar são pequenas atividades com regras claras, alta frequência de repetição e resultados que possam ser facilmente conferidos por uma pessoa. Por outro lado, é mais seguro manter uma etapa de revisão humana em tarefas que envolvam julgamento jurídico, aprovação de segurança, responsabilidade contratual ou decisões sobre valores importantes.

## Controles e manutenção fáceis de negligenciar na automação

Quando a automação é apressada devido à urgência do trabalho, os riscos do processo manual existente podem simplesmente ser transferidos para o código. Especialmente em um ambiente como o deste caso, que lida com arquivos externos, documentos assinados e dados de clientes, é necessário projetar controles juntamente com a velocidade de processamento.

### Controles mínimos a verificar

- **Permissões:** limitar as pastas e contas que a ferramenta de automação pode acessar ao escopo necessário.
- **Proteção de dados:** não inserir dados pessoais, materiais contratuais ou informações de autenticação em serviços externos de IA não autorizados.
- **Ambiente de teste:** executar primeiro com cópias e dados de teste não identificáveis, em vez dos originais.
- **Aprovação humana:** estabelecer procedimentos de confirmação em etapas difíceis de reverter, como envio e exclusão de arquivos e relatórios finais.
- **Registros:** manter registros das entradas, do horário de execução, dos resultados do processamento, dos erros e do histórico de correções.
- **Recuperação:** preservar os originais e os backups para possibilitar o retorno ao estado anterior em caso de falha.
- **Dependência do responsável:** documentar os procedimentos para que outros membros da equipe, além do criador, também saibam como executar e interromper a automação.

O critério de sucesso da automação também não deve ser “funcionou uma vez”. É necessário avaliar se ela pode ser modificada quando o formulário muda ou quando o responsável é substituído, se os erros podem ser detectados e se é possível retornar ao procedimento manual. Esses são os critérios que distinguem uma ferramenta de produtividade individual de curto prazo de um sistema de trabalho sustentável.

## Fatos confirmados pela experiência e limitações da generalização

Como este caso se baseia na experiência real de um responsável, ele não garante os mesmos resultados em todas as organizações. É necessário distinguir o que foi diretamente confirmado no caso daquilo que deve ser validado antes da aplicação em outro ambiente.

| O que foi observado no caso | O que deve ser verificado separadamente antes da aplicação |
|---|---|
| Um novo trabalho de manutenção foi adicionado sem mudanças na equipe | Alocação de pessoal e possibilidade de redistribuição do trabalho em cada organização |
| O canal único provocava interrupções repetidas no trabalho do responsável | Se o processamento direto entre solicitantes é permitido pelas normas de segurança |
| O fórum do sistema de gestão existente reduziu as etapas intermediárias | Permissões, retenção de registros e funcionalidades de aprovação do sistema utilizado |
| Uma pessoa sem experiência em desenvolvimento instalou uma ferramenta e aprendeu a usá-la com orientações de IA generativa | Permissões de instalação nos dispositivos da empresa e política de uso de IA externa |
| Um pequeno resultado gerou confiança para tentar outras automações | Precisão da automação, tempo economizado e custos de manutenção |

Portanto, o principal valor deste caso não está na afirmação de que uma ferramenta específica produz os mesmos resultados para qualquer pessoa. Está em não interpretar o trabalho repetitivo como falta de esforço individual, mas redefini-lo como um problema de fluxo, padrões, permissões e gargalos.

## Conclusão: a falta de tempo pode ser o ponto de partida

A automação não precisa ser vista apenas como um projeto separado, a ser aprendido depois que houver tempo disponível. Se o trabalho continua se acumulando e o mesmo problema se repetirá no mês seguinte, isso pode ser um sinal de que a estrutura atual precisa mudar.

O ponto de partida não precisa ser um plano grandioso de desenvolvimento. É possível escolher uma solicitação que interrompa a concentração com maior frequência e começar verificando se essa etapa realmente precisa passar por você. Se não for possível eliminá-la ou transferi-la para um sistema existente, é mais seguro padronizar o formato de entrada e começar automatizando uma pequena parte cujo resultado possa ser facilmente validado.

A pergunta mais importante deixada por este caso não é “como posso fazer este trabalho mais rapidamente?”. É “por que este trabalho se repete, por que precisa necessariamente passar por mim e até qual etapa pode ser atribuído a um sistema?”.

## FAQ

### É possível começar a automatizar o trabalho mesmo sem ser desenvolvedor?
Sim, mas é mais seguro começar com um escopo pequeno. É necessário descrever claramente o procedimento atual e as condições de entrada e saída, executar o método proposto pela IA generativa em uma cópia ou com dados de teste e, depois, verificar pessoalmente os resultados.

### Todas as tarefas repetitivas devem ser automatizadas?
Não. Primeiro, é necessário verificar se essa etapa pode ser eliminada ou realizada diretamente pelo solicitante. Se for difícil eliminá-la ou simplificar o fluxo e se tratar de uma tarefa repetitiva com regras claras, a automação poderá ser considerada.

### Vale a pena automatizar até mesmo tarefas que levam pouco tempo?
Pode valer a pena se ocorrerem com frequência e sem aviso, interrompendo o trabalho principal. É necessário avaliar não apenas o tempo de processamento de cada caso, mas também os custos envolvidos na verificação da solicitação, na mudança de tarefa, na complementação de informações ausentes, no registro e na retomada da concentração.

### Por que a padronização deve vir antes da automação do trabalho?
Porque, se os campos obrigatórios e o formato de entrada não forem consistentes, será difícil para a automação lidar com as exceções de forma confiável. Definir primeiro os critérios de conclusão, o formato das datas, as condições de assinatura e os motivos de recusa facilita a implementação e a validação.

### É permitido executar diretamente o código criado pela IA generativa?
Não se deve executá-lo diretamente. É necessário verificar se haverá exclusão de arquivos, alteração de permissões ou transmissão externa, além de conferir as políticas de segurança e as permissões de instalação da organização. É mais seguro validá-lo primeiro em uma cópia, e não no original, usando dados de teste desidentificados.

### A automação permite eliminar toda a revisão humana?
Depende do nível de risco da tarefa. Etapas em que os erros podem causar grandes impactos, como transferência e exclusão de arquivos, aprovação de segurança, decisões contratuais e decisões sobre valores importantes, devem manter procedimentos de verificação e aprovação por uma pessoa.

### Que tipo de tarefa é melhor escolher como primeiro alvo de automação?
São adequadas tarefas pequenas, realizadas com frequência, com regras claras e cujos resultados possam ser facilmente conferidos por uma pessoa. Também é necessário verificar se, em caso de erro, é possível restaurar os dados a partir do original e se o risco de exposição de informações sensíveis é baixo.

### Como determinar se a automação foi bem-sucedida?
Não se deve considerar apenas se a execução foi bem-sucedida, mas também comparar o número de interrupções, recusas e omissões, o tempo de espera para processamento e o tempo gasto na correção de erros. Também é necessário avaliar se será possível mantê-la mesmo com alterações nos formulários e substituições dos responsáveis, bem como retornar ao procedimento manual em caso de falha.

## Sources

- [Quando o aumento da equipe foi recusado, a automação começou com um “vamos tentar fazer isso” | 요즘IT](https://yozm.wishket.com/magazine/detail/3912/)

## Images

![Funcionária usa um laptop enquanto colegas consultam uma tela sensível ao toque](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI4NzUsInB1ciI6ImJsb2JfaWQifX0=--6ea22c48d8437db264e2c179ded939ce099f2a0b/ai-fcef29be.webp)
![Documentos e alertas desorganizados transformados em painel e fluxo de trabalho automatizados](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI4ODMsInB1ciI6ImJsb2JfaWQifX0=--8996698429ec4d415b74063aa44ca9f301aa486e/ai-cd6d8a57.webp)