Как составить техническое задание на доработку сайта на 1С-Битрикс

Содержание:

Фраза «нужно доработать корзину» понятна владельцу сайта, но недостаточна для оценки разработчиком. Неясно, для каких пользователей меняется сценарий, какие данные участвуют, что должно происходить при ошибке и по каким признакам работа считается выполненной. Чем сложнее сайт на 1С‑Битрикс, тем дороже такая неопределённость.

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

Чем ТЗ на доработку отличается от ТЗ на новый сайт

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

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

Структура технического задания на доработку Битрикс

1. Контекст и бизнес-цель

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

2. Границы задачи

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

3. Текущее и ожидаемое поведение

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

4. Роли и права

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

5. Данные и интеграции

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

6. Нефункциональные требования

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

7. Критерии приёмки

Каждый критерий должен проверяться. Например: «авторизованный пользователь добавляет товар, выбирает доставку, оплачивает заказ; заказ создаётся в Битрикс и передаётся в CRM с указанными полями». Формулировка «корзина удобная» для приёмки не подходит.

Какие материалы приложить к задаче

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

Как приоритизировать несколько доработок

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

Типичные ошибки заказчика

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

Кто должен готовить ТЗ

Заказчик лучше знает бизнес-процесс, а технический специалист — ограничения системы. Поэтому рабочий документ обычно создаётся совместно. Если задача крупная или требует выбора архитектуры, можно заказать отдельную разработку технического задания и прототипов. Для реализации и сопровождения подходит услуга доработки сайта на 1С‑Битрикс.

Пример постановки задачи для формы заказа

Слабая формулировка: «добавить быстрый заказ». Рабочая формулировка указывает роли и результат: гость нажимает кнопку в карточке товара, вводит имя и телефон, принимает условия обработки данных; система проверяет обязательные поля, создаёт заказ с источником «быстрый заказ», отправляет событие в CRM и показывает номер обращения. Менеджер получает уведомление, а ошибка интеграции записывается в журнал и не скрывает заявку.

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

Как оформить требования к интеграциям

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

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

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

Оценка, этапы и управление изменениями

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

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

Мини-чек-лист перед отправкой ТЗ разработчику

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

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

Что делать дальше

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

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