Вимірювання потоків цінності в постачанні програмного забезпечення за допомогою Схеми системи цінності

Повний текст

1 Вступ

Програмні команди ретельно вимірюються: швидкість (velocity), пропускна здатність, час виконання, частота розгортань і частка невдалих змін збираються автоматично. Проте ці числа залишають відкритим одне питання: яку цінність команда надала, кому і якою ціною в термінах втрат?

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

У праці описано, як організація з розробки може побудувати схему своєї системи цінності, прив'язати планову та реалізовану цінність до релізів, виявити опір потоку та витоки, оцінити спільні технічні вузли й вести цикл із чіткими ролями та ритмом. Вона спирається на аксіоми VMT A1, A2, A4, A5, A6, A7, A11 і A13 та теореми T3, T4, T5, T6, T8, T9, T15, T16 і T17. Вона не містить виміряних даних. Робочий приклад у розділі 9 є синтетичним.

2 Що вимірюють метрики постачання і чого вони не вимірюють

Метрики постачання описують рух роботи. Velocity рахує виконані оцінені трудовитрати; пропускна здатність рахує завершені елементи. Чотири ключові метрики, популяризовані Forsgren, Humble і Kim (Accelerate, 2018), а саме частота розгортань, час виконання змін, час відновлення сервісу та частка невдалих змін, описують швидкість і стабільність конвеєра постачання. Це дослідження пов'язує ці спроможності з результативністю організації, і ця праця цього не заперечує. Її теза вужча: ці метрики описують конвеєр, а не цінність, що проходить крізь нього.

З цього випливають три прогалини.

• Зусилля не є цінністю. Спринт із високою швидкістю (velocity) може постачити функції, якими ніхто не користується. Мовою презентації Product Value System, "функції не є цінністю" і "метрики не є цінністю": функція є припущенням про цінність, а метрика є її інтерпретацією.
• Швидкість не є напрямом. Короткий час виконання доставляє хибну гіпотезу швидше.
• Стабільність не є відсутністю антицінності. Низька частка невдалих змін нічого не говорить про затримки, плутанину, переробку на боці користувача чи втрату довіри, спричинену зміною, яка спрацювала точно за задумом.

З погляду Теорії управління цінністю (Value Management Theory, VMT) ця прогалина є структурною. Цінність існує лише всередині визначеної системи цінності й інтерпретується її акторами (A1, A2). Вона реалізується в момент споживання (A6), а планова та реалізована цінність зазвичай відрізняються (A4, T3). Метрики конвеєра збираються до споживання, на боці відправника, тож вони описують щонайбільше постачання планової цінності. Коли такі метрики стають цілями, виникає ефект, описаний Goodhart (1975): команди оптимізують лічильник. VMT формулює той самий ризик у системних термінах: локальна оптимізація не гарантує глобального покращення (T5).

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

3.1 Елементи нотації

У методології Æilus Схема системи цінності є першим базовим артефактом: формальним описом системи цінності, її акторів, потоків, перетворювачів і ключових обмінів, що використовується для встановлення меж системи та запобігання невидимим зовнішнім залежностям. VSS можна намалювати на рівні перетворювача або на рівні системи.

VSS Editor, випущений на aeilus.tech у грудні 2025 року, є візуальним редактором таких схем у браузері. Його нотація має невелику кількість елементів.

• Конвертори. Конвертор (converter) є назвою в Æilus для ролі перетворювача в схемі: функціонального блоку, такого як команда, сервіс чи підсистема, що отримує елементи цінності, перетворює їх і виробляє нові. Конвертори є місцями, де цінність створюється, підсилюється або руйнується.
• Потоки. Потік є напрямленим зв'язком між конверторами або між конвертором і зовнішнім світом. Він переносить обсяг цінності або антицінності в Æ. Потік є зовнішнім вхідним (цінність входить у систему), зовнішнім вихідним (цінність залишає систему) або внутрішнім (цінність між конверторами).
• Входи та виходи. Зовнішні вхідні та вихідні потоки позначають, де цінність входить і виходить. Разом вони визначають межу системи.
• Елементи цінності. Типи елементів описують, що саме рухається потоком: цінність для клієнта, дохід, витрати, ризики, технічний борг тощо. У збереженій схемі кожен елемент має вид (цінність або антицінність), знак, кількість і одиницю (Æ).
• Антицінність. Антицінність відображає втрати та негативні ефекти: затримки, переробку, дефекти, бюрократію, ризик, вигорання, марні зусилля. У схемі це явний елемент із від'ємним знаком, а не відсутність цінності (A5).

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

