3e Cronos: lançando uma plataforma interna do zero ao beta

O problema

A operação dependia de soluções de terceiros para controle de ponto e gestão de tempo corporativo — com as limitações de customização e integração que isso costuma trazer. A decisão foi construir uma plataforma própria, a 3e Cronos, e eu liderei essa iniciativa do zero até o lançamento da fase beta, conectando requisitos de negócio, produto e engenharia num único fluxo de decisão.

Decisões de arquitetura

A primeira decisão foi de stack: Python com Django para a lógica central da plataforma, aproveitando produtividade e um ORM maduro para modelar as regras de jornada de trabalho, e PHP com Laravel onde fazia sentido integrar com sistemas internos já existentes na empresa construídos nessa stack. Em vez de forçar uma reescrita completa de tudo numa única tecnologia, a escolha foi pragmática: usar a ferramenta certa para cada parte do problema, aceitando o custo de manter duas stacks em troca de velocidade de entrega e menor risco de integração.

A segunda decisão, talvez a mais importante para o resultado final, foi lançar em fases. Em vez de tentar cobrir todas as regras de jornada de trabalho e exceções da legislação trabalhista antes do primeiro release, a plataforma foi ao ar como beta com o fluxo essencial de registro de ponto funcionando para um grupo controlado de usuários. Isso permitiu validar a usabilidade do dia a dia — algo que só se descobre com uso real — antes de investir engenharia em casos de borda que talvez nem fossem prioritários.

Na modelagem de dados, o cuidado maior foi representar jornada de trabalho e exceções (faltas, horas extras, compensações) de um jeito que refletisse fielmente as regras trabalhistas e as políticas internas da empresa, para que o sistema pudesse ser auditável e servir de base confiável para decisões de RH e folha de pagamento no futuro.

Desafios & aprendizados

O maior aprendizado foi que baixo atrito no registro do dia a dia é o fator que decide a adesão a um sistema de controle de ponto — mais do que qualquer feature avançada. Colocar o beta na frente de usuários reais cedo mostrou isso rapidamente: pequenos atritos na interface de registro geravam mais reclamação do que a ausência de funcionalidades mais sofisticadas.

Também aprendi, nesse projeto, como é fácil subestimar o trabalho de tradução entre negócio e engenharia quando o domínio envolve legislação trabalhista. Regras que pareciam simples na conversa com a área de RH ("todo mundo tem direito a X horas de intervalo") escondiam exceções e casos específicos que só apareciam quando a gente tentava modelar o dado de verdade. Isso reforçou a importância de manter o time de produto, negócio e engenharia no mesmo espaço de decisão desde o início, em vez de tratar como um repasse de requisitos.

Resultado

A plataforma foi lançada do zero ao beta, conectando a necessidade de negócio diretamente à engenharia, e hoje serve de base para a gestão de tempo de toda a operação.