Техническое задание на доработку 1С: из чего собрать и как написать

Хорошее ТЗ на доработку 1С описывает три вещи: что должно получиться на экране и в отчётах, по каким правилам считать и как проверить, что задача сдана. Если в тексте есть эти три блока и к ним приложены примеры с числами, программист оценит работу точно, а заказчик потом не скажет «я имел в виду другое».

Ниже — структура документа, по которой пишут задание на доработку типовой конфигурации (Бухгалтерия, ЗУП, УТ, ERP) или на обмен с внешней системой. Разберём, как формулировать требования так, чтобы их нельзя было понять двояко, какие технические детали обязательны и как заранее прописать критерии приёмки, чтобы сдача проекта не превратилась в спор.

Зачем задание нужно и когда без него можно обойтись

ТЗ решает четыре практические задачи.

• 📊 Оценка. Пока нет описания, подрядчик не назовёт ни срок, ни цену — он не знает объёма. По внятному заданию оценка получается в разы точнее.
• 🤝 Фиксация договорённостей. Устная постановка забывается за неделю. Документ — это то, на что обе стороны ссылаются при споре.
• 🔁 Защита от «хотелок на ходу». Любое новое требование сверх ТЗ — это отдельная задача и отдельная оценка, а не «ну это же мелочь, доделайте заодно».
• 🧩 Передача дела. Если исполнитель сменится, новый разберётся в задаче по документу, а не по переписке в мессенджере.

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

Структура документа: обязательные разделы и необязательные

Типовая структура ТЗ на доработку 1С выглядит так. Крупные проекты опираются на ГОСТ 34.602-2020 (техническое задание на автоматизированную систему), для одной доработки достаточно упрощённого набора разделов.

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

Важный и часто забываемый пункт — раздел «что НЕ входит в работу». Одна строчка «миграция старых данных в объём не входит» снимает половину будущих конфликтов.

Как описать функциональные требования без двусмысленностей

Это ядро задания и главный источник недопонимания. Правило простое: от общей фразы спускайтесь к конкретному действию, пока не исчезнет возможность понять иначе.

Сравните две формулировки одной задачи.

• ❌ «Сделать автоматическое заполнение скидки в заказе».
• ✅ «При выборе контрагента в документе Заказ клиента подставлять процент скидки из его карточки (реквизит с видом цен), пересчитывать сумму строк и выводить итог с учётом скидки в подвале формы».

Вторая формулировка отвечает на три вопроса: что за объект, когда срабатывает правило и что именно меняется на экране.

Чтобы описание было полным, по каждому требованию пройдите по чек-листу ниже.

Пример с числами — самая недооценённая часть. Фраза «округлять до рублей» неоднозначна: 10,5 → 10 или 11? Напишите прямо: «округление по правилам арифметики, 10,50 → 11, 10,49 → 10». Такой пример заодно превращается в тест при приёмке.

Если логика ветвится, рисуйте таблицу решений или дерево «условие → результат», а не абзац текста. Пять строк таблицы читаются однозначно, абзац на пять условий — нет.

Технические требования: версии, обмен и права доступа

Функционал описывает, что увидит пользователь. Технический блок — в какой среде это работает и чего нельзя сломать.

Платформа и конфигурация. Укажите точно: конфигурация, её релиз и номер платформы не ниже такого-то (именно «не ниже», а не «новее» — так однозначно). Это критично: механизм, доступный на одном релизе, может отсутствовать на другом.

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

Интеграции и обмен. Если доработка завязана на внешнюю систему (сайт, маркетплейс, другая база), опишите обмен детально: протокол (HTTP-сервис, COM, файловый, через конвертацию данных), формат файла, частоту, а главное — сопоставление полей.

Права доступа . Если появляется новый документ или отчёт, укажите, каким профилям групп доступа он виден. Иначе функция будет готова, но половина пользователей её не увидит.

Нагрузка. Для операций по большим объёмам (обработка тысяч строк, фоновые задания) задайте порог: «обработка 10 000 строк — не дольше 5 минут». Без цифры «работает медленно» — не повод для доработки по гарантии.

Критерии приёмки: как закрыть проект без спора

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

Хороший критерий привязан к функциональному требованию и к примеру с числами из него:

