Moneyball для software-проєктів

Притча про калькулятор трудомісткості Digital Polygraph

Деякі фільми насправді не про те, що написано на афіші. Moneyball — один із них.

Якщо ви ще не бачили фільм, знайдіть український прокатний варіант: «Людина, яка змінила все» (2011, режисер Беннетт Міллер).

Формально це фільм про бейсбол: Oakland Athletics, Біллі Бін, Пітер Бренд, скаути, гравці, польовий менеджер, обмежений бюджет і інший спосіб перемагати.

Але під бейсболом у Moneyball прихований момент, коли стара культура оцінювання перестає працювати.

Саме тому Moneyball найкраще пояснює калькулятор трудомісткості Digital Polygraph.

Якщо ви бачили цей фільм, ви вже розумієте логіку. Усе, що там показано, майже напряму переноситься на software-проєкти.

Кімната

У Moneyball є кімната, де обговорюється майбутнє команди. За столом сидять досвідчені бейсбольні люди. Вони знають гру. Вони бачили сотні гравців. Вони говорять упевнено.

Вони дивляться на гравця й говорять про те, як він виглядає, як рухається, як б’є, чи має правильне тіло, правильне обличчя, правильну присутність.

Вони не дурні. Вони не зайві. Вони не вороги. Проблема в іншому: їхній досвід використовують для відповіді на неправильне запитання.

Oakland не має грошей, щоб грати як Yankees. Біллі Бін не може купувати красиві враження. Йому потрібен виміряний результат.

Така сама кімната існує в software

Перенесіть цю кімнату в software-розробку. Назви посад змінюються: founder, CTO, product owner, architect, senior engineer, Scrum Master, investor, consultant.

Предмет обговорення вже не бейсбольний гравець. Предмет обговорення — software-проєкт. Але мова часто звучить так само.

Слова сучасні. Ритуал старий. Упевненість подається як прогноз. Внутрішня мова команди подається як доказ для капітального рішення. Ритуал планування змушують відповідати на фінансове запитання.

Це не інженерне вимірювання. Це software scouting.

Story points мають своє місце

Story points не зникають. Вони просто залишаються там, де їм місце: всередині профінансованого етапу, всередині спринту, всередині щоденної роботи команди.

У Moneyball Арт Хау, якого зіграв Філіп Сеймур Гоффман, є польовим менеджером. Він працює з гравцями. Він керує грою на полі після того, як стратегія вже обрана.

Вони можуть допомагати Scrum Master, Delivery Manager або Team Lead організовувати роботу всередині етапу. Але вони не вирішують, чи заслуговує етап на капітал.

Вони не захищають runway. Вони не розраховують burn rate. Вони не визначають stop-loss. Вони не кажуть інвестору, чи треба фінансувати наступний етап.

Правильне запитання

Пітер Бренд не входить у фільм, щоб гадати голосніше. Він не замінює бейсбол. Він не замінює гравців. Він не замінює польового менеджера. Він не робить досвід непотрібним.

Він змінює запитання.

Старе запитання було таким: хто виглядає як хороший гравець? Нове запитання таке: хто дає виміряний результат, потрібний нам за ті гроші, які ми можемо витратити?

Digital Polygraph приносить таку саму зміну в software-проєкти. Він не питає, скільки це «відчувається» за часом.

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

Експерти залишаються необхідними. Domain experts, architects, senior engineers і product specialists не зникають. Їхня робота стає точнішою.

Вони більше не вгадують бюджет. Вони описують продукт. Після цього модель рахує.

OBP Digital Polygraph

У бейсболі Moneyball шукав метрику, яка справді має значення: не красу, не традицію, не репутацію, не відчуття скаута, а виміряний внесок.

Digital Polygraph має власний еквівалент цього зсуву. Це не velocity. Це не story points. Це не кількість senior developers у кімнаті.

Еквівалент Digital Polygraph — детермінована трудомісткість для виміряного software-результату.

Вона будується з функціональності, складності, новизни, повторного використання, інженерного етапу і стадії зрілості продукту.

Калькулятор бере структурований опис software-продукту і перетворює його на трудомісткість, строки, структуру команди і артефакт для рішення.

Що потрібно особі, яка приймає рішення

Велика корпорація може дозволити собі дорогу помилку. Вона може спалити кілька місяців, найняти більше людей, переписати модуль, закрити невдалу ініціативу і почати іншу.

Стартап — ні. Невелика software-команда — ні. Інвестор, який фінансує наступний етап, також не повинен. Founder з обмеженим runway не має права купувати красиві враження.

Особа, яка приймає рішення, має знати, що саме купується.

Це Prototype? Це MVP? Це Release Candidate? Це Production Release?

Капітал купує рух до зрілого software-продукту чи оплачує ще один ритуал упевненості?

Склад Software Moneyball

Порядок має значення

Спочатку скаути описують продукт. Потім Пітер Бренд приносить розрахунок. Потім Біллі Бін приймає капітальне рішення. Потім Арт Хау веде гру всередині вибраного етапу.

Якщо цей порядок зламати, проєкт повертається до гадання.

Якщо спринтова мова польового менеджера стає фінансовою моделлю, boardroom отримує внутрішню кухню команди замість математики капіталу.

Якщо експерти продають враження замість опису продукту, decision-maker купує впевненість замість виміряного результату.

Якщо founder приймає burn rate на основі story points, компанія грає у гру багатих клубів, не маючи їхнього бюджету.