5.4 Custo e economia unitária da engenharia

Visão geral e motivação

Este tema torna a Parte 5 explicitamente financeira: como expressar o custo de engenharia em termos que uma parte interessada financeira pode usar diretamente, e como construir economia unitária, custo expresso por unidade significativa de produção ou utilização, em vez de uma linha orçamental departamental opaca e agregada. O custo de engenharia é normalmente a maior linha de despesa controlável numa organização impulsionada por software, e ainda assim é frequentemente a menos bem compreendida pela função financeira, reportada como um único número grande com pouca visibilidade sobre o que a impulsiona ou como escala com o crescimento. Este tema existe para fechar essa lacuna, porque um líder de engenharia que não consegue responder “quanto nos custa correr este sistema” ou “como escala o nosso custo à medida que crescemos” em termos financeiros concretos está numa desvantagem real em todas as conversas de orçamento.

A disciplina específica que este tema recomenda, economia unitária, significa expressar o custo por implementação, por cliente servido, por transação processada, ou outra unidade que realmente importa ao negócio, em vez de apenas como custo total de pessoal ou gasto total de nuvem. Este reenquadramento liga-se diretamente ao princípio de resultados-acima-do-produto do tema 1.3: um número de custo total a cair não é automaticamente bom se vier de servir menos clientes, e um número de custo total a subir não é automaticamente mau se vier de servir proporcionalmente muitos mais. A economia unitária é o que torna as tendências de custo interpretáveis em vez de apenas visíveis.

Para equipas grandes, a disciplina deste tema é o que transforma as finanças de engenharia de uma caixa negra num sistema legível e gerível. As organizações empresariais usam a economia unitária para comparar a eficiência de custo de diferentes produtos, plataformas, ou equipas numa base justa; as organizações governamentais usam a mesma disciplina para demonstrar responsabilidade fiscal e para construir um caso baseado em evidência para investimento em infraestrutura que reduzirá o custo por cidadão servido ao longo do tempo.

Princípios-chave

O custo total isolado não é interpretável sem um denominador. A economia unitária, custo por unidade significativa, transforma um número opaco numa tendência acionável.
Escolha uma unidade que reflita valor genuíno de negócio ou missão, não um denominador arbitrário ou facilmente manipulável.
O custo tem múltiplos componentes: pessoas, infraestrutura, e ferramentas. Rastreie-os separadamente, já que cada um tem um impulsionador de custo diferente e uma alavanca diferente a puxar.
As práticas FinOps trazem o mesmo rigor ao custo de nuvem que este livro traz às métricas de entrega e qualidade. Trate o custo como mensurável e gerível, não como um dado inevitável e opaco.
Um custo total a cair não é automaticamente bom, e um a subir não é automaticamente mau, sem verificar o que aconteceu à medida unitária ao mesmo tempo.

Recomendações

Escolha uma unidade que reflita valor real entregue, não um denominador arbitrário

Selecione uma unidade para o seu cálculo de economia unitária que genuinamente rastreie valor de negócio ou missão: custo por cliente servido, custo por transação processada, custo por implementação, ou custo por interação de cidadão tratada para um serviço do setor público. Evite um denominador demasiado facilmente inflacionável para lisonjear o rácio, como uma contagem interna e largamente discricionária que não corresponde a nenhuma unidade externa genuína de valor entregue.

Separe os custos de pessoas, infraestrutura, e ferramentas

O custo de engenharia tem pelo menos três componentes distintos com impulsionadores diferentes e alavancas diferentes: custo de pessoas (salários, benefícios, largamente fixo no curto prazo), custo de infraestrutura (gasto de nuvem, largamente variável com a utilização e diretamente otimizável através da prática de engenharia), e custo de ferramentas e licenciamento (muitas vezes custos fixos por lugar ou por nível de utilização). Rastreie-os separadamente em vez de como um total combinado, já que um custo total crescente impulsionado por infraestrutura a escalar com crescimento genuíno exige uma resposta muito diferente do que o mesmo aumento total impulsionado por proliferação não gerida de ferramentas.

Aplique a disciplina FinOps especificamente ao custo de infraestrutura de nuvem

