Как написать ТЗ на доработку системы 1С?

Доработка 1С редко проваливается из-за сложности программирования. Намного чаще проблемы начинаются раньше — на этапе составления технического задания. Если ТЗ написано поверхностно, разработчик делает одно, заказчик ожидает другое, сроки растягиваются, а бюджет выходит из-под контроля.
Чтобы избежать конфликтов и бесконечных переделок, в техническом задании должны быть обязательные разделы. Отсутствие любого из них может превратить даже небольшую доработку в источник постоянных проблем.
1. Опишите бизнес-задачи
Самая распространённая ошибка — сразу переходить к тому, «какие кнопки добавить». Сначала необходимо ответить на вопрос: зачем нужна доработка?
Например:
— сократить время обработки заказов;
— автоматизировать расчёт премий;
— исключить ошибки ручного ввода;
— подготовить данные для регламентированной отчётности.
Когда разработчик понимает цель, он может предложить более эффективное решение и избежать реализации ненужного функционала.
2. Зафиксируйте текущий процесс
Перед изменением системы важно зафиксировать, как она работает сейчас.
В ТЗ желательно указать:
— используемые документы и справочники;
— последовательность действий пользователей;
— существующие ограничения;
— проблемные места процесса.
Без описания текущей логики высок риск сломать уже работающие механизмы или создать конфликт с другими доработками.
3. Опишите будущий процесс
Это ядро любого ТЗ. Необходимо пошагово описать:
— кто выполняет действие;
— в каком разделе программы;
— какие данные вводятся;
— что должно происходить после выполнения операции;
— какие проверки должны срабатывать.
Формулировка «система должна автоматически рассчитывать показатель» недостаточна. Нужно описать алгоритм расчёта, источники данных и ожидаемый результат.
4. Предусмотрите условия и исключения
Большинство ошибок возникает не в стандартных сценариях, а в нестандартных. В ТЗ обязательно нужно предусмотреть:
— отмену операций;
— корректировки задним числом;
— неполные данные;
— дублирующие записи;
— ошибки пользователя;
— особые категории документов или клиентов.
Чем подробнее описаны исключения, тем меньше сюрпризов появится после запуска.
5. Укажите изменяемые объекты конфигурации
Следует явно указать, какие объекты затрагивает доработка:
— документы;
— справочники;
— регистры сведений;
— регистры накопления;
— отчёты;
— обработки;
— печатные формы.
Это помогает оценить объём работ и снизить риск влияния изменений на другие подсистемы.

6. Приложите макеты экранов и примеры данных
Текстовые описания часто трактуются по-разному. Поэтому полезно приложить:
— скриншоты;
— схемы интерфейсов;
— примеры заполнения документов;
— образцы печатных форм;
— таблицы с тестовыми данными.
Один рисунок интерфейса способен заменить несколько страниц пояснений.
7. Определите права доступа
Многие вспоминают о безопасности уже после внедрения. В ТЗ необходимо определить:
— кто видит новый функционал;
— кто может изменять данные;
— кто имеет право удалять записи;
— какие роли получают доступ к новым объектам.
Без этого можно получить либо избыточные права, либо невозможность пользоваться разработанным решением.
8. Опишите требования к интеграциям
Если доработка взаимодействует с другими системами, нужно заранее описать:
— источники данных;
— формат обмена;
— периодичность синхронизации;
— правила обработки ошибок;
— ответственных за интеграцию.
Фраза «нужно выгружать данные в другую систему» не является полноценным требованием.
9. Определите критерии приёмки
Один из самых важных разделов. Для каждой функции необходимо определить, как будет проверяться результат.

Например:
— при проведении документа создаётся запись в регистре;
— отчёт формируется менее чем за 30 секунд;
— сумма рассчитывается по указанной формуле;
— пользователю выводится определённое сообщение об ошибке.
Если критериев приёмки нет, спор о том, выполнена задача или нет, практически неизбежен.
10. Укажите ограничения по срокам и производительности
Некоторые доработки работают корректно на тестовой базе, но начинают тормозить в рабочей системе. Поэтому стоит заранее указать:
— ожидаемое количество пользователей;
— объём данных;
— допустимое время выполнения операций;
— требования к скорости формирования отчётов.
Эти параметры напрямую влияют на архитектуру решения.
Хорошее ТЗ для доработки 1С — это не формальность и не бюрократия. Это инструмент, который помогает заказчику получить нужный результат, а разработчику — выполнить работу без постоянных уточнений и переделок.
Если в документе есть бизнес-цель, описание текущего и будущего процессов, исключения, права доступа, требования к интеграциям и понятные критерии приёмки, вероятность успешного внедрения возрастает в разы. Именно эти пункты превращают техническое задание из набора пожеланий в рабочий инструмент управления проектом.