Редактор зберігає схему як структурований JSON із вузлами (конверторами), потоками й елементами. Тому схему можна версіонувати разом із продуктом і згодом зчитувати аналітикою, що порівнює планові та реалізовані величини для кожного потоку. Таку аналітику анонсовано як майбутню роботу, і тут її не припускають.

3.3 Чим схема не є

VSS Editor явно не є панеллю KPI, інструментом BI, рушієм симуляції чи заміною фінансового обліку. Він ставить ясність попереду обчислень. Звідси рекомендований порядок моделювання: визначити межу, додати лише основні конвертори, з'єднати їх іменованими потоками (назви перед числами, напрям перед точністю), потім позначити антицінність, крок, що часто дає найбільше розуміння.

4 Чия цінність: система та її межа

Вимірювання цінності позбавлене сенсу, доки не вказано, чия цінність вимірюється (A1, T1). Обрана межа також змінює висновки без жодної зміни реальності (T15). Тому ця праця фіксує систему цінності до будь-яких вимірювань.

Змодельована тут система цінності є системою цінності продукту одного програмного продукту всередині продуктової організації. Услід за презентацією Product Value System її акторами є продуктова функція, команда розробки, експлуатація, продукт у production, користувачі та компанія як отримувач цінності, повернутої користувачами. Фінанси є зовнішнім забезпечувальним входом (зарплати).

Вимірюються дві реалізовані інтерпретації: цінність для користувачів, інтерпретована користувачами або їхньою спостережуваною поведінкою, і цінність для компанії, інтерпретована компанією як отримувачем зворотного потоку (дохід, утримання, зменшення витрат чи ризику). Планова цінність є інтерпретацією відправника до релізу. Цінність того самого релізу для партнера чи регулятора лежить поза межею, якщо її явно не розширити.

5 Від гіпотези продукту до реалізованої цінності: цикл цінності

Презентація Product Value System подає продуктову роботу як цикл, у якому гіпотези цінності створюються, реалізуються, валідуються та підтримуються. У термінах схеми цикл має такі конвертори та потоки.

1. Інвестиції до продуктової функції. Продуктова функція перетворює ресурси та сигнали користувачів на гіпотези, що несуть планову цінність.
2. Продуктова функція до розробки. Гіпотези стають елементами беклогу з плановою цінністю. Презентація формулює два очікування: планова цінність гіпотези не повинна зменшуватися під час її створення, а доставлена цінність не повинна сильно відрізнятися від планової.
3. Розробка до експлуатації. Розробка споживає зусилля й виробляє робочі зміни разом з антицінністю (технічний борг, дефекти, затримка).
4. Експлуатація до production. Зміни стають працюючим програмним забезпеченням; помилки релізу та простої з'являються як антицінність.
5. Production до користувачів. Цінність реалізується лише у використанні (A6), тож це перша точка, де можна спостерігати реалізовану цінність.
6. Користувачі до компанії. Користувачі повертають дохід, утримання та довіру. Допис автора в каналі від січня 2022 року називає це замкненим потоком: цінність, доставлена клієнту, врівноважується цінністю, що тече назад, часто, але не лише у вигляді грошей.

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

У презентації також наведено типи спостережуваних елементів для внутрішніх і зовнішніх продуктів. Елементи цінності включають заощаджений час, менше операційних помилок, грошовий потік, зниження ризику, менше когнітивне навантаження, передбачуваність, нові можливості та довіру. Відповідні елементи антицінності включають втрачений час, переробку, зростання операційних витрат, технічний борг, непередбачуваність, ручні обхідні рішення, втрату довіри та погіршення обслуговування клієнтів. Ця типологія є відправною точкою реєстру елементів цінності (Value Element Registry) для поставки.

