Как оценить стоимость доработки сайта до обращения к подрядчику

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

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

От чего зависит стоимость доработки сайта

Цена складывается не только из количества страниц или часов работы специалиста. Две внешне похожие задачи могут отличаться по сложности в несколько раз. Например, заменить текстовый блок на странице можно за несколько часов, а добавить на этой же странице калькулятор с передачей данных в CRM потребует проектирования, программирования, настройки обмена и тестирования.

Перед оценкой подрядчик обычно учитывает несколько факторов:

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

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

Как разложить задачу на понятные работы

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

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

Для каждой задачи подготовьте короткую карточку:

1. Проблема. Что сейчас мешает пользователю или сотруднику компании.
2. Изменение. Какой конкретный элемент нужно добавить, убрать или переделать.
3. Место. Какие страницы, разделы или шаблоны затрагиваются.
4. Результат. Как вы поймёте, что работа выполнена.
5. Ограничения. Что нельзя менять, какие сервисы нужно сохранить, к какому сроку всё должно быть готово.

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

Какие бывают доработки и сколько они обычно занимают

Ниже приведены ориентиры по рынку для типичных задач. Это не прайс-лист и не окончательная смета. Реальный срок зависит от платформы, качества текущего кода, числа страниц и того, требуется ли согласование дизайна.

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

Если подрядчик называет срок без уточнения платформы, доступа к сайту и состава результата, относитесь к такой оценке как к предварительной. Для принятия решения она полезна только как порядок величины.

Как оценить стоимость доработки сайта по этапам

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

1. Обследование и подготовка

На этом этапе специалист изучает сайт, проверяет доступы, определяет технологию, смотрит структуру шаблонов и выявляет ограничения. Для небольшой правки обследование может занять 1-3 часа. Для интернет-магазина или сайта со сложными интеграциями потребуется от одного до нескольких рабочих дней.

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

2. Проектирование решения

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

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

3. Дизайн и вёрстка

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

Стоимость здесь зависит от числа уникальных макетов и состояний, а не только от количества страниц. Один экран с несколькими сценариями иногда требует больше работы, чем несколько простых информационных страниц.

4. Программирование и настройка

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

5. Тестирование и публикация

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

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

Как понять, нужна ли полная переделка или достаточно точечной правки

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

Точечная доработка обычно оправдана, если:

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

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

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

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

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

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

Пароли не стоит отправлять в обычном письме или общем чате без необходимости. Сначала согласуйте безопасный способ передачи доступа и его уровень. Для предварительной оценки часто достаточно демонстрации экрана или временной учётной записи с ограниченными правами.

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

Как сравнить предложения подрядчиков

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

Попросите каждого подрядчика оформить смету в одинаковой структуре:

1. обследование и постановка задачи;
2. проектирование или подготовка макетов;
3. вёрстка и программирование;
4. настройка интеграций;
5. перенос изменений на рабочий сайт;
6. тестирование и исправление ошибок;
7. документация или инструкция для сотрудников;
8. условия поддержки после сдачи.

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

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

Типичные ошибки при самостоятельной оценке

Ошибка 1. Оценивать задачу по числу экранов

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

Ошибка 2. Не учитывать мобильную версию

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

Ошибка 3. Считать только разработку

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

Ошибка 4. Ставить все задачи в один приоритет

Исправление ошибки в форме заказа обычно важнее декоративной анимации. Разделите задачи на критические, полезные и желательные. Такой список позволит запустить важные изменения раньше и не потратить весь бюджет на второстепенные улучшения.

Ошибка 5. Не учитывать старые данные

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

Ошибка 6. Соглашаться на неопределённое «сделаем за неделю»

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

Частые вопросы

Можно ли узнать точную стоимость до передачи доступов?

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

Что дешевле, исправить старый сайт или создать новый?

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

Нужно ли заказывать технический аудит перед каждой доработкой?

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

Как заложить резерв в бюджет?

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

Кто должен писать техническое задание?

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

Когда нужна не доработка, а поддержка?

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

Что делать: короткий план

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

1. Составьте список проблем, которые мешают продажам, работе сотрудников или продвижению.
2. Для каждой проблемы опишите конкретное изменение, место размещения и ожидаемый результат.
3. Разделите задачи на обязательные, важные и желательные.
4. Соберите сведения о CMS, интеграциях, доступах, аналитике и ограничениях проекта.
5. Подготовьте скриншоты, примеры и исходные материалы, которые понадобятся подрядчику.
6. Запросите смету с отдельными этапами: обследование, проектирование, разработка, проверка и публикация.
7. Сравните предложения по составу работ, срокам и условиям исправления ошибок, а не только по общей цене.
8. Зафиксируйте результат, критерии приёмки, порядок согласований и стоимость дополнительных задач.
9. После публикации проверьте заявки, аналитику, мобильную версию и связанные страницы.

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

Полезные страницы по теме

• Создание сайтов под ключ