Medición de los flujos de valor en la entrega de software con el Esquema de Sistema de Valor

Texto completo

1 Introducción

Los equipos de software son medidos de cerca: la velocidad, el rendimiento, el tiempo de entrega, la frecuencia de despliegue y la tasa de fallos de los cambios se recopilan automáticamente. Sin embargo, estas cifras dejan abierta una pregunta: ¿qué valor entregó el equipo, a quién y a qué coste en pérdidas?

Este artículo propone un método para responder a esa pregunta con el Esquema de Sistema de Valor (Value System Schema, VSS), la notación de modelado de la metodología Æilus, tal como está implementado en el VSS Editor publicado en aeilus.tech. Es el quinto artículo de la serie "Æilus for Business". Utiliza el vocabulario definido en el primer artículo de la serie, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Bolshakov, ÆVRI, 2026), y no repite esas definiciones. El tratamiento formal del valor como moneda medible (Æ) se presenta en "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Bolshakov, ÆVRI, 2026).

El artículo describe cómo una organización de entrega puede construir un esquema de su sistema de valor, asociar valor planificado y valor realizado a las versiones, localizar la resistencia de flujo y las fugas, evaluar nodos técnicos compartidos y ejecutar el ciclo con roles y cadencia claros. Se apoya en los axiomas A1, A2, A4, A5, A6, A7, A11 y A13 de la VMT y en los teoremas T3, T4, T5, T6, T8, T9, T15, T16 y T17. No contiene datos medidos. El ejemplo desarrollado de la Sección 9 es sintético.

2 Qué miden las métricas de entrega y qué no miden

Las métricas de entrega describen el movimiento del trabajo. La velocidad cuenta el esfuerzo estimado completado; el rendimiento cuenta los elementos terminados. Las cuatro métricas clave popularizadas por Forsgren, Humble y Kim (Accelerate, 2018), a saber, la frecuencia de despliegue, el tiempo de entrega de los cambios, el tiempo de restablecimiento del servicio y la tasa de fallos de los cambios, describen la velocidad y la estabilidad del flujo de entrega. Esa investigación vincula estas capacidades con el rendimiento organizativo, y este artículo no lo discute. Su afirmación es más limitada: estas métricas describen el flujo de entrega, no el valor que pasa a través de él.

De ello se derivan tres carencias.

• El esfuerzo no es valor. Un sprint con alta velocidad puede entregar funcionalidades que nadie utiliza. En el lenguaje del documento Product Value System, "las funcionalidades no son valor" y "las métricas no son valor": una funcionalidad es una suposición sobre el valor, y una métrica es una interpretación de este.
• La rapidez no es dirección. Un tiempo de entrega corto entrega una hipótesis equivocada más rápido.
• La estabilidad no es la ausencia de antivalor. Una tasa baja de fallos de los cambios no dice nada sobre el retraso, la confusión, el retrabajo del lado del usuario o la pérdida de confianza causados por un cambio que funcionó exactamente como fue diseñado.

Desde el punto de vista de la Teoría de la Gestión del Valor (Value Management Theory, VMT), la carencia es estructural. El valor existe solo dentro de un sistema de valor definido y es interpretado por sus actores (A1, A2). Se realiza en el momento del consumo (A6), y el valor planificado y el valor realizado suelen diferir (A4, T3). Las métricas del flujo de entrega se recopilan antes del consumo, del lado del emisor, por lo que describen, como mucho, la entrega del valor planificado. Cuando tales métricas se convierten en objetivos, aparece el efecto descrito por Goodhart (1975): los equipos optimizan el contador. La VMT enuncia el mismo riesgo en términos de sistema: la optimización local no garantiza una mejora global (T5).

3 La notación del Esquema de Sistema de Valor

3.1 Elementos de la notación

En la metodología Æilus, el Esquema de Sistema de Valor es el primer artefacto central: una descripción formal del sistema de valor, sus actores, flujos, transformadores e intercambios clave, utilizada para establecer los límites del sistema y evitar dependencias externas invisibles. Un VSS puede dibujarse a nivel de transformador o a nivel de sistema.

El VSS Editor, lanzado en aeilus.tech en diciembre de 2025, es un editor visual en el navegador para tales esquemas. Su notación tiene un número reducido de elementos.

