Medição dos fluxos de valor na entrega de software com o Esquema do Sistema de Valor

Texto completo

1 Introdução

As equipes de software são medidas de perto: velocidade, vazão, lead time, frequência de implantação e taxa de falha de mudanças são coletadas automaticamente. No entanto, esses números deixam uma pergunta em aberto: que valor a equipe entregou, a quem e a que custo em perdas?

Este artigo propõe um método para responder a essa pergunta com o Esquema do Sistema de Valor (Value System Schema, VSS), a notação de modelagem da metodologia Æilus, tal como implementada no VSS Editor publicado em aeilus.tech. É o quinto artigo da série "Æilus for Business". Ele usa o vocabulário definido no primeiro artigo da série, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026), e não repete essas definições. O tratamento formal do valor como moeda mensurável (Æ) é apresentado em "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026).

O artigo descreve como uma organização de entrega pode construir um esquema do seu sistema de valor, associar valor planejado e valor realizado às versões (releases), localizar a resistência ao fluxo e o vazamento, avaliar nós técnicos compartilhados e executar o ciclo com papéis e cadência claros. Baseia-se nos axiomas A1, A2, A4, A5, A6, A7, A11 e A13 da VMT e nos teoremas T3, T4, T5, T6, T8, T9, T15, T16 e T17. Não contém dados medidos. O exemplo trabalhado na Seção 9 é sintético.

2 O que as métricas de entrega medem e o que não medem

As métricas de entrega descrevem o movimento do trabalho. A velocidade conta o esforço estimado concluído; a vazão conta os itens finalizados. As quatro métricas-chave popularizadas por Forsgren, Humble e Kim (Accelerate, 2018), a saber, frequência de implantação, lead time para mudanças, tempo de restauração do serviço e taxa de falha de mudanças, descrevem a rapidez e a estabilidade do pipeline de entrega. Essa pesquisa relaciona essas capacidades ao desempenho organizacional, e este artigo não a contesta. Sua afirmação é mais restrita: essas métricas descrevem o pipeline, não o valor que passa por ele.

Três lacunas decorrem disso.

• Esforço não é valor. Uma sprint com alta velocidade pode entregar funcionalidades que ninguém usa. Na linguagem do deck Product Value System, "features are not value" e "metrics are not value": uma funcionalidade é uma suposição sobre valor, e uma métrica é uma interpretação dele.
• Rapidez não é direção. Um lead time curto entrega uma hipótese errada mais depressa.
• Estabilidade não é ausência de antivalor. Uma baixa taxa de falha de mudanças nada diz sobre atraso, confusão, retrabalho do lado do usuário ou perda de confiança causada por uma mudança que funcionou exatamente como projetada.

Do ponto de vista da Teoria da Gestão de Valor (Value Management Theory, VMT), a lacuna é estrutural. O valor existe apenas dentro de um sistema de valor definido e é interpretado por seus atores (A1, A2). Ele é realizado no momento do consumo (A6), e o valor planejado e o realizado geralmente diferem (A4, T3). As métricas de pipeline são coletadas antes do consumo, do lado do remetente, de modo que descrevem, no máximo, a entrega do valor planejado. Quando essas métricas se tornam metas, surge o efeito descrito por Goodhart (1975): as equipes otimizam o contador. A VMT enuncia o mesmo risco em termos sistêmicos: a otimização local não garante melhoria global (T5).

3 A notação do Esquema do Sistema de Valor

3.1 Elementos da notação

Na metodologia Æilus, o Esquema do Sistema de Valor é o primeiro artefato central: uma descrição formal do sistema de valor, de seus atores, fluxos, transformadores e trocas-chave, usada para estabelecer os limites do sistema e evitar dependências externas invisíveis. Um VSS pode ser desenhado no nível do transformador ou no nível do sistema.

O VSS Editor, lançado em aeilus.tech em dezembro de 2025, é um editor visual baseado em navegador para esses esquemas. Sua notação tem um pequeno número de elementos.

