Новий стартап чи тривалий проєкт, внутрішній чи на аутсорсі — у будь-якому ІТ-проєкті команда стартує з естімейту — оцінює необхідні ресурси, витрати й терміни виконання робіт. Цим можуть займатися різні фахівці: бізнес-аналітики, sales-менеджери, продуктові та проєктні менеджери, а також безпосередні виконавці задач — розробники, дизайнери, тестувальники, DevOps’и тощо.
Вперше зіткнулися з оцінкою естімейту? Тоді ця стаття для вас. Спробуємо розібрати базові кроки: від комунікації в команді до погодження естімейту з клієнтом.
Що варто зробити на етапі pre-sale
Головна вимога до естімейту — бути максимально точним, наскільки це можливо в поточних умовах. Від цього залежить управління подальшими процесами: від підписання контракту із замовником до запуску готового продукту чи релізу фічі. Уже на стадії пресейлу, коли ви обговорюєте з клієнтом заплановані задачі й обсяг робіт, естімейт має включати:
- Спрогнозувати терміни. Ще до запуску проєкту потрібно зрозуміти, скільки робочих годин необхідно на реалізацію фічі чи покращення існуючого функціоналу. Йдеться про час усіх залучених фахівців. Естімейт повинен узгоджуватися з потребами бізнесу. Він може мати об’єктивно чи суб’єктивно обмежені терміни. Якщо замовник хоче отримати результат швидше, ніж ви оцінюєте, терміни краще переглянути.
- Визначити людські ресурси. Робочі години — не абстрактне поняття, а завжди прив’язане до конкретних людей. В естімейті нового проєкту необхідно на початковій стадії прогнозувати навантаження команди: скільки працюватиме розробників, дизайнерів, тестувальників тощо. Враховуйте, що вартість їхньої роботи за годину може варіюватися, як і те, наскільки швидко працює той чи інший фахівець над одними й тими ж задачами. Зрештою й це впливатиме на загальний час, необхідний для виконання проєкту.
- Порахувати бюджет. Цей пункт випливає з попередніх. Якщо клієнту потрібен швидкий результат, то йому слід готуватися заплатити більше. Потреба залучити в проєкт виключно досвідчених фахівців, здатних створювати унікальні рішення, теж вартує дорожче. Тож рахуючи естімейт, балансуйте між усіма параметрами. Намагайтесь знайти оптимальне рішення і для бізнесу (щодо вартості), і для ваших колег (щодо оплати праці).
- Описати план реалізації. Варто хоча б базово прописати можливу архітектуру й технології, обрати методологію розробки та розподілити ролі й час всередині команди. Все це дозволить глибше осягнути масштаб робіт, спрогнозувати шляхи майбутньої реалізації як проєкту в цілому, так і його окремих частин.
Естімейт — це завжди про компроміс між швидкістю, вартістю й якістю. Але оцінка має бути не лише балансованою, а й реалістичною.
3 важливих «НЕ», які я раджу врахувати на старті
- Не обіцяйте фантастичних термінів, щоб потім по ходу робіт не довелося пояснювати, чому ви збільшили кількість годин вдвічі чи навіть втричі.
- Не закладайте в естімейт надто великі цифри «про всяк випадок». Так ви ще до початку робіт можете втратити замовника, бо він не буде зацікавлений у такому бюджеті й строках.
- Не намагайтеся виконати проєкт в заявлені клієнтом терміни, якщо це справді нереально. Навіть з необмеженим бюджетом. Краще поясніть, скільки справді потрібно часу на ту чи іншу задачу і чому саме стільки? Що ви такого будете робити, від чого зростає кількість годин, та як це позначиться на результаті?
Дотримуючись цих правил, ви зменшите ймовірність непорозумінь із замовником.
Що впливає на точність естімейту
- Бізнес-ідея. Насамперед треба переконатися, що проєкт можливо реалізувати — це особливо критично для стартапів. Інколи ідея може здатися цікавою, але вона не є життєздатною. Також варто оцінити ваш досвід у предметній області. Наприклад, бізнесу потрібна програма для МРТ. Ви знаєте, що це таке, але не розумієте, як це працює під капотом. Тож слід розібратися ще в бізнес-логіці. А це стане блокером, який збільшить кількість робочих годин і вплине на оцінку.
- Технології. З одного боку, на точність естімейту впливає ваше знайомство з конкретними інструментами. Якщо за бажанням клієнта слід використовувати нову технологію, необхідно закладати час на її вивчення. З іншого боку, інколи замовники вимагають використовувати мову програмування без додаткових бібліотек або інших рішень. Це робить код універсальнішим, що корисно, наприклад, при зміні виконавців, яким не треба вивчати щось нове. Проте це уповільнює роботу: з готовими рішеннями все йде швидше.
- Досвід ІТ-спеціаліста. Проводити оцінку проєкту має людина з досвідом такої роботи — це очевидна аксіома. Але цей фахівець має робити поправку на саму команду. Сеньйор може вирішити: ось ця задача для мене швидка, десь на тиждень. Але виконувати її буде джуніор, який буде в шоку: йому на ту ж задачу об’єктивно потрібен місяць! Тож краще орієнтуватися на золоту середину — мідлів. Але пам’ятати про можливість поправки при змінах у команді.
- Вимоги клієнта. Завдання на проєкт може бути деталізованим і зрозумілим — тоді й точну оцінку провести відносно легко. Але так буває не завжди. Часто у клієнтів є лише загальне розуміння бізнес-потреб. Тому вже в ході робіт можуть з’являтися уточнення, які будуть корегувати наданий естімейт. Ба більше: нерідко замовники навіть з якісними вимогами можуть щось передумати — і, наприклад, ускладнити проєкт. Це також змінить вашу початкову оцінку.
Як би ви відповідально не поставились до естімейту, пам’ятайте: абсолютно точна оцінка неможлива. З одного боку, чітко прогнозований процес розробки існує фактично лише за моделлю Waterfall, коли один етап йде за іншим. Тобто спочатку працюють дизайнери, потім розробники, потім тестувальники тощо. Але ця методологія не є гнучкою. Вона часто не відповідає сучасним вимогам IT-розробки (на відміну від того ж Scrum, де роботи можуть йти в паралельному режимі). З іншого ж боку, дуже рідко зустрічаються бізнеси, які не змінюють власні вимоги під час проєкту. А нові ідеї — це завжди нові естімейти. Тому все це треба проговорювати ще на старті. Тобто ми даємо прогнози, беремо за них відповідальність, але все це є відносно динамічним.
Різновиди естімейтів
Залежно від конкретної мети оцінки, умов обговорення із замовником та особливостей самого проєкту, процес естімейту може доволі сильно відрізнятися. Передусім може бути різним об’єкт оцінювання:
- Проєкт. Це основний напрямок, коли ви даєте комплексний прогноз. Зробити його самотужки майже неможливо, навіть з погляду часових витрат. Якщо цей естімейт виконує, наприклад, фронтенд-розробник, то він може не врахувати якихось моментів по бекенду, не кажучи вже про дизайн або тестування. Тому краще рішення — брейншторм з цілою командою різних фахівців.
- Таск. Це більш низькорівнева оцінка для окремих задач по проєкту, коли вже є загальний естімейт. Фактично в основі комплексного прогнозу лежить саме оцінювання для безлічі тасок. Виконати подібний естімейт задачі може й один виконавець. Головне: аби він мав досвід реальних задач. Тоді він буде розуміти, скільки часу треба на конкретний таск.
Естімейт проєкт може відрізнятися за ступенем опрацювання:
- Швидка оцінка. Це приблизний прогноз, коли замовник хоче лише базового розуміння масштабу робіт. В ідеалі всі сторони мають усвідомлювати, що після занурення в нюанси такий естімейт може змінитися — навіть кратно. Але є й інша, більш важлива проблема. Quick estimate не дає розуміння по конкретних напрямах роботи. Ця оцінка може виглядати умовно так: на проєкт потрібно 600 годин. Але можуть виникнути запитання, що це включає та чому стільки.
- Детальна оцінка. Це більш реалістичний сценарій з розписуванням хай не всіх задач, але хоча б ключових напрямів роботи. Я завжди намагаюсь зробити більш детальний опис навіть для швидкої оцінки, ніж зазвичай. Це трохи складніше та потребує певного часу. Але, по-перше, завдяки детальній оцінці буде вищою точність й у quick. По-друге, по запиту ви зможете легко та швидко надати роз’яснення, з чого складається ваш прогноз. Це відкрита інформація.
Підхід до оцінювання може змінюватися залежно від статусу проєкту:
- Новий проєкт. Цей той самий випадок, коли необхідно оцінити бізнес-ідею, вивчити бізнес-логіку, продумати архітектуру, обрати технології, побудувати план робіт всередині команди тощо. Тобто акцент — на всьому тому, що було вже описано вище. Такий естімейт є класикою жанру, де все залежить виключено від вашого бачення та вимог замовника.
- Наявний проєкт. Тут треба розуміти контекст, реалізацію. Наприклад, вам потрібно змінити колір кнопки. Це проста задача. Але ви занурюєтесь у репозиторій, а там навіть прості речі потребують серйозних змін у коді! Тому потрібно насамперед аналізувати конкретні рішення, які використовували попередні розробники. Тільки так ви зможете надати якісний естімейт.
З мого досвіду, оцінка модернізації наявного проєкту потрібна вкрай рідко. Замовники з готовим продуктом потребують конкретних фахівців для реалізації вже визначених ідей або фіч. Тоді просять підготувати естімейт за окремими задачами.
Які етапи передбачає оцінювання проєкту
- Аналіз вимог. Будь-який естімейт починається зі збору інформації: про проєкт, замовника, бізнес-процеси, які має покривати продукт тощо. У клієнта може бути дуже загальна ідея. А може бути деталізований бріф з функціональними та нефункціональними вимогами. Також важливо дізнатися про потрібні інтеграції та всі можливі обмеження: часу, ресурсів, бюджету. Окрім цього, не зайвим буде проаналізувати аналоги продукту на ринку (якщо вони є, звичайно). До цих задач варто залучати бізнес-аналітиків та sales-менеджерів.
- Проєктування. На цьому етапі необхідно продумати хоча б на базовому рівні архітектуру продукту та обрати фронтенд- та бекенд-технології, які ви будете використовувати для реалізації проєкту. Якщо у замовника є побажання стосовно мови програмування чи окремих технологій, це також треба врахувати. Головне: зробити підбір всіх рішень, аж до баз даних і хмарних провайдерів. Пам’ятайте: чим більше обґрунтованих ідей буде надано та прийнято на початку, тим точнішою буде оцінка та простішою сама розробка в майбутньому.
- Декомпозиція. Це вже рівень того самого detailed estimate. Коли ви починаєте робити план робіт і розбивати проєкт не просто на категорії, а на підкатегорії, підпідкатегорії й глибше. Наприклад, якщо необхідно створити інтернет-магазин, то слід продумати безліч процесів: фільтрація товарів, реєстрація та авторизація користувачів, оформлення замовлень, інтеграція оплати, панель адміністратора для управління контентом тощо. Тільки розклавши проєкт на такі маленькі блоки, ви зможете зрозуміти складність задач та надати точну оцінку.
- Виявлення факторів впливу. Естімейт ніколи не є статичним — в процесі розробки все може динамічно змінюватися під впливом додаткових факторів. Найпростіший приклад — тестування. Замовник може обирати, які тести йому потрібні: юніт, енд-ту-енд, автоматизаційні тощо. У кожному випадку це додає час на проєкт. За нашим досвідом, юніт-тестування має збільшувати оцінку на 20%, а, наприклад, E2E на фронтенді — ще на 30–35%. Проте всі такі фактори є опціональними та потребують окремого обговорення із замовником.
- Фіксація ризиків. На проєкті завжди є зміни — та завжди є непередбачувані проблеми. Насамперед вони можуть стосуватися технологій. Наприклад, під час інтеграцій ви зіткнулись із незнайомими API. Це буде блокером, який потребує зайвого часу на пошук рішення. Але ризики можуть носити й інший характер. У когось зламався комп’ютер, хтось захворів, ви просто десь помилились у роботі чи самій оцінці — життя таке. Тому врахування форс-мажорів після розрахунку естімейту є must-have. Хороша практика — 15% на потенційні проблеми.
- Презентація оцінки. Неприпустимо скинути замовнику кількість годин і вартість — треба обов’язково пояснити, як ви прийшли до таких цифр. Інколи ця розмова є дуже детальною. Наприклад, треба показати: через негнучку схему роботи на кшталт Waterfall можуть збільшуватися ризики. Або в проєкті багато невідомого, тому закладаємо час на додаткові міти та сінки. Звичайно, на презентації може бути торг. Припустимо, замовник скаже: мені не потрібно стільки тестування. Тоді доведеться повернутись на попередні етапи та провести нові розрахунки.
Погоджуємо естімейт із клієнтом
Інколи очікування клієнта та ваші оцінки можуть дуже сильно не збігатися. І мова не про перегляд окремих факторів впливу, як було наведено вище про потребу у кількості тестів. Проблема може бути глибшою, що вимагає серйозного занурення в технічні та інші деталі.
Як побудувати розмову з клієнтом, залежить від рівня його обізнаності в технологіях.
- Нетехнічний клієнт. З ним найкращий спосіб — перевести комунікацію на sales-менеджерів або бізнес-аналітиків. Вони зможуть зрозуміло репрезентувати технічну інформацію для людини «не в темі» та підсвітити в розрахунках залежності й ризики. Досвід показує: спілкування розробників із таким замовником може швидко вийти з поля розуміння. Це цілком нормально. Девелопери теж інколи можуть неправильно зрозуміти ту ж бізнес-ідею або окремі бізнес-процеси. На допомогу прийдуть бізнес-аналітики, які вміють інтерпретувати в обидва боки вимоги та деталі проєкту.
- Технічний клієнт. Це не обов’язково сам замовник, інколи це і його технічна команда. Тоді краще залучати до розмови з ними розробників, які предметно обговорять реалізації та best practices. Для ефективної комунікації технарів будуть важливі обґрунтованість рішень, прозорість компромісів та технічна чесність. Наприклад, клієнту треба створювати в застосунку багато наукових графіків. У вас немає досвіду роботи з такою специфічною темою. Але розробник з тої сторони може сказати: це можна імплементувати за 80 годин, тому що є ось така-то технологія. Це буде влучним аргументом.
Оцінка проєкту — це не про сліпе вгадування, це методичний збір інформації, перевірка припущень, чесна комунікація з усіма стейкхолдерами й виконавцями. Реалістичний естімейт — ключ до порозуміння між командою та замовником. Звісно, часом, й ефективне оцінювання всіх зусиль і бюджету не гарантує, що все пройде гладко, але прорахунки однозначно підвищують шанси на успіх.
Тож рекомендую постійно вдосконалювати свої підходи до оцінювання проєктів, раз уже маєте з цим справу. Фіксуйте помилки, робіть висновки за результатами ретроспектив, і тоді ваші естімейти ставатимуть дедалі точнішими.