Більшість професіоналів у сфері програмного забезпечення повинні надавати оцінки своєї роботи, але лише небагато з нас є вправними в оцінюванні. Багато з нас не проходили навчання технікам оцінювання. Ми занадто оптимістичні, з короткою пам’яттю, яка маскує болючі перевитрати від попередніх проєктів. Ми не враховуємо запасних буферів для протидії несподіваним подіям або реальним ризикам. Більше того, ми часто не беремо до уваги необхідні аспекти діяльності. Коли ми врешті-решт стикаємося з цими завданнями, ми або виконуємо їх – перевищуючи при цьому наші оцінки, або пропускаємо їх, можливо, ставлячи під загрозу якість процесу.
Є кілька способів стати кращим оцінювачем. Найпростіший – це записувати свої оцінки разом із процесом оцінювання та припущеннями, а потім записати фактичні результати. Порівняння фактичних результатів з оцінками і розуміння відмінностей допоможе вам краще впоратися з цим завданням наступного разу.
На основі методу оцінювання «Delphi», розробленого в Корпорації “Rand”, і вдосконаленого Баррі Бемом, Нілом Поттером і Мері Сакрі, техніка «Wideband Delphi» використовує невелику команду обізнаних людей для анонімного генерування індивідуальних оцінок із опису проблеми, а потім досягає консенсусу шляхом ітерацій.
Метод «Wideband Delphi» має кілька переваг порівняно з отриманням оцінки від однієї особи. По-перше, вона допомагає скласти більш повний список завдань для основних діяльностей. Консенсусний підхід дозволяє уникнути упередженості в оцінках, які надходять від самопроголошених експертів, недосвідчених оцінювачів або впливових осіб з прихованими мотивами або різними цілями. Люди більш прихильні до оцінок, до створення яких вони самі доклали зусиль, ніж до тих, які їм нав’язують інші.
Жоден учасник у процесі оцінки не знає «правильної» відповіді. Створення декількох оцінок шляхом ітерації визнає цю невизначеність і наближає до передбачення реальності.
Метод «Wideband Delphi»
Метод «Wideband Delphi» можна використовувати для оцінки практично будь-чого – часу, необхідного для впровадження підсистеми, кількості ітерацій, необхідних для створення цілого продукту, або галонів фарби, необхідних для перефарбовування вашого будинку.
Метод «Delphi» допомагає розробити детальну структуру декомпозиції робіт (WBS), яка є основою для висхідної оцінки зусиль та термінів. Відправною точкою для сесії «Wideband Delphi» може бути специфікація проблеми, яка оцінюється, або початковий високорівневий список завдань чи графік. Результати включають комплексний перелік завдань; перелік дій, пов’язаних з якістю, процесом та допоміжною діяльністю; припущення щодо оцінки; і набір оцінок, по одній від кожного учасника.
Рис. 1 ілюструє хід процесу методу «Wideband Delphi». Під час планування команда визначає проблему, яку вони оцінюють, і обирає учасників. Початкова сесія збирає всіх оцінювачів, щоб зосередити їх на проблемі. Потім учасники індивідуально готують свої початкові списки завдань і оцінки. Вони приносять ці напрацювання на оціночну зустріч, під час якої за кілька циклів складається багатший список завдань і переглядається набір індивідуальних оцінок. Потім модератор або керівник проєкту збирає докупи інформацію, а команда переглядає результати. Отриманий в результаті діапазон оцінок має бути більш реалістичним, ніж будь-яка окрема оцінка. Давайте розглянемо кожен з цих етапів процесу.
Рис. 1. Етапи процесу за методом «Wideband Delphi».
Планування
Першим кроком сеансу «Wideband Delphi» є визначення та масштабування проблеми. Ви можете розбити складну проблему на менші частини, які можна оцінити більш точно, можливо, різними командами. Ініціатор оцінювання формулює постановку проблеми, яка надасть учасникам достатньо інформації для достовірних і обґрунтованих оцінок.
До складу учасників оцінювання входять модератор, який планує та координує діяльність, керівник проєкту та два-чотири інші оцінювачі. Модератор має бути достатньо поінформованим, щоб брати участь в оцінюванні, але також виступати в ролі неупередженого фасилітатора, який не буде спотворювати результати власними упередженнями чи уявленнями. Відбирайте учасників, які розуміють проблему або проєкт і пов’язані з ним питання оцінки.
Kick–off сесія
Початкова kick-off сесія допомагає всім учасникам розібратися з проблемою оцінювання. Модератор пояснює суть методу «Wideband Delphi» членам команди, які не знайомі з ним та надає всім учасникам постановку проблеми та будь-які припущення або обмеження проєкту. Мета полягає в тому, щоб надати оцінювачам достатньо інформації для якісної роботи без надмірного впливу на їхні оцінки.
Під час стартової сесії команда переглядає цілі оцінювання та обговорює проблему і будь-які питання, пов’язані з оцінюванням. Учасники домовляються про одиниці оцінки, які вони будуть використовувати, наприклад, тижні, сторі пойнти, робочі години або долари. Коли модератор дійде висновку, що всі знають достатньо, щоб зробити свій внесок, група готова до роботи. Перш ніж продовжити, переконайтесь, чи ви виконали всі передумови:
- Відібрано відповідних учасників.
- Учасники погоджуються з метою оцінки та одиницями виміру.
- Керівник проєкту може брати участь у сесії.
- Оцінювачі мають необхідну інформацію для ефективної роботи.
Індивідуальна підготовка
Уявімо, що ви хочете оцінити загальну кількість робочих годин, необхідних для завершення певного проєкту. Процес оцінки починається з того, що кожен учасник самостійно розробляє початковий перелік завдань, необхідних для досягнення поставленої мети проєкту. Для цього можна використати форму, подібну до тієї, що зображена на рис. 2. Потім кожен учасник оцінює кількість годин, необхідних для виконання кожного завдання. Розбийте кожну діяльність на завдання, які є достатньо малими, щоб їх можна було точно оцінити, можливо, в діапазоні від 10 до 20 робочих годин на кожне. Чітко формулюйте завдання, тому що комусь доведеться об’єднати списки завдань усіх учасників в один загальний список. Кожен учасник підсумовує свої оцінки для кожного завдання проєкту в домовлених одиницях, щоб сформувати свою початкову загальну оцінку.
Рис. 2. Приклад форми оцінки за методом «Wideband Delphi».
Одна з моїх головних порад щодо безпечного оцінювання полягає в тому, що ваша оцінка не повинна бути пов’язана з відповіддю, яку, на вашу думку, хоче почути керівник проєкту або інші ключові зацікавлені сторони. Оцінка може вийти за прийнятні межі графіка, зусиль або вартості. Якщо так, то це вимагає переговорів, які можуть призвести до скорочення обсягу робіт, подовження термінів або коригування ресурсів. Тим не менш, не дозволяйте зовнішньому тиску або очікуванням вплинути на ваше найкраще бачення того, як буде виконуватись робота.
Окрім визначення завдань проєкту, окремо записуйте будь-які завдання, пов’язані з супутніми або підтримуючими діяльностями. Під час початкового циклу на моїй першій сесії «Wideband Delphi» всі учасники пропустили завдання, пов’язані з контролем якості та забезпеченням якості, управлінням конфігурацією та процесними діяльностями. Ми швидко виявили це та додали їх до наступної ітерації. Обов’язково включіть завдання з доопрацювання після тестування або перегляду.
Якщо ви оцінюєте графік, врахуйте будь-які допоміжні завдання, які не є специфічними для проєкту, і які, можливо, доведеться врахувати при плануванні графіка. До них відносяться зустрічі, відпустки, навчання, інші проєктні завдання та безліч інших речей, які забирають час з вашого дня.
Радикально різні припущення можуть призвести до великих відмінностей в оцінках, тому записуйте всі припущення, які ви зробили під час підготовки своїх оцінок. Ви могли припустити, що команда придбає певну бібліотеку компонентів або повторно використає бібліотеку з попереднього проєкту. Інший оцінювач міг припустити, що в рамках проєкту ця бібліотека буде розроблена. Це може призвести до розбіжностей між вашими двома списками завдань і загальними оцінками.
Тримайте в голові наступні рекомендації під час оцінювання:
- Припустіть, що одна людина (ви) буде виконувати всі завдання.
- Припустіть, що всі завдання будуть виконуватися послідовно. Наразі не турбуйтеся про послідовність та попередні завдання.
- Припустіть, що ви можете присвятити безперервні зусилля кожному завданню. Це абсурдно оптимістично, але це спрощує оцінку робочих зусиль, необхідних для виконання завдань.
- Перерахуйте всі відомі вам періоди очікування між завданнями, з якими ви очікуєте зіткнутися. Це допоможе вам перетворити оцінки зусиль в оцінки графіків пізніше.
Оціночна сесія
Модератор розпочинає зустріч з оцінювання, збираючи індивідуальні оцінки учасників і створюючи діаграму, подібну до тієї, що зображена на рис. 3. Ви можете продемонструвати її на дошці для наглядності. Загальний розрахунок проєкту кожного учасника позначається хрестиком на лінії «Раунд 1». У цьому прикладі команда оцінює робочі години; показуйте будь-які одиниці оцінки, які узгодила команда по осі Х. Початкові оцінки, ймовірно, будуть охоплювати страшенно великий діапазон. Тільки уявіть, до яких різних висновків ви могли б дійти, якби попросили лише одного з учасників дати свою оцінку, а потім використали її для планування діяльності!
Рис. 3. Початкова діаграма оцінювання з сесії Wideband Delphi.
Модератор не ідентифікує, хто створив кожну оцінку. Ця анонімність є важливим аспектом методу «Wideband Delphi». Анонімність запобігає тому, щоб впливовий або поважний колега надмірно впливав на оцінки інших учасників.
Кожен оцінювач зачитує свій початковий список завдань, визначаючи будь-які зроблені припущення і порушуючи будь-які питання або проблеми, не розкриваючи свою оцінку. Кожен учасник визначить різні завдання, які необхідно виконати, і не буде думати про інші. Об’єднання індивідуальних списків завдань призводить до більш повного списку, ніж будь-який окремий оцінювач може скласти.
Під час цієї початкової дискусії члени команди також обговорюють свої припущення, проблеми з оцінкою та будь-які питання, що виникають у них щодо проблеми. В результаті команда почне сходитися до спільного набору припущень і спільного списку завдань.
Після цього початкового обговорення всі учасники одночасно (і мовчки) переглядають свої оцінки під час зустрічі. Вони можуть змінювати свої списки завдань на основі обговорення, а також коригувати індивідуальні оцінки завдань відповідно до свого нового розуміння. Сумарна зміна для всіх завдань дорівнює загальній зміні в загальній оцінці цього учасника.
Модератор збирає переглянуті загальні оцінки і наносить їх на той самий графік, на лінію «Раунд 2». Як показано на рис. 4, другий раунд часто призводить до вужчого розподілу оцінок, зосереджених на вищому середньому значенні, ніж середнє значення оцінок з першого раунду. Додаткові раунди повинні ще більше звузити цей розподіл. Цикл оновлення списку завдань, обговорення проблем та припущень та переоцінки триває доти, доки:
- Ви завершили чотири раунди,
- Оцінки збігаються до прийнятого вузького діапазону (визначеного заздалегідь),
- Вичерпано час, відведений на зустріч для оцінювання (зазвичай дві години), або
- Всі учасники хочуть залишити свої останні оцінки.
Рис. 4. Діаграма оцінювання, яка демонструє три раунди з сесії «Wideband Delphi».
Модератор стежить за тим, щоб група не відставала від плану, обмежуючи час обговорення кожного циклу до 15 або 20 хвилин, щоб уникнути нескінченної балаканини. Модератор повинен дотримуватися ефективних практик фасилітації зустрічей, таких як вчасний початок і завершення зустрічі, залучення всіх учасників до співпраці, а також підтримання нейтральної та неупередженої атмосфери.
Збереження анонімності індивідуальних оцінок є важливим для перших кількох раундів. Однак, у певний момент члени команди можуть погодитися викласти всі карти на стіл і дійти висновку шляхом відкритої дискусії. Це дає їм можливість обговорити завдання, для яких їхні оцінки суттєво відрізняються. В іншому випадку модератор не повинен вказувати, хто дав ту чи іншу оцінку, до завершення сесії.
Збирання завдань
Після оціночної зустрічі модератор або керівник проєкту збирає завдання та їхні індивідуальні оцінки в єдиний список завдань. Ця особа також об’єднує окремі списки припущень, активностей, пов’язаних з якістю та процесом, допоміжними завданнями і часом очікування.
Об’єднання передбачає видалення дублікатів завдань та досягнення певного розумного вирішення розбіжностей в оцінках окремих завдань. Великі розбіжності в оцінках для, здавалося б, схожих завдань можуть свідчити про те, що оцінювачі по-різному інтерпретували це завдання.
Наприклад, двоє людей можуть мати завдання під назвою «реалізувати модуль X». Однак, один оцінювач міг включити в завдання юніт тестування та рев’ю, тоді як інший розглядав лише написання коду. Всі оцінювачі мають чітко формулювати свої завдання, щоб мінімізувати плутанину під час етапу об’єднання. На етапі об’єднання повинен зберігатися діапазон оцінок для кожного завдання, але якщо оцінка завдання одним оцінювачем сильно відрізняється від оцінок інших оцінювачів, спочатку зрозумійте її, а потім, можливо, відхиліть або змініть її.
Огляд результатів
На останньому кроці команда з оцінювання переглядає підбиті підсумки та узгоджує їх. На цьому оціночна діяльність завершується. Мета полягає в тому, щоб отримати діапазон оцінок, який дозволить керівнику проєкту та іншим ключовим зацікавленим сторонам продовжити планування і виконання проєкту з достатнім рівнем впевненності. Фінальне рев’ю також дозволяє команді обміркувати поточний процес оцінювання та запропонувати поліпшення на майбутнє.
Завершення оцінювання
Тепер ви повинні вирішити, що робити з даними. Ви можете просто усереднити фінальні оцінки, щоб отримати єдину оцінку, яку, ймовірно, хоче почути той, хто просив про оцінку. Однак, є сенс зберігати діапазон оцінок. Оцінки – це передбачення майбутнього; діапазон відображає невизначеність, притаманну загляданню в кришталеву кулю.
Ви можете подати оцінку у вигляді набору з трьох чисел:
- Середнє значення оцінок як найбільш ймовірний результат
- Мінімальне значення як найкращий результат (ймовірність успіху – близько 10 відсотків)
- Максимальне значення як найгірший випадок (90-відсоткова ймовірність успіху)
Або ж ви можете представити середнє значення як номінальний очікуваний результат, плюс значення максимуму мінус середнє значення, і мінус середнє значення мінус мінімальне значення. Це дає діапазон ймовірних результатів, який є більш реалістичним, ніж будь-який одноточковий прогноз.
Незважаючи на те, що результати сесії «Wideband Delphi» можуть не відповідати очікуванням ключових стейкхолдерів, вони можуть вирішити, чи хочуть вони планувати свій проєкт з 10-відсотковим рівнем впевненності, 90-відсотковим рівнем впевненності або десь посередині між ними. Порівняння фактичних результатів (коли ви їх отримаєте) з оцінками є життєво важливим для поліпшення точності майбутніх оцінок команди.
«Wideband Delphi» висновки
Не існує досконалого методу оцінювання. Однак, «Wideband Delphi» включає в себе деякі надійні принципи оцінювання. Командний підхід визнає цінність поєднання різних точок зору експертів. Діапазон отриманих оцінок відображає внутрішню невизначеність будь-якого процесу оцінювання.
Хоч це і потребує часу, «Wideband Delphi» усуває частину впливу на оцінку і відфільтровує надмірні – і, як правило, вкрай нереалістичні – початкові значення. Цей підхід ілюструє мою філософію найкращої відповіді на будь-який запит щодо оцінки: “Дозвольте мені повернутись до вас з цим пізніше”.
Оригінальна стаття – Turn guesses into estimates with Wideband Delphi, переклад – Юлія Підгайна, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Оригінальне фото з статті автора.