Чому команди прохлопують свої естимейти
Я Оля Чмир, уже другий рік одна з проджект-менеджерів у компанії SPD-Ukraine на проекті PitchBook. У проекті тепер залучено 200 спеціалістів. На постійній основі я працюю з трьома різними командами, але, залежно від релізу, також маю можливість співпрацювати з іншими командами.
Проте так було не завжди. До PitchBook я працювала в стартапі E-learning, де керувала командою... відеопродакшну. І менеджером хоч би якої команди я була, проблему невідповідності естимейтів фактично витраченому часу я спостерігаю котрий рік поспіль. Як наслідок — виснаження, демотивація та інші неприємності, з якими доводиться немало працювати.
Хоч би ким ви були — розробниками, тестувальниками, менеджерами, зацікавленими в темі оцінки часу, — прошу до прочитання. Якщо ж у вас немає проблем і ваші команди ідеально визначають час, потрібний на виконання завдань, напишіть мені й поділіться своїм досвідом.
Що ж, пригадаймо той момент, коли проджект-менеджер приходить до команди й починає просити оцінити час, потрібний на виконання завдання чи навіть цілого проекту. І перше, що бачить в очах розробника, — сум та пригнічення. І не дарма. Протягом багатьох десятиліть чимало команд, які не могли об’єктивно оцінити потрібний їм час, і менеджери, які потім притягали команду до відповідальності за їхніми оцінками, неправильно використовували оцінки. Ще більше розчарування виникає, коли менеджери зважають лише на найнижчу кількість потрібних годин, почуту від розробників! Але погодьтеся: розробка не магія! І не дивно, що хештег #NoEstimates так прославився.
Давати точні оцінки складно, потрапити в них ще складніше.
Оцінки ніколи не досконалі. Але мета кожної спроби оцінювання — забезпечити надійний внесок у «досить хороший» план.
І те, що тема оцінки не втрачає своєї актуальності, підтверджують не лише команди та проджект-менеджери, а й власники бізнесу. Адже тривалість проекту з безумовною якістю — мало не основний у керуванні сподіваннями наших замовників чи партнерів, які, поміж іншим, на основі наших оцінок будують свої бізнес-стратегії та плани. І через значний розрив між сподіваною і фактичною тривалістю проекту можна втратити не лише проект, а й цілу ділову репутацію.
Процес оцінки
Сам процес оцінки часу можна полегшити, керуючись рекомендаціями, які наведено нижче.
Визначення результату виконання завдання
Перш ніж давати оцінку за часом на виконання завдання, зрозумійте якнайліпше, що саме потрібно для його реалізації. Тому обов’язково слід належно його описати. Далі переходимо до деталізації.
Як це працює в нас: ще до створення декомпозиції, а тим паче її оцінки, ми проводимо кілька раундів рев’ю специфікацій, аналізуємо незрозумілі частини описаної бізнес-логіки, шукаємо варіанти досягнення бізнес-цілі та обговорюємо їх з нашими продакт-менеджерами (вони ж — продактоунери). Коли максимум запитань мають відповіді й шлях, за яким буде створено новий функціонал, стає зрозумілим, переходимо до наступного кроку.
Декомпозиція та деталізація
Не можна оцінити завдання без чіткого розуміння, на що власне потрібен час. Трохи про правильну деталізацію:
- Діліть завдання на очевидні підзавдання, доки підзавдання не стануть настільки зрозумілими, що можна буде дати їм прийнятну часову оцінку. Якщо все ще неможливо точно оцінити, скільки часу потребує завдання, діліть далі його на ще дрібніші. Підсумкова оцінка підзавдань у майбутньому становитиме потрібну оцінку всього завдання.
- Не дозволяйте собі захоплюватися надмірним поділом. Багато ділити не дасть користі, радше навпаки — може зашкодити. Така деталізація забирає час на її побудову й подальше підтримання деталізованого плану. А ще вона безглузда в разі недостатньо докладного технічного завдання на момент оцінки.
Найліпші практики індустрії: не опускатися нижче за 4 години завдання. Хоча допускається 2 години або 1 година (потреба в цьому виникає тоді, коли завдання невеликої тривалості).
Як це працює в нас: для оцінки завдання WBD створюється максимально детально, зокрема, щоб на цьому етапі банально не забути додати до оцінки всі потрібні дії (наприклад, інтегруючи з іншими сервісами, під’єднали їхній моніторинг). Усі підзавдання оцінюються окремо, проте естимейт завдання, залогованого в Jira, — це сума оцінок підзавдань і виконується як одне ціле. Логування фактично витраченого часу також сумується.
Така практика значно полегшила процес код-рев’ю та наступних правок коду (ми мали негативний досвід, коли під час перевірки групи завдань потреба внесення правок у код вимагала правок уже готових завдань, а також впливала на завдання пов’язаних модулів), проте ускладнила аналіз фактично витраченого часу на реалізацію підзавдань.
Визначення ризикових підзавдань
Визначте, чи є завдання ризиковим. Воно ризикове, якщо, наприклад, пов’язане з роботою не дуже відомої технології або залежить від зовнішніх чинників. Додайте коефіцієнт на ризик. На те, що «щось піде не за планом», зазвичай відводиться
Якщо занадто багато ризикових завдань або ризик високий настільки, що ви абсолютно не в змозі визначити потрібний час, то відкладіть оцінку й ініціюйте створення окремого завдання типу Investigation, метою якого буде докладніше ознайомити й зрозуміти суть ризикового завдання. Оцініть час і на цю роботу. Після такого дослідження ви зможете точніше оцінити час, потрібний на ризикове завдання.
Як це працює в нас: по-перше, ми використовуємо систему падінгів. Кожне завдання в WBD має свій рахунок — від 0 до 3. Розробник, що створює декомпозицію, оцінює ризиковість завдання за встановленою шкалою. Відповідно до рахунку фінальна оцінка кожного окремого завдання зростає на
По-друге, якщо рахунок становить >3, то ми проводимо Investigation щодо окремо взятих завдань.
Оцінка часу деталізованого завдання, або Коли в гру вступає менеджер
По-перше, оцінюючи завдання, пам’ятайте: розробник ніколи не витрачає всі 8 годин робочого дня безпосередньо на роботу над завданням. Завжди будуть витрати часу на заварити/попити кави-чаю, послухати свіжий анекдот тощо. Потім розробник сідає за комп’ютер і намагається якийсь час згадати, що ж він робив. Його увагу відвертають колеги запитаннями щодо роботи й таке інше... А скільки часу витрачають розробники на мітингах?
Коли ж відбувається оцінка за запитом менеджера, є досить великий шанс дістати час лише на роботу над завданням без урахування всіх цих невиробничих витрат. Як наслідок — ці оцінки будуть використані в підсумковій оцінці. А отже, дістаємо неточну реальну оцінку. Тому розробникам варто уточнювати не лише деталі завдання, а й деталі запиту менеджера — потрібна оцінка в девгодинах, календарних днях тощо. Дізнайтеся, як ваш розробник оцінює ефективну роботу, і координуйте свої оцінки. Не забувайте додавати час на код-рев’ю, на інтеграцію різних частин проекту одна з одною (якщо це потребує більше часу). Пам’ятайте, що інтеграція модуля з іншими модулями або інтеграція підзавдань між собою може в деяких випадках потребувати тимчасових витрат на усунення тих чи інших помилок, непродуманості в реалізації інтегрованих модулів, а також призводить до накопичення технічного боргу.
Як це працює в нас: з моїми командами ми маємо домовленість, що вони оцінюють завдання в девгодинах (тільки під час формування роадмапи, коли все, що ми знаємо про нову функціональність, — кілька речень опису і, ймовірно, проблема, яку хочемо розв’язати, — ми можемо оцінювати в тижнях або навіть місяцях). Кількість ефективних годин для середньостатистичного розробника — 5,5 години на день, для тім/технічного ліда —
Час на код-рев’ю, виявилося, оцінити навіть важче, ніж час на реалізацію завдання. Були ситуації, коли час рев’ю інколи перевищував навіть час реалізації. Проте дослідним способом ми визначили, що на рев’ю витрачається близько 30% часу.
Окрім того, проекти, над якими працюють мої команди, дуже динамічні, і нам не властиві довгострокові проекти (зазвичай тривалість реалізації нового функціоналу —
Цифри та невідомі
Коли ми просимо оцінити завдання, намагайтеся просити не одну, а хоча б дві оцінки — мінімальну та максимальну. Ще ліпше три — мінімальну, максимальну та найімовірнішу. Менеджер не може насправді вплинути на дату доставки продукту, просто бажаючи, щоб команда вкладалася в мінімально можливий час, — хіба що жертвуючи масштабом або якістю проекту.
Невизначеність оцінок пов’язана з невідомими. Що більше невідомих, то менше впевнені ми повинні бути в оцінках. І навпаки, що менше невідомих, то більше впевненими ми повинні почуватися щодо оцінок.
Що це означає? Кожен проект має певний рівень невідомих. Коли розробники дають приблизну оцінку, — скажімо,
По-перше, звертаючись до невідомих, ми підвищуємо впевненість в оцінках.
Є 2 типи невідомих: невідомі невідомі й відомі невідомі. Не так уже й багато можна зробити для невідомих невідомих. За умовчанням, розробники не можуть врахувати їх у своїх оцінках; але вони могли б дати собі ще кілька днів «про всяк випадок», і ці дні зазвичай витрачаються на налагодження та інтеграцію. Щодо відомих невідомих, то, витрачаючи перші години або дні вашого проекту на їх вирішення, можна значно полегшити роботу, зменшивши цю невизначеність. Наприклад, 6 днів +/— 2 дні може стати, наприклад, 6 днів +/— 1 день.
Це саме той етап, де ми детально розбираємо специфікації, збираємо всі запитання, що стосуються невідомих, та якомога більше комунікуємо: із продактоунерами, із суміжними командами та, звичайно, всередині команди. Щоб на момент старту фактичної розробки кожен, хто працює над створенням функціоналу, знав, як працювати над дорученим завданням.
До речі, можна зрозуміти, що технічні завдання — частина можливих відомих невідомих. Що точніші технічні завдання, то менше невизначеності буде. Ставте собі кілька запитань:
- Чи зрозуміла вам специфікація?
- Наскільки покрито негативні кейси?
- Як ми тестуватимемо систему?
- Як поводитиметься система в момент відмови?
- Як ми моніторитимемо систему?
- Чи можливо виконати завдання простішим способом і водночас виконати бізнес-завдання?
- Чи може архітектура масштабуватися до кількості користувачів, яку ми хочемо?
- Які ризики пов’язані з рішенням, яке ми плануємо використати?
Параліч перед оцінкою також легко побороти.
Можливо, це не найліпша практика й дещо маніпулятивний підхід, але це працює та виховує культуру оцінювання. Розробники можуть не дуже цінувати її спочатку, але я думаю, що вона ініціює бесіду.
Особисто я її дуже люблю, хоч і намагаюся не зловживати нею. Отже, одного разу під час мітингу ми почали обговорювати досить велике технічне завдання. Розробник був у приємному передчутті, а я, намагаючись спланувати процес роботи всієї команди, поставила те саме запитання: «Скільки тобі часу потрібно, щоб закінчити це завдання?» Звичайно, побачила нервову посмішку й почула: «Я не можу знати, так ще нічого не зрозуміло». Тоді я почала гру...
Я: Тобі вистачить 3 місяці?
Розробник: Та ні, це занадто!
Я: Як щодо місяця?
Розробник: Хм... Можливо.
Я: А за тиждень?
Розробник: Точно не встигну! Там стільки роботи...
Я: 3 тижні буде досить? Чи 2?
Розробник: За 2 спробую закінчити. Проте 3 тижні має вистачити.
І ось ми вже на початку третього тижня й підходимо до закінчення розробки та підготовки завдання до код-рев’ю ;-)
Оцінка, як і все в проекті, також має свою якість. Ведіть для себе статистику якості часової оцінки за завданнями. Порівняйте реальний час, витрачений на завдання, з даною вам попередньою оцінкою. Визначте коефіцієнт похибки в оцінці часу. Визначте його як відношення реального часу (Tp), витраченого на завдання, до часу попередньої оцінки:
(To) : K = Tр / Tо
Що більше статистика вимірів, то вища ймовірність точніше вирахувати похибку. Запам’ятайте цей коефіцієнт і множте надалі на нього попередню оцінку. Це наблизить вас до точнішого прогнозу.
Щоб дістати точні оцінки, а також зберігання роадмапи всього проекту в актуальному стані, ми проводимо три основні кола оцінки тривалості роботи над створенням нового функціоналу:
- Попередня оцінка на основі короткого опису та проблем (зазвичай надається в тижнях або місяцях).
- Декомпозиція та її оцінка на основі специфікації (зазвичай створюється тім/технічним лідом релізу).
- Оцінка завдання розробником, який безпосередньо працюватиме над завданням.
На фазі закриття релізу ми, окрім ретроспективи, проводимо аналітику часу, витраченого на виконання завдання. І в рамках ретроспективи розглядаються значні відхилення від естимейтів — як позитивні, так і негативні.
Загалом вирахування коефіцієнту показує тенденцію, а також досить швидко коригує наступні оцінки.
Що робити, якщо команда давно знає і використовує ці правила, а оцінки все одно «вилітають»
Поговоримо про Planning fallacy, когнітивне викривлення планування — оману, яку ми переживаємо, плануючи завдання, а саме: чому ми завжди недооцінюємо час на певне завдання, навіть тоді, коли можемо згадати приклад з минулого, коли вже робили щось подібне, і тим паче коли знаємо, скільки часу це потребувало в минулому, ми завжди оптимістичні й думаємо, що цього разу все зробимо швидше.
Вікіпедія каже, що Planning fallacy інтерпретується як помилка планування. Цей концепт трапляється і в книжці Деніела Канемана «Мислення швидке й повільне». Проте сам термін запропонував у своєму дослідженні Роджер Бюхлер, а Канеман додав його до своєї антології найбільших помилок планування. Це зветься «когнітивне викривлення».
Що стосується когнітивного викривлення під час планування, то ми занадто оптимістичні в нашому плануванні. Роджер Бюхлер опитував групи студентів. Він запитував, у минулому, коли вони виконували певне завдання, яка була ймовірність того, що вони виконали його справді в ті строки, у які хотіли, і дістав результат, що в 70% випадків ніхто в зазначений термін не вкладався. Наступним запитанням було таке: «Як думаєте, чи можливо виконати наступне завдання в термін, який ви собі встановлюєте?», і 80% опитаних були впевнені, що вони вкладуться в нього.
Річ у тім, що ми думаємо про всі попередні фактори, які завадили нам щось здійснити, як одноразові. Що вони стосувалися саме попередньої ситуації, що це були непрораховані ризики й неконтрольовані події, які тепер не мають повторитися. Саме тоді, у минулому, стались певні події, але цього разу, звичайно, нічого такого статися не повинно.
Це перший фактор. Другий надзвичайно цікавий фактор, який описують експерименти: деталізованість і розпланованість ходу виконання завдання в майбутньому, наприклад коли ми продумуємо деталі робочого дня, починаючи з вранішнього підйому, скільки часу буде затрачено на підготовку та інше й скільки часу піде саме на виконання роботи. Так-от, що детальніше людина продумує, як виконуватиме завдання, то більша в нього оптимістична помилка планування, то більш оптимістичний він в оцінці строків.
Я ж проджект-менеджер, і планування — моя безпосередня робота. Саме тому певний час у неділю я витрачаю на планування свого тижня загалом і детально — понеділка. Окрім кількох регулярних мітингів, у мене завжди є термінові завдання, а також колись відкладені завдання. І ось у понеділок я собі зазвичай планую їх завершити.
Неділя. Я починаю складати деталізований план.
Прокинутись і встати о
Чому так відбувається
Коли ми щось продумали для себе, то нам здається, що так станеться з високою імовірністю
Було проведено досить цікавий експеримент, коли одну групу учасників просили продумати, чому вони не зможуть щось зробити. Наприклад, вчасно підготувати звіт. А інша частина учасників мала продумати, чому в них вийде успішно все завершити. І потім кожну групу просили оцінити ймовірність дістати хороший результат. Так-от, ті, кого просили фокусуватися на негативному, вважали, що ймовірність успіху нижча, а ті, хто фокусувався на позитивному, дали вищі оцінки. Відповідно, коли ми думаємо про виконання завдання в позитивному ключі, — коли ми почнемо працювати, з якою швидкістю просуватимемось, і в який час закінчимо, — одразу починаємо думати, що з найбільшою імовірністю так і буде.
Концепт hot-cold empathy gap
Він означає, що під час оцінки завдання ми можемо перебувати в різних станах. Наприклад, щойно завершився складний проект, ми починаємо роздумувати, що прокачали певний скіл, і в цей момент перебуваємо на піку ейфорії. Але ми не знаємо, у якому стані перебуватимемо, коли приступатимемо до іншого завдання, яке тепер оцінюємо. І на що нам вистачатиме сил, коли розпочнемо його виконувати. Коли ми надзвичайно вмотивовані, коли розплановуємо наступний проект/фазу тощо, ми перебуваємо в гарячому стані, але згодом адаптуємося — уже не так хвилюємося чи навіть боїмося нових невідомих завдань, усе з’ясовуємо, і ось це додаткове нервове навантаження минає. Поступово з гарячого стану ми переходимо в холодний. Під час оцінки ми певні, що справді займатимемося завданням, не відволікаючись, вкладатимемо туди всю силу волі, але потім стан змінюється, і в іншому стані ми приймемо інше рішення, побачимо інші фактори, які можуть здатися важливішими.
«Фокалізм»
Це означає, що ми думаємо, нібито в майбутньому вся наша увага буде приділена тому, що ми тепер плануємо. Тому що, плануючи тепер якесь завдання, ми думаємо, що і через тиждень, і через два всю увагу зосередимо на його виконанні. І ми навряд чи передбачаємо, що траплятимуться різні події, щось відволікатиме нас і що увага дедалі більше розсіюватиметься. Ми впевнені: весь наш фокус, яким він є тепер, буде спрямований на завдання. Але це не так.
Ось саме ці три фактори приводять до того, що ми неймовірно оптимістичні в наших оцінках. Цікаво, що психологи тестували ці фактори на групах як оптимістів, так і песимістів. І обидві групи з однаково великим оптимістичним буфером погоджуються на коротші строки виконання завдань, ніж це є насправді. І це попри те, що всі знають, що в минулому дуже рідко виходило вкластись у наперед встановлений строк.
І як із цим бути? Канеман і Тверскі пропонують не фокусуватися на плануванні на майбутнє й дивитись у минуле, скільки часу займало конкретне завдання. Інколи ми маємо власний досвід, але варто враховувати, що такий підхід діятиме в досить однотипних завданнях. Наприклад, професор Мак-Неллі стверджував, що він багато разів підряд фіксував, скільки часу в нього витрачається на вичитку однієї наукової статті. Згодом він дійшов до числа 90 хвилин — саме стільки часу потребував на виконання свого завдання. Також ми можемо орієнтуватися на інших людей, скільки часу в них іде на виконання завдання. Той самий професор Мак-Неллі в межах свого експерименту заміряв, скільки в його студентів витрачається часу на написання тез статті, вичитку, підготовку, щоб у майбутньому мати змогу підказати вже іншим студентам, як довго це триватиме. Але проблема з інформацією від інших людей у тому, що зазвичай ми не сприймаємо її досить серйозно. Ми враховуємо всі фактори навколишнього середовища, скілованість і риси характеру того, хто нам радить, і нівелюємо тим їхні оцінки. І ми впевнені, що саме з нами все буде інакше. Але фішка в тому, що коли ми плануємо для когось іншого, то саме тоді не маємо жодної оптимістичної похибки! Коли ми плануємо для іншої людини та вимірюємо строки, тоді ми точніші в наших прогнозах.
То в чому ж рація, якщо все одно нічого не працює...
Якщо ми точно знаємо, що всі з нас завжди пропускають встановлені строки, якщо це, звичайно, не фінальний дедлайн, то це не тому, що ми прокрастинуємо, а саме тому, що, найімовірніше, ми поставили собі занадто короткі й нереалістичні строки.
Якщо ми знаємо, що наші строки нереалістичні, то можемо додавати собі певний відсоток до тих строків, які нам здаються реалістичними. Адже тепер ми усвідомили, що переоцінили свої сили. Професор Мак-Неллі стверджує, що він так і робить: він ніколи свій строк не бере за чисту монету.
Інший підхід — попросити когось зовнішнього виміряти час, потрібний на виконання завдання. І правда буде десь посередині. «Правда посередині» — це не образна оцінка. Психологи справді виміряли це й визначили, що третя особа буде такою ж песимістичною у своїй оцінці, як оптимістичні ми. Тому правда саме посередині.
А також є певна ментальна вправа — два запитання, які дослідники ставили контрольним групам. Коли групи змушували себе продумувати відповіді на ці запитання, це допомагало їм визначити строки, які були не занадто оптимістичними, а більш реалістичними.
Перше запитання: «Якщо все буде, як завжди, скільки часу потрібно на виконання цього завдання?»
Друге запитання: «Як розвивалися події і які події зазвичай призводять до того, що строки так зміщуються?». І дослідники стверджують, що всі, хто ставив ці запитання, надавали більш реалістичні строки виконання своїх завдань. І ці підходи варті того, щоб їх пробувати, адже вони розвивають не скіл оцінки завдань як такий, вони розвивають цілий менталітет. Тобто ми відходимо від детального планування, охолоджуємо себе від гарячого стану й дивимося на речі реально, адже тепер знаємо, що це не працює, що завтра / через тиждень може трапитися що завгодно, ми можемо бути в зовсім іншому стані чи настрої. Замість цього ми встановлюємо собі нехай більші, але реалістичні строки.
Можна сказати, що так ми не розв’язуємо проблему, бо, імовірно, хтось інший або й ми самі можемо все зробити в ті визначені строки — мабуть, так, а мабуть, і ні. І чи повинні ми прагнути до робОти як рОботи, коли завжди перебуваємо в суперпродуктивному стані? І наші дослідники саме до цього й ведуть: прогнозуймо реалістичні сценарії. Цим ми викликаємо додатковий непотрібний стрес, у якому самі й вигораємо.
