Клиент присылает бриф и сразу спрашивает: «Когда будет готово?» Я не отвечаю в тот же день. Это и есть ответ на вопрос, почему разработчик не называет срок сразу: любая цифра, брошенная без расчёта, превращается в обязательство, которое потом аукается сорванным дедлайном. Пока я молчу, я считаю сколько экранов в макете, какие сервисы подключаются, что уже есть у клиента и чего нет. На это уходит от нескольких часов до пары дней, и это время экономит нам обоим нервы позже.
По теме статьи
Готовое решение
AI-чатбот для сайта на Claude - отвечает как ваш менеджер, работает 24/7
Подключу к вашему сайту чат-бота на Claude API. Бот отвечает на вопросы клиентов голосом вашего бренда, знает каталог и условия доставки, забирает лиды в CRM или Telegram.
от25 000 ₽
Консультация
Разобраться перед стартом
Созвон 30-60 минут: разбор задачи, аудит текущего решения, рекомендации по стеку. В финале — документ с планом.
от3 000 ₽
Почему быстрая оценка срока разработки почти всегда обман
Когда разработчик называет срок за минуту после первого сообщения, происходит одно из двух. Либо он копирует цифру с прошлого похожего проекта, не проверив, действительно ли новый заказ похож на старый. Либо накидывает срок с запасом «на всякий случай», чтобы не оказаться виноватым, если что-то пойдёт не так. Оба варианта работают до первого нестандартного случая.
На практике заказ вида «нужен скрипт для Tilda, который ограничивает промокод одним использованием на человека» выглядит на пять минут работы. Пока не выясняется, что промокод нужно привязывать не к email, а к номеру телефона, что данные нужно хранить между сессиями, а не только в localStorage, и что у клиента уже есть похожий скрипт от другого разработчика, который надо сначала разобрать и понять, почему он не работает. Из пяти минут получается день работы, а озвученный сходу срок «сегодня успею» превращается в проблему для обоих.
Что я раскладываю на составляющие, прежде чем назвать дату
Прежде чем дать дату, я прохожу по списку и оцениваю каждый пункт отдельно, а не проект целиком.
- сколько экранов, страниц или сценариев нужно реализовать и какие из них типовые, а какие требуют кастомной логики
- какие внешние сервисы подключаются и есть ли у меня опыт работы именно с этой связкой
- что клиент уже сделал сам: макет, тексты, доступы, и что придётся выяснять или ждать от него
- сколько итераций правок обычно требуется на проектах такого типа
- тестирование на боевых данных, а не только в песочнице
Пункт с доступами часто затягивает старт сильнее, чем сама разработка. Если клиент присылает пароль от хостинга через два дня после того, как я всё оценил, эти два дня просто выпадают из графика, и итоговая дата сдвигается независимо от моей скорости.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Интеграции, которые сильнее всего меняют срок сдачи проекта
Отдельные задачи всегда съедают больше времени, чем кажется на старте брифа, потому что у каждого сервиса своя логика и свои грабли.
Эквайринг T‑Bank в связке с WooCommerce требует не только подключить платёжный модуль, а протестировать сценарии: успешную оплату, отмену, возврат, обработку вебхука о смене статуса заказа. Тестовый режим редко ведёт себя так же, как боевой, и переход на реальные ключи иногда всплывает новыми ошибками, которых не было в песочнице.
СДЭК добавляет расчёт стоимости по городам и весу, виджет выбора пункта выдачи и синхронизацию статусов доставки с личным кабинетом клиента. Простое «показать стоимость доставки» на деле оборачивается работой с API, у которого не всегда понятная документация и лимиты на количество запросов.
Telegram-бот на aiogram, который выглядит как обычный бот с кнопками, превращается в проект с состояниями пользователя, хранением истории диалога в базе и обработкой ситуаций, когда пользователь нажимает кнопку не в том порядке, в котором ожидал сценарий.
Автоматизация в n8n зависит от количества подключаемых сервисов и качества их API. Три сервиса с нормальной документацией собираются за пару дней, а один сервис без вебхуков и с авторизацией через устаревший протокол может занять больше времени, чем все остальные вместе.
Когда в проекте несколько таких блоков сразу, я обычно предлагаю сначала оценить объём работ отдельной консультацией, чтобы не гадать на глаз с интеграцией CRM и эквайринга в одном флаконе.
Оценка на глаз против оценки после декомпозиции
Разница между первой реакцией на бриф и реальным сроком после разбора задачи на подзадачи обычно такая.
| Задача | Оценка на глаз | Оценка после декомпозиции |
|---|---|---|
| Правка текста и картинки на Tilda | 1 день | 1 день |
| Интеграция эквайринга в WooCommerce | 3-5 дней | 10-14 дней |
| Виджет СДЭК с расчётом по ПВЗ | 2-3 дня | 5-7 дней |
| Telegram-бот на aiogram с базой | неделя | 3-4 недели |
| Автоматизация в n8n на 3 сервиса | пара дней | 5-8 дней |
Простые правки почти не расходятся в оценке, потому что там нечего декомпозировать. А там, где есть внешние сервисы, разница вырастает в разы, и именно эта разница объясняет, почему разработчик не называет срок сразу на сложных задачах.
Какой запас я закладываю на риски и правки
К посчитанному времени на саму разработку я добавляю запас на три вещи. Первая - правки после демонстрации: клиент почти всегда просит поменять пару деталей, увидев результат вживую, а не на словах. Вторая - тестирование на боевых данных, потому что связка сервисов, которая работает в тестовом режиме, не гарантирует такое же поведение с реальными платежами или реальным трафиком. Третья - время на переписку и согласования, которое редко укладывается в рабочий день клиента день в день.
Без этого запаса срок выглядит красиво в переписке и разваливается на второй неделе проекта, когда выясняется, что клиент не отвечал на вопрос три дня, а без ответа двигаться дальше было нельзя.
Что ускоряет точный ответ по срокам с моей стороны
Скорость, с которой я называю дату, напрямую зависит от того, что мне присылает клиент в первом сообщении. Готовое техническое задание, примеры похожих сайтов или ботов, доступы к текущему хостингу и админке, ответ на вопрос про бюджет: каждый из этих пунктов убирает один раунд уточняющих вопросов.
Когда бриф состоит из одной фразы «нужен сайт как у конкурента, но лучше», оценка занимает больше времени просто потому, что мне приходится сначала выяснять, что именно «лучше» значит для конкретного бизнеса: другой дизайн, другая скорость загрузки, другой набор функций или всё вместе.
Частые вопросы
Через сколько дней разработчик обычно называет точный срок?
На простые задачи, вроде доработки скрипта для Tilda, я отвечаю в течение рабочего дня. На проекты с интеграциями: CRM, эквайринг, доставка, обычно нужно от 1 до 3 дней, чтобы разобрать техническое задание и уточнить детали у клиента.
Можно ли получить хотя бы примерный срок сразу?
Могу назвать вилку по аналогии с похожими проектами, но честно предупрежу, что это ориентир, а не обязательство. Точная дата появляется после того, как я вижу макет, доступы и список интеграций.
Почему оценка меняется уже после начала работы?
Чаще всего из-за скрытых требований, которые всплывают на этапе тестирования. Например, эквайринг ведёт себя иначе в боевом режиме, чем в тестовом, или клиент присылает доступы с задержкой в несколько дней.
Что делать, если срок критичен для бизнеса и привязан к конкретной дате?
Скажите об этом сразу, в первом сообщении. Я перестрою порядок задач так, чтобы обязательные функции были готовы к дедлайну, а второстепенные доработки перенесу на следующий этап после запуска.