Как выбрать подрядчика на сайт и не нарваться на долгострой

Выбрать подрядчика на сайт и не нарваться на долгострой — значит оценивать не обещания, а процесс: есть ли техническое задание и договор с этапами, кому принадлежат права на сайт и исходники, как организована работа и что входит в поддержку после запуска. Главный риск заказчика — заплатить и получить бесконечную стройку или исполнителя, который исчез. Защищает от этого не «хороший человек», а прозрачные правила. Ниже — что проверить до подписания, какие сигналы должны насторожить, как выглядит честный процесс и что спросить на старте.

Что проверить до подписания договора

Решение о подрядчике принимают не по красивому сайту самого исполнителя, а по конкретным вещам, которые можно увидеть и проверить до подписи. Разберём их по порядку.

Первое — портфолио. Смотрите не на картинки, а на проекты, близкие по типу к вашему: интернет-магазин, корпоративный сайт, портал. Полезно спросить, какие задачи решались, что было сложным, как проект развивался после запуска. Если подрядчик показывает только «свежие обложки» и не может рассказать о задачах и ходе работ, это повод насторожиться.

Второе — техническое задание. ТЗ — это не формальность, а основа проекта. В нём описано, что именно делается, какие разделы и функции входят в объём, что считается результатом этапа. Без ТЗ любые договорённости живут только в переписке, и на этапе приёмки начинается спор о том, что «входило» и что «не входило».

Третье — договор. В нём должны быть этапы, сроки, стоимость и порядок приёмки. Оплата, привязанная к этапам, а не ко всему проекту сразу, снижает риск: вы платите за принятый результат, а не за обещание.

Четвёртое — права. Домен, хостинг, лицензия на систему управления сайтом, исходные файлы и доступы должны быть оформлены на вас. Если всё это остаётся у подрядчика, вы становитесь заложником: сменить команду или развивать сайт самостоятельно будет сложно.

Пятое — поддержка после запуска. Сайт не работает сам по себе. Как только он создан, его нужно наполнять, обновлять, следить за работоспособностью. Поэтому заранее выясните, что входит в поддержку, как она оформляется и по какому регламенту оказывается.

• портфолио с проектами вашего типа и рассказом о ходе работ
• техническое задание как основа объёма
• договор с этапами, сроками, стоимостью и порядком приёмки
• права на домен, хостинг, лицензию, исходники и доступы — у вас
• понятный регламент поддержки после запуска
• прозрачная коммуникация: где видно, что в работе

Эти пункты отличают системного исполнителя от того, кто «возьмёт и сделает». Чем прозрачнее процесс на входе, тем ниже риск долгостроя.

Красные флаги подрядчика

Некоторые сигналы должны насторожить ещё до договора. По отдельности они не приговор, но несколько сразу — серьёзный повод искать другого исполнителя.

Подозрительно низкая цена. Она часто означает, что в смету заложен минимум, а всё остальное «доделаем за доплату». В результате итоговая стоимость оказывается выше, чем у тех, кто изначально считал честно.

Нет договора или ТЗ. Работа «по ходу» и «на словах» — прямой путь к долгострою. Когда объём не зафиксирован, его невозможно ни оценить, ни принять.

Не передают права на сайт. Если код, домен и доступы остаются у исполнителя, вы не сможете ни сменить команду, ни развивать проект без него.

Размытые сроки и смета. Формулировки вроде «примерно к осени» и «в пределах бюджета» не дают вам никаких ориентиров и не защищают от роста затрат.

Нет поддержки после запуска. Исполнитель, который «сдал и ушёл», оставляет вас один на один с сайтом, который нужно обслуживать.

Только обещания, нет подтверждений. Если нечего показать и не о чем рассказать, кроме слов, — это не опыт, а намерение.

Один-два флага — повод задать прямые вопросы. Несколько — повод искать другого. Долгострой почти всегда начинается с проигнорированных сигналов на старте.

Как устроен прозрачный процесс

У надёжного подрядчика работа видна и предсказуема. Это не про харизму менеджера, а про устройство процесса.

