Измерение потоков ценности в поставке программного обеспечения с помощью Схемы системы ценности

Полный текст

1 Введение

Работу программных команд измеряют пристально: скорость команды, пропускная способность, время выполнения, частота развёртываний и доля неудачных изменений собираются автоматически. Но один вопрос эти числа оставляют открытым: какую ценность команда доставила, кому и ценой каких потерь?

В статье предложен метод, который отвечает на этот вопрос с помощью Схемы системы ценности (VSS) - нотации моделирования методологии Æilus в том виде, в каком она реализована в VSS Editor, опубликованном на aeilus.tech. Это пятая статья серии "Æilus for Business". Она использует словарь, определённый в первой статье серии, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners" (Большаков, ÆVRI, 2026), и не повторяет эти определения. Формальное описание ценности как измеримой валюты (Æ) дано в работе "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective" (Большаков, ÆVRI, 2026).

Статья описывает, как организация, отвечающая за поставку, может построить схему своей системы ценности, привязать плановую и реализованную ценность к релизам, найти сопротивление потока и утечку, оценить общие технические узлы и проводить цикл с понятными ролями и ритмом. Она опирается на аксиомы VMT A1, A2, A4, A5, A6, A7, A11 и A13 и теоремы T3, T4, T5, T6, T8, T9, T15, T16 и T17. Измеренных данных в ней нет. Разобранный пример в разделе 9 синтетический.

2 Что измеряют метрики поставки и чего они не измеряют

Метрики поставки описывают движение работы. Скорость команды считает выполненный объём оценённых трудозатрат, пропускная способность - число завершённых задач. Четыре ключевые метрики, популяризированные Форсгреном, Хамблом и Кимом (Accelerate, 2018), - частота развёртываний, время выполнения изменений, время восстановления сервиса и доля неудачных изменений - описывают скорость и стабильность конвейера поставки. Их исследование связывает эти способности с результативностью организации, и статья с этим не спорит. Её утверждение скромнее: эти метрики описывают конвейер поставки, а не ценность, которая через него проходит.

Отсюда следуют три разрыва.

• Трудозатраты - не ценность. Спринт с высокой скоростью команды может выпустить функции, которыми никто не пользуется. Как сказано в презентации "Система ценности продукта", "функции - не ценность" и "метрики - не ценность": функция - это предположение о ценности, а метрика - её интерпретация.
• Скорость - не направление. Короткое время выполнения просто быстрее доставляет неверную гипотезу.
• Стабильность - не отсутствие антиценности. Низкая доля неудачных изменений ничего не говорит о задержке, путанице, переделках на стороне пользователя или потере доверия из-за изменения, которое сработало ровно так, как было задумано.

С точки зрения Теории управления ценностью (VMT) этот разрыв структурный. Ценность существует только внутри определённой системы ценности и интерпретируется её участниками (A1, A2). Она реализуется в момент потребления (A6), а плановая и реализованная ценность обычно расходятся (A4, T3). Метрики конвейера поставки собираются до потребления, на стороне отправителя, поэтому описывают в лучшем случае доставку плановой ценности. Когда такие метрики становятся целями, возникает эффект, описанный Гудхартом (1975): команды оптимизируют счётчик. VMT формулирует тот же риск в системных терминах: локальная оптимизация не гарантирует глобального улучшения (T5).

3 Нотация Схемы системы ценности

3.1 Элементы нотации

В методологии Æilus Схема системы ценности - первый ключевой артефакт: формальное описание системы ценности, её участников, потоков, преобразователей и ключевых обменов. Она нужна, чтобы задать границы системы и не допустить невидимых внешних зависимостей. VSS можно строить на уровне преобразователя или на уровне системы.

VSS Editor, выпущенный на aeilus.tech в декабре 2025 года, - это визуальный редактор таких схем, работающий в браузере. В его нотации немного элементов.