O FinOps é a disciplina de trazer responsabilidade financeira ao gasto variável de nuvem através de colaboração interfuncional entre equipas de engenharia, finanças, e negócio. Aplique as suas práticas centrais diretamente: etiquete os recursos de nuvem por equipa e serviço para atribuição de custo, reveja o gasto contra o orçamento numa cadência regular, e trate a eficiência de custo de infraestrutura (custo por unidade de utilização real) como uma métrica de engenharia que vale a pena otimizar deliberadamente, não uma sobrecarga fixa e inevitável a simplesmente aceitar.

Rastreie a tendência de custo unitário ao longo do tempo, e investigue o movimento explicitamente

Um instantâneo único de custo unitário é menos útil do que a sua tendência: o custo por cliente servido está a cair à medida que a plataforma amadurece e escala (um sinal de ganhos genuínos de eficiência), ou a subir (um sinal de ineficiência acumulada, dívida técnica a impulsionar custo mais alto de manutenção, ou uma mudança na combinação de clientes servidos para segmentos mais intensivos em recursos). Investigue explicitamente uma mudança significativa na tendência de custo unitário em vez de reportar o número sem explicação.

Ligue os dados de custo às métricas de dívida técnica e qualidade de outros temas deste livro

O custo crescente de infraestrutura ou manutenção por unidade é por vezes uma consequência direta e mensurável de dívida técnica acumulada (tema 4.5) ou de uma proliferação de pontos quentes de complexidade (tema 4.1, tema 4.3): caminhos de código ineficientes, infraestrutura redundante, e consultas mal otimizadas aparecem todos eventualmente como custo unitário elevado. Use o custo unitário crescente como uma entrada, ao lado dos sinais de processamento e complexidade da Parte 4, na sua discussão de priorização de dívida, já que um item de dívida com impacto demonstrado e mensurável de custo constrói um caso mais forte para investimento de remediação do que uma queixa não quantificada de qualidade sozinha.

Trocas: prós e contras

Abordagem	Prós	Contras
Reportar apenas o custo total	Simples, corresponde a como os orçamentos são tipicamente alocados	Não interpretável sem um denominador; esconde tendências de eficiência
Economia unitária com um denominador bem escolhido	Interpretável, acionável, comparável ao longo do tempo e entre equipas	Exige cuidado ao escolher uma unidade genuinamente significativa e difícil de manipular
Reporte de custo combinado (pessoas, infraestrutura, ferramentas combinados)	Número único simples	Obscurece qual impulsionador específico de custo está realmente a mudar e porquê
Componentes de custo separados	Revela a alavanca certa a puxar para uma dada tendência de custo	Exige atribuição de custo mais detalhada e infraestrutura de rastreio

A tensão central é simplicidade versus acionabilidade. Um único número de custo total é fácil de reportar e corresponde a como muitas organizações já alocam orçamento, mas obscurece tanto o que está a impulsionar as mudanças de custo como se essas mudanças refletem eficiência genuína ou crescimento genuíno. Resolva a tensão investindo na economia unitária e no reporte de componentes separados, algo mais complexos, que este tema recomenda, já que a acionabilidade resultante, saber exatamente que alavanca puxar quando o custo se move, vale o esforço adicional modesto de rastreio para qualquer organização para além da escala mais pequena.

Perguntas para debater com a sua equipa

Rastreamos o custo de engenharia por unidade significativa (cliente, transação, implementação), ou apenas como um total opaco? Se apenas existe um total, identifique que unidade tornaria a sua tendência de custo genuinamente interpretável e discuta o que seria necessário para começar a rastreá-la.
Conseguimos separar o nosso custo atual em componentes de pessoas, infraestrutura, e ferramentas, e sabemos qual está a impulsionar alguma mudança recente? Puxe a sua repartição real de custo, se existir, e verifique se é suficientemente detalhada para responder a esta pergunta com confiança.
Aplicámos práticas de etiquetagem e atribuição FinOps ao nosso custo de infraestrutura de nuvem, ou é uma única linha não atribuída? Se o gasto não pode ser atribuído a equipas ou serviços específicos, discuta como seria o primeiro passo em direção a uma atribuição genuína.
A nossa tendência de custo unitário moveu-se significativamente em qualquer direção recentemente, e sabemos porquê? Investigue um movimento real e recente, se existir, e veja se o consegue explicar com confiança ou se permanece um mistério.
A nossa tendência atual de custo de infraestrutura correlaciona-se com algum dos nossos sinais de dívida técnica ou ponto quente de complexidade da Parte 4? Faça referência cruzada destas fontes de dados explicitamente e veja se emerge uma ligação que possa fortalecer um caso de negócio de remediação de dívida.
Se perguntados amanhã por uma parte interessada financeira “quanto nos custa servir mais um cliente”, conseguiríamos responder com confiança? Esta pergunta concreta e prática testa se a sua economia unitária está realmente construída e pronta, ou meramente uma aspiração teórica.