• Conversores. Conversor é o nome, em Æilus, para um papel de transformador em um esquema: um bloco funcional, como uma equipe, um serviço ou um subsistema, que recebe elementos de valor, os transforma e produz novos. Os conversores são onde o valor é criado, amplificado ou destruído.
• Fluxos. Um fluxo é uma conexão direcional entre conversores, ou entre um conversor e o mundo exterior. Ele transporta uma quantidade de valor ou de antivalor em Æ. Um fluxo é externo de entrada (valor que entra no sistema), externo de saída (valor que sai do sistema) ou interno (valor entre conversores).
• Entradas e saídas. Os fluxos externos de entrada e de saída marcam onde o valor entra e sai. Juntos, definem o limite do sistema.
• Elementos de valor. Os tipos de elemento descrevem o que exatamente se move por um fluxo: valor para o cliente, receita, custos, riscos, dívida técnica e similares. Em um esquema salvo, cada elemento tem um tipo (valor ou antivalor), um sinal, uma quantidade e uma unidade (Æ).
• Antivalor. O antivalor representa perdas e efeitos negativos: atrasos, retrabalho, defeitos, burocracia, risco, burnout, esforço desperdiçado. No esquema, é um elemento explícito com sinal negativo, não a ausência de valor (A5).

3.2 O esquema como modelo legível por máquina

O editor salva um esquema como JSON estruturado com nós (conversores), fluxos e elementos. O esquema pode, portanto, ser versionado junto com o produto e, mais tarde, lido por análises que comparem quantidades planejadas e realizadas por fluxo. Tais análises são anunciadas como trabalho futuro e não são pressupostas aqui.

3.3 O que o esquema não é

O VSS Editor explicitamente não é um painel de KPIs, uma ferramenta de BI, um mecanismo de simulação nem um substituto da contabilidade financeira. Ele coloca a clareza antes do cálculo. A ordem de modelagem recomendada é a seguinte: definir o limite, adicionar apenas os conversores principais, conectá-los com fluxos nomeados (nomes antes de números, direção antes de precisão) e, então, marcar o antivalor, o passo que muitas vezes produz mais percepções.

4 O valor de quem: o sistema e seu limite

Uma medição de valor não faz sentido enquanto não declara o valor de quem é medido (A1, T1). O limite escolhido também altera as conclusões sem qualquer mudança na realidade (T15). Este artigo, portanto, fixa o sistema de valor antes de qualquer medição.

O sistema de valor modelado aqui é o sistema de valor do produto de um único produto de software dentro de uma organização de produto. Seguindo o deck Product Value System, seus atores são a função de produto, a equipe de desenvolvimento, as operações, o produto em produção, os usuários e a empresa como receptora do valor devolvido pelos usuários. As finanças são um fluxo externo habilitador de entrada (salários).

Duas interpretações realizadas são medidas: o valor para os usuários, interpretado pelos usuários ou por seu comportamento observável, e o valor para a empresa, interpretado pela empresa como receptora do fluxo de retorno (receita, retenção, redução de custo ou de risco). O valor planejado é a interpretação do remetente antes da release. O valor da mesma release para um parceiro ou regulador está fora do limite, a menos que este seja estendido explicitamente.

5 Da hipótese de produto ao valor realizado: o ciclo de valor

O deck Product Value System enquadra o trabalho de produto como um ciclo no qual hipóteses de valor são criadas, implementadas, validadas e sustentadas. Em termos de esquema, o ciclo tem os seguintes conversores e fluxos.

1. Investimento para a função de produto. A função de produto converte recursos e sinais dos usuários em hipóteses que carregam valor planejado.
2. Função de produto para o desenvolvimento. As hipóteses se tornam itens de backlog com valor planejado. O deck enuncia duas expectativas: o valor planejado de uma hipótese não deve diminuir enquanto ela é construída, e o valor entregue não deve diferir muito do valor planejado.
3. Desenvolvimento para operações. O desenvolvimento consome esforço e produz mudanças funcionais, junto com antivalor (dívida técnica, defeitos, atraso).
4. Operações para produção. As mudanças se tornam software em execução; erros de release e indisponibilidade aparecem como antivalor.
5. Produção para os usuários. O valor só é realizado no uso (A6), portanto este é o primeiro ponto em que o valor realizado pode ser observado.
6. Usuários para a empresa. Os usuários devolvem receita, retenção e confiança. A publicação do autor no canal em janeiro de 2022 chama isso de fluxo fechado: o valor entregue ao cliente é equilibrado pelo valor que retorna, muitas vezes, mas não apenas, em dinheiro.

O ciclo torna concreto o axioma da transformação (A7): cada conversor realiza o que recebe e produz novo valor planejado para o seguinte. Ele também mostra por que as métricas de pipeline cobrem apenas as etapas 3 e 4. As etapas 1, 2, 5 e 6, nas quais o valor é planejado, realizado e devolvido, ficam fora do pipeline.

O deck também lista tipos de elementos observáveis para produtos internos e externos. Os elementos de valor incluem tempo economizado, menos erros operacionais, fluxo de caixa, redução de risco, menor carga cognitiva, previsibilidade, novas capacidades e confiança. As contrapartes de antivalor incluem tempo perdido, retrabalho, custo operacional crescente, dívida técnica, imprevisibilidade, soluções manuais de contorno, perda de confiança e degradação do atendimento ao cliente. Esta tipologia é o ponto de partida de um Registro de Elementos de Valor (Value Element Registry) para a entrega.

