A maioria dos sistemas de escala nasce pensando em turno comercial: segunda a sexta, 8h às 18h, fins de semana livres. Funciona até a empresa ter uma operação que não para — indústria, energia, saúde, segurança — e aí aparecem os formatos que o modelo ingênuo não aguenta: 5x2 (cinco dias trabalhados, dois de folga), 6x3, 6x4, 12x48h (doze horas trabalhadas, quarenta e oito de descanso). Cada um com regra própria de quando o ciclo reinicia, quantos dias de folga acumulam, e como tratar feriado caindo num dia de trabalho.
Construí o EscalaOper para resolver exatamente isso: um sistema desktop integrado a app/web onde o gestor administra a escala e a equipe operacional acompanha em tempo real. Este post descreve o padrão de modelagem que faz o mesmo sistema aguentar qualquer um desses formatos sem uma condicional nova a cada turno diferente.
Por que o modelo ingênuo quebra
O primeiro instinto de quem nunca lidou com escala não-comercial é modelar dia da semana: “segunda trabalha, terça trabalha… sábado e domingo não”. Isso é uma tabela de exceções fixas por dia da semana — e o formato 5x2 raramente respeita a semana civil. Um ciclo 5x2 que começa numa quarta-feira produz um padrão de trabalho/folga que desliza pela semana inteira, mudando qual dia cai em folga a cada ciclo. Modelar isso como “segunda a sexta trabalha” está simplesmente errado para a maior parte dos calendários reais.
O erro se agrava com 12x48h: aqui não existe noção de “dia de trabalho fixo” nenhuma — o funcionário trabalha 12 horas, folga 48, e o dia da semana em que isso cai muda a cada rotação. Uma tabela de dias fixos não tem onde guardar esse padrão.
O padrão que resolve: ciclo + âncora, não calendário fixo
A modelagem que funciona para qualquer formato tem três peças, e nenhuma delas é “dia da semana”:
- Duração do ciclo, em dias: 5x2 tem ciclo de 7 dias (5 trabalho + 2 folga); 6x3 tem ciclo de 9; 12x48h tem ciclo de 3 dias (1 trabalho + 2 folga, contando em dias de 24h). O ciclo é a unidade que se repete — não a semana.
- Padrão dentro do ciclo: uma sequência de posições marcadas como trabalho ou folga, do tamanho do ciclo. Para 5x2:
[T,T,T,T,T,F,F]. Esse padrão nunca muda para aquele tipo de escala. - Data-âncora: a data em que o ciclo de uma pessoa específica começou. É essa âncora, e só ela, que decide em qual posição do padrão qualquer dia futuro (ou passado) cai — calculando
(dias desde a âncora) módulo (duração do ciclo).
O calendário não guarda o padrão de trabalho de ninguém. Ele só pergunta ao ciclo: em que posição eu estou hoje?
Com essas três peças, adicionar um formato de escala novo — digamos, um 4x2 que a empresa decide testar — não exige nenhuma mudança de código: é só um registro novo com duração=6 e padrão=[T,T,T,T,F,F]. O sistema que já aguenta 5x2, 6x3 e 12x48h aguenta o novo formato de graça, porque nenhum deles nunca foi um caso especial — todos são a mesma pergunta feita ao mesmo mecanismo.
Onde a complexidade de verdade mora: as exceções
O ciclo puro resolve o caso feliz. O que separa um sistema de escala usável de um acadêmico é como ele lida com o que quebra o padrão:
- Feriado caindo em dia de trabalho: normalmente gera direito a folga compensatória ou pagamento diferenciado — um registro de exceção sobre o dia calculado pelo ciclo, nunca reescrevendo o ciclo em si.
- Férias e afastamentos: suspendem o ciclo da pessoa por um intervalo, sem afetar o ciclo de ninguém mais na mesma escala.
- Convocação extra (cobrir a falta de um colega): um registro pontual que se sobrepõe ao dia calculado — a pessoa deveria estar de folga segundo o ciclo, mas foi convocada; o sistema precisa mostrar as duas coisas: o que o ciclo previa e o que de fato aconteceu.
A regra de desenho que se paga: o ciclo calcula a previsão; a exceção é sempre um registro à parte que sobrepõe o dia, nunca uma reescrita do padrão. Isso mantém o motivo de cada desvio auditável — “por que fulano trabalhou numa sexta que deveria ser folga dele” tem resposta no registro de exceção, não escondido dentro de uma condicional de código.
Desktop administra, app consulta em tempo real
A decisão de arquitetura do EscalaOper reflete quem faz o quê: o gestor usa a interface desktop para montar e ajustar a escala — operação de edição, que se beneficia de tela grande, atalhos de teclado, visão de mês inteiro. A equipe operacional só precisa consultar “estou de trabalho ou de folga amanhã” e ver convocações — isso é consumo, não edição, e o lugar certo é o bolso de cada um: app ou navegador, sempre com o dado mais recente, porque convocação de última hora é o cenário que mais importa acertar.
O princípio portável
Qualquer sistema que lide com repetição temporal — escala de trabalho, plano de manutenção preventiva, cronograma de rodízio, calendário de cobrança recorrente — cai na mesma armadilha e no mesmo padrão de solução: não modele o calendário civil, modele o ciclo e uma âncora, e trate toda exceção como um registro sobreposto, nunca como uma reescrita do padrão. O calendário que todo mundo usa para se situar no tempo raramente é a estrutura certa para guardar um padrão que se repete — ele só serve para perguntar ao ciclo em que posição um dia específico cai.