• Конвертеры. Конвертер - так в Æilus называется роль преобразователя на схеме: функциональный блок, например команда, сервис или подсистема, который получает элементы ценности, преобразует их и производит новые. В конвертерах ценность создаётся, усиливается или разрушается.
• Потоки. Поток - направленная связь между конвертерами или между конвертером и внешним миром. Он переносит некоторое количество ценности или антиценности в Æ. Поток бывает внешним входящим (ценность входит в систему), внешним исходящим (ценность покидает систему) или внутренним (ценность между конвертерами).
• Входы и выходы. Внешние входящие и исходящие потоки показывают, где ценность входит в систему и где покидает её. Вместе они задают границу системы.
• Элементы ценности. Типы элементов описывают, что именно движется по потоку: ценность для клиента, выручка, затраты, риски, технический долг и тому подобное. В сохранённой схеме у каждого элемента есть вид (ценность или антиценность), знак, количество и единица измерения (Æ).
• Антиценность. Антиценность представляет потери и негативные эффекты: задержки, переделки, дефекты, бюрократию, риск, выгорание, напрасные усилия. На схеме это явный элемент с отрицательным знаком, а не отсутствие ценности (A5).

3.2 Схема как машиночитаемая модель

Редактор сохраняет схему в структурированном JSON с узлами (конвертерами), потоками и элементами. Поэтому схему можно версионировать вместе с продуктом, а позже читать её аналитическими средствами, которые сравнивают плановые и реализованные количества по каждому потоку. Такая аналитика заявлена как будущая работа, и здесь на неё не рассчитываем.

3.3 Чем схема не является

VSS Editor прямо не задуман как дашборд KPI, инструмент бизнес-аналитики, движок симуляций или замена финансового учёта. Ясность для него важнее расчёта. Отсюда рекомендуемый порядок моделирования: задать границу, добавить только основные конвертеры, соединить их именованными потоками (сначала названия, потом числа, сначала направление, потом точность), затем отметить антиценность. Этот шаг часто даёт больше всего понимания.

4 Чья ценность: система и её граница

Измерение ценности бессмысленно, пока не сказано, чья ценность измеряется (A1, T1). Выбранная граница к тому же меняет выводы, хотя реальность остаётся прежней (T15). Поэтому статья фиксирует систему ценности до любых измерений.

Здесь моделируется система ценности продукта - одного программного продукта внутри продуктовой организации. Вслед за презентацией "Система ценности продукта" её участники - продуктовая функция, команда разработки, эксплуатация, продукт в продакшене, пользователи и компания как получатель ценности, которую возвращают пользователи. Финансы - внешний обеспечивающий входящий поток (зарплаты).

Измеряются две реализованные интерпретации: ценность для пользователей, которую интерпретируют сами пользователи или их наблюдаемое поведение, и ценность для компании, которую интерпретирует компания как получатель обратного потока (выручка, удержание, снижение затрат или риска). Плановая ценность - это интерпретация отправителя до релиза. Ценность того же релиза для партнёра или регулятора находится за границей системы, если граница явно не расширена.

5 От продуктовой гипотезы к реализованной ценности: контур ценности

Презентация "Система ценности продукта" описывает продуктовую работу как контур, в котором гипотезы ценности создаются, реализуются, проверяются и поддерживаются. В терминах схемы у этого контура следующие конвертеры и потоки.

1. Инвестиции - продуктовой функции. Продуктовая функция превращает ресурсы и сигналы пользователей в гипотезы, несущие плановую ценность.
2. Продуктовая функция - разработке. Гипотезы становятся элементами бэклога с плановой ценностью. В презентации сформулированы два ожидания: плановая ценность гипотезы не должна снижаться, пока её реализуют, а доставленная ценность не должна сильно отличаться от плановой.
3. Разработка - эксплуатации. Разработка потребляет трудозатраты и выпускает работающие изменения, а вместе с ними антиценность (технический долг, дефекты, задержку).
4. Эксплуатация - продакшену. Изменения становятся работающим программным обеспечением, ошибки выпуска и простои проявляются как антиценность.
5. Продакшен - пользователям. Ценность реализуется только при использовании (A6), поэтому здесь реализованную ценность впервые можно наблюдать.
6. Пользователи - компании. Пользователи возвращают выручку, удержание и доверие. Пост автора в канале от января 2022 года называет это замкнутым потоком: ценность, доставленная клиенту, уравновешивается ценностью, которая течёт обратно, часто, но не только в виде денег.