Этапы. Проект разбит на части, у каждой — свой результат и своя оплата. Вы видите, за что платите на каждом шаге, и можете остановиться, если что-то идёт не так.

Трекер задач. Задачи живут в общем списке, а не в чьей-то голове. Вы видите, что в работе, что сделано и что ждёт вашего решения.

Регулярная связь. Отчёты и демонстрации промежуточных результатов вместо тишины на месяц. Чем раньше вы видите результат, тем дешевле исправить отклонение.

Фиксация изменений. Новые пожелания не растворяются в проекте, а оформляются отдельным этапом с оценкой. Так и вы, и исполнитель понимаете, что меняется объём и сроки.

Такой процесс защищает обе стороны: вы не платите за бесконечную стройку, подрядчик не работает бесплатно над растущими требованиями. Прозрачность и есть главная гарантия.

Почему «сделаем по ходу» почти всегда дороже

Когда объём не зафиксирован, каждое уточнение превращается в спор. Заказчик считает, что это «и так должно быть», исполнитель — что это новая работа. В итоге либо страдает качество, либо растёт смета, либо проект останавливается. ТЗ и этапы снимают этот конфликт заранее.

Что даёт общий трекер задач

Трекер — это не контроль ради контроля, а способ обеим сторонам видеть картину. Заказчик понимает, на каком этапе проект, и может вовремя дать обратную связь. Исполнитель фиксирует договорённости и не тратит время на пересказ статуса в переписке. Если трекера нет и прогресс обсуждается только на словах, вы не можете отличить «почти готово» от «ещё не начинали».

Вопросы, которые стоит задать на старте

Перед началом работы задайте прямые вопросы. По ответам многое видно: уверенные конкретные ответы — хороший знак, уклончивость и «давайте начнём, по ходу разберёмся» — тревожный.

• Как вы фиксируете объём и смету? Будет ли техническое задание?
• На кого оформляются домен, хостинг, лицензия и исходники?
• Как проект разбит на этапы и как привязана оплата?
• Что входит в поддержку после запуска и как она оформляется?
• Как я буду видеть прогресс и общаться с командой?
• Что происходит, если требования меняются в процессе?

Ответы на эти вопросы стоит зафиксировать письменно — в договоре или приложении к нему. Тогда договорённости не зависят от того, кто именно ведёт проект, и сохраняются, даже если состав команды изменится.

Как выбрать подрядчика: порядок оценки

Чтобы сравнивать исполнителей не по впечатлению, а по делу, задайте единый порядок оценки. Он помогает не поддаться первому сильному впечатлению и увидеть разницу между кандидатами.

Сначала соберите одинаковый набор данных по каждому подрядчику: портфолио, наличие ТЗ, условия договора, порядок оплаты, права на сайт, регламент поддержки. Затем оцените каждый пункт по одному и тому же вопросу: подтверждено документами или только на словах. И только после этого сравнивайте.

Такой порядок полезен тем, что убирает эмоции. Красивая презентация и обаятельный менеджер не заменяют письменных договорённостей. Если по ключевым пунктам ответы размыты, разница в цене уже не имеет решающего значения.

Сравнительная таблица: критерии выбора подрядчика

Сведите оценки в одну таблицу. Ниже — пример критериев и того, что считать хорошим и тревожным признаком.

Заполняйте таблицу по каждому кандидату отдельно. Если по нескольким строкам стоит тревожный признак, это не повод для торга, а повод продолжать поиск.

Учебный пример: как заказчик выбирал подрядчика

Данные в примере условные и приведены для иллюстрации подхода, а не как статистика.

Учебный пример. Небольшая компания планирует корпоративный сайт с каталогом услуг и формой заявки. Руководитель получил три предложения.

Первый исполнитель назвал самую низкую цену и пообещал «сделать быстро». На вопрос о ТЗ ответил, что «всё обсудим в процессе», договор предложил на одну страницу без этапов, а домен и лицензию — оформить на себя «для удобства».

Второй предложил среднюю цену, показал проекты похожего типа, но затруднился объяснить, что входит в поддержку, и не смог сказать, как заказчик будет видеть прогресс.