6 Valor planejado e realizado por release, resistência e vazamento

6.1 A release como unidade de comparação

A unidade de comparação é a release, ou o item do backlog quando as releases são pequenas. Para cada uma, o método registra no Æ:

• valor planejado: a estimativa do emissor, registrada antes do início do desenvolvimento e atualizada somente por meio de uma decisão explícita e registrada;
• valor realizado e antivalor realizado: a interpretação do receptor após a release ter estado em uso durante um período de observação acordado;
• valor retrospectivo: uma reavaliação posterior, quando os efeitos de segunda ordem (carga de suporte, churn, dívida técnica) se tornam visíveis.

O deck propõe uma introdução em etapas: primeiro o valor planejado em cada item do backlog, depois o valor e o antivalor realizados em cada item liberado, e por fim o valor retrospectivo. Sem valor planejado não há lacuna a medir; sem valor realizado o plano continua sendo uma hipótese.

6.2 Resistência ao fluxo na entrega

A resistência ao fluxo é a lacuna entre o valor planejado e o realizado somada ao antivalor que surge em um fluxo. A VMT trata uma lacuna diferente de zero como normal (T3), mas sustenta que a resistência se acumula historicamente (T4) e reduz a capacidade de realizar valor futuro (T6). Na entrega, o valor se perde na implementação (escopo cortado, hipótese mal interpretada), na release (defeitos, rollbacks), na adoção (os usuários não conseguem encontrar ou usar a mudança) e pelo atraso. Seguindo o conceito de custo do atraso (Reinertsen, 2009), o atraso é modelado como antivalor no fluxo atrasado, e não como uma métrica separada.

Se cada fluxo carrega suas próprias grandezas planejadas e observadas, o esquema mostra em qual conversor a perda ocorreu. Este é o propósito do Registro de Resistência do Fluxo (Flow Resistance Register) e do Relatório de Lacuna entre Valor Planejado e Valor Realizado (Planned vs Realized Value Gap Report) no conjunto de artefatos do Æilus.

6.3 Vazamento

O vazamento é um excesso sustentado de valor realizado que sai do sistema em relação ao valor que entra (A11). Em um sistema de valor de produto, duas formas são comuns. Na primeira, os usuários se beneficiam, mas o fluxo de retorno não cobre o fluxo de entrada habilitador. Na segunda, a equipe consome investimento enquanto hipóteses são construídas, mas nunca realizadas. A vazão pode parecer saudável nos dois casos; o esquema mostra ambos porque as entradas e saídas estão em uma única fronteira.

7 Nós compartilhados: avaliação em todos os fluxos

Alguns conversores em um sistema de software não produzem nenhum valor que um usuário nomearia, mas todo fluxo de valor passa por eles. A publicação do autor no canal em setembro de 2025 e o artigo relacionado em aeilus.tech usam a autorização como exemplo: ela não gera valor por si mesma, mas sem ela todo cenário para. Um API gateway ou um pipeline de CI são do mesmo tipo.

Avaliado isoladamente, esse nó mostra custo e nenhum resultado, e convida a cortes de custo. No esquema, ele aparece em muitos fluxos ao mesmo tempo, e sua eficiência só se torna clara por meio do valor agregado de todos os fluxos que ele sustenta. O método atribui, portanto, a um nó compartilhado:

• o conjunto de fluxos que passam por ele, lido a partir do esquema;
• o antivalor que ele acrescenta a cada um desses fluxos (latência, indisponibilidades, falhas de login, defeitos de integração);
• seu valor consumido (esforço da equipe, infraestrutura).

Sua eficiência é o valor entregue menos o antivalor em todos os seus fluxos, confrontado com o valor consumido, seguindo a definição de eficiência de processo do mesmo artigo. Uma degradação em um nó compartilhado nunca é um incidente local; é resistência acrescentada a todo fluxo que ele atende. O teorema T8 acrescenta um argumento de sustentabilidade: a estabilidade se perde quando um papel de transformação não pode ser desempenhado, e a redundância do papel aumenta a estabilidade.

8 O que um líder de equipe ganha

A publicação do autor no canal em fevereiro de 2022 lista o que a abordagem oferece a uma equipe e ao seu líder. Reformulado nos termos deste artigo:

