Как написать техническое задание для программиста 1С: структура и образец

Большинство конфликтов между заказчиком и программистом 1С возникает не из-за сложности задачи, а из-за размытой постановки. Фраза «сделайте, чтобы отчёт показывал продажи» каждой стороне понятна по-своему: заказчик ждёт сводку по менеджерам с маржой, а разработчик выводит обороты по документам. Техническое задание (ТЗ) снимает эту двусмысленность и превращает пожелание в проверяемый результат.

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

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

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

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

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

Структура технического задания: обязательные разделы

Универсальная структура ТЗ для доработки 1С включает семь блоков. Порядок можно менять, но удалять разделы без причины не стоит — каждый закрывает свой класс вопросов.

1. Цель и контекст. Какую бизнес-проблему решаем и почему текущий механизм не подходит.
2. Текущее поведение. Как система работает сейчас: пошагово, с указанием документов и форм.
3. Требуемое поведение. Как должно работать после доработки — тоже пошагово.
4. Затрагиваемые объекты. Конфигурация и её версия, документы, справочники, регистры, отчёты, роли.
5. Примеры данных. Конкретные примеры входных данных и ожидаемого результата.
6. Критерии приёмки. Проверяемые условия, по которым работа считается выполненной.
7. Ограничения. Что делать нельзя: не трогать типовые механизмы, не менять обмен данными и т.п.

Отдельно укажите среду: точное название конфигурации (например, «1С:Управление торговлей 11» или «1С:Бухгалтерия 3.0»), режим работы (файловая или клиент-серверная база) и наличие нестандартных доработок. Разработчику, который видит базу впервые, это экономит часы на разведке.

Как описывать требования: язык объектов 1С

Главное правило: описывайте результат через объекты конфигурации, а не через абстракции. Сравните две формулировки одной задачи.

Плохо: «Нужен отчёт по эффективности менеджеров». Хорошо: «Нужен отчёт за выбранный период с группировкой по справочнику "Пользователи". Источник данных — проведённые документы "Реализация товаров и услуг". Колонки: сумма документа, сумма себестоимости, маржа (разница), количество документов. Отбор по организации обязателен, отбор по складу — опционален».

Вторая формулировка сразу отвечает на вопросы: откуда брать данные, как считать показатели, какие отборы нужны. Если вы не знаете точных имён объектов — опишите путь пользователя: «Открываем Продажи → Реализация (акты, накладные), в табличной части Товары нужно добавить колонку…». Разработчик сам сопоставит это с метаданными.

Скриншоты форм с пометками «здесь добавить колонку», «эту кнопку переименовать» сокращают время на уточнения сильнее, чем страницы текста. Прикладывайте их к ТЗ всегда, когда речь идёт об изменении интерфейса.

Образец ТЗ на доработку отчёта

Ниже — сокращённый, но рабочий образец формулировок, который можно взять за шаблон.

Цель: менеджеры по продажам должны видеть задолженность клиентов с разбивкой по срокам просрочки, чтобы приоритизировать звонки.

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

Требуемое поведение: новый отчёт «Дебиторская задолженность по срокам». Параметры: дата отчёта, организация. Строки — контрагенты. Колонки: сумма долга всего, не просрочено, просрочено 1–30 дней, 31–60, 61–90, свыше 90. Просрочка считается от даты оплаты, указанной в документе реализации; если дата оплаты не заполнена — от даты документа плюс 14 календарных дней. Двойной щелчок по сумме открывает список документов, образующих долг.

Критерии приёмки: итог по колонке «всего» совпадает с типовым отчётом по взаиморасчётам на ту же дату; документ без даты оплаты попадает в корректный интервал по правилу 14 дней; отчёт формируется по базе за год в разумное время без зависания.

Ограничения: типовой отчёт «Взаиморасчёты с контрагентами» не изменять; доработку выполнить через внешний отчёт или расширение конфигурации.

Примеры данных и критерии приёмки

Раздел с примерами — самый недооценённый. Один-два числовых примера исключают споры о логике расчёта. Например: «Реализация от 10 марта на 100 000 руб., дата оплаты 25 марта, дата отчёта 20 апреля. Просрочка 26 дней → сумма попадает в колонку "1–30 дней"». Разработчик проверит алгоритм на этом примере ещё до сдачи работы.

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

Контрольные точки

Как проверить результат

Итоговые суммы нового отчёта

Норма

Совпадают с типовым отчётом по тем же данным

Тревожный признак

Расхождения без объяснимой причины

Поведение на граничных данных

Норма

Пустые поля и незаполненные даты обрабатываются по правилам из ТЗ

Тревожный признак

Ошибки, пустые строки или падение отчёта

Типовые механизмы

Норма

Стандартные документы и отчёты работают как раньше

Тревожный признак

После доработки сломались смежные функции

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

Первая ошибка — описание решения вместо задачи. Заказчик пишет «создайте регистр сведений с измерением Номенклатура», хотя на самом деле ему нужно «видеть цену последней закупки в карточке товара». Возможно, регистр не нужен вовсе — задача решается иначе. Описывайте желаемый результат, а выбор механизма оставьте разработчику, если вы не уверены в архитектуре.

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

Как согласовать ТЗ и принять работу

Перед стартом работ попросите разработчика подтвердить ТЗ письменно и задать вопросы до начала кодирования. Если вопросов нет совсем — это тревожный знак: либо ТЗ идеально (что редкость), либо его не прочитали внимательно. Оценку трудоёмкости требуйте после согласования ТЗ, а не до.

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

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

Сколько страниц должно быть в ТЗ для 1С?

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

Кто должен писать ТЗ — заказчик или программист?

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

Нужно ли в ТЗ указывать, как именно программировать?

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

Что делать, если требования изменились в середине работы?

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

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

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