Как поставить задачу разработчику 1С, чтобы не переделывать

Техническое задание программисту 1С — это документ, где вы заранее фиксируете, что должно получиться: какой результат, в каких документах и отчётах, по каким правилам. Чем точнее составить техзадание, тем меньше переделок, спорных часов в счёте и фраз «а я думал, вы имели в виду другое».

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

Что ТЗ закрывает: оценка, рамки, приёмка

Устная постановка задачи почти всегда расходится с результатом — не из-за злого умысла, а потому что в голове у заказчика и исполнителя разные картинки. Письменное ТЗ решает три задачи сразу:

• 🎯 Фиксирует объём. Всё, чего нет в ТЗ, — это новая задача и отдельная оплата. Это защищает обе стороны: вы не получите «а это уже сверх договорённостей», а исполнитель — бесконечные «ещё мелочи».
• 💰 Даёт основу для оценки. По расплывчатому «надо допилить отчёт» цену назвать нельзя. По конкретным полям, условиям отбора и формату выгрузки — можно и в часах, и в деньгах.
• ✅ Задаёт правила приёмки. Без описанного результата спор «готово / не готово» упирается в мнения. С критериями приёмки есть проверяемый список.

Отдельная ценность — ТЗ переживает людей. Уволился сотрудник, сменился подрядчик — по документу новый человек поймёт, что и зачем делалось, а не будет расшифровывать чужой код вслепую.

Из каких разделов состоит грамотное техзадание

Жёсткого шаблона для доработок 1С нет, но набор разделов за годы устоялся. Для коробочной автоматизированной системы структуру задаёт ГОСТ 34.602-2020, для отдельной программы — ГОСТ 19.201-78; на практике для доработки берут облегчённый вариант:

Контекст в начале экономит больше всего времени. Всегда указывайте точную редакцию и релиз конфигурации — путь меню и даже набор реквизитов в Бухгалтерии 3.0, ЗУП 3.1 и УТ 11 различаются, и доработка под одну редакцию в другой может просто не встать.

Как описать бизнес-процесс, а не код

Самая частая просьба разработчика — «объясните, что вы делаете руками, по шагам». Описывать нужно процесс, а не предполагаемую техническую реализацию. Способ её реализовать — зона ответственности исполнителя.

Удобно описать процесс в двух состояниях:

1. Как есть. «Менеджер вручную заносит скидку в каждую строку реализации, сверяясь с таблицей в Excel».
2. Как должно стать. «При выборе контрагента скидка подставляется в строки автоматически по его категории из справочника».

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

Сложную логику проще показать на примере с числами, чем формулой:

• Заказ на 100 000 ₽, клиент категории «Опт» → скидка 7% → к оплате 93 000 ₽.
• Тот же заказ, но есть позиция из акции → на неё скидка не распространяется.
• Клиент без категории → скидка 0%, цена остаётся прайсовой.

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

Требования к формам, отчётам и печати

Видимую часть доработки — формы и отчёты — описывайте предметно: что должно появиться на экране и на бумаге.

Для печатной формы укажите:

• какие поля выводятся и откуда берутся (реквизит документа, данные контрагента, расчёт);
• порядок и группировку строк;
• что выводить в шапке и подвале, нужна ли подпись и печать;
• формат вывода — на печать, в PDF, в Excel.

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

Для отчёта опишите:

• строки и колонки, по чему группировка и итоги;
• отборы и параметры (период, организация, склад);
• пример: «хочу видеть остатки по складам с колонкой “резерв” и итогом снизу».

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

Что писать в разделе про обмены и интеграции

Если доработка касается обмена с другой системой — сайтом, маркетплейсом, банком, другой базой 1С — этому нужен отдельный раздел. Здесь неточность стоит дороже всего: данные уходят наружу.

Укажите минимум:

• направление обмена — выгрузка из 1С, загрузка в 1С или двусторонний;
• формат — файл (CSV, XML, JSON), веб-сервис, прямое подключение к базе;
• триггер — по кнопке, по расписанию (регламентное задание), по событию проведения;
• сопоставление полей — что с чем совмещается на обеих сторонах.

