Разработка и Конфигурация · 10 мин
Как написать ТЗ для программиста 1С: структура и готовый пример
Как составить техническое задание для программиста 1С: структура ТЗ, формулировка требований, готовый пример, типичные ошибки и критерии приёмки работы.
Плохое техническое задание — главная причина того, что доработка 1С выходит за сроки и бюджет. Формулировки вроде «сделайте удобный отчёт» или «чтобы всё считалось автоматически» программист интерпретирует по-своему, а заказчик получает не то, что ожидал. Конфликт почти неизбежен: исполнитель считает, что выполнил задачу, заказчик — что его не поняли.
Хорошее ТЗ для программиста 1С пишется не на языке программирования, а на языке бизнес-процесса: что делает пользователь, какие данные вводит, что должен получить на выходе и как система должна реагировать на нестандартные ситуации. Программист 1С сам выберет технические средства — задача постановщика точно описать желаемое поведение системы.
Ниже разобрана структура рабочего ТЗ, правила формулировки требований, готовый пример задания и критерии приёмки, по которым можно объективно проверить результат.
Что должно быть в ТЗ: обязательная структура
Минимальный набор разделов, без которых задание нельзя считать полным:
- Цель доработки. Какую проблему решаем и зачем это нужно бизнесу. Одна-две фразы: «менеджеры вручную пересчитывают скидки, из-за ошибок теряем до 5% маржи».
- Текущая ситуация. Как процесс работает сейчас — в программе или вне её (Excel, бумага, устные договорённости).
- Требуемый результат. Что появится в системе: новый документ, отчёт, кнопка, автоматический расчёт, обмен данными.
- Сценарий работы пользователя. Пошагово: кто, где и что нажимает, что вводит, что видит.
- Правила и формулы. Алгоритмы расчёта, условия, ограничения, поведение в нестандартных случаях.
- Критерии приёмки. Проверяемые условия, по которым работа считается выполненной.
Отдельно фиксируют окружение: конфигурация и её версия (например, «1С:Управление торговлей 11», «1С:ERP 2»), режим работы (файловая или клиент-серверная база), наличие типовых доработок, которые нельзя ломать. Программисту это нужно, чтобы оценить трудоёмкость и не предложить решение, несовместимое с вашей базой.
Как формулировать требования, чтобы их поняли правильно
Главное правило: каждое требование должно быть проверяемым. Если по формулировке нельзя однозначно ответить «выполнено» или «не выполнено», её нужно переписать. Сравните: «отчёт должен формироваться быстро» — непроверяемо; «отчёт по продажам за месяц по базе из 50 тысяч документов формируется не дольше 30 секунд» — проверяемо.
Избегайте оценочных слов: «удобно», «красиво», «оптимально», «корректно». Вместо них — конкретика: «кнопка «Печать» расположена в командной панели формы документа», «поле «Скидка» не должно принимать значения больше 30%».
Требования к расчётам давайте с примерами на реальных числах. Формулировка «скидка 10% при сумме заказа от 100 000 рублей» дополняется примером: «заказ на 120 000 ₽ → итог со скидкой 108 000 ₽; заказ на 99 000 ₽ → скидка не применяется». Пример снимает 90% вопросов о граничных условиях.
Описывайте нестандартные ситуации явно: что делать, если поле не заполнено, если остатка на складе не хватает, если документ уже проведён. Поведение системы в исключениях — самая частая зона недопонимания.
Готовый пример ТЗ на доработку
Ниже — сокращённый, но реальный по структуре пример задания на автоматизацию скидок в «1С:Управление торговлей 11».
1. Цель. Исключить ручной расчёт скидок менеджерами и ошибки в ценах при оформлении заказов клиентов.
2. Текущая ситуация. Менеджер рассчитывает скидку в Excel по таблице и вручную меняет цену в документе «Заказ клиента».
3. Требуемый результат. Скидка применяется автоматически при проведении заказа по правилам из п. 5. В документе отображается сумма скидки и итог с учётом скидки.
4. Сценарий пользователя. Менеджер создаёт «Заказ клиента», заполняет товары, нажимает «Провести». Система рассчитывает скидку, показывает её в отдельной колонке табличной части и в итогах документа. Менеджер не редактирует цены вручную.
5. Правила расчёта. Сумма заказа от 100 000 ₽ — скидка 5%; от 300 000 ₽ — 10%. Скидка не применяется к товарам из группы «Акционные». Пример: заказ 320 000 ₽, из них 50 000 ₽ акционные товары → скидка 10% применяется к 270 000 ₽, итог скидка 27 000 ₽.
6. Исключения. Если у клиента задолженность по оплате — скидка не применяется, выводится предупреждение «Скидка не применена: задолженность по оплате».
7. Критерии приёмки. Тест на 5 заранее согласованных примерах заказов даёт суммы, совпадающие с расчётом в ТЗ; акционные товары исключены из расчёта; при задолженности скидка не применяется.
- 1Опишите цель и текущий процесс словами пользователя
- 2Зафиксируйте пошаговый сценарий работы в системе
- 3Выпишите правила и формулы с числовыми примерами
- 4Опишите поведение в исключительных ситуациях
- 5Сформулируйте проверяемые критерии приёмки
- 6Согласуйте ТЗ с пользователем процесса до передачи программисту
Как описывать отчёты и печатные формы
Отчёты и печатные формы — самая частая категория доработок и одновременно самая конфликтная, если ТЗ расплывчато. Для отчёта обязательно укажите: источник данных (какие документы и регистры), перечень колонок с точными названиями, группировки и итоги, отборы, которые пользователь сможет менять, и периодичность использования.
Лучший способ описать отчёт — приложить макет в Excel: шапка, строки, итоги, пример заполнения тремя-пятью строками данных. Программист по макету видит и структуру, и формат вывода, а заказчик получает именно то, что нарисовал.
Для печатной формы приложите образец заполненного документа и укажите, откуда берётся каждое поле: «Номер — номер документа без префикса», «Покупатель — наименование и ИНН из карточки контрагента». Поля, которых нет в базе, отметьте отдельно — их придётся хранить или вычислять, и это влияет на оценку работ.
Критерии приёмки: как проверить результат
Приёмка по принципу «посмотрел — вроде работает» приводит к тому, что ошибки всплывают через месяц, когда исправлять уже дороже. Критерии приёмки формулируйте в ТЗ заранее, до начала работ, в виде тестовых сценариев: исходные данные → действие → ожидаемый результат.
Тестируйте на копии рабочей базы, а не на боевых данных. Проверяйте не только «счастливый путь» (всё заполнено правильно), но и ошибки: пустые поля, отрицательные остатки, повторное проведение, отмена документа. Именно на граничных случаях доработки ломаются чаще всего.
Как проверить результат доработки
Суммы совпадают с расчётом из ТЗ до копейки
Расхождения на граничных значениях (скидка, НДС, округление)
Понятное предупреждение, данные не портятся
Ошибка платформы, документ проводится с неверными данными
Стандартные отчёты и документы работают как раньше
После доработки сломались смежные механизмы
Доработка доступна нужным ролям, скрыта от остальных
Новые объекты видны всем или никому
Типичные ошибки при составлении ТЗ
Ещё одна системная ошибка — пытаться написать ТЗ на языке программиста: «создать регистр сведений», «добавить реквизит в табличную часть». Если вы не разработчик, такие указания могут навязать неоптимальное решение. Опишите, что должно храниться и где это видеть пользователю, — выбор механизма оставьте исполнителю, но зафиксируйте требование: решение не должно мешать обновлению конфигурации.
Что приложить к ТЗ и как согласовывать изменения
Полезные приложения к заданию: скриншоты текущих форм с пометками, макеты отчётов в Excel, образцы заполненных документов, выгрузка тестовых данных. Чем больше наглядного материала, тем меньше уточняющих вопросов на старте.
Заранее договоритесь, как обрабатываются изменения ТЗ в процессе работы. Практичный вариант: новые требования оформляются дополнением к ТЗ с пересмотром сроков и стоимости, а не устными просьбами в мессенджере. Иначе «маленькие уточнения» незаметно удваивают объём работ и становятся предметом спора.
Перед тем как писать ТЗ, проведите 15-минутное интервью с тем, кто реально работает с процессом: кладовщиком, менеджером, бухгалтером. Пользователи называют детали, о которых руководитель не знает, — и именно эти детали чаще всего требуют доработки после сдачи.
Что важно запомнить
ТЗ для программиста 1С описывает бизнес-задачу, а не техническое решение: цель, сценарий пользователя, правила с числовыми примерами, исключения и проверяемые критерии приёмки. Макеты отчётов и примеры документов экономят больше времени, чем страницы текстовых описаний.
Частые вопросы
Кто должен писать ТЗ — заказчик или программист?
Исходное ТЗ пишет заказчик, потому что только он знает бизнес-процесс. Программист может дополнить его техническим разделом (выбор объектов метаданных, способ хранения данных), но формулировка задачи — зона ответственности постановщика. Если выписать требования самостоятельно не получается, заказывают платное обследование: аналитик описывает процесс и составляет ТЗ, которое затем реализует любой исполнитель.
Насколько подробным должно быть ТЗ?
Достаточным для однозначной проверки результата. Для простой доработки (печатная форма, небольшой отчёт) хватает 1–2 страниц с макетом. Для изменения учётного механизма — несколько страниц со сценариями и примерами расчётов. Избыточная детализация технических решений вредна, недостаточная детализация бизнес-правил — критична.
Что делать, если программист говорит, что задача невыполнима?
Попросите письменно указать причину: ограничение платформы, конфигурации или конфликт с существующими доработками. Часто «невозможно» означает «невозможно именно таким способом» — тогда просите предложить альтернативу, которая решает ту же бизнес-задачу. Если сомнения остаются, получите независимую оценку у другого специалиста по 1С.
Нужно ли указывать сроки и бюджет в ТЗ?
ТЗ описывает требования к результату, а сроки и стоимость фиксируются в договоре или задании на работы. Но в ТЗ стоит указать ограничения, влияющие на оценку: желаемую дату запуска, требование не прерывать работу пользователей, запрет на снятие конфигурации с поддержки.
Можно ли давать ТЗ устно, если доработка маленькая?
Даже мелкую задачу стоит зафиксировать письменно — хотя бы в письме или сообщении с описанием результата и примером. Устные договорённости забываются и трактуются по-разному, а спор из-за «мелочи» стоит дороже, чем десять минут на формулировку.
Как проверить доработку, если я не разбираюсь в 1С?
Вам и не нужно разбираться в технической части — проверяйте по критериям приёмки из ТЗ: подготовьте контрольные примеры с известным правильным результатом и сравните с тем, что выдала система. Дополнительно попросите показать работу на копии базы и проверьте, что типовые функции (проведение документов, стандартные отчёты) не пострадали.