Hourly vs блок: коли обсяг 80–140 годин

Одна з найчастіших дилем для клієнтів: hourly чи фікс-блок? Особливо коли мова про проекти на 80–140 годин — це вже не «дрібниця на вихідні», але ще не великий корпоративний портал.

У цій статті я розбираю, коли краще обрати hourly, коли — блок/фікс, як я працюю з діапазоном 80–140 годин і як забезпечую прозорість для клієнта (звіти, ризики, комунікація щодо перевитрат/економії).

Коли краще обрати hourly

Hourly (оплата за години) — це не «невизначеність», а інструмент для проектів із багатьма невідомими.

Hourly має сенс, коли:

• Нечіткий обсяг. Наприклад: «Хочемо редизайн + новий каталог, але точно не знаємо, скільки буде фільтрів, яких блоків, яка логіка».

• Багато досліджень і експериментів. Нові інтеграції, нестандартна логіка, складні калькулятори, кастомні воронки.

• Висока ймовірність змін вимог. Клієнт ще сам не до кінця розуміє, що хоче, або бізнес-процеси можуть змінитись у процесі.

Плюси hourly:

• Ви платите за реальну роботу, а не за «вгаданий» обсяг.

• Легше змінювати пріоритети: якщо в процесі щось стає неактуальним, ми просто не робимо ці задачі.

• Менше ризику, що розробник «закладе в ціну всі можливі ризики» і проект вийде дорожчим, ніж міг би бути.

Мінуси hourly:

• Клієнту важче планувати бюджет: немає чіткої фінальної цифри на старті.

• Потрібна довіра і прозора звітність: скільки годин витрачено, на що, що залишилось.

Коли краще обрати блок/фікс

Блок (фікс-цена за пакет робіт) — це коли ми домовляємось про чіткий обсяг і фіксуємо ціну.

Блок має сенс, коли:

• Чітко описаний обсяг. Наприклад: «Лендінг + 5 внутрішніх», «Корпоративний сайт: головна, послуги, про нас, блог, контакти», «WooCommerce каталог + чекаут».

• Повторювані задачі. Пакетні доробки, серія однакових сторінок, типова інтеграція, яку ви вже робили.

• Клієнту важливі передбачуваність і дедлайн. Коли бюджет затверджений всередині компанії і не можна його перевищити.

Плюси блоку:

• Чітка цифра на старті: легше планувати бюджет.

• Менше потрібно занурюватись у деталі: є перелік робіт, є результат.

• Зручно для внутрішнього затвердження: «у нас є бюджет X, проект коштує Y».

Мінуси блоку:

• Розробник закладає ризики в ціну: якщо щось піде не так, він має бути впевнений, що не працює в мінус.

• Зміни вимог часто означають додаткові угоди/доплати: «це вже не входить у блок».

• Якщо обсяг виявився меншим, клієнт все одно платить фікс.

Як я працюю з діапазоном 80–140 годин

Діапазон 80–140 годин — це типовий проект: невеликий корпоративний сайт, каталог послуг, WooCommerce на старті, редизайн існуючого сайту.

Як я оцінюю обсяг:

Аудит/бриф. Дивлюсь на макети (якщо є), опис функціоналу, приклади референсів.

Розбивка на етапи. Наприклад:

• Аудит і структура: 8–12 год

• Верстка ключових шаблонів: 20–30 год

• Інтеграція в WordPress: 20–30 год

• WooCommerce/каталог: 20–40 год

• Тестування, правки, запуск: 12–20 год

Разом: орієнтовно 80–132 год.

Фіксація ризиків. Вказую, де можливі додаткові години: складні фільтри, кастомні інтеграції, великий обсяг контенту.

Як я комунікую діапазон клієнту:

• Даю не одну цифру, а діапазон: «Орієнтовно 80–140 годин, залежно від складності фільтрів і обсягу контенту».

• Пояснюю, від чого залежить верхня межа: наприклад, «якщо фільтри прості — ближче до 80, якщо кастомні з логікою — ближче до 140».