• Convertidores. Un convertidor es el nombre que Æilus da a un rol de transformador en un esquema: un bloque funcional, como un equipo, un servicio o un subsistema, que recibe elementos de valor, los transforma y produce otros nuevos. Los convertidores son los lugares donde el valor se crea, se amplifica o se destruye.
• Flujos. Un flujo es una conexión direccional entre convertidores, o entre un convertidor y el mundo exterior. Transporta una cantidad de valor o de antivalor en Æ. Un flujo es externo de entrada (valor que entra en el sistema), externo de salida (valor que sale del sistema) o interno (valor entre convertidores).
• Entradas y salidas. Los flujos externos de entrada y de salida marcan dónde entra y sale el valor. Juntos definen el límite del sistema.
• Elementos de valor. Los tipos de elemento describen qué es exactamente lo que se mueve por un flujo: valor para el cliente, ingresos, costes, riesgos, deuda técnica y similares. En un esquema guardado, cada elemento tiene un tipo (valor o antivalor), un signo, una cantidad y una unidad (Æ).
• Antivalor. El antivalor representa pérdidas y efectos negativos: retrasos, retrabajo, defectos, burocracia, riesgo, agotamiento, esfuerzo desperdiciado. En el esquema es un elemento explícito con signo negativo, no la ausencia de valor (A5).

3.2 El esquema como modelo legible por máquina

El editor guarda un esquema como JSON estructurado con nodos (convertidores), flujos y elementos. Por tanto, el esquema puede versionarse junto con el producto y ser leído posteriormente por herramientas analíticas que comparen las cantidades planificadas y realizadas por flujo. Dichas herramientas analíticas se anuncian como trabajo futuro y aquí no se dan por supuestas.

3.3 Lo que el esquema no es

El VSS Editor no es, explícitamente, un panel de KPI, una herramienta de BI, un motor de simulación ni un sustituto de la contabilidad financiera. Pone la claridad antes del cálculo. A continuación se indica el orden de modelado recomendado: definir el límite, añadir solo los convertidores principales, conectarlos con flujos nombrados (los nombres antes que los números, la dirección antes que la precisión) y, después, marcar el antivalor, el paso que con frecuencia aporta más conocimiento.

4 El valor de quién: el sistema y su límite

Una medición de valor carece de sentido hasta que establece de quién es el valor que se mide (A1, T1). El límite elegido también cambia las conclusiones sin que cambie nada en la realidad (T15). Por ello, este artículo fija el sistema de valor antes de cualquier medición.

El sistema de valor modelado aquí es el sistema de valor del producto de un único producto de software dentro de una organización de producto. Siguiendo el documento Product Value System, sus actores son la función de producto, el equipo de desarrollo, operaciones, el producto en producción, los usuarios y la empresa como receptora del valor devuelto por los usuarios. Finanzas es un flujo de entrada habilitador externo (salarios).

Se miden dos interpretaciones realizadas: el valor para los usuarios, interpretado por los usuarios o por su comportamiento observable, y el valor para la empresa, interpretado por la empresa como receptora del flujo de retorno (ingresos, retención, reducción de costes o de riesgo). El valor planificado es la interpretación del emisor antes de la versión. El valor de la misma versión para un socio o un regulador queda fuera del límite, a menos que este se amplíe explícitamente.

5 De la hipótesis de producto al valor realizado: el ciclo de valor

El documento Product Value System plantea el trabajo de producto como un ciclo en el que las hipótesis de valor se crean, se implementan, se validan y se sostienen. En términos de esquema, el ciclo tiene los siguientes convertidores y flujos.

1. Inversión hacia la función de producto. La función de producto convierte recursos y señales de los usuarios en hipótesis que portan valor planificado.
2. De la función de producto al desarrollo. Las hipótesis se convierten en elementos del backlog con valor planificado. El documento establece dos expectativas: el valor planificado de una hipótesis no debería disminuir mientras se construye, y el valor entregado no debería diferir mucho del valor planificado.
3. Del desarrollo a operaciones. El desarrollo consume esfuerzo y produce cambios funcionales, junto con antivalor (deuda técnica, defectos, retraso).
4. De operaciones a producción. Los cambios se convierten en software en ejecución; los errores de versión y el tiempo de inactividad aparecen como antivalor.
5. De producción a los usuarios. El valor se realiza solo en el uso (A6), por lo que este es el primer punto en el que puede observarse el valor realizado.
6. De los usuarios a la empresa. Los usuarios devuelven ingresos, retención y confianza. La publicación del autor en su canal de enero de 2022 lo llama un flujo cerrado: el valor entregado al cliente se equilibra con el valor que fluye de vuelta, a menudo, pero no solo, dinero.