• Valor entregue como feedback. Para qualquer período, a equipe vê o valor que entregou, no Æ, confirmado pelos destinatários, em vez do sinal indireto da velocity.
• Uma medida de efetividade independente da metodologia de processo. Qualquer que seja a prática, a medida é o valor realizado por valor consumido, e as práticas são selecionadas ou descartadas por seu efeito sobre ela (P7).
• Transparência para o negócio. O trabalho técnico se torna explicável por meio dos fluxos que ele sustenta.
• Prioridade do backlog a partir do valor. A prioridade pode ser derivada do valor planejado, de sua confiança e de seu custo do atraso, em vez de vir do stakeholder que fala mais alto.
• Custo do atraso e erros de produção como antivalor. O negócio pode mostrar como o valor cai quando uma mudança é tardia ou defeituosa, e a equipe vê como a utilidade de seu trabalho depende do momento e da qualidade em produção.
• Argumentos para recursos compartilhados. Onde administradores e engenheiros de DevOps são compartilhados, a prioridade baseada em valor explica por que o trabalho de uma equipe foi adiado em favor do de outra, nos dois sentidos.

Esses ganhos só se sustentam se o valor realizado for validado por seus destinatários. Se a equipe estima e confirma o próprio valor, a medida se torna mais um contador autodeclarado, e aplica-se T17: interpretações de fontes influentes que não são confirmadas pela realização acumulam antivalor.

9 Um esquema elaborado de um produto sintético

Esta seção descreve um produto sintético e ilustrativo. Não é um estudo de caso, não descreve nenhuma organização real e não contém números medidos.

O produto sintético é uma aplicação web por assinatura por meio da qual pequenas empresas de serviços aceitam reservas de clientes. Seu sistema de valor segue a fronteira definida na Seção 4. Dois nós compartilhados, um serviço de autorização e um API gateway, atendem a todos os fluxos voltados ao usuário. O departamento financeiro fornece o fluxo de entrada habilitador. A empresa recebe a receita de assinaturas e a retenção como fluxo de retorno.

O esquema é construído no VSS Editor em quatro passagens: a fronteira com um fluxo de entrada externo (investimento e salários) e os fluxos de saída externos para os usuários; sete conversores; fluxos nomeados pelos elementos de valor que carregam; e elementos de antivalor. As quantidades permanecem vazias até a primeira sessão de estimativa.

Considere um lançamento hipotético: uma funcionalidade de lembretes destinada a reduzir as consultas perdidas. Antes do desenvolvimento, o product owner registra o valor planejado por elemento (tempo economizado, menos reservas perdidas, efeito esperado na retenção). Após um período de observação acordado, a análise de produto e uma amostra de usuários de negócio fornecem o valor realizado, e a equipe registra o antivalor realizado: um lançamento atrasado, um defeito que enviou lembretes duplicados, carga extra no gateway de API. A diferença é a resistência deste lançamento. O defeito e a carga no gateway também estão em fluxos que atendem a outros cenários, por isso são atribuídos também aos nós compartilhados. Um trimestre depois, o valor retrospectivo registra se a retenção chegou a mudar. Em uma aplicação real, as quantidades viriam das sessões descritas a seguir.

10 Como executar

10.1 Quem estima e quem valida

A regra do Æilus da publicação de 2025 é curta: o valor de saída de um processo deve ser avaliado por quem o consome, e outra pessoa deve verificar essa avaliação. Aplicada à entrega, isso resulta em uma divisão clara.

• O valor planejado é estimado pelo remetente. Para hipóteses, é o product owner, atuando como Proprietário do Transformador de Valor (Value Transformer Owner, VTO) do transformador de produto. Para o transformador de desenvolvimento, é o líder da equipe como VTO.
• O valor realizado é interpretado pelo receptor: os usuários, observados por meio de análise de produto ou web, e a empresa no caso do fluxo de retorno. A apresentação propõe, como medida temporária, que a análise de produto represente o lado do usuário até que se estabeleça uma validação direta.
• A validação da interpretação é feita por uma segunda parte: o Proprietário do Sistema de Valor (Value System Owner, VSO), que responde pela sustentabilidade em nível de sistema, ou um Proprietário do Fluxo para um fluxo crítico.
• A integridade metodológica é apoiada por um Æilus Master (na apresentação, um Æilus champion exercido por um gerente de projeto), que prepara os relatórios de entrega de valor, de planejado versus real e de resistência ao fluxo.

10.2 Cadência

O Æilus não prescreve um calendário. Uma cadência mínima para uma equipe de entrega, coerente com os eventos recomendados pela metodologia, é a seguinte.