• «В Заказе клиента при контрагенте со скидкой 10 % сумма 1 000 ₽ пересчитывается в 900 ₽ — проверено на тестовой базе».
• «Выгрузка 500 заказов с сайта проходит без ошибок, номенклатура сопоставлена по артикулу, расхождений по суммам нет».

Плохой критерий — «форма работает корректно». Корректно по чьему мнению?

Пропишите заранее и процедуру приёмки:

1. Исполнитель передаёт доработку на тестовой базе (копии рабочей), а не сразу в боевую.
2. Заказчик проходит сценарии из критериев приёмки на реальных, но тестовых данных.
3. Замечания фиксируются письменно одним списком, а не вкидываются по одному неделю.
4. После исправления — повторная проверка только по спорным пунктам.
5. Перенос в рабочую базу — отдельный пункт с указанием, кто и когда его делает (и с резервной копией перед переносом).

Частые ошибки в ТЗ для 1С

Это не повтор шагов выше, а отдельные ловушки, в которые попадают даже при аккуратной структуре.

• Цель подменяется решением. Заказчик пишет «добавьте кнопку, которая делает Х», хотя задачу закрывает штатная настройка. Описывайте бизнес-задачу, а способ оставьте исполнителю — он знает платформу лучше.
• «Как сейчас, только лучше». Ссылка на текущее поведение без описания. Новый исполнитель вашу базу не видел.
• Нет примеров с числами. Алгоритм на словах понимается десятком способов. Один числовой пример отсекает девять.
• Забыли про граничные случаи. Что делать с пустым складом, нулевой ценой, возвратом, закрытым периодом — именно здесь всплывают ошибки после сдачи.
• Печатная форма без макета. «Сделать красивый счёт» — исполнитель сделает на свой вкус. Приложите образец: какие поля, в каком порядке, с каким форматом дат и сумм.
• Нет раздела «не входит». Без явной границы объём работ расползается, и оценка перестаёт действовать.
• Смешаны требования разных конфигураций. В Бухгалтерии — «Типы цен», в Управлении торговлей — «Виды цен»; термины из чужой конфигурации сбивают исполнителя.

Шаблон ТЗ и инструменты для его подготовки

Собирать документ с нуля каждый раз не нужно. Достаточно одного файла-шаблона с заголовками разделов из таблицы выше — дальше заполняете под конкретную задачу.

Минимальный каркас для одной доработки:

1. Общие сведения
   Конфигурация, релиз, платформа (не ниже ...). Заказчик, исполнитель.

2. Цель доработки
   Какую задачу закрываем. Что НЕ входит в работу.

3. Функциональные требования
   3.1 Требование. Объект → событие → алгоритм → пример с числами.
   3.2 ...
   (для каждого: что видит пользователь, поведение в граничных случаях)

4. Технические требования
   Способ доработки (расширение / правка типовой).
   Обмен: протокол, формат, частота, сопоставление полей.
   Права доступа. Нагрузка (пороги по времени/объёму).

5. Печатные формы и отчёты (если есть)
   Макет, список полей, пример заполнения.

6. Критерии приёмки
   Проверяемые утверждения, привязанные к требованиям из п. 3.

7. Порядок сдачи
   Тестовая база, этапы, сроки, перенос в рабочую базу.

От простого к сложному требования выглядят так. Простое ТЗ — одна страница: «в отчёте Остатки товаров добавить колонку с ценой по виду цен „Закупочная“, пример: товар с ценой 100 ₽ — в новой колонке 100 ₽». Этого хватит, чтобы оценить и сделать работу за час.

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

Чем писать и чем проверять документ:

• 📝 Текстовый редактор или вики. Для одной доработки хватит обычного документа; для проекта с историей правок удобнее вики или система, где видно, кто что менял.
• 🖼 Макеты форм. Экранные формы и печатные документы проще показать картинкой или таблицей полей, чем описать словами.
• 📊 Таблицы решений. Для ветвящейся логики — таблица «условие → результат» прямо в документе.
• ✅ Трекер задач. Каждое функциональное требование удобно завести отдельной задачей со ссылкой на пункт ТЗ — тогда видно прогресс по сдаче.

Отдельного «волшебного» инструмента проверки ТЗ не существует: лучшая проверка — прочитать документ глазами исполнителя и заказчика и для каждого требования спросить «а что, если данные другие?». Если на вопрос нет ответа в тексте — требование недописано.