Як дати адекватну оцінку часу, коли невизначеність б'є по голові

Більшість людей не вміють адекватно оцінювати терміни виконання завдань. Ой як це часом змушує понервувати… Тут і «дедлайн підкрадається непомітно». І перестраховка в 500% на всяк випадок (все одно не вистачає). І віджимання «свідомо роздутих термінів», щоб виконавець пообіцяв чогось прийнятного. І невиразні бурмотіння замість конкретних цифр.
image

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

найненависніший питання
Виступаючи на десятки конференцій, я часто питав людей залі: «На яке питання ви найбільше не любите відповідати?». І завжди відповіддю було: «Коли буде готове?!». Питання хвилює і викликає емоції. Ось прямо зараз підійдіть до вашому колезі і запитайте його, коли буде готово. Знаєте, що ви швидше за все почуєте?

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

Розумієте? На питання «Коли?»   відповідають розповіддю про проблеми! Так робить майже все людство.

Ще приклад — для тих, хто пам'ятає університетський курс програмування. Який тип даних повинна повернути програма запит «Коли?». DataTime або щось типу того. Людина на це стабільно викидає Exception. Так не один, а багато, бажано з General Protection Fault. Це реально баг в прошивці практично всіх людей!

Що за гидота така? Чому люди так сильно не люблять оцінювати терміни? Адже все просто:

image

Невизначеність б'є по макітрі
Коренева причина в те, що, оцінюючи обсяг робіт, ми стикаємося з невизначеністю.

Ми змушені передбачати майбутнє   будувати прогноз і нести за нього відповідальність. Начальники і клієнти вимагають цього від нас, а    від своїх підлеглих.

Але прогнози потрібні нам як опора. Як спроба відгородитися від невизначеності. Як спроба задовольнити головне бажання. І я не про секс, голод і сон, а про бажання керувати реальністю. Кожен день. О, як велике цей момент спокуса спихнути контакт з невизначеністю на іншого…

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

З давнину такими моделями були ворожіння: кидання костей, ворожіння по нутрощах тварин, тіні і інша містична радість. На ворожіннях засновані світові релігії. Але   на я б хотів засновувати свої бізнес-процеси.

Судячи з всьому, навіть Бог підкоряється принципу невизначеності, і не може одночасно знати положення і швидкість частинки.
Стівен Хокінг

Це питання філософське, технічного рішення не 
Повернемося до формулі. Вона, в принципі, вірна.

image