Третий предложил цену выше первого, но с письменным ТЗ, договором с этапами и оплатой по ним, оформлением домена и лицензии на заказчика и понятным регламентом поддержки. Прогресс — в общем трекере задач, промежуточные результаты показывают на демонстрациях.

Руководитель выбрал третьего. Входные условия: зафиксированный объём, этапы с приёмкой, права у заказчика. Проверка результата: на каждом этапе он принимал работу по ТЗ, видел задачи в трекере и получал доступы по мере готовности. Если бы требования менялись, они оформлялись бы отдельным этапом с оценкой, а не «растворялись» в проекте.

Такой подход не гарантирует, что проект пройдёт без сложностей, но он делает риски видимыми и управляемыми: понятно, за что вы платите, что уже сделано и что будет дальше.

Как проверить решение на своём проекте

Прежде чем подписывать договор, пройдите по своему набору критериев и убедитесь, что ответы не остались на словах.

• есть письменное ТЗ с описанием объёма и результата этапов
• в договоре указаны этапы, сроки, стоимость и порядок приёмки
• оплата привязана к принятым этапам, а не ко всему проекту сразу
• домен, хостинг, лицензия и исходники оформляются на вас
• описан регламент поддержки после запуска
• понятно, где видно прогресс и как согласуются изменения
• ответы на вопросы зафиксированы письменно

Если хотя бы часть пунктов не подтверждена документами, это не значит, что исполнитель плохой. Это значит, что риск долгостроя пока не закрыт и его нужно обсудить до подписания.

Ограничения и ошибки при реализации

Даже при хорошем подрядчике проект может пойти не так. Чаще всего причина — не в исполнителе, а в нерешённых вопросах на старте.

Ошибка первая — экономить на подготовке. Попытка сжать ТЗ и этапы ради скорости приводит к тому, что спорные места всплывают в самый неудобный момент.

Ошибка вторая — не фиксировать изменения. Новые пожелания, не оформленные отдельным этапом, размывают сроки и смету.

Ошибка третья — оставлять права у исполнителя. Это удобно ровно до того момента, когда нужно сменить команду или развивать сайт самостоятельно.

Ошибка четвёртая — недооценивать поддержку. Сайт — не одноразовая покупка. Его нужно наполнять и обслуживать, иначе вложения в создание не окупаются. Об этом стоит договориться заранее, а не после запуска.

Ошибка пятая — ждать, что сайт «сам начнёт работать». Доступность сайта круглосуточно не означает, что его сразу увидят и начнут использовать. Чтобы сайт приносил результат, им нужно заниматься — и это отдельная работа, которую стоит планировать.

Ограничения тоже важно понимать. Никакой подрядчик не может гарантировать конкретный коммерческий результат от сайта: он зависит от продукта, спроса и того, как вы развиваете проект. Подрядчик отвечает за качество работ и соблюдение договорённостей, а не за продажи.

Что делать после запуска: передача прав и поддержка

После запуска начинается не финал, а следующий этап. Убедитесь, что вам переданы все доступы: к домену, хостингу, системе управления сайтом, лицензии. Проверьте, что вы можете войти и что права оформлены на вас.

Договоритесь о поддержке заранее. Она может включать обновления, резервное копирование, исправление ошибок и доработки. Регламент поддержки лучше зафиксировать письменно: что входит, как оформляется заявка, в какие сроки она рассматривается. Полезно заранее продумать, как организовано резервное копирование сайта на Битрикс — хранение и восстановление, чтобы данные можно было восстановить при необходимости.

Если сайт работает на Битрикс, отдельного внимания требуют доступы, данные и настройки — их стоит держать в порядке и понимать, кто за что отвечает. Об этом подробнее в материале про администрирование сайта на Битрикс — доступы, данные и настройки.

Когда проект развивается, полезно периодически проверять его состояние. Плановый аудит сайта на Битрикс: как проходит и что вы получите помогает увидеть, что требует внимания, до того как это станет проблемой. А если вы только планируете новый проект, стоит заранее описать задачу и оценить разработку сайтов на Битрикс — так проще сравнивать предложения подрядчиков.

FAQ