• A cada refinamento do backlog: o valor planejado é atribuído aos novos itens, usando o registro de elementos.
• A cada lançamento, após o período de observação: o valor e o antivalor realizados são registrados e validados; uma breve retrospectiva de valor discute a lacuna.
• Mensalmente ou a cada trimestre: uma Revisão de Resistência do Fluxo sobre o esquema, incluindo os nós compartilhados; valor retrospectivo para itens lançados anteriormente.
• A cada trimestre ou diante de mudança estrutural: uma Revisão do Sistema de Valor dos limites, transformadores e dependências, com o arquivo do esquema atualizado e versionado.

10.3 Disciplina

Todo artefato precisa de um responsável, um ciclo de atualização e uma finalidade de decisão; caso contrário, gera antivalor por custo de manutenção e falsa confiança. Para este método, as finalidades de decisão são a prioridade do backlog, a alocação de recursos compartilhados, o momento do lançamento e o investimento em nós compartilhados. O crescimento do valor planejado só é admissível quando a capacidade da equipe de realizá-lo está confirmada (P9). Escalar o valor planejado mais rápido do que o valor realizado é o modo de falha descrito por T16.

11 Limitações e o que um estudo empírico exigiria

Este artigo é conceitual e não foi testado com dados medidos. Decorrem dele várias limitações.

• Qualidade da estimativa. Os valores no Æ são interpretações cuja confiabilidade depende dos estimadores e de sua calibração.
• Comensurabilidade parcial. Tempo economizado, receita e confiança são apenas parcialmente comensuráveis (A13). Expressá-los em uma única moeda exige uma Política de Agregação de Valor, que este artigo pressupõe, mas não define.
• Atribuição. O valor realizado costuma resultar de vários lançamentos e de fatores externos; o esquema mostra a estrutura, mas não consegue isolar a contribuição de um único lançamento.
• Fluxos ocultos. Se o esquema não consegue explicar a estabilidade ou o declínio observado do sistema, há fluxos latentes ou o limite está errado (T9). Um esquema é uma hipótese sobre a estrutura e deve ser revisado.
• Custo do método. Sessões que não produzem decisões transformam o próprio método em antivalor.

Um estudo empírico exigiria, no mínimo: várias equipes de entrega que apliquem o método por um período longo o bastante para registrar o valor retrospectivo; um registro de elementos estável e uma política de agregação acordados antes da coleta de dados; validação independente do valor realizado pelos destinatários, e não pelas próprias equipes; coleta paralela de métricas convencionais de entrega, para que se possa examinar a relação entre essas métricas e o valor realizado; e uma comparação das decisões tomadas com e sem o esquema. Somente um estudo assim poderia mostrar se a priorização baseada em valor altera o valor entregue e em que condições.

12 Conclusão

As métricas de entrega descrevem como o trabalho se move por um pipeline, não o que ele mudou para seus destinatários; sob a VMT elas não podem fazê-lo, porque o valor é contextual, só se realiza no uso, e o valor planejado e o realizado divergem. O Esquema do Sistema de Valor (Value System Schema), conforme implementado no VSS Editor, permite que as equipes de software desenhem o ciclo de valor do produto desde a hipótese até o valor realizado e de volta à empresa. Registrar o valor planejado, realizado e retrospectivo por lançamento transforma o ciclo em uma medição: a resistência e o vazamento tornam-se visíveis, os nós compartilhados são avaliados em todos os fluxos que atendem, e os líderes de equipe obtêm como retorno o valor entregue, a prioridade baseada em valor e o custo do atraso e dos erros. O método permanece honesto apenas se o limite do sistema for declarado, se os destinatários validarem o valor realizado e se cada artefato servir a uma decisão. Se ele melhora o valor entregue na prática é uma questão empírica que este artigo formula, mas não responde.

Referências

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Bolshakov, V. Value Management Theory (VMT), version 1.4. 2026.
• Bolshakov, V. Value Management Methodology Æilus, v2.0. 2026.
• Bolshakov, V. VMT, Æilus v2.0 and the Product Value System (presentation). 2026.
• Bolshakov, V. New Tool Released: Value System Schema Editor (VSS Editor). aeilus.tech, 2025.
• Bolshakov, V. Assessing the Value of Processes: Efficiency, Risks, and Anti-Value. aeilus.tech, 2025.
• Bolshakov, V. Artifacts and Reports. Æilus methodology, aeilus.tech/methodology/artifacts-and-reports/. 2026.
• Bolshakov, V. Æilus channel posts on value flows, team leadership and the VSS Editor (in Russian). 2022-2025.
• Forsgren, N., Humble, J., Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. The Principles of Product Development Flow. 2009.