Контур делает конкретной аксиому преобразования (A7): каждый конвертер реализует то, что получает, и производит новую плановую ценность для следующего. Он же показывает, почему метрики конвейера поставки охватывают только шаги 3 и 4. Шаги 1, 2, 5 и 6, где ценность планируется, реализуется и возвращается, лежат за пределами конвейера.

В презентации также перечислены наблюдаемые типы элементов для внутренних и внешних продуктов. Элементы ценности: сэкономленное время, меньше операционных ошибок, денежный поток, снижение риска, меньшая когнитивная нагрузка, предсказуемость, новые возможности и доверие. Им соответствуют элементы антиценности: потерянное время, переделки, рост операционных затрат, технический долг, непредсказуемость, ручные обходные решения, потеря доверия и ухудшение обслуживания клиентов. Эта типология - отправная точка реестра элементов ценности для поставки.

6 Плановая и реализованная ценность по релизу, сопротивление и утечка

6.1 Релиз как единица сравнения

Единица сравнения - релиз, а если релизы мелкие, то элемент бэклога. Для каждого из них метод фиксирует в Æ:

• плановую ценность: оценку отправителя, записанную до начала разработки и изменяемую только явным решением, которое фиксируется в журнале;
• реализованную ценность и реализованную антиценность: интерпретацию получателя после того, как релизом пользовались в течение согласованного периода наблюдения;
• ретроспективную ценность: повторную оценку позже, когда проявятся эффекты второго порядка (нагрузка на поддержку, отток, технический долг).

Презентация предлагает вводить это поэтапно: сначала плановая ценность у каждого элемента бэклога, затем реализованная ценность и антиценность у каждого выпущенного элемента, затем ретроспективная ценность. Без плановой ценности нечего сравнивать, без реализованной план остаётся гипотезой.

6.2 Сопротивление потока в поставке

Сопротивление потока - это разрыв между плановой и реализованной ценностью плюс антиценность, которая возникает в потоке. VMT считает ненулевой разрыв нормой (T3), но утверждает, что сопротивление накапливается исторически (T4) и снижает способность реализовать ценность в будущем (T6). В поставке ценность теряется при реализации (урезанный объём, неверно понятая гипотеза), при выпуске (дефекты, откаты), при освоении (пользователи не могут найти изменение или воспользоваться им) и из-за задержки. Вслед за концепцией стоимости задержки (Рейнертсен, 2009) задержка моделируется как антиценность на запоздавшем потоке, а не как отдельная метрика.

Если у каждого потока есть свои плановые и наблюдаемые количества, схема показывает, в каком конвертере произошла потеря. Для этого в наборе артефактов Æilus есть реестр сопротивления потоков и отчёт о разрыве между плановой и реализованной ценностью.

6.3 Утечка

Утечка - это устойчивое превышение реализованной ценности, покидающей систему, над ценностью, которая в неё входит (A11). В системе ценности продукта часто встречаются две её формы. В первой пользователи получают выгоду, но обратный поток не покрывает обеспечивающий входящий поток. Во второй команда потребляет инвестиции, пока строит гипотезы, которые так и не реализуются. Пропускная способность в обоих случаях может выглядеть здоровой. Схема показывает обе формы, потому что входящие и исходящие потоки лежат на одной границе.

7 Общие узлы: оценка по всем потокам

Некоторые конвертеры программной системы не производят ценности, которую назвал бы пользователь, но через них проходит каждый поток ценности. Пост автора в канале от сентября 2025 года и связанная с ним статья на aeilus.tech берут в пример авторизацию: сама по себе она ценности не генерирует, но без неё не работает ни один сценарий. API-шлюз или конвейер непрерывной интеграции устроены так же.

Если оценивать такой узел в изоляции, он показывает затраты без результата и словно напрашивается на сокращение. На схеме же он стоит сразу на многих потоках, и его эффективность становится понятна только через совокупную ценность всех потоков, которые он поддерживает. Поэтому метод сопоставляет общему узлу:

• набор потоков, которые через него проходят, - он считывается со схемы;
• антиценность, которую узел добавляет каждому из этих потоков (задержки ответа, сбои, неудачные входы, дефекты интеграции);
• потребляемую им ценность (трудозатраты команды, инфраструктура).