Капость у те, що ні чисельник, ні знаменник цього дробу не відомі. Хоча б тому, що:
  • Підпис замовника (кров'ю) під технічним завданням не гарантує, що документ описує саме той обсяг робіт, який реально потрібен. Вона навіть не гарантує, що замовник читав ТЗ. Реальний обсяг робіт ви дізнаєтеся тільки після приймання проекту.
  • Будь-яка постановка задачі гарантовано містять «дірки», які можна трактувати двояко. Чим товще постановка   тим більше таких місць.
  • Продуктивність людей (особливо програмістів) може відрізнятися в РАЗИ і залежить від настільки великого числа факторів, що врахувати вплив всіх просто неможливо.
Всі відомі мені математичні моделі, що намагаються відповісти на питання «ДОКИ?», побудовані на серйозних спрощень. Застосовувати їх на практиці можна лише для демонстрації неспроможності цих моделей і марності буття.

З певною часткою ймовірності можна спрогнозувати дату завершення завдання або проекту, якщо:
  •  вас стабільна, сработавшаяся команда виконавців;
  • роботи виконуються для одного і  ж клієнта, який дає стабільну зворотний зв'язок (читай   генерує прогнозована кількість «правочек») і демонструє стабільні вимоги до якості;
  • команда вже працювала з подібними завданнями;
  • робочий процес, технологічний стек і навколишнє середовище   незмінні;
  • сам проект вкладається в головах команди;
  • влаштовує оцінка відносних, а не в абсолютних величинах (ніяких тобі рублів і годин!);
  • вже є досвід роботи у таких же умовах і дані, отримані в попередніх ітераціях; або клієнт готовий працювати ітеративне і отримувати прогнози, виходячи з реальних вимірів продуктивності попередніх етапів.
Найгірше справи йдуть у сэйлов, які змушені робити вигляд, що всі ці умови виконані (хоча як раз навпаки). Але  спробуємо перейнятися цією галюцинацією. У цьому разі можна припустити, що ймовірність завершення завдання до певного терміну відповідає нормальному розподілу Гауса.

Про дзвін Гаусса щось чули навіть гуманітарії. Це розподіл часто зустрічається в природі. Поняття «нормальний ріст», «нормальна вага» і «нормальна людина» — це як з області Гауссівської нормальності. Дзвін Гаусса намагаються прив'язати скрізь, де можна і не можна, якщо мова йде про ніж-то без впливу величезного числа випадкових завад.

Отже, якщо виникає питання: «Яка там ймовірність вкластися в оцінку?»   можна відповісти — «Нормальна»   і показати цей графік.
image
Посередині дзвони   найбільш імовірна трудомісткість. Але оскільки ми працюємо з величинами, схильним випадковостям   нам потрібно робити допуск на величину розсіювання значень випадкових величин (по-розумному   середньоквадратичне відхилення або σ). Проблема в те, що якщо ми беремо діапазон ± 1σ   ймовірність, що ми вкладемося в наш інтервал оцінки, всього 68%. У залишилася третини випадків нас звинуватять у некомпетентність і поставлять в кут.

На величину 2σ   ймовірність буде 95%, але сам інтервал вийде до непристойності великий. Тут вже ваш замовник скаже: «Фу-фу, ви не можете мені сказати точні оцінки, а конкуренти сказали. Ви   упирі. До побачення». П'ять відсотків   так мало, якщо у вас багато завдань, і за зрив термінів щодо кожній з них болісно б'ють.

3σ   99.7% ймовірності попадання в потрібний нам інтервал. Якщо клієнт запитує «До якого терміну ви гарантовано закінчите проект»   відповідь буде НІКОЛИ математично правильний. Навіть у цих синтетичних умовах математика проти вас.

Торги і маніпуляції
До жаль, для оцінки завдань гаусівських розподілу розподіл використовувати некоректно. Якщо компанія акуратно збирала дані по прогнозами і реальних термінів, швидше за все, графік розподілу ймовірностей буде виглядати приблизно так:
image
Це більше схоже на розподіл Пуассона (схоже, так не воно). Від нормального розподілу Гаусса відрізняється тим, що спочатку якийсь час має значення 0, потім починає зростати (в цій точці оцінки дають оптимісти), швидко доходить до піка (це точка, в якій дають оцінки реалісти) і має довгий хвіст праворуч (там сидять всі факапи і спрацювали ризики).

Такий розподіл ймовірностей природно, т. к. зробити завдання на годину раніше реалістичного терміну складніше, ніж затягнути на тиждень. Робота займає стільки часу, скільки на неї відвели   закон Паркінсона. Тому раніше все одно не вийде.

А оптимісти не вкладаються в терміни практично завжди.

Для нас важливо мати можливість давати вилки на проекти з розкидом від реалістичної оцінки до найбільш вірогідною, наприклад, 80%. А клієнтові може бути цікава саме оптимістична оцінка. Але назвати її одну ви не можете, тому що не знаєте, які ризики можуть спрацювати з цією людиною. Тому повідомляєте вилку.

Клієнт може відреагувати на неї вкрай різко (особливо якщо він   колишній програміст). Йому не зрозуміло, чому з'явилася вилка   завдання адже відома! Сказати клієнту в лоб, що «Вилка з'явилася тому, що ми не знаємо, наскільки ти адекватний»   конфліктний варіант. Простіше пояснити, що вилка потрібна для підстраховки.

Більш веселі математичні моделі (PERT-аналіз, логнормальний або стійке розподіл) годяться тільки для вишуканих понтів на конференціях. Але не особливо допомагають при спілкуванні з клієнтом, який просить «не вантажити цієї фігньою, а чітко сказати, скільки коштує і коли буде готове».

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

Адекватна модель
Під адекватною моделлю я розумію таку, яка дає прийнятну для практичної діяльності точність.

Я вважаю, що потрібно привчити людей жити з невизначеністю. Так, математика і буття сильно проти нас. Але потрібно змушувати себе давати оцінки з доброю часткою ймовірності (скажімо, 80% або 90% залежно від сфери), що залишилися ризики брати на себе. У у разі, якщо вони виникли   вибачитися перед клієнтом), усміхатися і зам'яти конфлікт або зробити профакапленное за свій рахунок (не йдучи в негативну прибуток).

Про буфери, підстраховку і закон Мерфі
Клієнта треба привчити до вилок і до що них закладена підстраховка. Це не обман, а реальність. Ми можемо бути впевненими лише в одному: тут працює закон Мерфі. Якщо він часто б'є, буфери повинні бути більше. Перевірити частоту Мерфі можна ітеративне.

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

Якщо буфер з'їдений на третина, а робота ще не готова — це привід почати експедирування і проштовхування. У сфері веб-розробки ми використовуємо burndown chart, щоб візуалізувати витрата.