Сопоставление полей удобно оформить таблицей — это снимает половину вопросов по интеграции:

Отдельно оговорите поведение при ошибках: что делать, если контрагент не найден, цена нулевая, товар отсутствует в базе. Без этого исполнитель примет решение сам — и не факт, что совпадёт с вашим.

Критерии приёмки и сценарии проверки

Раздел, который чаще всего забывают, — а он превращает субъективное «нравится / не нравится» в проверяемый результат. Критерий приёмки — это условие, по которому вы говорите «принято».

Формулируйте их проверяемо, через конкретные действия и ожидаемый результат:

1. Создаю реализацию на клиента категории «Опт» на 100 000 ₽ → скидка 7% подставилась автоматически, к оплате 93 000 ₽.
2. Печатаю накладную → в шапке появился новый реквизит «Номер договора».
3. Запускаю выгрузку на сайт → в логе 0 ошибок, товары появились с ценами.

Приложите тестовые сценарии — набор проверок, которые вы прогоните на готовой доработке. Хорошая практика: заказчик проверяет не на рабочей базе, а на её копии. Любые доработки сначала катят на тестовую копию базы, а не на рабочую — ошибка в коде на боевой базе портит реальные данные, и откат обходится дороже самой доработки.

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

Короткий пример готового ТЗ

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

ТЗ: автоматическая скидка в реализации по категории клиента

1. Контекст
   Конфигурация: 1С:Управление торговлей 11, релиз 11.5.x.
   База клиент-серверная, пользователей ~15.

2. Как есть
   Менеджер вручную проставляет процент скидки в каждую строку
   документа «Реализация товаров и услуг», сверяясь с таблицей в Excel.

3. Как должно стать
   При выборе контрагента в реализации скидка подставляется в строки
   автоматически по его категории:
   — «Опт» → 7%;
   — «Постоянный» → 5%;
   — остальные → 0%.
   Категория хранится в дополнительном реквизите контрагента «Категория».

4. Исключения
   — На позиции из документа «Установка цен» акционного типа скидка
     не распространяется.
   — Менеджер может изменить подставленный процент вручную.

5. Приёмка
   — Клиент «Опт», сумма 100 000 ₽ → скидка 7%, к оплате 93 000 ₽.
   — Клиент без категории → скидка 0%.
   — Акционная позиция → скидка не применяется.

6. Ограничения
   Доработка — через расширение конфигурации, без снятия с поддержки.
   Тестирование на копии базы, гарантия 2 недели.

Обратите внимание: ни слова о том, как это программировать — только что и с какими числами должно получиться. Исключения и критерии приёмки занимают столько же места, сколько и сам алгоритм, — и это правильно.

Типичные ошибки при постановке задачи

Ошибки в ТЗ дорого обходятся не на этапе написания, а на приёмке — когда переделка уже стоит денег и времени.

• 🚫 Описание решения вместо задачи. «Сделайте реквизит в документе» вместо «нужно, чтобы менеджер видел дату отгрузки». Может, реквизит и не нужен — исполнитель предложит проще. Описывайте цель, а не способ.
• 🚫 Нет исходного состояния. Только «как должно стать», без «как есть». Разработчик не знает вашего процесса и начнёт с догадок.
• 🚫 Пропущены исключения и граничные случаи. Что с возвратами, с нулевыми суммами, с закрытым периодом — об этом вспоминают в последний момент.
• 🚫 Нет версии конфигурации. Доработка написана под одну редакцию, а база оказалась другой — часть кода не подходит.
• 🚫 «И ещё по мелочи». Устные добавки поверх ТЗ размывают оценку и сроки. Любая новая хотелка — строкой в документ.
• 🚫 Нет критериев приёмки. Без них приёмка превращается в бесконечный пинг-понг правок по вкусу.

Частые вопросы