Его эффективность - это поставленная ценность минус антиценность по всем его потокам, соотнесённая с потребляемой ценностью, в соответствии с определением эффективности процесса из той же статьи. Деградация общего узла никогда не бывает локальным инцидентом: это сопротивление, добавленное каждому потоку, который он обслуживает. Теорема T8 добавляет довод об устойчивости: стабильность теряется, когда роль преобразования некому выполнить, а резервирование роли повышает стабильность.

8 Что получает руководитель команды

Пост автора в канале от февраля 2022 года перечисляет, что подход даёт команде и её руководителю. В терминах этой статьи:

• Доставленная ценность как обратная связь. За любой период команда видит ценность, которую она доставила, в Æ и подтверждённую получателями, а не косвенный сигнал в виде скорости команды.
• Мера эффективности, не привязанная к методологии процесса. Какой бы ни была практика, мерой служит реализованная ценность на единицу потреблённой ценности, а практики выбирают или выводят из употребления по их влиянию на эту меру (P7).
• Прозрачность для бизнеса. Техническую работу можно объяснить через потоки, которые она поддерживает.
• Приоритеты бэклога из ценности. Приоритет можно вывести из плановой ценности, уверенности в ней и стоимости задержки, а не из того, кто из заинтересованных лиц громче.
• Стоимость задержки и ошибок в продакшене как антиценность. Бизнес может показать, как падает ценность, если изменение опоздало или вышло с ошибками, а команда видит, как полезность её работы зависит от сроков и качества на проде.
• Аргументы при общих ресурсах. Там, где администраторы и DevOps-инженеры общие, приоритет на основе ценности объясняет, почему работу одной команды отложили в пользу другой, и наоборот.

Эти выгоды сохраняются, только если реализованную ценность подтверждают её получатели. Если команда сама оценивает и сама подтверждает свою ценность, мера превращается в очередной счётчик с самоотчётом, и действует T17: интерпретации влиятельных источников, не подтверждённые реализацией, накапливают антиценность.

9 Разобранная схема синтетического продукта

В этом разделе описан синтетический, иллюстративный продукт. Это не кейс, он не описывает никакую реальную организацию и не содержит измеренных чисел.

Синтетический продукт - веб-приложение по подписке, через которое небольшие сервисные компании принимают записи клиентов. Его система ценности следует границе, заданной в разделе 4. Все потоки, обращённые к пользователям, обслуживают два общих узла: сервис авторизации и API-шлюз. Финансы обеспечивают входящий поток. Компания получает выручку от подписок и удержание клиентов как обратный поток.

Схема строится в VSS Editor в четыре прохода: граница с одним внешним входящим потоком (инвестиции и зарплаты) и внешними исходящими потоками к пользователям; семь конвертеров; потоки, названные по элементам ценности, которые они переносят; элементы антиценности. Количества остаются пустыми до первой сессии оценки.

Рассмотрим один гипотетический релиз: функцию напоминаний, которая должна сократить число пропущенных визитов. До начала разработки владелец продукта записывает плановую ценность по элементам (сэкономленное время, меньше пропущенных записей, ожидаемое влияние на удержание). После согласованного периода наблюдения продуктовая аналитика и выборка бизнес-пользователей дают реализованную ценность, а команда фиксирует реализованную антиценность: релиз опоздал, дефект привёл к дублированию напоминаний, выросла нагрузка на API-шлюз. Разница - это сопротивление данного релиза. Дефект и нагрузка на шлюз лежат и на потоках других сценариев, поэтому их относят также к общим узлам. Через квартал ретроспективная ценность покажет, изменилось ли удержание вообще. В реальном применении количества брались бы из сессий, описанных далее.

10 Как это проводить

10.1 Кто оценивает и кто подтверждает

Правило Æilus из поста 2025 года короткое: выходную ценность процесса должен оценивать тот, кто её потребляет, и кто-то другой должен эту оценку перепроверять. Применительно к поставке это даёт чёткое разделение.