Експедирування і проштовхування при налагоджених процесах повинні займати не  5% всієї роботи. Якщо менше   у вас є запас потужностей. Якщо більше   у вас проблема.

На складних проектних ланцюжках найбільший контроль повинен бути на виявленні пляшкового горлечка проекту і контролі його живлять буферів.

Принципи адекватой оцінки
Є лише ДВА способи робити оцінки:
  1. спираючись на свою картину світу в минулого (свій досвід і історичні дані);
  2. продовжуючи свою картину світу в майбутнє (експертні оцінки і інтуїція).
На початковому етапі, коли людина ще не привчений давати точні оцінки, йому треба розповісти, навіщо вони потрібні. І не бити, якщо щось піде не так — це шкідливо, оскільки будуть презакладывать, а потім спрацює закон Паркінсона, потім закон Мерфі і тенденція факапить і затягувати буде прогресувати. Але бити, якщо виконавець не проэскалировал при виникненні проблеми.

Завдання керівника   привчити оцінювати свою роботу. Не просто давати завдання і дивитися, як людина з криками «Бляха-муха!» біжить її робити. А переконатися, що потрібний обсяг робіт проаналізовано.

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

Опора на минуле має ряд недоліків, які впливають на точність оцінки.
  1. Людина, що робить повторно одну і ту ж (або дуже схожу) операцію, починає робити її швидше. З майстерністю зростає швидкість. Тому не можна сказати, що одна і та ж завдання у одного і  ж людини займе однаковий час.

    До  ми не в Японії і не в Німеччині. Ми   Росії. А для нас характерно творче ставлення до всьому. У тому числі до регламентам і правилами. Іноді це добре, але сильно шкодить на конвеєрному виробництві.

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

    Немає нічого страшного, якщо це контрольовано: ми розуміємо, що завдання носить експериментальний характер і закладаємо час на експеримент (а не раптом дізнаємося, що замість чіткої і налагодженої роботи співробітник чисто-по-приколу почав експериментувати і упоролся).
    image
  2. Ми схильні забувати деталі, нюанси і дрібниці тих операцій, які виконуємо рідко. А це означає, що наші оцінки, засновані тільки на минулого досвід виконання завдання, практично завжди будуть занадто оптимістичними.
  3.  противагу забудькуватості в дрібницях ми добре пам'ятаємо, якщо раніше боляче отримали за перевищення строків на схожою задачі. І, якщо у нас не гурток садомазо, повторень не хочемо. І починаємо перестраховуватися.

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

Продовження картини світу в майбутнє
Отже, одного досліду для оцінки недостатньо. Два інших способи   експертні оцінки і інтуїція.

Найкраще, що ми повинні виконати   уявити, як саме ми будемо реалізовувати завдання. Чим детальніше уявімо, тим точніше будуть прогнози. Тут важливо говорити правду самому собі: якщо в уявному експерименті з ходу роботи з'явилися технологічні нестиковки — вони гарантовано виллються в додатковий час.

Картина світу може бути неадекватною   процесі роботи ми стикаємося з несподіванками. Там, де ми не хочемо розбиратися в дрібницях і вникати в деталі, ми хочемо просто закинути багато підстраховки. У програмістів є формула «Оціни, а потім помнож або на π (3,14...), або на e (2,71...). Немаленькі множники, так і розкид великий. Але в підсумку факапим навіть з ними. Вся справа в неуважність до дрібниць, лінь розбиратися або відсутності адекватних ресурсів на вивчення нюансів.

Так, оцінка вимагає ресурсів, іноді   серйозних. Якщо завдання нове, процес оцінки повинен бути розбитий на стадії.
  1. Постановка задачі, аналіз і попередня оцінка (оцінюється термін отримання термінів).
  2. Фаза ресерча.
  3. Уточнена оцінка, початок роботи, фіксація оцінки (саме після ресерча і невеликого шматка реальної роботи).
  4. Виконання завдання. Подальша зміна оцінки можливе тільки як форс-мажор або косяк, і має відбуватися за принципом «уперся   розкажи». У тривалих завданнях   узгоджені контрольні точки.
image
Чим ми уважніше до дрібниць   тим точніше наші прогнози. До жаль, вчити когось бути уважним до дрібниць важко і довго. Але треба, нехай навіть через опір. Якщо зовсім ніяк   тоді розлучатися.

Секретні методики світу IT
У IT все сильно заморочені щодо точності оцінок, строків і ресурсів. У інших галузях такий педантичності не спостерігається. У IT-шників це зведено в культ. Втім, як і робота з фактично витраченому часу і фокуси з множенням на e і на π.