Perspetiva setorial

Startup. A economia unitária importa imensamente cedo, já que investidores e fundadores precisam ambos de saber se o custo de servir cada cliente adicional está a tender para a sustentabilidade ou para um modelo de negócio que não consegue escalar. Rastreie isto desde muito cedo, mesmo com estimativas aproximadas, em vez de esperar até a empresa ser grande o suficiente para justificar ferramentas formais de FinOps.

Pequena empresa. Os painéis de faturação do fornecedor de nuvem normalmente fornecem visibilidade básica suficiente de custo sem ferramentas dedicadas de FinOps; a principal disciplina é escolher uma unidade sensata (custo por cliente ou custo por transação) e verificar a tendência periodicamente, em vez de apenas olhar para a fatura total isoladamente.

Empresa. A prática FinOps e o rastreio de componentes de custo separados são essenciais a esta escala, onde o gasto de nuvem pode representar uma linha orçamental muito grande e muitas vezes pouco escrutinada espalhada por muitas equipas. Invista em etiquetagem adequada de atribuição de custo e numa cadência dedicada de revisão de custo, e use a economia unitária para comparar a eficiência de custo justamente através de diferentes linhas de produto ou plataformas.

Governo. A responsabilidade fiscal e a eficiência demonstrável de custo são diretamente relevantes para a justificação orçamental e a responsabilização pública. A economia unitária expressa como custo por cidadão servido, ou custo por transação processada, é muitas vezes uma métrica muito mais persuasiva e interpretável para comissões orçamentais do que uma cifra bruta de gasto total, e apoia diretamente o caso de negócio para investimento em infraestrutura que reduz o custo por unidade ao longo do tempo.

Exemplos

Empresa. A equipa financeira de uma empresa de software como serviço tinha estado alarmada com o aumento do gasto total de infraestrutura de nuvem durante vários trimestres consecutivos, inicialmente assumindo ineficiência ou desperdício. Uma análise de economia unitária, custo por cliente ativo, mostrou que o custo unitário tinha na realidade estado a cair consistentemente mesmo com o gasto total a subir, porque a contagem de clientes estava a crescer mais depressa do que o custo de infraestrutura, uma melhoria genuína de eficiência mascarada ao olhar apenas para o gasto total. Este reenquadramento mudou a conversa financeira de “porque é que a engenharia está a gastar mais” para “como sustentamos esta escala eficiente”, uma discussão materialmente mais produtiva que evitou um mandato desnecessário e potencialmente prejudicial de corte de custos que teria visado gasto genuinamente saudável impulsionado por crescimento.

Governo. A agência de serviços digitais de um governo estadual foi solicitada a justificar o investimento continuado em infraestrutura de nuvem a uma comissão orçamental que comparava custos contra o sistema legado no local que estava a substituir. Uma análise de economia unitária, custo por transação de cidadão processada, mostrou que o custo unitário do novo sistema baseado em nuvem era substancialmente mais baixo do que o do sistema legado tinha sido, apesar do gasto nominal total mais alto, porque o novo sistema tratava um volume muito mais alto de transações com o mesmo ou menor orçamento total de infraestrutura. Esta comparação de custo unitário, em vez de uma comparação de gasto total mais difícil de interpretar, tornou-se a evidência central num caso bem-sucedido para investimento continuado e expandido em nuvem.

Argumento de negócio: motivações, ROI, e TCO

O retorno de uma economia unitária rigorosa é uma resposta defensável e interpretável à pergunta que toda a parte interessada financeira eventualmente faz: este gasto é eficiente, e está a escalar sustentavelmente? O exemplo empresarial acima mostra o risco de errar nisto: uma vista apenas de gasto total quase desencadeou um mandato desnecessário e contraproducente de corte de custos contra gasto que estava, numa base unitária, a tornar-se mais eficiente, não menos.

