Срыв сроков разработки сайта я вижу почти в каждом втором проекте, который достаётся мне на доработку после другого подрядчика или фрилансера. Причём дело редко в лени или недобросовестности исполнителя - чаще срабатывает одна и та же комбинация факторов: размытое техническое задание, доработки на ходу и интеграции, которые оказались сложнее, чем выглядели на этапе оценки. За практику я вёл сайты на Tilda, WordPress, кастомные веб-сервисы на React и Laravel, telegram-ботов и автоматизацию в n8n - и почти всегда просрочка укладывается в пять-шесть повторяющихся причин. Разберу их по порядку, с цифрами и примерами из своих проектов.
Нечёткое техническое задание - главный источник срыва сроков разработки сайта
Когда заказчик присылает бриф из трёх пунктов вроде «сделайте современный сайт для стройкомпании, посмотрите на конкурентов», оценка срока превращается в гадание. Я закладываю в такие проекты условные 4 недели на лендинг, но по факту третья неделя уходит на переписку «а можно сделать как у вот этого сайта, только по-другому» - и это нормальная часть процесса, если её не заложить в план заранее.
На практике недооценка объёма работ из-за размытого ТЗ добавляет к сроку от 30 до 50%. Причина простая: без зафиксированной структуры страниц, списка функций и референсов исполнитель начинает работу с одним пониманием проекта, а заказчик его видит иначе. Расхождение всплывает не на старте, а через две-три недели, когда переделывать уже дороже по времени, чем сделать заново.
Я на старте любого проекта - будь то сайт на WordPress от 60 000 ₽ или веб-сервис от 150 000 ₽ - фиксирую структуру, список экранов и функций письменно, до начала вёрстки. Это не гарантирует, что правок не будет, но убирает половину поводов для споров о сроках.
Постоянные правки и расширение объёма работ в процессе
Scope creep - это когда проект стартовал как лендинг, а к середине разработки в переписке появляются «давайте добавим личный кабинет», «а можно ещё фильтр по каталогу» и «неплохо бы интеграцию с CRM». Каждая такая правка сама по себе выглядит небольшой, но за месяц их набирается 15-20, и совокупно они добавляют к сроку не дни, а недели.
Пример из практики: интернет-магазин на WooCommerce стартовал с бюджетом и сроком под простой каталог с оплатой через эквайринг T‑Bank. В процессе заказчик добавил накопительные скидки, синхронизацию остатков с 1С и личный кабинет с историей заказов. Каждое дополнение обсуждалось отдельно, но в сумме проект вместо 5 недель занял 9 - при том, что моя часть работы по каждой отдельной правке укладывалась в оценку.
Единственный рабочий способ не терять контроль над сроками при расширении задачи - фиксировать каждую правку как отдельную задачу с собственной оценкой времени, а не «довесок» к уже согласованному сроку. Я так и делаю: новая функция получает отдельный срок и, если нужно, отдельную оплату, а не растворяется в общем дедлайне.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Интеграции с внешними сервисами: где чаще всего теряется время
Это отдельная больная тема, потому что интеграции почти никогда не зависят только от разработчика. Подключение эквайринга T‑Bank к WooCommerce технически занимает 3-5 дней активной работы: настройка модуля, тестовые платежи, обработка вебхуков о статусах заказа. Но ожидание доступов от банка - модерация магазина, подтверждение реквизитов, выдача боевых ключей - может растянуть весь этап до 2-3 недель, и это время разработчик физически не может ускорить.
То же самое с СДЭК: API для расчёта доставки и создания заказов подключается за 1-2 дня, но получение договора и тестового доступа у самой СДЭК иногда занимает больше времени, чем сама разработка. Я всегда закладываю такие внешние задержки в план отдельной строкой и предупреждаю заказчика заранее, чтобы он параллельно начал оформление документов с банком или службой доставки, а не ждал, пока до этого дойдёт очередь.
| Интеграция | Время разработки | Типичная внешняя задержка |
|---|---|---|
| Эквайринг T‑Bank в WooCommerce | 3-5 дней | 1-3 недели на модерацию и выдачу ключей |
| СДЭК (расчёт доставки, заказы) | 1-2 дня | от нескольких дней до 2 недель на договор и тестовый доступ |
| Кастомный скрипт для Tilda (CRM, оплата) | от 2 дней | зависит от скорости ответа CRM-провайдера по API-ключам |
| Telegram-бот с оплатой | от 5 дней | подключение платёжного провайдера через BotFather и банк |
Для типовых связок вроде Tilda с СДЭК или эквайрингом я держу под рукой готовые заготовки - в библиотеке готовых скриптов собраны рабочие решения под частые интеграции, что реально сокращает срок разработки на несколько дней по сравнению с написанием кода с нуля под каждый проект.
Проблемы на стороне заказчика: контент, доступы, согласования
Половина затянутых проектов, которые я видел, стопорится не на моей стороне. Тексты для сайта, фотографии товаров, доступы к хостингу и домену, согласование макета внутри компании заказчика - всё это регулярно превращается в узкое горлышко. У меня был случай, когда сайт на Tilda был технически готов за 2 недели, а публикация состоялась через 2,5 месяца - просто потому, что заказчик не мог собрать финальные тексты и фото от маркетингового отдела.
Отдельно стоит согласование: если решение по дизайну принимает не один человек, а комитет из трёх-четырёх сотрудников с разными вкусами, каждый круг правок растягивается на дни просто из-за переписки и созвонов. Я стараюсь на старте договориться об одном ответственном за финальное решение - это не всегда получается, но там, где получается, сроки держатся в разы точнее.
Доступы - ещё один частый тормоз: без ключей от домена, хостинга, личного кабинета в CRM или платёжной системы работа физически останавливается, а получение этих доступов иногда занимает у заказчика больше времени, чем сама разработка модуля, который на них завязан.
Недооценка сложности и технический долг
Задачи, которые выглядят просто на словах, часто скрывают неочевидную сложность. «Сделайте бота, который принимает заявки и пересылает в чат» - звучит на полдня работы, но если бот на aiogram должен вести диалог с несколькими состояниями (FSM), обрабатывать отмену на любом шаге, хранить историю в базе и не терять сообщения при перезапуске сервера, реальный срок вырастает до недели и больше.
То же с автоматизацией в n8n: связка из двух-трёх сервисов кажется тривиальной, пока не начинаешь обрабатывать ошибки - что делать, если внешний API не ответил, как избежать дублирования заявок при повторной отправке вебхука, как логировать сбои для отладки. Именно обработка edge-кейсов, а не основной сценарий, обычно съедает большую часть времени в таких задачах.
Кастомные скрипты для Tilda подвержены той же проблеме: простая доработка вроде валидации формы стоит от 3 000 ₽ и занимает пару часов, а комплексная интеграция с CRM и эквайрингом, где нужно синхронизировать статусы заказов в обе стороны, - это уже от 40 000 ₽ и совсем другой объём тестирования. Я всегда прошу описать сценарий целиком, включая нештатные ситуации, прежде чем называть срок - иначе оценка будет верна только для идеального случая, который на практике реализуется редко.
Как планировать сроки, чтобы не сорвать дедлайн
На своей практике я закладываю буфер 20-30% сверх базовой оценки - не потому что работаю медленно, а потому что часть времени всегда уходит на внешние факторы: модерацию платёжных систем, ожидание контента, согласования. Заказчику я говорю об этом буфере сразу, чтобы финальный срок не воспринимался как что-то «на всякий случай», а был частью реалистичного плана.
Ещё несколько вещей, которые реально снижают риск затянутого проекта:
- Фиксировать ТЗ письменно до старта работы, даже если это два-три абзаца с перечнем страниц и функций
- Разбивать проект на этапы с промежуточной приёмкой - так отклонение от плана видно через неделю, а не через месяц
- Заранее запускать процессы, которые не зависят от разработчика: заявку на эквайринг, договор с СДЭК, сбор контента
- Замораживать список функций после согласования ТЗ, а новые идеи оформлять как отдельный этап со своим сроком
- Держать одного ответственного за финальные решения по дизайну и контенту со стороны заказчика
Если непонятно, с чего начать оценку своего проекта или где именно у вас в плане скрыт риск затянуть сроки, разумнее один раз обсудить это предметно, чем потом разбираться постфактум с готовым, но не тем сайтом. Список актуальных услуг с ценами и форматами работы можно посмотреть на странице услуг.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Сколько времени в среднем занимает разработка сайта?
Зависит от типа сайта: лендинг на Tilda - от 1 до 3 недель, сайт на WordPress с каталогом - от 3 до 6 недель, интернет-магазин под ключ с интеграциями - от 6 до 10 недель, веб-сервис или SaaS на кастомном стеке - от 2 месяцев и больше. Эти сроки актуальны при зафиксированном ТЗ и без затяжных согласований на стороне заказчика.
Что делать, если разработчик уже сорвал сроки?
Сначала стоит выяснить причину: если дело в неотвеченных вопросах или неполученных доступах с вашей стороны, закрыть эти пробелы - часто это ускоряет процесс сильнее, чем давление на исполнителя. Если причина в самой разработке, попросите конкретный план по оставшимся задачам с датами, а не общее «скоро будет готово» - это сразу показывает, насколько реалистичен новый срок.
Как заранее заложить время на непредвиденные доработки?
Я закладываю буфер 20-30% сверх базовой оценки и обязательно проговариваю с заказчиком, что каждая новая идея, не входившая в исходное ТЗ, получает отдельную оценку срока, а не встраивается в уже согласованный дедлайн бесплатно и без пересмотра плана.
Можно ли ускорить разработку, если сроки поджимают?
Частично да - за счёт готовых решений под типовые задачи вместо разработки с нуля, распараллеливания независимых частей проекта между несколькими исполнителями и урезания второстепенного функционала до релиза первой версии. Но интеграции с внешними сервисами вроде банков или служб доставки ускорить получится не всегда - там сроки часто держит не разработчик, а сторона, выдающая доступы.