Когда клиент рассылает одно и то же техзадание трём-четырём подрядчикам, разные сроки у подрядчиков в ответах выглядят так, будто люди читали разные документы. Один пишет «сделаю за 3 дня», второй называет две недели, третий сразу закладывает полтора месяца. Разброс в ценах при этом обычно ещё заметнее. За десять с лишним лет заказной разработки я вижу это с обеих сторон стола: и как исполнитель, который считает оценку, и как человек, который сам нанимает смежников на часть проекта. Разброс не значит, что кто-то жулик, а кто-то честный. Просто в короткую строчку «прикрутить СДЭК» или «сделать бота» каждый подрядчик кладёт свой набор допущений, и увидеть их в самой заявке почти невозможно.
Откуда берутся разные сроки у подрядчиков на одинаковое ТЗ
Возьмём реальный пример: заказчик просит «подключить доставку СДЭК на Tilda». Для одного подрядчика это значит вставить готовый виджет расчёта стоимости, который отработает за 2-3 дня. Для другого это интеграция с личным кабинетом СДЭК через API: расчёт по фактическому весу и габаритам товаров, синхронизация статусов заказа, обработка ошибок, когда сервис СДЭК не отвечает. На такую работу закладывают 10-15 дней. Оба подрядчика правы в своей логике, просто ТЗ было прочитано по-разному, потому что в нём не было решающих деталей: сколько товарных позиций, нужен ли расчёт по нескольким складам, что делать при сбое API.
То же самое с формулировкой «настроить приём платежей». Через готовый виджет T‑Bank на Tilda это несколько часов работы. А «принимать оплату на сайте на WooCommerce с рекуррентными платежами и частичными возвратами» - это уже интеграция на уровне бэкенда, обработка вебхуков об изменении статуса платежа и тесты на боевых картах в песочнице банка. Разница в сроке между этими двумя формулировками десятикратная, хотя заказчик в переписке мог одной фразой описать обе задачи как «подключить оплату».
Что подрядчик на самом деле закладывает в оценку срока
Когда я называю срок, в него входит не только написание кода. Обычно это несколько слоёв, и подрядчики расходятся именно в том, сколько слоёв они посчитали.
Технический аудит перед оценкой
Прежде чем сказать «три дня», нужно понять, во что встраивается доработка. Сайт на Tilda с рукописными скриптами в блоке T123 и сайт с аккуратным Zero Block устроены по-разному, и время на то, чтобы разобраться в чужом коде, у разных исполнителей отличается на порядок. Кто-то закладывает на аудит полдня, кто-то вообще его пропускает и потом досчитывает срок по ходу работы, из-за чего изначальная оценка не совпадает с реальностью.
Резерв на тестирование и правки
Опытный подрядчик закладывает в срок не только написание кода, но и проверку на граничных случаях: что будет, если СДЭК не вернул ответ за секунду, что если клиент ввёл нулевой вес товара, что если платёж завис в статусе «в обработке». Junior-исполнитель или фрилансер, который стремится показать самый низкий срок, чтобы выиграть тендер, часто просто не учитывает эту часть работы. Отсюда и берутся сроки в три раза короче: оценка честная, но она покрывает только happy path, без сценариев сбоев.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Опыт и стек: почему один и тот же скрипт занимает разное время
Разница в сроках сильно зависит от того, делает ли исполнитель что-то знакомое или каждый раз пишет с нуля. У меня есть наработки под типовые сценарии на Tilda: зоны доставки, ограничение промокодов, конвертер валют. Если задача клиента ложится в этот шаблон, доработка занимает 1-3 дня. Если нужна логика, которой раньше не делал, время увеличивается в 3-5 раз, потому что часть его уходит не на написание кода, а на проектирование решения.
То же с Telegram-ботами на aiogram. У подрядчика, который уже собрал десяток ботов, есть заготовки под FSM-состояния, обработку платежей через Telegram Payments, логирование ошибок. Он соберёт бота на 5-6 диалоговых сценариев за полторы-две недели. Тот, кто делает первого бота в жизни, потратит на то же самое месяц, просто потому что параллельно разбирается с архитектурой самой библиотеки.
С автоматизацией в n8n похожая картина. Если у подрядчика уже настроена связка с нужной CRM или мессенджером, сценарий из 10-15 нод собирается за 2-3 дня. Если для интеграции нужен кастомный HTTP-запрос к API, которого раньше не было в практике, время растёт, потому что приходится разбираться в документации стороннего сервиса и тестировать граничные случаи вручную. Если хочется сразу увидеть все мои направления и прикинуть, к чему ближе своя задача, проще посмотреть услуги и с чем я работаю одним списком, чем гадать по переписке.
Скрытые риски, которые один подрядчик учитывает, а другой нет
Часть разброса в сроках связана не с квалификацией, а с тем, что подрядчики по-разному оценивают риск. Например, «полечить сайт от вирусов» - формулировка, которая скрывает огромный диапазон работ. Если заражён один файл и сайт на актуальной версии CMS, чистка и закрытие дыры занимают день-два. Если заражение массовое, в базе данных сидят скрытые редиректы, а движок не обновлялся три года, восстановление растягивается на полторы-две недели, потому что приходится вручную проверять каждый файл и таблицу. Поэтому такую цену я всегда называю «от» и сразу обозначаю, что итоговый срок зависит от уровня заражения, а не фиксирую его заранее.
Похожая история с легаси-кодом на Tilda: если на сайте уже стоят чужие скрипты без комментариев и без версии в git, часть срока уходит не на саму задачу, а на то, чтобы не сломать то, что уже работает. Подрядчик, который это закладывает, называет более длинный срок и оказывается ближе к реальности, чем тот, кто оценил только чистую разработку.
Как сравнивать предложения подрядчиков без иллюзий
Когда получаешь три оценки с разбросом в разы, полезно понимать порядок цифр, который встречается на рынке, и сверять свою ситуацию с ним, а не ориентироваться только на самое дешёвое предложение.
| Задача | Реалистичный срок на рынке | От чего зависит разброс |
|---|---|---|
| Кастомный скрипт для Tilda (точечная доработка) | 1-5 дней | Есть ли похожая заготовка, насколько чист исходный код блока |
| Комплексная интеграция (CRM, эквайринг, СДЭК) | 2-6 недель | Число систем, которые нужно связать, и объём тестирования сбоев |
| Telegram-бот на aiogram | 1-4 недели | Количество диалоговых сценариев, есть ли готовые FSM-заготовки |
| Автоматизация в n8n | 3 дня - 3 недели | Число нод и то, знаком ли исполнитель с API стороннего сервиса |
| Интернет-магазин под ключ | 4-10 недель | Число товарных категорий и интеграций оплаты и доставки |
Это ориентиры по рынку в целом, у разных студий и фрилансеров цифры внутри диапазона будут прыгать. Если предложение выбивается за верхнюю границу диапазона в разы, стоит спросить, что именно туда заложено. Чаще всего там либо избыточный резерв на риски, либо задача понята шире, чем вы её видите.
Как получить от подрядчика реалистичный срок, а не выдуманный
Самый рабочий способ сократить разброс в оценках, который я использую и сам, когда нанимаю смежников: просить не срок, а разбивку по этапам. «Аудит текущего кода - 1 день, интеграция API - 3 дня, тестирование сценариев сбоя - 2 дня» читается совсем иначе, чем голое «неделя». По такой разбивке видно, что именно подрядчик посчитал, а что пропустил.
Второй момент, который экономит нервы: спрашивать не абстрактный срок, а срок на конкретный похожий проект, который подрядчик уже сдал. Если человек делал интеграцию СДЭК на Tilda три раза, он назовёт цифру с меньшей погрешностью, чем тот, кто прикидывает по ощущениям. И третье: если задача плохо описана самим заказчиком, никакая оценка подрядчика не будет честной, потому что он оценивает не работу, а свою интерпретацию текста. В таком случае разумнее сначала оплатить короткую консультацию, чтобы разложить задачу на этапы и получить реалистичный срок под конкретную формулировку, а не под то, что каждый прочитал по-своему.
Частые вопросы
Почему один подрядчик даёт срок в три раза короче другого?
Чаще всего потому, что в короткий срок заложен только happy path: написание кода без учёта тестирования граничных случаев, обработки сбоев внешних API и совместимости со старым кодом на сайте. Такой срок не обязательно обман, просто в нём меньше объёма работы, чем закладывает подрядчик с более длинной оценкой.
Можно ли доверять самому короткому сроку из нескольких предложений?
Можно, но сначала стоит спросить, что именно входит в эту оценку: включено ли тестирование, кто чинит правки после сдачи и что будет, если в процессе всплывут детали, которых не было в ТЗ. Если ответ расплывчатый, короткий срок с высокой вероятностью вырастет уже в процессе работы.
Как понять, что срок в предложении подрядчика реалистичный?
Попросите разбивку по этапам с указанием, что входит в каждый: аудит, разработка, тестирование сценариев сбоя. Если подрядчик может расписать это за пару минут, значит он уже прикидывал задачу детально, а не назвал число на глаз.
Стоит ли фиксировать срок в договоре, если оценки разошлись в разы?
Стоит, но вместе со сроком фиксируйте и то, что именно в него входит, вплоть до перечня сценариев тестирования. Тогда при отклонении от плана будет понятно, кто и почему промахнулся: заказчик не описал деталь в ТЗ или подрядчик не учёл её при оценке.