Хорошее техническое задание на интеграцию 1С описывает не только поля и кнопки. Оно отвечает на вопросы: где возникают данные, кто вправе их менять, что считать успешным обменом и как действовать при сбое. Без этих договорённостей даже технически исправное подключение превращается в источник ручной работы.
Начните с процесса, который хотите изменить
Фраза «связать сайт с 1С» не позволяет оценить проект. Для одного бизнеса это ночное обновление цен, для другого — передача заказов, резервирование товаров, работа с несколькими складами и уведомление покупателей. Опишите текущую работу сотрудника: какие документы он открывает, что переписывает, сколько систем проверяет и где возникают расхождения.
После этого сформулируйте целевой процесс. Например: покупатель оформляет заказ на сайте, менеджер видит его в учётной системе, подтверждает наличие, а покупатель получает статус. Это учебный сценарий, а не универсальная схема: у компании с предоплатой или заказными позициями последовательность будет другой.
У каждого процесса должен быть ответственный со стороны бизнеса. Бухгалтер согласует документы, склад — доступное количество, руководитель продаж — статусы, редактор — содержание карточек. Программист не должен самостоятельно решать, какая из спорящих цифр является правильной для компании.
Составьте паспорт систем
Укажите название и версию конфигурации 1С, наличие изменений и расширений, режим размещения, CMS сайта, используемые модули и ответственных за инфраструктуру. Отдельно перечислите ограничения: например, нельзя остановить продажи днём, обновления конфигурации выполняет другой подрядчик, доступ к серверу выдаётся только через администратора.
Паспорт нужен не для формальности. Один и тот же сценарий может потребовать разных решений в типовой конфигурации и в глубоко изменённой базе. Предварительная оценка должна содержать список допущений, которые будут проверены на обследовании, а не скрывать неизвестные обстоятельства внутри общей суммы.
Определите владельца каждого вида данных
Не назначайте одну систему главной «вообще». Товарное название для учёта может принадлежать 1С, а продающее описание и SEO-заголовок — сайту. Если выгрузка каждый раз заменяет весь объект, бухгалтерское название способно затереть подготовленный редактором материал.
| Данные | Что закрепить в ТЗ | Проверка результата |
|---|---|---|
| Товар | Постоянный идентификатор, правила создания и архивирования | Повторная выгрузка не создаёт дубль |
| Цена | Тип цены, валюта, налоги, округление | Контрольные позиции совпадают с согласованным источником |
| Остаток | Склады, резервы, страховой запас | Сайт показывает именно доступное к продаже количество |
| Заказ | Идентификатор, состав, доставка, оплата | Один заказ соответствует одному согласованному объекту учёта |
| Контент | Поля, которые обмен не должен менять | Ручное редактирование сохраняется после синхронизации |
Для каждого поля укажите обязательность и допустимые значения. Пустая строка, отсутствие поля и команда удалить значение — разные ситуации. Если это не различать, частичный пакет может неожиданно стереть изображения, характеристики или реквизиты.
Опишите события, а не только расписание
«Обмен раз в несколько минут» не объясняет, что именно запускает обновление. Нужны перечень событий и направление передачи: создание заказа, изменение количества, подтверждение оплаты, отмена, возврат. Не любое изменение должно немедленно отправлять целую базу на сайт.
Согласуйте допустимую задержку для каждого события. Остатки ходового товара и дополнительная фотография не имеют одинаковой срочности. Вместо обещания «мгновенно» задайте измеримый критерий для тестовой нагрузки и отдельно опишите поведение при временной недоступности систем.
Добавьте жизненный цикл документа. Кто может отменить заказ после резерва? Что произойдёт при частичной отгрузке? Как обрабатывается платёж, который пришёл после отмены? Эти вопросы помогают обнаружить противоречия до разработки интерфейса.
Обязательно включите ошибки и восстановление
Интеграция должна переживать повторный запрос, пропавшее соединение и некорректные данные. В ТЗ полезно зафиксировать принцип: повторная доставка одного события не создаёт второй заказ, а неуспешная строка пакета не исчезает без следа. Конкретный механизм разработчик выбирает с учётом архитектуры.
- Какие ошибки повторяются автоматически, а какие требуют решения сотрудника.
- Где видны время последнего успешного обмена и очередь проблемных объектов.
- Кому приходит уведомление и сколько информации достаточно для диагностики.
- Как повторить обработку после исправления данных без полной загрузки каталога.
- Как проверить согласованность систем после длительного перерыва.
Логи не должны становиться бесконтрольной копией базы клиентов. Укажите, какие идентификаторы нужны для расследования, кто имеет доступ и как ограничивается хранение. Пароли и токены в журнале не нужны даже для удобства поддержки.
Приложите тестовые данные и критерии приёмки
Подготовьте небольшой, но разнообразный набор: обычный товар, вариант с характеристикой, отсутствующая позиция, товар с несколькими единицами измерения, заказ со скидкой и отменённый заказ. Обезличенные примеры лучше абстрактного описания «любые товары» показывают сложность задачи.
Каждый критерий сформулируйте как наблюдаемый результат. Вместо «цены работают корректно» напишите: после изменения выбранного типа цены контрольная позиция получает согласованное значение; другие типы цен и редакторские поля не меняются. Для проверки повторов отправьте одно событие дважды и убедитесь, что бизнес-операция осталась одна.
Укажите среду приёмки, ответственных и способ фиксации замечаний. Желательно отделить ошибку относительно утверждённого сценария от нового пожелания: это позволяет обсуждать доработки без спора о том, «подразумевалась ли» функция.
Как выглядит достаточная структура документа
- Цели проекта и границы первой версии.
- Паспорт систем и схема текущего процесса.
- Матрица данных, идентификаторов и владельцев полей.
- События, направления обмена и жизненные циклы.
- Ошибки, повторная обработка, мониторинг и доступы.
- Тестовые примеры, критерии приёмки и порядок запуска.
- Передаваемые материалы и условия дальнейшего сопровождения.
Документ не обязан быть огромным. Его ценность в том, что заказчик, разработчик сайта и специалист 1С одинаково понимают результат. Если по одному пункту возможны три взаимоисключающих трактовки, объём текста ещё не превратился в ясность.
Перед запросом стоимости полезно собрать черновик этой структуры и провести короткий разбор со всеми участниками. Нерешённые вопросы лучше вынести отдельным списком с ответственными, чем выдавать предположения за согласованные требования.
Обсудим вашу задачу
Расскажите, что нужно запустить или улучшить. Помогу определить состав работ и следующий шаг. Подольск, Московская область; работаю с проектами по всей России.
