Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Чому команди прохлопують свої естимейти

Я Оля Чмир, уже другий рік одна з проджект-менеджерів у компанії SPD-Ukraine на проекті PitchBook. У проекті тепер залучено 200 спеціалістів. На постійній основі я працюю з трьома різними командами, але, залежно від релізу, також маю можливість співпрацювати з іншими командами.

Проте так було не завжди. До PitchBook я працювала в стартапі E-learning, де керувала командою... відеопродакшну. І менеджером хоч би якої команди я була, проблему невідповідності естимейтів фактично витраченому часу я спостерігаю котрий рік поспіль. Як наслідок — виснаження, демотивація та інші неприємності, з якими доводиться немало працювати.

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

Що ж, пригадаймо той момент, коли проджект-менеджер приходить до команди й починає просити оцінити час, потрібний на виконання завдання чи навіть цілого проекту. І перше, що бачить в очах розробника, — сум та пригнічення. І не дарма. Протягом багатьох десятиліть чимало команд, які не могли об’єктивно оцінити потрібний їм час, і менеджери, які потім притягали команду до відповідальності за їхніми оцінками, неправильно використовували оцінки. Ще більше розчарування виникає, коли менеджери зважають лише на найнижчу кількість потрібних годин, почуту від розробників! Але погодьтеся: розробка не магія! І не дивно, що хештег #NoEstimates так прославився.

Давати точні оцінки складно, потрапити в них ще складніше.

Оцінки ніколи не досконалі. Але мета кожної спроби оцінювання — забезпечити надійний внесок у «досить хороший» план.

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

Процес оцінки

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

Визначення результату виконання завдання

Перш ніж давати оцінку за часом на виконання завдання, зрозумійте якнайліпше, що саме потрібно для його реалізації. Тому обов’язково слід належно його описати. Далі переходимо до деталізації.

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

Декомпозиція та деталізація

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

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

Найліпші практики індустрії: не опускатися нижче за 4 години завдання. Хоча допускається 2 години або 1 година (потреба в цьому виникає тоді, коли завдання невеликої тривалості).

Як це працює в нас: для оцінки завдання WBD створюється максимально детально, зокрема, щоб на цьому етапі банально не забути додати до оцінки всі потрібні дії (наприклад, інтегруючи з іншими сервісами, під’єднали їхній моніторинг). Усі підзавдання оцінюються окремо, проте естимейт завдання, залогованого в Jira, — це сума оцінок підзавдань і виконується як одне ціле. Логування фактично витраченого часу також сумується.

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

Визначення ризикових підзавдань

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

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

Як це працює в нас: по-перше, ми використовуємо систему падінгів. Кожне завдання в WBD має свій рахунок — від 0 до 3. Розробник, що створює декомпозицію, оцінює ризиковість завдання за встановленою шкалою. Відповідно до рахунку фінальна оцінка кожного окремого завдання зростає на 0–30% максимально оціненого часу.

По-друге, якщо рахунок становить >3, то ми проводимо Investigation щодо окремо взятих завдань.

Оцінка часу деталізованого завдання, або Коли в гру вступає менеджер

По-перше, оцінюючи завдання, пам’ятайте: розробник ніколи не витрачає всі 8 годин робочого дня безпосередньо на роботу над завданням. Завжди будуть витрати часу на заварити/попити кави-чаю, послухати свіжий анекдот тощо. Потім розробник сідає за комп’ютер і намагається якийсь час згадати, що ж він робив. Його увагу відвертають колеги запитаннями щодо роботи й таке інше... А скільки часу витрачають розробники на мітингах?

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

Як це працює в нас: з моїми командами ми маємо домовленість, що вони оцінюють завдання в девгодинах (тільки під час формування роадмапи, коли все, що ми знаємо про нову функціональність, — кілька речень опису і, ймовірно, проблема, яку хочемо розв’язати, — ми можемо оцінювати в тижнях або навіть місяцях). Кількість ефективних годин для середньостатистичного розробника — 5,5 години на день, для тім/технічного ліда — 2–4 години на день.

Час на код-рев’ю, виявилося, оцінити навіть важче, ніж час на реалізацію завдання. Були ситуації, коли час рев’ю інколи перевищував навіть час реалізації. Проте дослідним способом ми визначили, що на рев’ю витрачається близько 30% часу.

Окрім того, проекти, над якими працюють мої команди, дуже динамічні, і нам не властиві довгострокові проекти (зазвичай тривалість реалізації нового функціоналу — 1,5–2 місяці). Тому на інтеграцію додаємо ще 1 тиждень.

