Разработка и Конфигурация · 11 мин
Как написать ТЗ для 1С-программиста
Как составить техническое задание для 1С-программиста: структура ТЗ, описание доработок, сценарии, приёмка, типичные ошибки и готовый шаблон разделов.
Техническое задание — главная причина, по которой доработка 1С получается с первого раза или превращается в бесконечные правки. Программист не знает ваших бизнес-процессов, а вы не обязаны знать внутреннее устройство конфигурации. ТЗ — это мост между «нам нужно, чтобы счёт формировался сам» и конкретным алгоритмом, который можно запрограммировать и проверить.
Хорошее ТЗ не обязано быть длинным. Для небольшой доработки достаточно одной-двух страниц, если в них есть ответы на четыре вопроса: что сейчас происходит, что должно получиться, в каких объектах конфигурации это происходит и как проверить результат. Плохое ТЗ — это фраза «сделайте удобно» или скриншот с надписью «тут не работает».
Ниже — практическая структура документа, правила формулировок и способы проверить ТЗ до передачи в работу. Материал подходит и для постановки задач штатному специалисту, и для работы с фрилансером или франчайзи.
Определите, какая задача стоит перед доработкой
Прежде чем писать ТЗ, ответьте себе на вопрос: какую бизнес-проблему решает доработка. «Менеджеры тратят 20 минут на ручное заполнение счёта» — это проблема. «Нужна кнопка в документе» — это уже решение, и оно может быть не лучшим. Если в ТЗ описана проблема, программист может предложить более простой или типовой механизм, о котором вы не знали.
Отдельно зафиксируйте, кто будет пользоваться результатом: роль пользователя (менеджер, кладовщик, бухгалтер), его права, рабочее место. Одна и та же доработка для разных ролей может потребовать разного интерфейса и разных ограничений по доступу.
Проверьте, не решается ли задача типовыми средствами. Настройка правил заполнения, дополнительные реквизиты, варианты отчётов, расширения конфигурации — значительная часть «доработок» на самом деле делается настройкой без изменения кода. Это дешевле, быстрее и не ломает обновления.
Как выбрать действие
Структура ТЗ: обязательные разделы
Рабочий минимум для большинства задач — шесть разделов. Их можно оформить в любом текстовом редакторе или таск-трекере, важна не форма, а полнота.
- Цель и контекст. Что заставило ставить задачу, кто пострадал от текущей ситуации, какой эффект ожидается.
- Текущее поведение. Как процесс работает сейчас: шаги пользователя, используемые документы и отчёты, где возникает проблема.
- Целевое поведение. Как должно работать после доработки — по шагам, от лица пользователя.
- Объекты конфигурации. Какие документы, справочники, регистры и отчёты затрагиваются, с точными названиями из вашей базы.
- Данные и правила. Откуда берутся значения, формулы расчёта, условия, исключения, поведение при пустых или ошибочных данных.
- Критерии приёмки. Проверяемый сценарий: «если сделать X, то система должна показать Y».
Для мелких задач разделы можно сжать до нескольких предложений, но ни один не стоит пропускать полностью. Чаще всего исполнители «угадывают» именно правила расчёта и поведение в исключительных ситуациях — и именно там потом возникают претензии.
Как описать сценарий работы пользователя
Сценарий — ядро ТЗ. Пишите его нумерованным списком от лица конкретной роли: «Менеджер открывает документ «Заказ клиента», заполняет контрагента, нажимает кнопку «Создать счёт»…». Каждый шаг — одно действие и одна реакция системы.
Обязательно опишите ветвления: что происходит, если условие не выполнено. Например: «Если у контрагента не заполнены банковские реквизиты, система выводит предупреждение и не создаёт счёт». Именно отсутствие описания исключений — главный источник багов: программист реализует «счастливый путь», а все остальные случаи ведут себя непредсказуемо.
Полезно приложить примеры на реальных данных: скриншот заполненного документа, пример итогового отчёта или печатной формы, образец файла для загрузки или выгрузки. Пример часто заменяет абзац текста и исключает двойное толкование.
Пример формулировки требования
Слабая формулировка: «Нужно, чтобы скидка считалась автоматически». Сильная: «В документе «Заказ клиента» при изменении суммы по строке товара система должна пересчитывать скидку: при сумме строки от 100 000 руб. — 5%, от 300 000 руб. — 10%. Скидка записывается в поле «ПроцентСкидки» табличной части «Товары» и участвует в типовом расчёте суммы. Ручное изменение процента скидки пользователем должно оставаться возможным».
Формулировки, которых нужно избегать
Оценочные слова — главный враг ТЗ. «Удобно», «быстро», «красиво», «как в другой программе» не проверяемы и каждый понимает их по-своему. Заменяйте их на измеримые признаки: «отчёт строится не дольше 30 секунд на данных за месяц», «кнопка расположена в командной панели документа», «форма повторяет макет из приложенного файла».
Избегайте и технических решений, навязанных без необходимости. Если вы не разработчик, не пишите «сделать через запрос к регистру накопления» — опишите, какие данные нужны и в каком виде. Выбор механизма реализации оставьте исполнителю, иначе вы берёте на себя ответственность за архитектурные ошибки.
Не смешивайте в одном ТЗ несколько независимых задач. Доработка печатной формы и новый отчёт по складам — два разных задания с разными сроками и приёмкой. Смешение усложняет оценку, тестирование и приёмку результата.
Критерии приёмки и тестирование
Критерии приёмки превращают ТЗ из пожелания в договорённость. Формат простой: действие → ожидаемый результат. Например: «Создать заказ с суммой строки 150 000 руб. → в поле «ПроцентСкидки» появляется 5, сумма строки уменьшается на скидку». Напишите 5–10 таких проверок, включая минимум две на ошибочные или граничные ситуации.
Договоритесь о среде тестирования заранее. Доработка должна сначала разворачиваться на копии базы — никогда не внедряйте изменения сразу в рабочую. В ТЗ или сопроводительном письме зафиксируйте: на какой версии платформы и конфигурации ведётся разработка, кто делает копию базы, кто и в какие сроки проводит тестирование.
Отдельный пункт — поведение при обновлении конфигурации. Если доработка меняет типовые объекты, уточните у исполнителя, как она переживёт обновление релиза. Предпочтительный вариант для большинства задач — расширение конфигурации: оно не снимает базу с поддержки и значительно упрощает обновления.
Оформление, согласование и изменения
Храните ТЗ в одном месте с версионированием: таск-трекер, общий документ с историей правок, папка с файлами вида «ТЗ_задача_v2». Устные уточнения в мессенджере фиксируйте в тексте ТЗ отдельной правкой — иначе через месяц никто не вспомнит, о чём договаривались.
Перед передачей в работу покажите ТЗ двум людям: будущему пользователю доработки (он найдёт неточности в сценарии) и исполнителю (он задаст вопросы, ответы на которые нужно вписать в документ). Раунд вопросов до старта работ — нормальная и желательная практика, а не признак плохого ТЗ.
Изменения после начала разработки оформляйте как новую редакцию ТЗ с пересмотром сроков и стоимости. «Маленькое уточнение по ходу» — самая частая причина сорванных сроков и конфликтов об оплате.
Как проверить ТЗ перед передачей
Описано пошагово, от лица роли, с реакциями системы на каждый шаг
Общие фразы «должно работать автоматически» без сценария
Описано поведение при пустых данных, ошибках, отсутствии прав
Описан только идеальный путь без ветвлений
Точные названия документов, полей, отчётов как в базе
Размытые указания «в накладной», «в карточке»
Есть список проверок вида «действие → результат», включая граничные случаи
Приёмка не описана или сводится к «посмотрим, как получится»
Приложены примеры: скриншоты, файлы, заполненные документы
Примеров нет, исполнитель тестирует на выдуманных данных
Частые вопросы
Какой объём должен быть у ТЗ?
Объём вторичен, важна полнота. Для новой кнопки или печатной формы обычно достаточно 1–2 страниц, для нового блока учёта — 5–10 страниц со схемами и примерами. Если ТЗ на простую задачу разрослось до десятка страниц, скорее всего, в нём смешаны несколько задач — разделите их.
Кто должен писать ТЗ — заказчик или программист?
Исходную постановку пишет заказчик, потому что только он знает бизнес-процесс. Программист может дополнить документ техническим разделом: какие объекты будут изменены, каким механизмом решается задача, какие есть ограничения. Такой совместный документ — лучший вариант для задач средней сложности и выше.
Что делать, если я не знаю, как называются объекты в конфигурации?
Используйте названия из интерфейса: откройте нужный документ или отчёт и перепишите заголовки формы, полей и кнопок дословно, приложите скриншот. Этого достаточно, чтобы программист нашёл объект в конфигураторе. Внутренние имена объектов он определит сам.
Нужно ли указывать сроки и бюджет в ТЗ?
В самом ТЗ — нет, это документ о том, «что делать». Сроки и стоимость определяются после оценки ТЗ исполнителем и фиксируются в договоре, заказ-наряде или карточке задачи. Но полезно указать желаемую дату результата и приоритет: это влияет на выбор между быстрым и основательным решением.
Как принимать работу, если я не разбираюсь в коде?
Вам и не нужно разбираться в коде — для этого и пишутся критерии приёмки. Пройдите каждый сценарий из ТЗ на копии базы: выполните действие и сверьте результат с ожидаемым. Если все проверки проходят, включая граничные случаи, работа принимается. Качество кода важно для будущих доработок, но проверять его должен другой разработчик при необходимости.
Что делать, если после приёмки нашлась ошибка?
Зафиксируйте её как новую задачу со ссылкой на исходное ТЗ: что сделано, что ожидалось по критериям приёмки, что получилось. Если сценарий был описан в ТЗ и работает неверно — это гарантийный случай, исправляется в рамках исходной задачи. Если ситуация в ТЗ не была предусмотрена, это новая доработка, а не ошибка исполнителя.
Что важно запомнить
Пишите ТЗ через сценарии: роль, действия пользователя, реакции системы, исключения, примеры данных и проверяемые критерии приёмки. Избегайте оценочных слов и смешения задач. Тестируйте только на копии базы, а изменения требований фиксируйте новой редакцией документа.