Історія, з якої все почалося
Пам'ятаю свій третій проєкт на Freelancehunt. Замовник написав: «Потрібен сайт з адмінкою, нічого складного. Скільки часу забере?» Я подивився макети, поважно кивнув сам собі та відповів: «Тиждень».
Через тиждень я не спав третю ніч поспіль, доробляв інтеграцію з платіжкою, яку «забув» врахувати, відповідав на гнівні повідомлення замовника та пив уже шосту чашку кави. Проєкт здав через місяць. Грошей заробив менше, ніж якби пішов кур'єром.
Якщо ти зараз читаєш це й думаєш «ну я ж розумніший, зі мною такого не буде» — вітаю, ти вже в зоні ризику. Я теж так думав. І знаєш що? Через рік знову потрапив у ту саму пастку. І через два. Поки нарешті не зрозумів, що оцінка термінів — це не інтуїція, а навичка. Якої можна навчитися.
У цій статті розберемо, чому ми постійно помиляємось, як рахувати терміни нормально та що робити, якщо вже горить.
Чому ми вічно недооцінюємо терміни
Помилка планування — вона реальна
Є такий когнітивний баг, називається planning fallacy. Суть проста: люди систематично недооцінюють, скільки часу забере завдання. Навіть коли знають, що зазвичай недооцінюють. Навіть коли спеціально намагаються закласти запас.
Науковці перевіряли це десятки разів. Результат завжди один: середня людина впевнена, що впорається за X, а насправді за х1,5-2. Програмісти — не виняток. Скоріше навпаки.
Я ж досвідчений, я швидко
Це друга пастка. Коли бачиш завдання й думаєш: «А, тут React, форма, валідація — за день зроблю». І правда, написати код за день можна. Але проєкт — це не тільки код.
Це ще:
- дзвінки із замовником, де він каже: «Ой, а давайте ось тут поміняємо»,
- рев'ю та правки,
- баги, що вилазять у браузері, який ти не тестував,
- налаштування деплою, яке раптом забирає півдня,
- очікування відповіді замовника 3 дні, щоб погодити одну кнопку.
Тиск замовника
«А можна швидше?». «Конкурент сказав, що зробить за тиждень». «У нас горить, дуже треба до понеділка».
І ти, особливо якщо тільки починаєш і боїшся втратити замовлення, киваєш: «Так, звісно, до понеділка встигну». Хоча в голові прикинув, що потрібно три тижні.
Це найнебезпечніша помилка новачка. Бо потім ти підведеш не замовника, ти підведеш себе. Працюватимеш ночами, спатимеш по 4 години, нервуватимеш. І в підсумку все одно не встигнеш.
Що насправді входить у термін розробки
Коли замовник питає: «Скільки займе», він має на увазі: «Коли я отримаю готовий продукт». А «готовий продукт» — це:
- Чиста розробка — власне код. Це 40-60% часу, не більше.
- Проєктування — продумати архітектуру, обрати стек, накидати схему БД. Якщо пропустиш цей етап, втратиш утричі більше часу потім.
- Тестування та баги — закладай мінімум 20% від часу розробки. На клієнтських проєктах — 30%.
- Комунікація — дзвінки, листування, демо. На невеликому проєкті це легко з'їдає 5-10 годин.
- Правки та ітерації — замовник завжди щось змінює. Навіть якщо каже, що не буде.
- Деплой і налаштування оточення — домен, SSL, змінні оточення, CI/CD. Година? Півдня? Залежить від везіння.
- Документація — README, інструкції для замовника, передача проєкту.
- Буфер на форс-мажори, бо в замовника відвалиться платіжка у проді, у тебе зламається ноутбук або провайдер послуги оновить API без попередження.
Як рахувати терміни: робочі методи
Метод 1: декомпозиція
Найчесніший спосіб. Розбиваєш проєкт на максимально дрібні завдання — такі, щоб кожне забирало від 1 до 4 годин. Якщо завдання більше, його треба розбити ще.
Приклад. «Зробити форму реєстрації» — це погане завдання, у ньому може бути і 2 години, і 2 дні. Розбиваємо:
- зверстати форму за макетом — 2 години,
- налаштувати валідацію полів — 1,5 години,
- підключити API реєстрації — 2 години,
- обробити помилки сервера — 1 година,
- зробити підтвердження по email — 3 години,
- протестувати всі сценарії — 1,5 години.
Разом 11 годин замість абстрактних «ну, день-два». І ти вже бачиш, де конкретно може затягнутися.
Метод 2: три оцінки
Для кожного великого завдання прикидаєш три цифри:
- Оптимістична — якщо все йде ідеально.
- Реалістична — як зазвичай.
- Песимістична — якщо все зламається.
Формула: (Опт + 4×Реал + Песим) / 6. Це дасть зважену оцінку з урахуванням ризиків.
Звучить як магія, але працює. Особливо коли є завдання з невизначеністю, наприклад, інтеграція із чужим API, який ти вперше бачиш.
Метод 3: правило множення
Найпростіший спосіб для новачків. Рахуєш, скільки забере «по-чесному», а потім множиш на 1,5. Не тому що ти повільний, а тому що це життя.
Якщо зовсім немає досвіду в таких проєктах, множ на 2. Краще здати раніше терміну й стати героєм, ніж запізнитися та виправдовуватися.
Мій особистий фреймворк: як я оцінюю проєкт зараз
Розкажу покроково, як я роблю це зараз, після всіх набитих ґуль.
Крок 1. Не відповідаю одразу. Якщо замовник питає термін прямо в першому повідомленні, я ніколи не називаю цифру. Пишу: «Дайте мені 1-2 дні вивчити вимоги, я підготую детальну оцінку». Це одразу показує, що ти підходиш до справи серйозно, а не зі стелі.
Крок 2. Ставлю питання. До оцінки термінів у мене є чекліст:
- Чи є готові макети? Якщо ні — хто їх робить?
- Який стек бажаний? Чи є обмеження?
- Де хоститься? Хто налаштовує домен і SSL?
- Які інтеграції потрібні (платежі, розсилки, аналітика)?
- Скільки очікується раундів правок?
- Чи є референси (схожі проєкти)?
- Хто приймає роботу і в якому форматі?
Кожне неотримане питання — це +1 день до фінального терміну. Серйозно.
Крок 3. Декомпозую проєкт на завдання по 1-4 години. Записую в табличку (я використовую Notion, але підійде і Google Sheets).
Крок 4. Підсумовую години та множу на 1,5. Отримую «брудну» кількість годин.
Крок 5. Переводжу в календарні дні. Я працюю 5-6 продуктивних годин на день (не 8, давай реалістично). Якщо вийшло 60 годин роботи, це 12 робочих днів, тобто майже 3 календарні тижні з урахуванням вихідних.
Крок 6. Називаю замовнику діапазон, а не точну цифру. Не «3 тижні», а «3-4 тижні». І завжди додаю: «Термін залежить від швидкості погодження правок з вашого боку».
Як захищати терміни перед замовником
Найскладніше не порахувати термін, а відстояти його. Замовник тиснутиме. Це нормально, це його робота.
Не виправдовуйся. Якщо ти сказав «3-4 тижні», а замовник каже «треба за 2», не починай пояснювати, чому ти не встигнеш. Поясни, що можна встигнути за 2 тижні, але без ось цього, цього і цього. Дай замовнику вибір: або термін, або обсяг.
Покажи розбивку. Коли замовник бачить таблицю з 30 завданнями та годинами за кожним, сперечатися стає важче. Це не програміст зі стелі взяв, а конкретний план.
Прописуй у договорі. Мінімум: що входить у скоуп, скільки раундів правок включено, що вважається додатковою роботою та як тарифікується. Без цього scope creep (поступове розростання завдань) з'їсть твій прибуток.
На Freelancehunt, до речі, зручно використовувати Сейф — там можна окремо прописати етапи з різними сумами та строками. Це юридично захищає обидві сторони й дисциплінує комунікацію.
Одразу позначай, від чого залежить термін. «Термін 3 тижні за умови, що ви відповідаєте на запитання протягом 24 годин і погоджуєте правки протягом 48 годин». Це не нахабство, а професіоналізм.
Що робити, якщо вже горить
О'кей, ти прочитав усе вище, але проєкт усе одно затягується. Що робити?
Перше: визнай це якомога раніше. Найбільша помилка — мовчати до останнього, сподіваючись «надолужити на вихідних». Не надолужиш. Чим раніше скажеш замовнику, тим більше у тебе варіантів.
Друге: напиши замовнику чесно. Не «вибачте, я не встигаю, я поганий», а конструктивно: «Я бачу, що в початковий термін не вкладаємося з причин X та Y. Пропоную три варіанти:
А) Зсунути термін на N днів;
Б) Викинути з MVP функції Z та Q, решту здати вчасно;
В) Підключити додаткового розробника за +30% до бюджету».
Дай замовнику вибір.
Третє: репріоритизуй. Що з решти завдань реально критично для запуску, а що можна зробити в другій ітерації? Часто виявляється, що 30% завдань можна відкласти без шкоди для продукту.
Четверте: не працюй ночами. Знаю, звучить контрінтуїтивно. Але якість коду на третю безсонну ніч така, що ти створюєш більше багів, ніж закриваєш. Краще чесно зсунути термін, ніж зробити аби як і потім місяць фіксити.
Антипатерни: чого робити НЕ треба
«Зроблю на вихідних». Вихідні потрібні для відпочинку. Якщо ти систематично працюєш по суботах, у тебе проблеми з оцінкою термінів, а не з продуктивністю.
Фікс-прайс без чіткого ТЗ. Якщо замовник не може зрозуміло описати, що йому потрібно, не погоджуйся на фіксовану ціну. Тільки погодинна оплата або поетапна.
Три паралельних проєкти. Здається, що більше проєктів = більше грошей. На практиці — більше перемикань контексту, більше косяків, більше вигорання. Краще два проєкти з нормальними термінами, ніж три в режимі «горить».
Мовчання. Якщо щось іде не за планом, пиши замовнику одразу. Не через тиждень. Не «коли розберуся». Одразу. На Freelancehunt історія листування зберігається, і чесна, своєчасна комунікація завжди працює на твою репутацію та відгуки.
Інструменти, які допомагають
- Toggl або Clockify — для трекінгу реального часу. Через місяць побачиш, що завдання, які ти оцінював у 2 години, насправді забирають 4. Це перевертає оцінки.
- Notion або Linear — для декомпозиції проєктів на завдання.
- Google Calendar — блокуй час під конкретні завдання, а не «попрацюю над проєктом».
- Шаблони комерційних пропозицій — один раз зроби нормальний шаблон з розбивкою за годинами і перевикористовуй у ставках на Freelancehunt. Економить десятки хвилин на кожен відгук.
Головне
Оцінка термінів — це не про те, щоб вгадати. Це про те, щоб не брехати. Собі насамперед.
Коли ти кажеш замовнику «3 тижні», маєш сам у це вірити. А щоб вірити, потрібні цифри, декомпозиція, досвід і буфер. Не інтуїція і не бажання сподобатись.
І ще одне: перші пів року ти все одно помилятимешся. Це нормально. Головне, записувати реальні терміни та порівнювати з оцінками. Через 10-15 проєктів ти почнеш відчувати час. Через 30 — потраплятимеш у терміни з похибкою 10-15%.
А поки множ на 1,5. І не працюй ночами. Серйозно.