Цифри та невідомі

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

Невизначеність оцінок пов’язана з невідомими. Що більше невідомих, то менше впевнені ми повинні бути в оцінках. І навпаки, що менше невідомих, то більше впевненими ми повинні почуватися щодо оцінок.

Що це означає? Кожен проект має певний рівень невідомих. Коли розробники дають приблизну оцінку, — скажімо, 4–8 днів, — вони дають дві цінні інформації: кількість днів і впевненість у цьому. Якщо непевність велика, це означає, що є потенційно багато невідомих, які вплинуть на ймовірну поставку. Такий вплив може бути великий або взагалі бути відсутнім.

По-перше, звертаючись до невідомих, ми підвищуємо впевненість в оцінках.

Є 2 типи невідомих: невідомі невідомі й відомі невідомі. Не так уже й багато можна зробити для невідомих невідомих. За умовчанням, розробники не можуть врахувати їх у своїх оцінках; але вони могли б дати собі ще кілька днів «про всяк випадок», і ці дні зазвичай витрачаються на налагодження та інтеграцію. Щодо відомих невідомих, то, витрачаючи перші години або дні вашого проекту на їх вирішення, можна значно полегшити роботу, зменшивши цю невизначеність. Наприклад, 6 днів +/— 2 дні може стати, наприклад, 6 днів +/— 1 день.

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

До речі, можна зрозуміти, що технічні завдання — частина можливих відомих невідомих. Що точніші технічні завдання, то менше невизначеності буде. Ставте собі кілька запитань:

  • Чи зрозуміла вам специфікація?
  • Наскільки покрито негативні кейси?
  • Як ми тестуватимемо систему?
  • Як поводитиметься система в момент відмови?
  • Як ми моніторитимемо систему?
  • Чи можливо виконати завдання простішим способом і водночас виконати бізнес-завдання?
  • Чи може архітектура масштабуватися до кількості користувачів, яку ми хочемо?
  • Які ризики пов’язані з рішенням, яке ми плануємо використати?

Параліч перед оцінкою також легко побороти.

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

Особисто я її дуже люблю, хоч і намагаюся не зловживати нею. Отже, одного разу під час мітингу ми почали обговорювати досить велике технічне завдання. Розробник був у приємному передчутті, а я, намагаючись спланувати процес роботи всієї команди, поставила те саме запитання: «Скільки тобі часу потрібно, щоб закінчити це завдання?» Звичайно, побачила нервову посмішку й почула: «Я не можу знати, так ще нічого не зрозуміло». Тоді я почала гру...

Я: Тобі вистачить 3 місяці?
Розробник: Та ні, це занадто!
Я: Як щодо місяця?
Розробник: Хм... Можливо.
Я: А за тиждень?
Розробник: Точно не встигну! Там стільки роботи...
Я: 3 тижні буде досить? Чи 2?
Розробник: За 2 спробую закінчити. Проте 3 тижні має вистачити.

І ось ми вже на початку третього тижня й підходимо до закінчення розробки та підготовки завдання до код-рев’ю ;-)

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

(To) : K = Tр / Tо

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

Щоб дістати точні оцінки, а також зберігання роадмапи всього проекту в актуальному стані, ми проводимо три основні кола оцінки тривалості роботи над створенням нового функціоналу:

  1. Попередня оцінка на основі короткого опису та проблем (зазвичай надається в тижнях або місяцях).
  2. Декомпозиція та її оцінка на основі специфікації (зазвичай створюється тім/технічним лідом релізу).
  3. Оцінка завдання розробником, який безпосередньо працюватиме над завданням.

На фазі закриття релізу ми, окрім ретроспективи, проводимо аналітику часу, витраченого на виконання завдання. І в рамках ретроспективи розглядаються значні відхилення від естимейтів — як позитивні, так і негативні.

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

Що робити, якщо команда давно знає і використовує ці правила, а оцінки все одно «вилітають»

Поговоримо про Planning fallacy, когнітивне викривлення планування — оману, яку ми переживаємо, плануючи завдання, а саме: чому ми завжди недооцінюємо час на певне завдання, навіть тоді, коли можемо згадати приклад з минулого, коли вже робили щось подібне, і тим паче коли знаємо, скільки часу це потребувало в минулому, ми завжди оптимістичні й думаємо, що цього разу все зробимо швидше.

