Чи не мрія будь-якого власника компанії керувати IT-продуктом так, щоб постачати продукт у строк, обганяючи конкурентів, і робити це з високою якістю, радуючи користувачів? Хотілося б знайти срібну кулю для управління і, здається, вона є. Не така вже й срібна і не така вже й куля, але досить надійний і обкатаний роками підхід до управління, який можна назвати FFF: Fix Time and Budget, Flex Scope.
Чому і коли варто обрати FFF? Подивімось.
Три комбінації
Кожен із підходів до управління проєктом, по суті, відрізняється тим, що фіксує або не фіксує такі величини: бюджет, обсяг робіт, термін і внутрішню якість системи.
Конкретна комбінація створює певні умови роботи, має плюси та мінуси:
Fixed price
- Зафіксовано три точки проєктного трикутника: термін, гроші та обсяг роботи.
- Основні ризики бере на себе виконавець і, як наслідок, ці ризики відображаються на оцінці. Крім цього створюються ризики і для замовника, про це я писав у статті 12 проблем під час роботи за технічним завданням в IT-продукті.
- Великим плюсом цього підходу є наперед визначені до початку робіт параметри проєкту. Дуже часто бізнесу/державі потрібно прописати в договорі термін, гроші та обсяг роботи.
- Внутрішню якість при цьому рідко фіксують. Натомість майже завжди саме якістю жертвують, щоб у нашому мінливому світі примудритися вкластися в строк із фіксованим обсягом роботи. Чому так відбувається і що є коренем проблеми, обговоримо трохи далі.
- Оплата відбувається наприкінці проєкту з можливою передоплатою на початку.
Time and Materials (T&M)
- Зафіксовано гроші та внутрішню якість системи, хоча другою часто нехтують через недбалість або недосвідченість з обох сторін.
- Замовник бере в оренду ресурси виконавця за фіксованою ставкою і управляє ними на свій розсуд.
Виконавець відповідає за те, щоб дати максимально якісний продукт за рахунок своєї компетенції. - Оплачується при цьому час, який співробітники виконавця були зайняті на проєктах замовника. Це відбувається наприкінці звітного періоду, наприклад, раз на місяць.
- Основні ризики бере на себе замовник.
- Якщо у замовника є чітке розуміння завдань і організовано контроль роботи (зокрема власних ресурсів, особливо Product Owner’а), то це найоптимальніший і найшвидший варіант управління, бо він найменш бюрократизований, відповідно, всі займаються тільки розробкою без зайвих відволікань на ритуали погоджень.
Fix Time and Budget, Flex Scope (FFF)
- Зафіксовано три точки проєктного трикутника: термін, гроші та внутрішня якість системи.
- Оплата відбувається наприкінці проєкту з можливою передоплатою на початку.
- У контракті описуються завдання, але досить високорівнево, щоб можна було флексити обсяг роботи без переписування контракту.
- Обсяг роботи обговорюється на початку проєкту, але є предметом для зміни.
- Під час розробки потрібно стежити за спалюванням бюджету, терміном релізу, що наближається, і завданнями, що залишилися, щоб усе найважливіше встигнути до терміну. Глибину опрацювання завдань і кінцевий список цих завдань можуть змінювати під час роботи прямо на плануваннях або стендапах.
- Ризики діляться порівну: розробники зобов’язуються поставити цінність у термін і бюджет, а замовник намагається вибрати/обрізати завдання, виходячи з пріоритетів бізнесу і поточної ситуації.
Внутрішня якість системи стає дуже важливою, тому що обсяг робіт може змінитися, при цьому термін і бюджет рухати ніхто не збирається. Тому код, тести, внутрішній дизайн, архітектура й автоматизація мають бути високої якості, мати гнучкість і, зрештою, допомагати швидко підлаштовуватися під будь-які зміни.
Внутрішня якість системи – це те, як ПЗ влаштовано всередині. Зовні софт може мати гарний вигляд і навіть працювати непогано, але всередині може складатися з одних “милиць”, макаронного коду, крихких інтеграцій, розроблятися без тестів і працювати без належного рівня моніторингу. Низька якість загрожує уповільненням розробки та підвищенням вартості підтримки. Високою якістю можна вважати, наприклад, відсутність технічного боргу й успішне проходження коду через метрики SonarQube.
Корінь проблеми
Чому сформувалися саме такі три комбінації? Чому не можна зафіксувати все? Адже найпростіше – зафіксувати бюджет, обсяг робіт, дату релізу і внутрішню якість системи, підписати договір (якщо замовник внутрішній, то пройти процедуру узгодження в стейкхолдерів) і зробити роботу з точним попаданням у всі чотири величини. Але, як показує практика, є фундаментальна проблема, яка не дає з легкістю пройти цей шлях без спотворень.
Ні в кого не виникає проблем із розрахунком бюджету, доволі легко порахувати дату релізу і є безліч метрик і чеклистів, щоб задати конкретний рівень якості IT-продукту. Це все просто, якщо ви можете точно оцінити обсяг робіт. Іншими словами, якщо є детальний список завдань і точна оцінка цього обсягу робіт, то інші три величини рахуються легко. І навпаки, якщо точної оцінки немає, то інші величини теж будуть неточні, тому що ґрунтуються на оцінці обсягу робіт.
З оцінкою обсягу робіт завжди проблеми, тому що немає жодної методики оцінки, яка б працювала з прийнятною точністю. Усі методики спираються на попередній досвід команди, яка робила схожі речі, що в підсумку означає неточності, тому що люди неточні: емоційні, оптимістичні, забудькуваті. Відсутність методики точного оцінювання – перший фактор, що заважає нам потрапляти в оцінку обсяг робіт.
Під час роботи над IT-продуктом змінюються: список завдань, які треба зробити, глибина їхнього опрацювання, підхід до проєктування системи. Це відбувається під впливом зовнішнього середовища: зміни на ринку, зміни в стратегії компанії, зміни в політиці всередині компанії, зворотний зв’язок від користувачів, нові вступні дані від тих, хто на етапі аналітики промовчав, а надалі вирішив висловитися, і т. д. Наша неможливість впливати на зовнішні впливи – другий фактор, що заважає від самого початку потрапити в оцінку.
Третій фактор полягає в тому, що немає критеріїв для визначення досягнення повноти при описі обсягу робіт. Написання ТЗ неможливо закінчити, його можна тільки припинити.
Треба застерегти, що все це справедливо, якщо ви працюєте в досить складній області: за Cynefin framework це області Complex і Complicated. Якщо ж ваш проєкт потрапляє в Obvious і водночас він досить короткий, то обсяг роботи ви, найімовірніше, оціните дуже точно.
Отже, ми маємо, що корінь проблеми в неточній оцінці обсягу робіт і практичній неможливості зробити цю оцінку точною, тому:
- У Fixed price проєктах жертвують внутрішньою якістю системи, адже потрапити в оцінку з трьома фіксованими вершинами майже неможливо. Або в тих же Fixed price проєктах перезакладають у бюджет стільки ризиків, щоб покрити взагалі будь-які неточності оцінки, що є неефективним.
- У T&M легко піти в неефективне управління ресурсами, адже постійно відстежувати роздмухування скоупа й обрізати його досить складно. Потрібні правильні інструменти і дуже сильні Product Owner’и.
- FFF заздалегідь приймає, що обсяг роботи не передбачити, але при цьому “забиває кілочки” на терміні та бюджеті, щоб уникнути проблем T&M.
А може взагалі не оцінювати?
Якщо оцінити обсяг робіт не можна з достатньою точністю, то може взагалі цим не займатися? Є такий рух #NoEstimates.
Якщо коротко, то ми організовуємо процес розробки так, щоб максимально ефективно проводити завдання від етапу ідеї до викочування в прод і при цьому зберігати високу внутрішню якість. Організовувати процес пропонують за Kanban з відстеженням метрик обробки потоку і особливою увагою до поліпшення процесу доставки нових фіч. Передчасні оцінки вважаються шкідливими, оцінка і груммінг беклога – втрата часу.
Я двома руками за цей підхід. Він мені подобається, як інженеру і як керівнику. Але життя так влаштоване, що власникам бюджету потрібна оцінка, хоча б на перших етапах роботи, хоча б приблизна. У Byndyusoft ми іноді переходимо до #NoEstimates, але тільки після доволі тривалих стосунків із замовником і відбувається це далеко не завжди.
FFF – баланс гнучкості та передбачуваності
Оцінки, хоч і псують життя і є втратами часу, але без них складно починати роботу. При цьому зрозуміло, що жодна оцінка не буде точною. Виходить, що найкращий варіант – зафіксувати термін і бюджет, щоб бізнес зміг із цим жити, а обсяг роботи залишити плаваючою величиною.
Окрім цього, замовник і виконавець повинні домовитися, що в кожен момент часу команда займається тільки найважливішими і потрібними завданнями, а замовник приділяє час на те, щоб стежити в динаміці за вибором пріоритетів.
Уперше я побачив опис FFF у книзі Getting Real від 37signals у розділі Fix Time and Budget, Flex Scope. Наразі в моїй компанії це найпопулярніший підхід до роботи, ним задоволені і замовники, і ми.
Внутрішня якість системи
Як я писав вище, працювати за FFF можна, якщо в компанії є компетентні розробники, які здатні забезпечити високу внутрішню якість системи. Зазвичай це досягається автоматизацією всього і вся, складанням чеклистів із найкращими практиками, постійним рев’ю коду та архітектури, усіма видами тестування і, найголовніше, набором правильних людей у команду.
Чому не варто забувати про внутрішню якість, написано в блозі Мартіна Фаулера у статті Is High Quality Software Worth the Cost?
Якщо сказати коротко, то при FFF передбачаються зміни в напрямку розвитку продукту, а це передбачає достатню гнучкість системи. Якщо якість системи низька, то кожен “поворот” сповільнюватиме розробку і збільшуватиме її вартість, аж до повної зупинки проєкту.
Якщо ви хочете працювати за FFF, то закладіть критерії якості в контракт, щоб зафіксувати їх напевно.
Мотивація замовника і виконавця
Робота за FFF дає правильну мотивацію з боку замовника і виконавця. На відміну від Fixed Price, де замовник і виконавець спілкуються через інтерфейс контракту, і на відміну від T&M, де замовник може втратити межі та витратити більше, ніж треба; у FFF усім доводиться вкладатися в комунікації та “жити” у проєкті, щоб зробити найважливіше й при цьому задовольнити умови контракту.
Обираємо FFF
Fixed price і T&M мають свої переваги в певних контекстах:
- Якщо ви берете участь у тендері та зобов’язуєтеся виконати конкретну роботу за обумовлений час і гроші, водночас комунікація здебільшого вибудувана через договір підряду, найімовірніше, найкращим варіантом буде Fixed price.
- Якщо замовник точно знає, що йому потрібно, і вміє ефективно вибудовувати процес роботи, то йому достатньо купити ресурси з T&M і розпоряджатися ними на свій розсуд.
Проте, за інших рівних умов ми намагаємося вибирати FFF. Цей підхід здається найбільш збалансованим: він знижує ризики замовника і виконавця, створює потрібну мотивацію з обох сторін і піклується про внутрішню якість системи.