El ciclo concreta el axioma de transformación (A7): cada convertidor realiza lo que recibe y produce nuevo valor planificado para el siguiente. También muestra por qué las métricas del flujo de entrega cubren solo los pasos 3 y 4. Los pasos 1, 2, 5 y 6, en los que el valor se planifica, se realiza y se devuelve, quedan fuera del flujo de entrega.

El documento también enumera tipos de elementos observables para productos internos y externos. Los elementos de valor incluyen el tiempo ahorrado, menos errores operativos, flujo de caja, reducción de riesgos, menor carga cognitiva, previsibilidad, nuevas capacidades y confianza. Las contrapartes de antivalor incluyen el tiempo perdido, el retrabajo, el aumento del coste operativo, la deuda técnica, la imprevisibilidad, las soluciones manuales provisionales, la pérdida de confianza y el deterioro del servicio al cliente. Esta tipología es el punto de partida de un Registro de Elementos de Valor para la entrega.

6 Valor planificado y realizado por versión, resistencia y fuga

6.1 La versión como unidad de comparación

La unidad de comparación es la versión, o el elemento del backlog cuando las versiones son pequeñas. Para cada uno, el método registra en Æ:

• valor planificado: la estimación del emisor, registrada antes de que comience el desarrollo y actualizada solo mediante una decisión explícita y registrada;
• valor realizado y antivalor realizado: la interpretación del receptor después de que la versión haya estado en uso durante un período de observación acordado;
• valor retrospectivo: una reevaluación posterior, una vez que se han hecho visibles los efectos de segundo orden (carga de soporte, abandono de clientes, deuda técnica).

El documento propone una introducción por etapas: primero el valor planificado en cada elemento del backlog, después el valor realizado y el antivalor en cada elemento publicado, y por último el valor retrospectivo. Sin valor planificado no hay brecha que medir; sin valor realizado el plan sigue siendo una hipótesis.

6.2 Resistencia de flujo en la entrega

La resistencia de flujo es la brecha entre el valor planificado y el realizado más el antivalor que aparece en un flujo. VMT considera normal una brecha distinta de cero (T3), pero sostiene que la resistencia se acumula históricamente (T4) y reduce la capacidad de realizar valor futuro (T6). En la entrega, el valor se pierde en la implementación (alcance recortado, hipótesis mal interpretada), en la publicación (defectos, reversiones), en la adopción (los usuarios no pueden encontrar o usar el cambio) y por el retraso. Siguiendo el concepto de coste del retraso (Reinertsen, 2009), el retraso se modela como antivalor en el flujo tardío, no como una métrica separada.

Si cada flujo lleva sus propias cantidades planificadas y observadas, el esquema muestra en qué convertidor se produjo la pérdida. Este es el propósito del Registro de Resistencia del Flujo y del Informe de Brecha entre Valor Planificado y Valor Realizado en el conjunto de artefactos de Æilus.

6.3 Fuga

La fuga es un exceso sostenido de valor realizado que sale del sistema sobre el valor que entra en él (A11). En un sistema de valor de producto son comunes dos formas. En la primera, los usuarios se benefician pero el flujo de retorno no cubre el flujo de entrada habilitante. En la segunda, el equipo consume inversión mientras se construyen hipótesis que nunca se realizan. El rendimiento puede parecer saludable en ambos casos; el esquema muestra ambos porque las entradas y las salidas se sitúan en una misma frontera.

7 Nodos compartidos: evaluación a través de todos los flujos

Algunos convertidores de un sistema de software no producen ningún valor que un usuario pueda nombrar, y sin embargo todos los flujos de valor pasan por ellos. La publicación del autor en su canal de septiembre de 2025 y el artículo relacionado de aeilus.tech usan la autorización como ejemplo: no genera valor por sí misma, pero sin ella todos los escenarios se detienen. Una pasarela de API o una canalización de CI son de la misma clase.

Evaluado de forma aislada, un nodo así muestra coste y ninguna salida, e invita a recortar costes. En el esquema aparece en muchos flujos a la vez, y su eficiencia solo se aclara mediante el valor agregado de todos los flujos que sustenta. Por ello el método asigna a un nodo compartido:

• el conjunto de flujos que pasan por él, leído a partir del esquema;
• el antivalor que añade a cada uno de esos flujos (latencia, caídas, inicios de sesión fallidos, defectos de integración);
• su valor consumido (esfuerzo del equipo, infraestructura).