6 Запланована та реалізована цінність за релізами, опір і витік

6.1 Реліз як одиниця порівняння

Одиницею порівняння є реліз або елемент беклогу, коли релізи невеликі. Для кожного з них метод фіксує в Æ:

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

Презентація пропонує поетапне впровадження: спочатку запланована цінність для кожного елемента беклогу, потім реалізована цінність і антицінність для кожного випущеного елемента, потім ретроспективна цінність. Без запланованої цінності немає розриву, який можна виміряти; без реалізованої цінності план залишається гіпотезою.

6.2 Опір потоку в поставці

Опір потоку (flow resistance) - це розрив між запланованою та реалізованою цінністю плюс антицінність, що виникає в потоці. VMT вважає ненульовий розрив нормальним (T3), але стверджує, що опір накопичується історично (T4) і знижує здатність реалізувати майбутню цінність (T6). У поставці цінність втрачається під час реалізації (скорочення обсягу, неправильно зрозуміла гіпотеза), у релізі (дефекти, відкоти), під час впровадження (користувачі не можуть знайти зміну або скористатися нею) та через затримку. Відповідно до концепції вартості затримки (Reinertsen, 2009), затримка моделюється як антицінність у запізнілому потоці, а не як окрема метрика.

Якщо кожен потік має власні планові та спостережувані величини, схема показує, у якому конвертері сталася втрата. Саме для цього призначені реєстр опору потоків та звіт про розрив між запланованою та реалізованою цінністю в наборі артефактів Æilus.

6.3 Витік

Витік (leakage) - це стійке перевищення реалізованої цінності, що залишає систему, над цінністю, що входить у неї (A11). У системі цінності продукту поширені дві форми. У першій користувачі отримують користь, але зворотний потік не покриває забезпечувальний вхідний потік. У другій команда споживає інвестиції, поки гіпотези будуються, але так і не реалізуються. В обох випадках пропускна здатність може виглядати здоровою; схема показує обидва, тому що вхідні та вихідні потоки лежать на одній межі.

7 Спільні вузли: оцінювання за всіма потоками

Деякі конвертери в програмній системі не створюють цінності, яку назвав би користувач, проте кожен потік цінності проходить через них. Допис автора в каналі за вересень 2025 року та пов'язана стаття на aeilus.tech використовують як приклад авторизацію: вона сама по собі не створює цінності, але без неї зупиняється кожен сценарій. API-шлюз або CI-конвеєр належать до того самого типу.

Якщо оцінювати такий вузол ізольовано, він показує витрати й жодного результату та провокує скорочення витрат. У схемі він з'являється одразу на багатьох потоках, а його ефективність стає зрозумілою лише через сукупну цінність усіх потоків, які він підтримує. Тому метод приписує спільному вузлу:

• множину потоків, що проходять через нього, зчитану зі схеми;
• антицінність, яку він додає до кожного з цих потоків (затримка, збої, невдалі входи, інтеграційні дефекти);
• його спожиту цінність (зусилля команди, інфраструктура).

Його ефективність - це доставлена цінність мінус антицінність за всіма його потоками, співвіднесені зі спожитою цінністю, відповідно до визначення ефективності процесу з тієї самої статті. Деградація спільного вузла ніколи не є локальним інцидентом; це опір, доданий до кожного потоку, який він обслуговує. Теорема T8 додає аргумент сталості: стабільність втрачається, коли трансформаційна роль не може бути виконана, а резервування ролі підвищує стабільність.

8 Що отримує керівник команди

Допис автора в каналі за лютий 2022 року перелічує, що підхід дає команді та її керівникові. Переформульовано в термінах цієї статті:

