Cost Classification: CapEx vs. OpEx Explicado

O que mede

Cost classification divide o trabalho de engenharia concluído em duas categorias contábeis: CapEx (capital expenditure — trabalho que cria ou melhora substancialmente um ativo, capitalizado no balanço e depreciado ao longo do tempo) e OpEx (operating expenditure — trabalho que mantém tudo funcionando, contabilizado como despesa imediatamente). Um terceiro bucket, não classificado, cobre qualquer coisa que ainda não teve uma regra definida — deliberadamente nunca escondido, já que jogar item não classificado silenciosamente num dos dois buckets distorceria a divisão.

Por que importa

Essa não é uma métrica de engenharia que por acaso tem nome de finanças — é um insumo real de como uma empresa reporta suas finanças. Custo de engenharia capitalizado vira um ativo que deprecia ao longo de anos em vez de um custo que bate inteiro nas despesas do trimestre atual, o que afeta diretamente o lucro reportado, e em algumas jurisdições, a elegibilidade pra crédito fiscal de P&D. Times de finanças precisam dessa divisão desde que software existe; o que geralmente falta é um jeito confiável e de baixo esforço de produzir isso, que não dependa de engenheiro marcando o próprio ticket manualmente meses depois, de memória.

Também importa por um segundo motivo, mais do dia a dia: uma quebra CapEx/OpEx ao vivo é um dos jeitos mais claros de ver quanto do resultado da engenharia vai pra construir coisa nova versus manter coisa existente funcionando — uma pergunta que CTO e CFO se importam, por motivos diferentes, e que é genuinamente difícil de responder sem esse tipo de classificação em vigor.

Como calcular

Classifique cada item concluído (não item de backlog — só trabalho que de fato foi entregue) em CapEx, OpEx, ou deixe não classificado, baseado em regras mapeadas a partir das mesmas categorias semânticas usadas em outro lugar (trabalho de Feature comumente mapeia pra CapEx, correção de Bug e Toil comumente mapeiam pra OpEx, embora o mapeamento exato seja uma decisão de política, não uma regra fixa). Junto da contagem de itens em cada bucket, hours — tempo decorrido de quando o trabalho começou até terminar — dá uma noção aproximada de escala, embora valha a pena deixar explícito que tempo decorrido não é a mesma coisa que esforço rastreado: um item bloqueado por uma semana esperando revisão conta essa semana do mesmo jeito que se alguém tivesse trabalhando ativamente nele o tempo todo.

Um exemplo rápido: um time conclui 20 itens num mês — 16 mapeiam pra CapEx, 4 pra OpEx, nenhum não classificado. A divisão é 80% CapEx, 20% OpEx por contagem. Se esses itens também carregam 1.395 horas decorridas entre eles, a mesma divisão pode ser expressa em horas em vez de contagem de item — útil pra uma conversa com finanças, já que impacto em dinheiro costuma acompanhar horas mais de perto do que contagem bruta de item.

Como interpretar os números

Não existe uma razão CapEx/OpEx "correta" universal — depende inteiramente da política de capitalização da própria empresa (que em si é uma escolha contábil legítima, às vezes conservadora) e da fase de construção do produto em que o time está. Um time em desenvolvimento pesado de feature nova naturalmente pende pra CapEx; um time majoritariamente fazendo manutenção e correção de bug num produto maduro pende pra OpEx, e isso não é um problema pra consertar, é só como manutenção se parece. O que vale a pena observar em vez de perseguir uma razão-alvo: um bucket de não classificado crescendo, que geralmente significa que trabalho novo está sendo entregue mais rápido do que alguém está atualizando as regras de classificação pra ele.

Uma armadilha comum

Trabalho cancelado — um item começado, depois abandonado antes de terminar — inflando silenciosamente os totais de "entregue" é um modo de falha real, não hipotético: um item que fica cancelado por meses pode acabar contado como concluído num sistema que não rastreia cancelamento como estado próprio, superestimando tanto os totais de CapEx/OpEx quanto qualquer outra coisa que assume que "concluído" significa "entregue". Tratar trabalho cancelado como uma categoria própria e visível — em vez de silenciosamente dobrar pra qualquer bucket em que estava quando alguém desistiu — evita essa distorção.

Como o moasy.tech calcula isso

O moasy.tech classifica todo item concluído em CapEx, OpEx ou não classificado usando regras semânticas que você configura — o mesmo motor de regras usado pra classificação de Bug/Feature/ Dívida Técnica/Toil/Risco em outro lugar, então cost classification continua consistente com como o time já categoriza o próprio trabalho, em vez de exigir uma segunda taxonomia separada. Reclassificar uma categoria (por exemplo, mover Dívida Técnica de OpEx pra CapEx) reflete imediatamente no dashboard, sem precisar de ressincronização — é uma visão ao vivo de uma decisão de política, não um relatório gerado uma vez e deixado desatualizado. Trabalho cancelado é rastreado como um sinal próprio, mantido separado dos totais de CapEx/OpEx/não classificado pra nunca contar silenciosamente como entregue.

Veja a implementação completa na página de Cost Classification, ou o passo a passo pra configurar a regra de classificação no tutorial de Help.

Dado ilustrativo, apenas para demonstração.

Perguntas sobre cost classification