Це переклад матеріалу "How Much Does This Cost?" by Evan Leybourn. Блог Евана за посиланням.
«Є так багато людей, які можуть підрахувати витрати, і так мало тих, хто може оцінити вартість» – невідомий мовець.
Контракти, бюджети та розцінки. Ці три поняття можуть змусити найзатятіших практиків #NoEstimates (без оцінки) бігти в укриття. Але цього не варто робити.
Розуміння результатів, цінності та довіри є ключем до успішної побудови контракту на основі #NoEstimates або будь-якої адаптивної та agile delivery моделі. Без них, очевидно, організація стає обмеженою в здатності адаптуватися та використовувати ринок, що постійно змінюється.
Контекст контрактів
По суті, договір визначається рівнем ризику, який кожна сторона готова прийняти. Щоб керувати цим ризиком, є три запитання, які кожен замовник колись поставить перед agile проєктом.
"Скільки це буде коштувати?"
"Скільки часу це займе?"
"Що я маю отримати?"
І хоча варіанти «стільки, скільки ви готові витратити», «стільки, скільки необхідно» і «скільки ви попросите» іноді є прийнятними відповідями, багатьом клієнтам такий підхід незручний. Це більшою мірою впливає на клієнта, ніж на команду, але часто призводить до помилкової думки, що agile команди, або #NoEstimates, виписують собі чистий чек. Як тоді визначити та охопити проєкт, де замовник очікує чітко визначеного часу, вартості чи обсягу?
Давайте спочатку розберемося з основами. Існує фундаментальна залежність між часом, вартістю та обсягом. Щоб зрозуміти це, можна візуалізувати свій проєкт у вигляді конвеєра, як показано нижче. Ширина труби – це розмір вашої команди, довжина – час, доступний для доставки, а потік – це ваш обсяг. Будь-які варіації вимагають зміни однієї з цих трьох змінних. Фактично (і спрощено) у вас є три варіанти: збільшити потужність (вартість), збільшити тривалість (час) або зменшити вимоги (обсяг). З точки зору гнучкості, ваша швидкість не змінюється лише тому, що ви додаєте більше роботи.
Рисунок 1 Зв’язок між часом, вартістю та обсягом
Крім того, більшість досліджень показує, що тривала понаднормова робота може призвести до значного зниження продуктивності.
Ми також повинні розуміти, що кожен проєкт має обмеження, і що це не обов’язково погано. Творчість та інновації підтримуються та стимулюються завдяки обмеженням, з якими ми маємо справу. Однак, за визначенням, методи agile delivery дають клієнту контроль над продуктом і не обмежують рамки, окрім встановлених контекстом проєкту на початку. Функціональність продукту може розвиватися, бо беклоги змінюються між ітераціями. Навіть в Agile Manifest це дуже чітко описано: Співпраця із замовником важливіша за обговорення умов контракту.
Іншими словами, обсяг проєкту непередбачуваний. Я піду далі й скажу, що всі проєкти непередбачувані, але waterfall контракти закривають на це очі й просуваються легко «ля-ля-ля» і вдають, ніби все добре.
Отже, що це означає для контрактів? Контракти покладаються на передбачуваність: я заплачу вам X, щоб зробити Y, а це демонструє фундаментальний недолік у тому, як ми традиційно будуємо контракти. Отже, для agile контракту нам потрібно знайти інше обмеження – інший спосіб узгодження зобов’язань.Але давайте почнемо з того, з чого повинні починатися всі контракти: довіра.
Питання довіри
Значною мірою форма та гнучкість контракту, укладеного між сторонами, залежать від рівня довіри, який існує між ними. Це можна визначити на чотирьох різних рівнях.
Рисунок 2 Піраміда довіри
Відгук: це найнижча форма довіри, яка існує, коли довіра між сторонами ґрунтується на рекомендаціях третьої сторони, якій вони взаємно довіряють.
Контракт: це найпоширеніший рівень довіри, і більшість відносин не виходять за його межі. Це відбувається, коли сторони створюють юридично закріплені контракти (можливо, зі штрафними з астереженнями) як основний механізм, що забезпечує довіру між ними.
Ідентифікація: цей рівень довіри створюється з часом і існує, коли сторони мають можливість працювати разом і будувати довіру на основі особистого досвіду.
Партнерство: це найвищий рівень довіри між двома сторонами, який існує, коли обидві сторони мають однакові цілі та результати. Це може бути у формі стратегічного партнерства чи подібної структури.
Розуміння рівнів довіри відіграє суттєву роль для розробки agile контрактів.
Розробка agile контрактів
Це підводить нас до суті цієї статті – самих контрактів. Досвід показує, що більшість software контрактів мають три форми: контракти за терміном та матеріалами, контракти на основі результатів або фіксовані контракти.
Контракти за терміном та матеріалами
Терміни й матеріали (також відомий як T&M) є найбільш правильною моделлю, яка відповідаю “Agile” контракту, яка забезпечує найбільшу гнучкість для змін, масштабування та адаптації до вимог. Якщо ви можете визначити та надати пріоритет цінності user story, контракт T&M дає вам можливість припинити роботу (або, принаймні, активувати положення про закриття контракту), щойно вартість delivery перевищує вартість того, що є delivered. Іншими словами, робота повинна тривати до тих пір, поки замовник не вирішить припинити роботу.
Рисунок 3 Ціна проти вартості
Щоб зрозуміти, що це означає, нам може допомогти візуалізація норми витрат. У наведеному вище простому прикладі ми відстежуємо цінність кожної історії порівняно з лінійними фінансовими витратами (фіксований розмір команди). У цьому прикладі, який є досить поширеним серед software проєктів, початкові історії мають низьку цінність (технічна структура або завдання бази даних), за якими йдуть прості, але високоцінні завдання, за якими відповідно йдуть менш цінні та складніші завдання. У цьому прикладі дуже легко зрозуміти, де має закінчитися контракт T&M, оскільки цінність зменшується порівняно з вартістю.
Якщо потрібні додаткові засоби контролю, ви можете створити обмежений контракт T&M, який обмежує витрати до фіксованої суми. У цьому стилі контракту критично важливо переконатися, що обмеження є достатньо високим, щоб загальний прибуток від інвестицій був позитивним. І оскільки ви завжди можете витратити менше, це має бути верхня межа того, що прийнятно для обох сторін.
Контракти на основі результатів
Останнім часом набуває популярності використання контрактів на основі результатів або на основі ефективності. Іноді вони відомі як «потужність за годину», як асоціація до авіаційних двигунів, які базуються на нальоті годин, а не на фіксованих або річних контрактах.
Складність полягає у визначенні результату, який можна виміряти і який є взаємоприйнятним з фінансової точки зору.
Типовими прикладами контрактів на основі результатів є програмне забезпечення як послуга та інші pay-per-use моделі. Повертаючись до рівнів довіри, для того, щоб контракти, засновані на результатах, були успішними, організації повинні бути на вершині піраміди довіри (див. рис. 2) – на рівні партнерства.Під час розробки контракту на основі результатів вам потрібно буде встановити наступні параметри:
Очікуваний результат: цілком очевидно, що вам потрібно визначити результат, який ви вимірюєте.
Вимірювання результатів та рівні: як ви будете вимірювати ефективність результату та як вони оцінюються за договором.
Крива платежів: як ви будете платити (або отримувати оплату) відповідно до показників ефективності та рівнів вище. Чи є у вас достатні стимули для перевищення базового рівня?
Ризики для результату: які ризики ви готові прийняти (особливо це стосується труднощів у вимірюванні результату)
«Фіксовані» контракти
Сумний факт полягає в тому, що багатьом клієнтам, особливо тим, хто знаходиться на нижчих рівнях піраміди довіри або там, де є значні витрати капіталу, потрібні «фіксовані» контракти. У стандартному випадку це комбінація фіксованих витрат, часу або обсягу.
Надання фіксованих розцінок іноді можна сумістити із #NoEstimates, але це вимагає особливої уваги, щоб добре керувати гнучким компонентом у зрозумілий та досяжний спосіб. Існує 7 форм фіксованих договорів.
А саме:
1. ФІКСОВАНА ВАРТІСТЬ: коли ваш клієнт просить фіксовану цінову пропозицію до початку роботи, але залишається гнучким щодо обсягу доставки та часу, який це займе.
Наприклад: Забезпечення операційної підтримки та послуг з технічного обслуговування.
Як пропонувати: Визначте та оцініть приблизні user stories на ітерації 0. Використовуйте ці дані, щоб обчислити вартість доставки.
Як це зробити: Робіть короткі ітерації (1-2 тижні), оскільки довші ітерації мають тенденцію до перевищення витрат. Крім того, скорочення часу, витраченого на завдання технічної заборгованості та рефакторингу, також може допомогти подолати короткострокові бюджетні обмеження ціною довгострокової ефективності.
Як вимірювати: Відстежуйте швидкість та рівень горіння, оскільки це ваші ключові показники вартості. Постійно коригуйте обсяг і час залежно від того, що ви вимірюєте.
2. ФІКСОВАНИЙ ЧАС: коли ваш клієнт просить остаточну доставку до певної дати, але залишається гнучким щодо обсягу та вартості.
Наприклад: Розробка та друк нового маркетингового матеріалу для запуску продукту.
Як пропонувати: Використовуючи історичні дані про швидкість, кожна команда може спрогнозувати кількість історій, які вони можуть обробити до встановленого терміну.
Як це зробити: Суворо дотримуйтеся часових меж. Тривалість визначається фіксованою кількістю ітерацій, а подовження ітерації відтермінує вашу кінцеву дату.
Як вимірювати: Відстеження команди та швидкості проєкту та/або часу циклу.
3. ФІКСОВАНИЙ ОБСЯГ: коли ваш клієнт має фіксований набір вимог, але гнучкий щодо часу, необхідного для доставки, і вартості доставки. Це іноді називають «heavy agile».
Наприклад: Зміна наявних звітів відповідно до внутрішніх вимог до звітності.
Як пропонувати: Зосередьтеся на визначенні та оцінці беклогів перед початком роботи, щоб забезпечити точне визначення обсягу.
Як це зробити: Працюйте в попередньо визначеному та узгодженому порядку.
Як вимірювати: Виміряйте, скільки історій було опрацьовано на даний момент, і спрогнозуйте рівень опрацьованих історій в майбутньому, щоб оцінити можливі кінцеві дати.
4. ФІКСОВАНІ ВАРТІСТЬ І ЧАС: це виступає еквівалентом обмеженого часу та матеріалів. Коли ваш клієнт просить фіксовану цінову пропозицію з остаточною доставкою до визначеної дати. У цій ситуації точний набір функцій або обсяг залишається гнучким.
Наприклад: Робота над узгодженим продуктом до кінця фінансового року.
Як пропонувати: Розрахуйте загальну вартість як вартість за тиждень або вартість за ітерацію – це один із найпростіших варіантів пропозицій, який повністю сумісний із #NoEstimates, оскільки ви визначаєте ціну проєкту на основі того, що клієнт очікує та готовий заплатити, а не на основі потенційної оціночної вартості. Таким чином вартість фактично закладена в бюджет, а не оцінена.
Як це зробити: На додаток до критеріїв у фіксованому часі та фіксованій вартості, за потреби оновлюйте беклоги.
Як вимірювати: Виміряйте, скільки історій було опрацьовано на даний момент, і спрогнозуйте рівень опрацьованих історій в майбутньому, щоб оцінити, скільки історій можна опрацювати за доступний час. Виміряйте темпи витрат (burn rate), щоб переконатися, що витрати відповідають очікуваному бюджету.
5. ФІКСОВАНІ ВАРТІСТЬ І ОБСЯГ: коли ваш клієнт просить фіксовану цінову пропозицію за заздалегідь визначеним набором вимог. У цій ситуації кінцева дата доставки залишається гнучкою.
Наприклад: Створення та опрацювання продукту відповідно до архітектурних специфікацій.
Як пропонувати: Збільшіть непередбачені витрати (% або $) під час ітерації 0, щоб переконатися, що ваша пропозиція враховує несподівані затримки, які вплинуть на вашу вартість.
Як це зробити: На додаток до критеріїв у фіксованій вартості та фіксованому обсязі, за потреби відкоригуйте дату доставки.
Як вимірювати: Виміряйте, скільки історій було опрацьовано на даний момент, і спрогнозуйте рівень опрацьованих історій в майбутньому, щоб оцінити можливу дату обробки для всіх оброблених історій. Виміряйте темпи витрат (burn rate), щоб переконатися, що витрати відповідають очікуваному бюджету.
6. ФІКСОВАНІ ЧАС І ОБСЯГ: коли ваш клієнт просить фіксований набір вимог з остаточною доставкою до визначеної дати. У цій ситуації загальна вартість для клієнта залишається гнучкою.
Наприклад: Виконання юридичних вимог до юридичної кінцевої дати.
Як пропонувати: Під час ітерації 0 попередньо призначте вимоги за тижнем або ітерацією, щоб визначити розклад обсягу обробки. Доповніть графік додатковим часом, щоб задовольнити несподівані дефекти або технічну заборгованість.
Як це зробити: На додаток до критеріїв у фіксованому часі та фіксованому обсязі, збільште розмір команди, щоб гарантувати вчасне виконання обсягу.
Як вимірювати: Виміряйте, скільки історій було опрацьовано на даний момент, і спрогнозуйте рівень опрацьованих історій в майбутньому, щоб оцінити можливу дату обробки для всіх оброблених історій. Виміряйте темпи витрат (burn rate) та інформуйте клієнта про ймовірну остаточну вартість проєкту.
7. ФІКСОВАНІ ВАРТІСТЬ, ЧАС І ОБСЯГ: у цьому остаточному сценарії ваш клієнт не надає вам гнучкості щодо бюджету проєкту, графіку чи обсягу.
Скасувати роботу. Це не підходить для agile, тому це слід запускати за допомогою традиційної структури. Навіть у цьому випадку це, імовірно, зазнає невдачі без певної гнучкості.але… якщо ви почнете з пілотного періоду часу та матеріалів, ви зможете значно пом’якшити ризик, пов’язаний із пізнішим повністю фіксованим контрактом.
Внутрішні моделі фінансування
Поки що ми розглянули, як створити гнучкий контракт у контексті двох окремих організацій. Але як ви структуруєте модель фінансування, якщо робота виконується всередині компанії. Більшість фінансових підрозділів вимагають бюджетів у звичайному режимі (BAU) і проєктного бюджету принаймні на 18 місяців вперед. Через це може бути важко реагувати або діяти на можливості на ринку, особливо в контексті #NoEstimates. Однак, як і у розробці agile контрактів, вам доступні варіанти.
Хоча це тема для іншої статті, я хочу представити два простих підходи, які можна використовувати, щоб гарантувати, що організації залишатимуться адаптивними. Це непередбачені витрати на рівні команди та поточні щомісячні (або квартальні) бюджети.
Непередбачені витрати на рівні команди
У рамках місячного бюджету кожній команді виділіть кошти на випадок непередбачених обставин (зазвичай ~20%), щоб вони витрачали їх на власний розсуд: або на виконання вимог, або як механізм інноваційних змін в організації. Невикористані непередбачені витрати повинні бути перенесені, щоб заохочувати команди до розумних витрат, а не слідувати традиційному підходу «використай – або втрать».
Щомісячні (або квартальні) бюджети
Скорочуючи тривалість кожного бюджетного періоду, організації можуть адаптувати фінансування відповідно до поточних потреб команди чи відділу. Оскільки більшість бюджетних пропозицій будуть ідентичними або майже ідентичними до попередніх місяців, накладні витрати на керування кількома короткими бюджетами є незначними. Команди та відділи мають заохочуватися (а в деяких випадках стимулюватися) до інновацій у своїх існуючих бюджетах і, де це можливо, до скорочення вихідних витрат. Це потребує більше зусиль з боку відділу фінансів і бухгалтерського обліку, але це можна зробити за допомогою відповідних інструментів і допоміжних процесів.
Є ще виклики, пов’язані з капіталізацією, але це не нова проблема. Ознайомтеся зі стандартною програмою Agile Accounting Standard Program, щоб зрозуміти, як agile може узгодити загальні стандарти бухгалтерського обліку.
Висновок
В основному всі ці підходи зводяться до основного принципу управління ризиками. Умови вашого контракту встановлюватимуться відповідно до рівня ризику, який готова прийняти кожна сторона. У agile контексті або контексті #NoEstimates ви точно захочете уникнути ситуації, коли контракт надмірно обмежує партнерство, де ризик уже низький або може бути прийнятим.
Враховуючи те, що ми знаємо зараз, повернімося назад і відповімо на початкові три запитання.
Питання: "Скільки це буде коштувати?"
Відповідь: "Стільки, скільки ви готові витратити".
Питання: "Скільки часу це займе?"
Відповідь: "Стільки часу, скільки потрібно, щоб зробити те, що ви просите".
Питання: "Що я отримаю?"
Відповідь: "Будь-що з ваших бажань, про які ви нам скажете".
Comments