Как составить задачу на доработку сайта, чтобы её правильно оценили

01

Почему фраза «нужно доработать сайт» не даёт оценку

Разработчик оценивает не название функции, а объём изменений в конкретном сценарии. Формулировка «добавить форму на страницу» оставляет десятки неизвестных: на каких страницах она нужна, какие поля обязательны, куда уходят данные, как работают согласия, нужна ли защита от спама, сохраняются ли UTM-метки, что происходит после отправки и кто будет получать уведомления.

В практике поддержки сайтов на 1С-Битрикс типовая задача сначала выглядит как небольшая правка. Например, маркетинг просит «вывести цену в каталоге». При проверке выясняется, что цена зависит от региона, торгового предложения, авторизации, валюты и обмена с учётной системой. Это уже не одна правка шаблона, а набор бизнес-правил, которые надо подтвердить до оценки.

Техническое задание на доработку сайта не обязано объяснять PHP-код или архитектуру компонентов. Задача заказчика — точно описать текущую ситуацию, цель и ожидаемое поведение. Задача подрядчика — определить способ реализации, риски, трудозатраты и вопросы, которые ещё влияют на смету.

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

03

Соберите исходные данные до постановки задачи разработчику

Начинайте не с формулировки решения, а с фиксации факта. Укажите URL страницы и путь к ней, устройство и браузер, если ошибка проявляется не везде, дату наблюдения и частоту. Если проблема касается заявки, приложите номер заявки, время отправки, email для теста и статус в CRM. Это позволяет отделить ошибку вёрстки от сбоя обработчика, почты, API или прав доступа.

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

Доступы не следует отправлять в общий чат. В задаче достаточно перечислить, какие доступы потребуются: административная часть 1С-Битрикс, тестовый пользователь, CRM, аналитика или API. Перед передачей проверьте, что у аккаунта минимально необходимые права, а у подрядчика есть безопасный канал получения реквизитов.

04

Четыре части задачи, которые нужны для точной оценки

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

Отдельно запишите желаемый результат, не подменяя его способом реализации. Формула «добавить обработчик» понятна технически, но не отвечает, какие данные должен получить бизнес. Формула «в карточке лида сохраняются utm_source, utm_campaign и адрес страницы; значения доступны в отчёте» позволяет подрядчику предложить корректное решение.

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

05

Примеры требований для формы, каталога и посадочной страницы

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

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

Для посадочной страницы опишите целевое действие, источник трафика, состав блоков, мобильную версию и требования к SEO. Если страница создаётся под рекламную кампанию, определите, нужно ли закрывать её от индексации, какие цели аналитики должны срабатывать и как проверяются UTM. Инструкция по штатным возможностям платформы доступна в документации 1С-Битрикс, но поведение конкретного шаблона и интеграций следует проверять на проекте.

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

06

Как провести задачу от идеи до приёмки

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

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

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

1. 1

   Зафиксируйте цель. Определите бизнес-результат и владельца, который подтвердит готовность.

2. 2

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

3. 3

   Соберите доказательства. Добавьте URL, скриншоты, примеры и сведения о ранее выполненных проверках.

4. 4

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

5. 5

   Примите по сценариям. Выполните тесты из критериев и зафиксируйте результаты до закрытия задачи.

07

Риски, которые часто не попадают в первую формулировку

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

Особый риск — изменения в уже работающей форме. Добавленное поле может не передаваться в CRM, нарушить обязательность, не попасть в email-шаблон или исчезнуть после обновления компонента. Если на сайте несколько одинаковых форм, зафиксируйте, распространяется ли доработка на все экземпляры либо только на конкретный URL.

Срок «сегодня до 18:00» — тоже требование, а не комментарий. Сообщите, почему дата критична: запуск рекламы, рассылка, акция, изменение цен. Исполнитель сможет предложить безопасный минимальный объём к дедлайну и вынести второстепенные улучшения во второй этап.

08

Как оценить ответ подрядчика до запуска работ

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

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

Для сайта на 1С-Битрикс уточните, на каком окружении будут работы, есть ли резервная копия, как учитывается кеш и кто проверяет административную часть. Для задач с CRM и аналитикой заранее назначьте сотрудников, у которых есть доступ к карточкам сущностей и отчётам: разработчик не должен угадывать, какое поле бизнес считает правильным.

09

Когда задача готова к оценке

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

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

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