Чому оцінка термінів у проєкті майже завжди виявляється заниженою

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

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

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

Причина перша: оцінку просять до завершення дискавері

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

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

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

Причина друга: сказати «я поки не знаю» сприймається як непрофесійність

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

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

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

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

Причина третя: оцінка перетворюється на обіцянку без окремої домовленості про це

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

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

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

Чому саме ці три причини важче помітити, ніж технічну складність

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

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

Що можна змінити в самому процесі озвучення оцінки

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

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

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

Короткий чекліст перед тим, як озвучити оцінку замовнику

Перш ніж назвати конкретний термін, є сенс пройти три пункти, симетричні до причин вище:

• Чи ця оцінка дається до чи після завершення дискавері — і чи знає замовник, яка саме це стадія?
• Чи озвучується діапазон із явним рівнем впевненості, чи одне округлене число, що виглядає точнішим, ніж є насправді?
• Чи узгоджено заздалегідь, за яких умов і ким ініціюється перегляд оцінки, якщо зʼявляється нова інформація?

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