Su eficiencia es el valor entregado menos el antivalor a través de todos sus flujos, contrastado con el valor consumido, siguiendo la definición de eficiencia de proceso del mismo artículo. Una degradación en un nodo compartido nunca es un incidente local; es resistencia añadida a cada flujo al que sirve. El teorema T8 añade un argumento de sostenibilidad: la estabilidad se pierde cuando no se puede desempeñar un rol de transformación, y la redundancia del rol aumenta la estabilidad.

8 Lo que gana un líder de equipo

La publicación del autor en su canal de febrero de 2022 enumera lo que el enfoque aporta a un equipo y a su líder. Reformulado en los términos de este documento:

• El valor entregado como retroalimentación. Para cualquier período, el equipo ve el valor que entregó, en Æ, confirmado por los destinatarios, en lugar de la señal indirecta de la velocidad.
• Una medida de efectividad independiente de la metodología de proceso. Sea cual sea la práctica, la medida es el valor realizado por valor consumido, y las prácticas se seleccionan o se abandonan por su efecto sobre ella (P7).
• Transparencia para el negocio. El trabajo técnico se vuelve explicable a través de los flujos que sustenta.
• Prioridad del backlog a partir del valor. La prioridad puede derivarse del valor planificado, su confianza y su coste del retraso, en lugar de derivarse del interesado que más grita.
• Coste del retraso y errores de producción como antivalor. El negocio puede mostrar cómo cae el valor cuando un cambio llega tarde o es defectuoso, y el equipo ve cómo la utilidad de su trabajo depende del momento y de la calidad en producción.
• Argumentos para los recursos compartidos. Allí donde los administradores y los ingenieros de DevOps son compartidos, la prioridad basada en el valor explica por qué el trabajo de un equipo se aplazó en favor del de otro, en ambas direcciones.

Estas ganancias solo se mantienen si el valor realizado es validado por sus destinatarios. Si el equipo estima y confirma su propio valor, la medida se convierte en otro contador autodeclarado, y se aplica T17: las interpretaciones de fuentes influyentes que no son confirmadas por la realización acumulan antivalor.

9 Un esquema desarrollado de un producto sintético

Esta sección describe un producto sintético e ilustrativo. No es un estudio de caso, no describe ninguna organización real y no contiene cifras medidas.

El producto sintético es una aplicación web por suscripción a través de la cual pequeños negocios de servicios aceptan reservas de clientes. Su sistema de valor sigue la frontera definida en la Sección 4. Dos nodos compartidos, un servicio de autorización y una pasarela de API, sirven a todos los flujos orientados al usuario. Finanzas aporta el flujo de entrada habilitante. La empresa recibe los ingresos por suscripción y la retención como flujo de retorno.

El esquema se construye en el VSS Editor en cuatro pasadas: la frontera con una entrada externa (inversión y salarios) y las salidas externas hacia los usuarios; siete convertidores; flujos nombrados por los elementos de valor que transportan; y elementos de antivalor. Las cantidades permanecen vacías hasta la primera sesión de estimación.

Consideremos un lanzamiento hipotético: una funcionalidad de recordatorios destinada a reducir las citas perdidas. Antes del desarrollo, el propietario del producto registra el valor planificado por elemento (tiempo ahorrado, menos reservas perdidas, efecto esperado en la retención). Tras un período de observación acordado, la analítica de producto y una muestra de usuarios de negocio aportan el valor realizado, y el equipo registra el antivalor realizado: un lanzamiento tardío, un defecto que envió recordatorios duplicados, carga adicional en la pasarela de API. La diferencia es la resistencia de este lanzamiento. El defecto y la carga de la pasarela también se encuentran en flujos que atienden a otros escenarios, por lo que se asignan también a los nodos compartidos. Un trimestre después, el valor retrospectivo registra si la retención cambió siquiera. En una aplicación real, las magnitudes provendrían de las sesiones que se describen a continuación.

10 Cómo ponerlo en marcha

10.1 Quién estima y quién valida

La regla de Æilus de la publicación de 2025 es breve: el valor de salida de un proceso debe ser evaluado por quien lo consume, y otra persona debe comprobar esa evaluación. Aplicada a la entrega, esto da una división clara.

• El valor planificado lo estima el emisor. En el caso de las hipótesis, es el propietario del producto, que actúa como Propietario del Transformador de Valor (VTO) del transformador de producto. En el caso del transformador de desarrollo, es el líder del equipo como VTO.
• El valor realizado lo interpreta el receptor: los usuarios, observados mediante analítica de producto o web, y la empresa en el caso del flujo de retorno. La presentación propone, como medida temporal, que la analítica de producto represente el lado del usuario hasta que se establezca una validación directa.
• La validación de la interpretación la realiza una segunda parte: el Propietario del Sistema de Valor (VSO), que es responsable de la sostenibilidad a nivel de sistema, o un Propietario del Flujo en el caso de un flujo crítico.
• La integridad metodológica cuenta con el apoyo de un Æilus Master (en la presentación, un campeón de Æilus a cargo de un director de proyecto), que prepara los informes de entrega de valor, de plan frente a realidad y de resistencia de flujo.