• Пропоную пріоритети: що робимо в першу чергу, що можна винести в другий етап, якщо бюджет обмежений.

Прозорість для клієнта: звіти, ризики, перевитрати

Незалежно від моделі (hourly чи блок), для мене важливо, щоб клієнт розумів, куди йдуть години і бюджет.

Як виглядає звіт по годинах

Для hourly-проектів я надаю:

Короткий звіт (раз на тиждень/етап):

• Скільки годин витрачено.

• На які задачі (наприклад: «верстка головної», «інтеграція форми», «налаштування фільтрів»).

• Скільки годин залишилось у рамках бюджету.

За потреби — детальнішу розбивку по етапах.

Це не «шпигунство», а інструмент довіри: клієнт бачить прогрес і може коригувати пріоритети.

Як я комунікую ризики

Якщо в процесі я бачу, що:

• Задача складніша, ніж здавалась на старті.

• З’явились нові вимоги, які не обговорювались.

• Контент/макети вимагають більше роботи, ніж планувалось.

Я одразу пишу клієнту/PM:

• Що змінилось.

• Як це впливає на години (наприклад: «+10–15 год до оцінки»).

• Які є варіанти: спростити, винести в другий етап, додати бюджет.

Перевитрати vs економія

Перевитрати:

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

• Пропоную варіанти: що можна спростити, що винести, де зекономити.

Економія:

• Якщо обсяг виявився меншим (наприклад, 70 годин замість 80–100), клієнт платить за реальні години (для hourly) або ми домовляємось, як врахувати економію в наступних етапах (для блоку).

Головне — ніяких сюрпризів «в кінці», коли приходить фінальний рахунок.

Приклад: корпоративний сайт з каталогом послуг

Вхідні дані:

• Головний сайт компанії, 6–8 основних сторінок.

• Каталог послуг з фільтрами (послуга, галузь, регіон).

• Форми заявок, інтеграція з поштою/CRM.

• Макети в Figma, але без повних мобільних версій.

Початкова оцінка: 80–120 годин.

Як я розбиваю на етапи:

• Аудит макетів, уточнення вимог: 8–10 год

• Верстка ключових шаблонів (головна, послуги, каталог, стаття): 25–35 год

• Інтеграція в WordPress (ACF, кастомні типи записів): 20–30 год

• Каталог + фільтри: 20–35 год

• Форми + інтеграції: 6–10 год

• Тестування, правки, запуск: 10–15 год

Разом: 89–135 годин.

Що може збільшити обсяг:

• Кастомна логіка фільтрів (наприклад, складні умови, залежні фільтри).

• Додаткові мови (мультиязичність, переклади, URL-структура).

• Великий обсяг контенту, який треба структурувати і імпортувати.

Що я пропоную клієнту:

• Зробити базову версію фільтрів у першому етапі, складну логіку винести в другий.

• Спочатку запустити одну мову, потім додати інші.

• Пріоритезувати сторінки: спочатку головна + ключові послуги, потім другорядні.

Як обрати: hourly чи блок?

Обирайте hourly, якщо:

• У вас ще немає чіткого опису всіх вимог.

• Є багато невідомих і ймовірних змін.

• Вам важливі гнучкість і можливість змінювати пріоритети в процесі.

Обирайте блок, якщо:

• Ви чітко знаєте, що хочете (є макети, ТЗ, приклади).

• Вам важлива передбачуваність бюджету і дедлайну.

• Зміни вимог малоймовірні або небажані.

Компромісний варіант:

• Фіксувати перший етап (аудит + структура + ключові шаблони) як блок.

• Решту (каталог, фільтри, інтеграції) робити hourly, бо там найбільше невідомих.

Потрібна допомога з оцінкою проекту?

Якщо у вас є проект на 80–140 годин (або близько того) і ви вагаєтесь між hourly і блоком — напишіть. Обговоримо ваші вхідні дані (макети, функціонал, бізнес-цілі) і я дам чесну оцінку: яка модель вигідніша для вас і чому.

Це не зобов’язує до співпраці — але допоможе уникнути несподіваних витрат і неочікуваних правок уже в процесі розробки.