Різноманіття методів говорить тільки про те, що IT-шники багато думали, як вирішити проблему. Нижче   пара технік, які допомагають людям втягнутися в оцінки.

Абсолютні і відносні оцінки
Людині складно оцінювати абсолютні величини. А з відносним проблем менше.

Який розмір у Юпітера? Руками не показати, словами не описати   цифри занадто великі для розуміння маленьким земним мозком.

А тепер скажіть, який розмір у Юпітера порівняно з Землею, використовуючи аналогії. Тут вже простіше: Земля розміром з горошину, а Юпітер   кавун. Земля носить маєчку розміру S, а Юпітер   XXXL.
image
Мозок краще сприймає відносні величини   використовувати це в оцінці завдань. Одну велику розбийте на десяток поменше і дайте оцінку кожної окремо. Порівнюйте підзадачі між собою: яка носить футболку XS, а яка L? Футболки навіть не обов'язково переводити в годинник   вже зрозумієте приблизний обсяг робіт.

У IT при правильно вихованих замовників допустимо робити оцінки завдань не в абсолютних, а в відносних величинах. Нові завдання оцінюються відносно простий і всім відомою. Крім того, оцінка відносних величинах дозволяє компенсувати природні похибки в самих оцінках і в формулюваннях завдань (т. к. на проекті кількість кострубатих завдань і кривих оцінок буде приблизно однаковим від етапу до етапу).

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

Planning Poker
Якщо маєчки і інші порівняння вам не підходять, переходьте на Planning Poker. Це спосіб ігровій манері витягнути з виконавців все дрібниці процесу і можливі проблеми. І в підсумку отримати оцінку завдання, близьку до реальності. У колоді покеру   картки з цифрами (оце так поворот!), які позначають години: ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.

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

Якщо цифри однакові або трохи розрізняються   записуйте в план загальна арифметичне. Якщо є значна різниця   зверніться відзначилися, чому вони оцінили завдання так. Хтось не врахував тривалу доставку деталей з іншого міста? Або забув про інноваційне ПО, яке встановили на минулого тижня? Спливуть нові подробиці, і оцінка стане точніше.
image
Не тисніть, щоб у терміни, які ви отримали покері, все було зроблено   закон Мерфі ніхто не відміняв. На цей випадок менеджер повинен закладати підстраховку.

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

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

Декомпозиції потрібно навчати. Якщо розглядати на прикладі IT   приблизно так.
Спочатку береться готовий проект, який знається на складові   щоб людина, який повинен дати оцінку, зрозумів, у чому суть і від нього хочуть.
Поступово завдання ускладнюється: для декомпозиції дається проект, в якому є тільки прототип. Потім   стандартне технічне завдання, потім   погане і складне ТЗ.

Людина повинна навчитися готовий цілісний проект або ТЗ ділити на етапи і складові. І кожному давати оцінку. Коли навчиться — його оцінки стануть адекватними, наближеними до ідеальному відсотком ймовірності та без непояснених буферів.

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

Якщо ці скіли вже є, далі виховуйте його схемою:
  1. Покажіть математичні моделі розподілів і поясніть, що злитися з оцінок не вийде.
  2. Розкажіть, що розуміється під адекватною оцінкою, як вона буде використовуватися і чому вам потрібна саме вона. Розкажіть, що вам потрібна оцінка без перезаставлених в 100500 раз подстраховок.
  3. Покажіть, як будується планування потоку робіт всієї компанії на на основі цієї оцінки або як її буде використовувати ваш клієнт. Не тримати людей за ідіотів — якщо їм розповісти правду і реальні потреби, більшість з них будуть намагатися робити найбільш точні прогнози.
  4. Привчіть до принципами «уперся   повідом» і «будь-яка задача повинна бути проаналізована і оцінена».
  5. Змусьте оцінювати людей всі свої завдання самостійно.
  6. Дайте вивчити статистику організації (кошторису і реальні витрати по проектам).
  7. Привчіть до принципом «не знаєш, що робити   декомпозируй». Дайте кілька проектів на декомпозицію. Перевіряйте і шукайте дірки і нестиковки. Довго і нудно розмовляйте по приводу знайдених нестиковок.
  8. Дайте оцінювати реальні ТЗ. Проходитесь підсумковій оцінці рядок за рядком, питайте, як прийшов до нею. Перевіряйте на повноту і несуперечність. Показуйте дірки в оцінках, куди може відлітати час.
У нашої галузі можна навчити людину робити хороші оцінки за пару тижнів. Для тренування потрібно використовувати типові об'єкти і давати постійний зворотний зв'язок. При такій роботі зона, де людина зможе робити прогнози, буде постійно розширюватися.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.