В ІТ існує декілька непорозумінь з оцінками, а ця публікація покликана їх вирішити.

Проєкти – не проєкти

Про це я вже писав у публікації Ваші проєкти – лайно. Більшість проєктів не проєкти, в них відсутній фіксований об’єм робіт, строки, бюджет та заздалегідь виділені людські ресурси. В умовах нескінченного об’єму робіт та відсутності строків зникає будь-яка необхідність в оцінці задач, оскільки така оцінка не допоже з’ясувати, чи буде проєкт (який саме об’єм робіт?!) завершено у строк (який?!) та чи вкладеться розробка у запланований бюджет (який?!).

Деякі менеджери проєктів виправдовуються тим, що заміряють velocity команд та окремо узятих членів команд. Це все дурня, оскільки ефективність роботи команд та окремих їх членів і так зрозумілі із спілкування з ними і просто закритих задач. Нас цікавлять найкращі виконавці, аби їх винагородити та найгірші, аби від них позбутися. Все це і так зрозуміло, без жодних оцінок.

Чи варто нагадувати, що за PMBOK проєкт оцінюється на першій стадії – ініціації для визначення строків його виконання, бюджету та інших ресурсів? На практиці багато хто працює за Scrum, або чимось подібним над ефемерними проєктами та оцінюють задачі які можна взяти у наступну ітерацію.

ІТшка має зафіксувати, що працює зазвичай над продуктами, а не над проєктами, бо використання терміну проєкт у більшості випадків вводить в оману.

Відсутність нормативів

Я вже писав про те, що ІТшечка може багато чому повчитися у більш сталих індустрій в публікації DevOops або чому *баних АйТівців може навчити гірничий інженер. На гірничих підприємствах існують нормативи, наприклад, яку сумарну довжину свердловин по яким гірським породом можна набурити тим чи іншим перфоратором. Вони були створені емпіричним шляхом, через заміри геологами параметрів порід та через вимірювання часу на буріння по ним нормувальником. В таблицях норм враховані всі ключові параметри, що впливають на продуктивність тих чи інших операцій.

В ІТ багато що відрізняється від гірничого підприємства. Наприклад, відсутні однакові задачі, чітке розуміння факторів, а від так і будь-які нормативи. Через це якісні оцінки задач та планування з їх використанням неможливі. На багатьох “проєктах”, де я працював, менеджери проєктів просто множили оцінку, яку давали розробники на два чи навіть три і все одно могли сильно помилитися.

Крім того, робота використовує усі наявні ресурси. Якщо задача була оцінена у тиждень роботи, але насправді може бути виконана за чотири години, то на неї все одно буде витрачено тиждень. Навіщо працювати більше, якщо винагороду отримаємо ту саму?

Anti-Agile

Концепція проєктів по своїй суті є anti-agile. Зараз модно бути прикидатися agile і тому усі намагаються поєднати непоєднуване. Що варто нарешті зрозуміти, то це те, що Agile – це великий обман побудований навколо дуже простого маніфесту, метою якого було правильно розставити пріоритети в розробці програмного забезпечення.

Agile Manifesto не суперечить Waterfall чи концепції проєктів, а от культ Agile протиречить та створює багато непорозумінь. Особливо це стосується методологій, які хибно називаються Agile-методологіями, наприклад Scrum.

Джеф Сазерленд – автор методології Scrum та один із підписантів Manifesto of Agile Software Development у своїй книзі про Scrum розповідає, що методології побудована на основі реформ військових юнітів, які були організовані у самодостатні кросс-функціональні команди, що постійно узгоджували свої дії. Також він приводив приклад того, як Scrum може бути застосовано у будівництві чи ремонті будинку. Усе це має не так багато спільного з розробкою програмного забезпечення.

Також Джеф Сазерленд пропонує оцінювати задачі у розмірах собак. Він усвідомлює, що задачі важко оцінити у необхідному на них часі, але їх можна оцінити порівнюючи між собою, як наприклад, порівнюючи розміри представників різних пород собак. Ця задача – пекінес, ця – вівчарка, а ось ця – кане корсо. Навіщо це стейкхолдерам/замовникам? Їм це не потрібно! Це потрібно менеджерам “проєктів” аби оцінювати velocity (по-суті throughput – пропускну здатність) команд. Навіщо?! Аби можна було оцінити, чи команда рухається швидше, чи повільніше у розмірах собак. Що це нам дає в умовах того, що розробники можуть почати називати пекінесів вівчарками?

НІЧОГО!!!!!!1

Виходить так, що культ Agile – це найбільша Anti-Agile штука, яка проковтнула Agile та висрала купу методологій, що йдуть проти Agile. Їх основна мета – бути проданими, а не вирішити якісь реальні проблеми. Реальні проблеми вирішують тільки інженери, а методології мають бути лише документуванням послідовності та аргументації їх дій для подальшого аналізу та обміну досвідом.

Як необхідно проводити оцінювання?

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

По-друге, не варто вигадувати штучних обмежень. Якщо якась функціональність має бути реалізована до вступу нового податкового законодавства у дію – це реальне обмеження. Якщо необхідно підготувати інфраструктуру до чорної п’ятниці, коли трафік може зрости у 20 разів – це реальне обмеження. Насправді таких обмежень не так багато і тероризувати розробників через те, що вони ни вкладаються у строки, які назвали – це найгірше чим може займатися менеджер проєкта.

Якщо існує якесь реальне обмеження по часу чи по бюджету – ми маємо одразу прийняти той факт, що не вкладемося у цей час та бюджет, просто базуючись на попередньому досвіті. Ми маємо розпочинати роботу над задачами до того, як вони стають негайними. Якщо до чорної п’ятниці необхідно готовувати два тижні, то необхідно розпочати цю роботу принаймні за два місяці, аби точно вкластися в реальні обмеження. Крім того, необхідні зміни необхідно пріоритизувати. Якщо зміни пріоретизовані, то ми матимемо можливість виконати не всі зміни, а лише критично необхідні і таким чином надати замовникам принаймні основу, найголовніше з того, що їм необхідно. Якщо ми не можемо керувати реальними обмеженнями, такими як час до певної події, що від нас не залежить, чи кількість грошей на рахунку у нашого замовника – ми можемо принаймні керувати об’ємом роботи.