Вікіпедія каже, що Planning fallacy інтерпретується як помилка планування. Цей концепт трапляється і в книжці Деніела Канемана «Мислення швидке й повільне». Проте сам термін запропонував у своєму дослідженні Роджер Бюхлер, а Канеман додав його до своєї антології найбільших помилок планування. Це зветься «когнітивне викривлення».

Що стосується когнітивного викривлення під час планування, то ми занадто оптимістичні в нашому плануванні. Роджер Бюхлер опитував групи студентів. Він запитував, у минулому, коли вони виконували певне завдання, яка була ймовірність того, що вони виконали його справді в ті строки, у які хотіли, і дістав результат, що в 70% випадків ніхто в зазначений термін не вкладався. Наступним запитанням було таке: «Як думаєте, чи можливо виконати наступне завдання в термін, який ви собі встановлюєте?», і 80% опитаних були впевнені, що вони вкладуться в нього.

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

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

Я ж проджект-менеджер, і планування — моя безпосередня робота. Саме тому певний час у неділю я витрачаю на планування свого тижня загалом і детально — понеділка. Окрім кількох регулярних мітингів, у мене завжди є термінові завдання, а також колись відкладені завдання. І ось у понеділок я собі зазвичай планую їх завершити.
Неділя. Я починаю складати деталізований план.

Прокинутись і встати о 7-й ранку. 1,5 години на ранкові процедури та збори. О 9-й приїхати в офіс. 30 хвилин на зробити каву, перевірити пошту, навіть спитати про вихідні в колег. О 9:30 я, мотивована та натхненна, починаю готувати план нового проекту. Чи піде все за цим планом? Чи зможу я його зреалізувати? Ні... Знаєте, де зламається мій ідеальний план? Я нізащо не встану о 7-й ранку!..

Чому так відбувається

Коли ми щось продумали для себе, то нам здається, що так станеться з високою імовірністю

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

Концепт hot-cold empathy gap

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

«Фокалізм»

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

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

І як із цим бути? Канеман і Тверскі пропонують не фокусуватися на плануванні на майбутнє й дивитись у минуле, скільки часу займало конкретне завдання. Інколи ми маємо власний досвід, але варто враховувати, що такий підхід діятиме в досить однотипних завданнях. Наприклад, професор Мак-Неллі стверджував, що він багато разів підряд фіксував, скільки часу в нього витрачається на вичитку однієї наукової статті. Згодом він дійшов до числа 90 хвилин — саме стільки часу потребував на виконання свого завдання. Також ми можемо орієнтуватися на інших людей, скільки часу в них іде на виконання завдання. Той самий професор Мак-Неллі в межах свого експерименту заміряв, скільки в його студентів витрачається часу на написання тез статті, вичитку, підготовку, щоб у майбутньому мати змогу підказати вже іншим студентам, як довго це триватиме. Але проблема з інформацією від інших людей у тому, що зазвичай ми не сприймаємо її досить серйозно. Ми враховуємо всі фактори навколишнього середовища, скілованість і риси характеру того, хто нам радить, і нівелюємо тим їхні оцінки. І ми впевнені, що саме з нами все буде інакше. Але фішка в тому, що коли ми плануємо для когось іншого, то саме тоді не маємо жодної оптимістичної похибки! Коли ми плануємо для іншої людини та вимірюємо строки, тоді ми точніші в наших прогнозах.

То в чому ж рація, якщо все одно нічого не працює...

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

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

Інший підхід — попросити когось зовнішнього виміряти час, потрібний на виконання завдання. І правда буде десь посередині. «Правда посередині» — це не образна оцінка. Психологи справді виміряли це й визначили, що третя особа буде такою ж песимістичною у своїй оцінці, як оптимістичні ми. Тому правда саме посередині.

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

Перше запитання: «Якщо все буде, як завжди, скільки часу потрібно на виконання цього завдання?»

Друге запитання: «Як розвивалися події і які події зазвичай призводять до того, що строки так зміщуються?». І дослідники стверджують, що всі, хто ставив ці запитання, надавали більш реалістичні строки виконання своїх завдань. І ці підходи варті того, щоб їх пробувати, адже вони розвивають не скіл оцінки завдань як такий, вони розвивають цілий менталітет. Тобто ми відходимо від детального планування, охолоджуємо себе від гарячого стану й дивимося на речі реально, адже тепер знаємо, що це не працює, що завтра / через тиждень може трапитися що завгодно, ми можемо бути в зовсім іншому стані чи настрої. Замість цього ми встановлюємо собі нехай більші, але реалістичні строки.