• Плановую ценность оценивает отправитель. Для гипотез это владелец продукта, выступающий владельцем преобразователя ценности (VTO) продуктового конвертера. Для конвертера разработки это руководитель команды как VTO.
• Реализованную ценность интерпретирует получатель: пользователи, за которыми наблюдают через продуктовую или веб-аналитику, и компания для обратного потока. Презентация предлагает временную меру: пока прямое подтверждение не налажено, сторону пользователей представляет продуктовая аналитика.
• Проверку интерпретации выполняет вторая сторона: владелец системы ценности (VSO), отвечающий за устойчивость на уровне системы, или владелец потока для критического потока.
• Методологическую целостность поддерживает Æilus Мастер (в презентации - чемпион Æilus, эту роль выполняет руководитель проекта). Он готовит отчёты о доставке ценности, о плане и факте и о сопротивлении потоков.

10.2 Ритм

Æilus не предписывает календарь. Минимальный ритм для команды поставки, согласованный с рекомендуемыми событиями методологии, такой.

• На каждом уточнении бэклога: новым элементам назначается плановая ценность с опорой на реестр элементов.
• По каждому релизу, после периода наблюдения: реализованная ценность и антиценность фиксируются и подтверждаются, на короткой ретроспективе ценности обсуждается разрыв.
• Ежемесячно или ежеквартально: обзор сопротивления потоков по схеме, включая общие узлы; ретроспективная ценность для элементов, выпущенных ранее.
• Ежеквартально или при структурных изменениях: обзор системы ценности - границ, конвертеров и зависимостей, с обновлением и версионированием файла схемы.

10.3 Дисциплина

У каждого артефакта должны быть владелец, цикл обновления и решение, ради которого он существует. Иначе он создаёт антиценность через затраты на поддержку и ложную уверенность. Для этого метода такие решения - приоритеты бэклога, распределение общих ресурсов, сроки релизов и инвестиции в общие узлы. Рост плановой ценности допустим, только когда подтверждена способность команды её реализовать (P9). Наращивать плановую ценность быстрее реализованной - это сценарий провала, описанный в T16.

11 Ограничения и что потребуется для эмпирического исследования

Статья концептуальная и на измеренных данных не проверялась. Отсюда несколько ограничений.

• Качество оценок. Значения в Æ - это интерпретации, и их надёжность зависит от тех, кто оценивает, и от их калибровки.
• Частичная соизмеримость. Сэкономленное время, выручка и доверие соизмеримы лишь частично (A13). Чтобы выразить их в одной валюте, нужна политика агрегирования ценности. Статья предполагает её наличие, но не определяет её.
• Атрибуция. Реализованная ценность часто складывается из нескольких релизов и внешних факторов. Схема показывает структуру, но не может выделить вклад одного релиза.
• Скрытые потоки. Если схема не объясняет наблюдаемую стабильность или упадок системы, значит, есть скрытые потоки или граница выбрана неверно (T9). Схема - это гипотеза о структуре, и её нужно пересматривать.
• Цена метода. Сессии, которые не приводят к решениям, превращают сам метод в антиценность.

Эмпирическому исследованию потребуется как минимум: несколько команд поставки, которые применяют метод достаточно долго, чтобы зафиксировать ретроспективную ценность; стабильный реестр элементов и политика агрегирования, согласованные до сбора данных; независимое подтверждение реализованной ценности получателями, а не самими командами; параллельный сбор привычных метрик поставки, чтобы можно было изучить связь между ними и реализованной ценностью; сравнение решений, принятых со схемой и без неё. Только такое исследование покажет, меняет ли приоритизация на основе ценности доставленную ценность и при каких условиях.

12 Заключение

Метрики поставки описывают, как работа движется по конвейеру поставки, а не то, что она изменила для получателей. С точки зрения VMT иначе и быть не может: ценность контекстна, реализуется только при использовании, а плановая и реализованная ценность расходятся. Схема системы ценности в реализации VSS Editor позволяет программным командам нарисовать контур ценности продукта от гипотезы до реализованной ценности и обратно в компанию. Фиксация плановой, реализованной и ретроспективной ценности по каждому релизу превращает контур в измерение: сопротивление и утечка становятся видимыми, общие узлы оцениваются по всем потокам, которые они обслуживают, а руководители команд получают в качестве обратной связи доставленную ценность, приоритеты на основе ценности и стоимость задержек и ошибок. Метод остаётся честным, только если граница системы названа, реализованную ценность подтверждают получатели и каждый артефакт служит какому-то решению. Улучшает ли он доставленную ценность на практике - эмпирический вопрос, который статья ставит, но на который не отвечает.

Источники

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