O custo total de propriedade inclui ferramentas de atribuição de custo (práticas de etiquetagem FinOps) e a disciplina analítica para separar componentes de custo e rastrear tendências unitárias ao longo do tempo. Esse investimento é modesto comparado com o risco de tomar uma decisão orçamental significativa, cortar gasto que era na realidade eficiente, ou falhar em apanhar gasto que estava genuinamente a tornar-se ineficiente, baseada apenas numa vista mal informada de custo total.

Antipadrões e armadilhas

Reportar o custo total sem denominador: não interpretável e esconde se o custo está a escalar eficiente ou ineficientemente.
Escolher uma unidade facilmente manipulável ou arbitrária para o cálculo de custo: produz um rácio que lisonjeia em vez de informar.
Combinar o custo de pessoas, infraestrutura, e ferramentas num único número: obscurece qual impulsionador específico está realmente a mudar e que alavanca o aborda.
Nenhuma atribuição de custo de nuvem (etiquetagem FinOps): deixa o gasto de infraestrutura efetivamente não gerido e não responsabilizado ao nível da equipa ou serviço.
Reagir a uma mudança de custo total sem verificar a tendência unitária: pode desencadear um mandato desnecessário de corte de custos contra gasto genuinamente eficiente e impulsionado por crescimento.
Nunca ligar as tendências de custo a dados de dívida técnica ou complexidade: perde um caso quantificado e fortalecido para investimento em remediação de dívida.

Modelo de maturidade

Nível 1, Iniciar: O custo de engenharia é reportado apenas como um total opaco, sem economia unitária ou separação de componentes.
Nível 2, Desenvolver: Existe alguma repartição de custo, mas a economia unitária é inconsistente e a atribuição de custo de nuvem está largamente ausente.
Nível 3, Padronizar: A economia unitária com um denominador bem escolhido é rastreada consistentemente, com o custo separado em componentes de pessoas, infraestrutura, e ferramentas em toda a organização.
Nível 4, Gerir: As práticas de atribuição e revisão FinOps estão estabelecidas, e as tendências de custo unitário são ativamente investigadas e ligadas a sinais de dívida técnica e qualidade.
Nível 5, Orquestrar: A organização consegue responder com confiança a perguntas detalhadas de custo unitário de partes interessadas financeiras, e os dados de custo informam diretamente tanto as decisões de investimento de engenharia como a justificação orçamental ao mais alto nível.

Ideias para debate

Que unidade tornaria a nossa tendência de custo genuinamente interpretável, e rastreamo-la?
Conseguiríamos separar uma mudança recente de custo nos seus componentes de pessoas, infraestrutura, e ferramentas?
Alguma parte do nosso gasto de infraestrutura está atualmente não atribuída a uma equipa ou serviço específico?
A nossa tendência de custo unitário moveu-se recentemente, e sabemos porquê?
Onde poderia o custo unitário crescente ser um sintoma de dívida técnica não abordada?

Principais conclusões

A economia unitária, custo por unidade significativa de valor, transforma um número opaco de custo total numa tendência interpretável e acionável.
Escolha uma unidade que reflita valor genuíno de negócio ou missão, e evite um denominador facilmente manipulável ou arbitrário.
Separe o custo em componentes de pessoas, infraestrutura, e ferramentas, já que cada um tem um impulsionador diferente e uma alavanca diferente.
Aplique a disciplina FinOps especificamente ao custo de infraestrutura de nuvem, incluindo etiquetagem de atribuição e revisão regular.
Um custo total a cair não é automaticamente bom, e um a subir não é automaticamente mau, sem verificar a tendência unitária ao lado.

Referências e leituras adicionais

Cloud FinOps, de J.R. Storment e Mike Fuller.
Accelerate: The Science of Lean Software and DevOps, de Nicole Forsgren, Jez Humble, e Gene Kim.
Site Reliability Engineering, de Betsy Beyer, Chris Jones, Jennifer Petoff, e Niall Richard Murphy, eds.
O FinOps Framework da FinOps Foundation, finops.org.