• Доставлена цінність як зворотний зв'язок. За будь-який період команда бачить цінність, яку вона доставила, в Æ, підтверджену отримувачами, замість опосередкованого сигналу швидкості (velocity).
• Міра ефективності, незалежна від методології процесу. Якою б не була практика, мірою є реалізована цінність на одиницю спожитої цінності, а практики обираються або відкидаються за їхнім впливом на неї (P7).
• Прозорість для бізнесу. Технічна робота стає зрозумілою через потоки, які вона підтримує.
• Пріоритет беклогу від цінності. Пріоритет можна виводити із запланованої цінності, впевненості в ній та вартості її затримки, а не з вимог найгучнішого стейкхолдера.
• Вартість затримки та помилки в продакшені як антицінність. Бізнес може показати, як падає цінність, коли зміна запізнюється або має дефекти, а команда бачить, як корисність її роботи залежить від термінів і якості в продакшені.
• Аргументи для спільних ресурсів. Там, де адміністратори та DevOps-інженери спільні, пріоритет на основі цінності пояснює, чому роботу однієї команди було відкладено на користь іншої, в обидва боки.

Ці переваги діють лише тоді, коли реалізована цінність підтверджується її отримувачами. Якщо команда сама оцінює та підтверджує власну цінність, міра стає ще одним самозвітним лічильником, і застосовується T17: інтерпретації від впливових джерел, не підтверджені реалізацією, накопичують антицінність.

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

Цей розділ описує синтетичний, ілюстративний продукт. Це не кейс, він не описує жодної реальної організації і не містить виміряних чисел.

Синтетичний продукт - це вебзастосунок за підпискою, через який малі сервісні бізнеси приймають бронювання клієнтів. Його система цінності відповідає межі, визначеній у розділі 4. Два спільні вузли, сервіс авторизації та API-шлюз, обслуговують усі потоки, орієнтовані на користувачів. Фінанси забезпечують забезпечувальний вхідний потік. Компанія отримує дохід від підписки та утримання клієнтів як зворотний потік.

Схему побудовано у VSS Editor за чотири проходи: межа з одним зовнішнім вхідним потоком (інвестиції та зарплати) і зовнішніми вихідними потоками до користувачів; сім конвертерів; потоки, названі за елементами цінності, які вони переносять; та елементи антицінності. Величини залишаються порожніми до першої сесії оцінювання.

Розглянемо один гіпотетичний випуск: функцію нагадувань, призначену зменшити кількість пропущених записів. Перед розробкою власник продукту фіксує заплановану цінність (planned value) для кожного елемента (заощаджений час, менше пропущених бронювань, очікуваний вплив на утримання клієнтів). Після узгодженого періоду спостереження продуктова аналітика та вибірка бізнес-користувачів надають реалізовану цінність (realized value), а команда фіксує реалізовану антицінність: запізнілий випуск, дефект, через який надсилалися дубльовані нагадування, додаткове навантаження на API-шлюз. Різниця є опором цього випуску. Дефект і навантаження на шлюз також розташовані на потоках, що обслуговують інші сценарії, тому їх приписують і спільним вузлам. Через квартал ретроспективна цінність (retrospective value) показує, чи змінилося утримання взагалі. У реальному застосуванні величини походили б із сесій, описаних далі.

10 Як це запровадити

10.1 Хто оцінює і хто перевіряє

Правило Æilus із допису 2025 року коротке: вихідну цінність процесу має оцінювати той, хто її споживає, а цю оцінку має перевіряти хтось інший. У застосуванні до постачання це дає чіткий розподіл.

• Заплановану цінність оцінює відправник. Для гіпотез це власник продукту, який діє як власник перетворювача цінності (Value Transformer Owner, VTO) продуктового перетворювача. Для перетворювача розробки це керівник команди як VTO.
• Реалізовану цінність інтерпретує отримувач: користувачі, яких спостерігають через продуктову або веб-аналітику, а для зворотного потоку - компанія. Презентація пропонує як тимчасовий захід, щоб продуктова аналітика представляла сторону користувачів, доки не буде налагоджено пряму валідацію.
• Валідацію інтерпретації виконує друга сторона: власник системи цінності (Value System Owner, VSO), який відповідає за стійкість на рівні системи, або власник потоку (Flow Owner) для критичного потоку.
• Методологічну цілісність підтримує Æ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.