Можна сказати, що так ми не розв’язуємо проблему, бо, імовірно, хтось інший або й ми самі можемо все зробити в ті визначені строки — мабуть, так, а мабуть, і ні. І чи повинні ми прагнути до робОти як рОботи, коли завжди перебуваємо в суперпродуктивному стані? І наші дослідники саме до цього й ведуть: прогнозуймо реалістичні сценарії. Цим ми викликаємо додатковий непотрібний стрес, у якому самі й вигораємо.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному17
LinkedIn

Схожі статті




31 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

подскажите куда сдавать почку чтоб попасть к вам на проект.
— полуседой ветеран споров с ПМ и нервных срывов

P.S. возможно я даже не шучу

Классная статья 👌 Подкупает уровень рефлексии и желание getting things done

Дякую за статтю, записав собі багато корисної інформації

Окреме дякую за перелік, виявився для мене актуальним:
Чи зрозуміла вам специфікація?
Наскільки покрито негативні кейси?
Як ми тестуватимемо систему?
Як поводитиметься система в момент відмови?
Як ми моніторитимемо систему?
Чи можливо виконати завдання простішим способом і водночас виконати бізнес-завдання?
Чи може архітектура масштабуватися до кількості користувачів, яку ми хочемо?
Які ризики пов’язані з рішенням, яке ми плануємо використати?

Прошу, рада бути корисною

Иногда тупо лень, что-то делать. И глубоко наплевать на то, что ты там себе написал. Все равно в дедлайн уложусь. В последний день, объевшись глицина, валерьянки и запив сверху энергетиком. Не надо так делать, просто не надо.

Всё на самом деле еще проще:

ПРАВИЛО ВЕСТГЕЙМЕРА: Чтобы определить, сколько времени потребует работа, возьмите время, которое по-вашему на нее необходимо, умножьте на 2 и замените единицы измерения на единицы более высокого порядка. Так, мы выделяем два дня на одночасовую работу.

И другие полезные рекомендации :

1) Под давлением всё ухудшается. — Закон термодинамики Мерфи
2) Если кажется, что работу сделать легко, это непременно будет трудно. Если на вид она трудна, значит выполнить её абсолютно невозможно.
3) Допустимые отклонения будут накапливаться однонаправленно, чтобы причинить максимум трудностей при сборке.
4) Непечатный жаргон — это тот язык, которым решительно все программисты владеют в совершенстве. — Постулаты Трумэна по программированию
5) Неточно спланированная программа требует в три раза больше времени, чем предполагалось; тщательно спланированная — только в два раза.

Дякую за ваші рекомендації, впевнена, що для когось вони також стануть у нагоді.

Щодо нашого проекту — це велика екосистема, тому така кількорівнева система оцінок нам підходить та використовується для планування роботи усіх задіяних команд (від аналітиків/продактів до девелопменту і маркетингу/сейлз/кастомер саппорт, і тд)

Достаточный ответ на вопрос топика «чому команди прохлопують свої естимейти» — потому что кто-то прогноз извращает в дедлайн.

Так, нажаль, деякі менеджери і команди плутають поняття «естимейт» і «тривалість»

Потому что вопрос «сколько часов потребуется» и «когда будет закончено» — это на самом деле два разных вопроса.

При этом прогноз делался «на коленке», а за дедлайн уже а-та-та.
Качественное эстимирование — это тоже работа, работа командная, работа не самая простая. Только не до всех менеджеров это доходит. Чё там, «тыжпрофессионал».

потому что «сначала давайте продадим, а там разберемся» ))

Буває й так :) Мені здається, що це найпоширеніший підхід стартапів. Продавати на рівні ідеї, а там як піде. Проте коли ваш продукт починає рости і розвиватись, ви розширюєте коло ваших клієнтів, наступає момент, коли потрібно якісно керувати їх очікуваннями і своєю репутацію. І тут гарний, прогнозований план буде перевагою перед конкурентами ;)

Дуже багато толкових порад, дякую. Особливо сподобалась цитата «I’ll get back to you soon» :) Дійсно, взяти час на оцінку — гарних підхід, як і основувати оцінки на зрозумілих вимогах. В свою чергу, для розуміння вимог необхідна комунікація і виявлення проблематики, як результат — найкращого рішення.

Дякую за статтю, цікаво.

Kyiv PMDay 2019. Olha Chmyr “Why team f*ck up their own estimates”
www.youtube.com/...​bIqwnJ9U&feature=youtu.be

Дякую за посилання — для тих, кому більше подобається слухати, ніж читати

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

Підписатись на коментарі