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

Вперше зіткнулися з оцінкою естімейту? Тоді ця стаття для вас.

Євген Бодня, JS/UI Group Lead в команді NIX, розповідає про основні кроки: від комунікації в команді до погодження естімейту з клієнтом.

Що варто зробити на етапі pre-sale

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

• Спрогнозувати терміни. Ще до запуску проєкту потрібно зрозуміти, скільки робочих годин необхідно на реалізацію фічі чи покращення існуючого функціоналу. Йдеться про час усіх залучених фахівців. Естімейт повинен узгоджуватися з потребами бізнесу. Він може мати об’єктивно чи суб’єктивно обмежені терміни. Якщо замовник хоче отримати результат швидше, ніж ви оцінюєте, сроки краще переглянути.
• Визначити людські ресурси. Робочі години — не абстрактне поняття, а завжди прив’язане до конкретних людей. В естімейті нового проєкту необхідно на початковій стадії прогнозувати навантаження команди: скільки працюватиме розробників, дизайнерів, тестувальників тощо. Враховуйте, що вартість їхньої роботи за годину може варіюватися, як і те, наскільки швидко працює той чи інший фахівець над одними й тим ж задачами. Врешті й це впливатиме на загальний час, необхідний для виконання проєкту.
• Порахувати бюджет. Цей пункт випливає з попередніх. Якщо клієнту потрібен швидкий результат, то йому слід готуватися заплатити більше. Потреба залучити в проєкт виключно досвідчених фахівців, здатних створювати унікальні рішення, теж вартує дорожче. Тож рахуючи естімейт, балансуйте між усіма параметрами. Намагайтесь знайти оптимальне рішення і для бізнесу (щодо вартості), і для ваших колег (щодо оплати праці).
• Описати план реалізації. Варто хоча б базово прописати можливу архітектуру й технології, обрати методологію розробки та розподілити ролі й час всередині команди. Все це дозволить глибше осягнути масштаб робіт, спрогнозувати шляхи майбутньої реалізації як проєкту в цілому, так і його окремих частин.

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

3 важливих «‎НЕ», які я раджу врахувати на старті:

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

Дотримуючись цих правил, ви зменшите ймовірність непорозумінь із замовником.

Що впливає на точність естімейту

• Бізнес-ідея

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

• Технології

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

• Досвід ІТ-спеціаліста

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

• Вимоги клієнта

Завдання на проєкт може бути деталізованим і зрозумілим — тоді й точну оцінку провести відносно легко. Але так буває не завжди. Часто у клієнтів є лише загальне розуміння бізнес-потреб. Тому вже в ході робіт можуть з’являтися уточнення, які будуть корегувати наданий естімейт. Ба більше: нерідко замовники навіть з якісними вимогами можуть щось передумати — і, наприклад, ускладнити проєкт. Це також змінить вашу початкову оцінку.

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

Різновиди естімейтів

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

• Проєкт. Це основний напрямок, коли ви даєте комплексний прогноз. Зробити його самотужки майже неможливо, навіть з погляду часових витрат. Якщо цей естімейт виконує, наприклад, фронтенд-розробник, то він може не врахувати якихось моментів по бекенду, не кажучи вже про дизайн або тестування. Тому краще рішення — брейншторм з цілою командою різних фахівців.
• Таск. Це більш низькорівнева оцінка для окремих задач по проєкту, коли вже є загальний естімейт. Фактично в основі комплексного прогнозу лежить саме оцінювання для безлічі тасок. Виконати подібний естімейт задачі може й один виконавець. Головне: аби він мав досвід реальних задач. Тоді він буде розуміти, скільки часу треба на конкретний таск.

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

• Швидка оцінка. Це приблизний прогноз, коли замовник хоче лише базового розуміння масштабу робіт. В ідеалі всі сторони мають усвідомлювати, що після занурення в нюанси такий естімейт може змінитися — навіть кратно. Але є й інша, більш важлива проблема. Quick estimate не дає розуміння по конкретних напрямах роботи. Ця оцінка може виглядати умовно так: на проєкт потрібно 600 годин. Але можуть виникнути запитання, що це включає та чому стільки.
• Детальна оцінка. Це більш реалістичний сценарій з розписуванням хай не всіх задач, але хоча б ключових напрямів роботи. Я завжди намагаюсь зробити більш детальний опис навіть для швидкої оцінки, ніж зазвичай. Це трохи складніше та потребує певного часу. Але, по-перше, завдяки детальній оцінці буде вищою точність й у quick. По-друге, по запиту ви зможете легко та швидко надати роз’яснення, з чого складається ваш прогноз. Це відкрита інформація.

Підхід до оцінювання може змінюватися залежно від статусу проєкту:

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

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

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