10.2 Cadencia

Æilus no prescribe un calendario. Una cadencia mínima para un equipo de entrega, coherente con los eventos recomendados por la metodología, es la siguiente.

• En cada refinamiento del backlog: se asigna valor planificado a los nuevos elementos, utilizando el registro de elementos.
• En cada lanzamiento, tras el período de observación: se registran y validan el valor y el antivalor realizados; una breve retrospectiva de valor analiza la brecha.
• Mensualmente o por trimestre: una Revisión de Resistencia del Flujo sobre el esquema, incluidos los nodos compartidos; valor retrospectivo de los elementos lanzados anteriormente.
• Por trimestre o ante un cambio estructural: una Revisión del Sistema de Valor de los límites, los transformadores y las dependencias, con el archivo del esquema actualizado y versionado.

10.3 Disciplina

Todo artefacto necesita un propietario, un ciclo de actualización y un propósito de decisión; de lo contrario, genera antivalor por el coste de mantenimiento y la falsa confianza. Para este método, los propósitos de decisión son la prioridad del backlog, la asignación de recursos compartidos, el momento del lanzamiento y la inversión en nodos compartidos. El crecimiento del valor planificado solo es admisible cuando se confirma la capacidad del equipo para realizarlo (P9). Escalar el valor planificado más rápido que el valor realizado es el modo de fallo descrito por T16.

11 Limitaciones y qué necesitaría un estudio empírico

Este artículo es conceptual y no se ha probado con datos medidos. De ello se derivan varias limitaciones.

• Calidad de la estimación. Los valores en Æ son interpretaciones cuya fiabilidad depende de los estimadores y de su calibración.
• Conmensurabilidad parcial. El tiempo ahorrado, los ingresos y la confianza solo son parcialmente conmensurables (A13). Expresarlos en una sola moneda requiere una Política de Agregación de Valor, que este artículo asume pero no define.
• Atribución. El valor realizado suele ser resultado de varios lanzamientos y de factores externos; el esquema muestra la estructura, pero no puede aislar la contribución de un solo lanzamiento.
• Flujos ocultos. Si el esquema no puede explicar la estabilidad o el declive observados del sistema, existen flujos latentes o el límite es incorrecto (T9). Un esquema es una hipótesis sobre la estructura y debe revisarse.
• Coste del método. Las sesiones que no producen decisiones convierten el propio método en antivalor.

Un estudio empírico necesitaría, como mínimo: varios equipos de entrega que apliquen el método durante un período lo bastante largo como para registrar valor retrospectivo; un registro de elementos estable y una política de agregación acordados antes de la recopilación de datos; validación independiente del valor realizado por parte de los destinatarios y no de los equipos; recopilación paralela de métricas convencionales de entrega, de modo que se pueda examinar la relación entre esas métricas y el valor realizado; y una comparación de las decisiones tomadas con el esquema y sin él. Solo un estudio así podría mostrar si la priorización basada en el valor cambia el valor entregado, y en qué condiciones.

12 Conclusión

Las métricas de entrega describen cómo avanza el trabajo por un flujo de producción, no qué cambió para sus destinatarios; bajo la VMT no pueden hacerlo, porque el valor es contextual, solo se realiza en el uso, y el valor planificado y el realizado divergen. El Esquema de Sistema de Valor, tal como se implementa en el VSS Editor, permite a los equipos de software dibujar el ciclo de valor del producto desde la hipótesis hasta el valor realizado y de vuelta a la empresa. Registrar el valor planificado, realizado y retrospectivo por lanzamiento convierte el ciclo en una medición: la resistencia y la fuga se hacen visibles, los nodos compartidos se evalúan a lo largo de cada flujo al que sirven, y los líderes de equipo obtienen el valor entregado, la prioridad basada en el valor y el coste del retraso y de los errores como retroalimentación. El método se mantiene honesto solo si se declara el límite del sistema, los destinatarios validan el valor realizado y cada artefacto sirve a una decisión. Si mejora el valor entregado en la práctica es una cuestión empírica que este artículo plantea pero no responde.

Referencias

• 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.