В черговий раз виникло питання про точність оцінок часу, необхідного на розробку. В черговий раз спробував сформулювати для себе відповідь.
Перш за все, «точних» оцінок не існує в принципі. Трудовитрати - це завжди випадкова величина, що підкоряється деякому розподілу ймовірностей. Зовні воно виглядає приблизно так.
У цьому прикладі ймовірність завершення завдання за 4 дня дорівнює 0.5, за 6 днів - 0.75, за 8 днів - 0.9.
Я, як справжній злий і тупий строгий замовник, тут змішую поняття трудовитрат і терміну завершення завдання, але це в даному випадку не принципово. Для простоти будемо вважати, що завдання виконує одна людина, і він приділяє їй весь свій час, поки завдання не буде виконано. (Ви ж знаєте, що з такими прикидками «для простоти» ні в якому разі не можна погоджуватися при плануванні реальних проектів, адже правда?)
Коли від нас вимагають оцінку трудовитрат, ми зазвичай встановлюємо для себе якийсь приблизний поріг ймовірності. Наприклад, якщо ми поставимо поріг 0.9, то наші оцінки будуть виконуватися в середньому дев'ять разів з десяти.
Це тільки приблизна форма кривої. Навряд чи хтось зможе точно сформулювати параметри розподілу для оцінки чергового завдання. Можна, звичайно, спробувати побудувати його на підставі зібраної статистики по вже виконаним завданням. Але статистика, швидше за все, буде брехати, тому що весь час змінюються умови, від яких залежать параметри розподілу.
І тут ми плавно підходимо до першої проблеми точності оцінок. Один з улюблених питань замовників (і виступаючих в їх ролі начальників): «Чому ваші оцінки завжди помилкові, якщо ви вже стільки років вирішуєте одні й ті ж завдання?»
І, що характерно, часто ми з ним погоджуємося і, виходячи з кабінету після прочухана, терзає себе: «і правда, коли ж я перестану наступати на ці граблі?» Це підтверджується величезною кількістю «наукових», навколонаукових і антинаукових способів оцінки, які винайшла індустрія розробки ПО за роки свого існування. Ми намагаємося оцінити обсяг коду, кількість юзкейсов, функціональних вузлів або папуг. Ми множимо отримані оцінки на число «пі» або «e». Але при цьому не ставимо під сумнів головне: точна оцінка може бути «обчислена», якщо ми знайдемо чарівну формулу.
Але давайте задумаємося: а чи дійсно ми вирішуємо одні й ті ж завдання?
Ось уявіть. Ми ставимо завдання програмісту - скажімо, написати функцію обчислення квадратного кореня. Програміст витратив на неї, наприклад, три дні, ще день пішов на тестування і виправлення помилок.
Наступного понеділка ми ставимо програмісту нове завдання: написати функцію обчислення квадратного кореня. І даємо йому чотири дні. Виходячи з накопиченого досвіду. Набратися досвіду програміст завершує роботу за два дні, причому без помилок.
Ми віддаємо належне його і даємо йому третє завдання: написати функцію вилучення квадратного кореня.
Через пару місяців продуктивність програміста стабілізується, і він зможе видавати по три функції обчислення квадратного кореня в день. Виходячи з цієї продуктивності, ми зможемо видавати дуже точні оцінки ... Оцінки трудовитрат на написання функції обчислення квадратного кореня.
Абсурдність прикладу очевидна, але він демонструє базову проблему, закладену в більшість способів оцінки трудовитрат. Програмісти ніколи не вирішують одні й ті ж завдання. Всі завдання унікальні.
Звичайно, дуже часто в програмуванні використовуються типові підходи до вирішення певних завдань - різного роду шаблони і фреймворки. У різних областях програмування може включати більше або менше рутинних завдань. Але правда полягає в тому, що рутина зазвичай автоматизується (або віддається недосвідченому молодняку, який вносить свою частку непередбачуваності), а основна частка невизначеності ховається саме в тій частині завдання, яка становить її унікальність.
При цьому обурення замовника абсолютно щиро: з його точки зору ми дійсно вирішуємо одні і ті ж бізнес-завдання. Я майже десять років пропрацював в дуже вузькій області - розробка додатків для терміналів, що приймають банківські картки. І з точки зору бізнес-замовників. всі ці десять років я безліч разів вирішував абсолютно одну і ту ж задачу: «навчити» термінал виконувати продаж по карті клієнта. З технічної ж точки зору ні одна з цих завдань не була схожа на іншу. Кількість параметрів, за якими вони відрізнялися, величезна: разное залізо, різні мови, різні компілятори, різні протоколи, різні інтерфейси ... Але для бізнесу це все несуттєво - термінал або виконує транзакцію, або ні.
Чи можна з цим щось зробити? Як враховувати невизначеність при плануванні проекту?
Найбільш поширений спосіб: закласти при плануванні якомога більше ризиків і видати оцінку, в яку можна вкластися з максимально можливою вірогідністю. Ця «максимальна можливість» визначається, по-перше. ступенем нахабства менеджера і його готовністю торгуватися з замовником, а по-друге - ступенем занедбаності його параної, що виявляється при обліку ризиків.
Але навіть якщо нам вдасться сторгуватися за оцінки з ймовірністю 0.9, це не зменшить напруженості в проекті. По перше. кожен десятий термін все одно буде зірваний (і це обов'язково буде найважливіша і відповідальна задача). По-друге. в чотирьох випадках з десяти виявиться, що ви завищили оцінку мінімум удвічі (знову подивіться на графік: оцінка з ймовірністю 0.9 в два рази перевищує оцінку з ймовірністю 0.5). І тоді на вас посиплються звинувачення в перестрахування, а на вашу команду - в ухиляння від роботи.
Набагато краще спосіб, що дозволяє боротися з невизначеністю її ж зброєю - теорією ймовірності. Існує безліч імовірнісних методів оцінки, з яких найбільш відомим (по числу згадок в підручниках) є метод PERT. а найбільш надійним (по моєму особистому досвіду) - практика Planning Poker. Хоча прихильники Agile, швидше за все, не замислюються про імовірнісних механізмах, закладених в цей метод, а просто беруть і роблять.
Planning Poker дає напрочуд точні оцінки. Фактично з його допомогою ми враховуємо в черговий оцінці колективний досвід вирішення всіх попередніх завдань і основні ризики. Але успішно застосовувати його може тільки добре злагоджена команда досвідчених розробників (читай: Agile-команда).
Радикальний спосіб вирішення проблеми пропонує теорія обмежень. Метод критичної ланцюга передбачає повну відмову від оцінок з високою ймовірністю. Замість цього пропонується давати оцінки окремих завдань з ймовірністю приблизно 0.5, закладаючи загальний часовий резерв на весь проект.
Але це спосіб дійсно радикальний. Щоб він спрацював, потрібно змінити загальну проектну культуру організації.
Зробіть паузу. Прочитайте ще раз, повільно, вдумуючись в сенс: потрібно змінити загальну проектну культуру організації.
Спробуйте прикинути, скільки людей у вашій компанії будують свою роботу навколо моделі «точних оцінок». Відділ QA планує тестування, виходячи з передбачуваних термінів завершення ітерацій розробки. Відділ продажів включає ці оцінки в договір з клієнтом, але в договорі це називається вже не «оцінками», а «термінами поставки». Відділ маркетингу анонсує дату випуску чергової версії «вбивці конкурентів» у своєму прес-релізі. І під усім цим підписується Самий Головний Бос.
А тепер уявіть, що ви говорите всім цим людям: «Із завтрашнього дня ми даємо всі оцінки з ймовірністю 0.5».
Ні, так вони не зрозуміють. Ви говорите ось так: «З завтрашнього дня ми будемо виконувати тільки половину своїх обіцянок щодо термінів».
Те, що ви почуєте у відповідь, і буде квінтесенцією проектної культури вашої організації.