Разработка и Конфигурация · 10 мин
ТЗ в 1С: что это и как правильно составить техническое задание
Что такое техническое задание (ТЗ) на разработку и доработку 1С, из чего оно состоит, как его составить и согласовать, типичные ошибки и проверка результата.
ТЗ в контексте 1С — это техническое задание на разработку, доработку или настройку конфигурации. Это документ, в котором заказчик описывает, что должна делать система: какие документы создавать, какие проводки формировать, как выглядят отчёты, какие проверки выполнять при записи. Именно по ТЗ программист 1С понимает объём работ, оценивает сроки и стоимость, а заказчик получает инструмент приёмки результата.
Без ТЗ доработка 1С превращается в цепочку догадок: разработчик делает «как понял», заказчик ожидает «как представлял», и расхождения всплывают уже на этапе сдачи, когда переделывать дорого. Даже короткое задание на пару страниц снижает число переделок и конфликтов, потому что фиксирует договорённости до начала кодирования.
ТЗ нужно не только для внешнего подрядчика. Внутренний разработчик тоже работает эффективнее, когда требования записаны: задание можно обсудить с пользователями, согласовать с руководителем, а потом проверить результат по пунктам. Ниже разберём, из чего состоит грамотное ТЗ, как его составить и какие ошибки встречаются чаще всего.
Что такое ТЗ в 1С и когда оно обязательно
Техническое задание — это описание будущего поведения системы на языке, понятном и бухгалтеру, и программисту. В отличие от устной просьбы «сделайте нам удобно», ТЗ отвечает на конкретные вопросы: какой документ создаётся, какие поля в нём обязательны, что происходит при проведении, какие ограничения действуют, кто имеет доступ.
Формально ТЗ может быть отдельным документом (Word, Google Docs, страница в wiki или задаче трекера), приложением к договору с подрядчиком или постановкой задачи во внутренней системе учёта. Форма вторична — важно содержание и то, что обе стороны его подтвердили.
ТЗ обязательно, когда работа сложнее элементарной настройки: добавление нового документа, изменение проведения, интеграция с сайтом или обменом, нестандартный отчёт, миграция данных. Для мелких правок вроде «добавить реквизит в справочник» достаточно короткой постановки задачи, но даже её лучше записать текстом, а не передавать устно.
Из каких разделов состоит грамотное ТЗ
Структура задания зависит от масштаба работ, но рабочий минимум выглядит одинаково почти всегда.
- Цель и контекст. Какую бизнес-задачу решаем и почему текущий типовой механизм не подходит.
- Сценарии работы. Пошаговое описание действий пользователя и реакции системы: «менеджер создаёт заказ → система проверяет остаток → при нехватке показывает предупреждение».
- Объекты конфигурации. Какие документы, справочники, регистры, отчёты и обработки создаются или меняются, с перечнем реквизитов и их типов.
- Проводки и движения. Какие записи формируются при проведении, по каким регистрам, с какими аналитиками.
- Права и ограничения. Кто видит и редактирует данные, какие проверки блокируют запись.
- Критерии приёмки. Проверяемые условия, по которым заказчик принимает работу: «отчёт за месяц формируется и сходится с обороткой по счёту 62».
Отдельным пунктом стоит зафиксировать, что не входит в работу. Фраза «интеграция с телефонией в данную доработку не входит» экономит недели споров на этапе сдачи.
Как составить ТЗ: пошаговый порядок
Составление начинается не с текста, а с выяснения реальной потребности. Часто за формулировкой «нужна кнопка» скрывается задача, которую правильнее решить иначе — например, автоматической операцией без участия пользователя.
- 1Опишите бизнес-проблему: что сейчас делается вручную, где возникают ошибки или потери времени
- 2Поговорите с пользователями, которые будут работать с доработкой, и зафиксируйте их сценарии
- 3Опишите каждый сценарий по шагам: действие пользователя — реакция системы
- 4Перечислите объекты: новые и изменяемые документы, справочники, регистры, отчёты с реквизитами
- 5Опишите проводки, движения по регистрам и правила заполнения полей
- 6Зафиксируйте ограничения: права, проверки, обязательность полей, запреты
- 7Сформулируйте критерии приёмки — конкретные проверяемые условия
- 8Согласуйте ТЗ с пользователями и руководителем до передачи разработчику
Хороший приём — описывать сценарии на примерах с реальными данными: «покупатель ООО "Ромашка", заказ на 10 шт., на складе 6 шт. — система должна...». Конкретика выявляет неоднозначности, которые в абстрактной формулировке незаметны.
После передачи ТЗ разработчику договоритесь о формате вопросов: уточнения по ходу работы фиксируются письменно и дополняют задание. Иначе устные решения потеряются, и на приёмке стороны будут ссылаться на разные версии договорённостей.
ТЗ для разных видов работ: отчёт, документ, интеграция
Требования к детализации зависят от типа доработки. Универсального шаблона нет, но есть акценты для каждого случая.
ТЗ на отчёт
Для отчёта критичны: источник данных (какие регистры и документы), состав колонок и их расчёт, группировки, отборы, период, а также эталон сверки — с чем сравнивать результат. Фраза «отчёт по продажам» недопустимо расплывчата; «сумма по колонке "Выручка" за месяц равна кредитовому обороту счёта 90.01» — проверяемое требование.
ТЗ на новый документ или изменение проведения
Здесь важны табличная часть с типами реквизитов, поведение при проведении (какие регистры затрагиваются, какие записи формируются), поведение при отмене проведения и обработка граничных случаев: незаполненные поля, отрицательные остатки, дубли строк.
ТЗ на интеграцию и обмен
Для обменов описывают: формат и канал передачи, состав передаваемых данных, направление (в одну сторону или двусторонний обмен), расписание, поведение при ошибках связи и правила разрешения конфликтов, когда объект изменён в обеих системах. Без пункта про ошибки интеграция рано или поздно «молча» перестанет работать, и никто не заметит.
Сравнение вариантов
Подходит для крупных доработок и работы с подрядчиком; требует времени на составление, но минимизирует переделки
Подходит для мелких правок внутри своей команды; риск недопонимания выше, критерии приёмки всё равно нужны
Дополняет ТЗ для форм и отчётов: картинка интерфейса снимает большинство споров о внешнем виде
Типичные ошибки при составлении ТЗ
Самая дорогая ошибка — начинать разработку до согласования ТЗ. Переделка готового кода стоит в разы дороже правки текста документа, а спор «мы же договаривались» без письменной фиксации почти всегда проигрывает заказчик.
Как согласовать ТЗ и принять работу по нему
Согласование — это не формальность. ТЗ должны прочитать и подтвердить три стороны: пользователь, который будет работать с доработкой; руководитель, отвечающий за бюджет; разработчик, подтверждающий реализуемость и оценку. Если разработчик предлагает изменить требование из-за технических ограничений — правка вносится в текст ТЗ, а не остаётся в переписке.
Приёмка выполняется строго по критериям из задания. Каждый пункт проверяется на тестовой базе с реальными данными: создаются документы из сценариев, проводятся, сверяются отчёты и движения по регистрам.
Как проверить результат
Каждый сценарий выполняется от начала до конца без ошибок
Часть шагов требует ручных действий, не описанных в задании
Записи по регистрам соответствуют описанию в ТЗ
Движения формируются, но аналитика или суммы отличаются
Итоги сходятся с эталонным источником (оборотка, старый отчёт)
Расхождения объясняются «особенностями расчёта», не указанными в ТЗ
Пустые поля и отмена проведения обрабатываются корректно
Программа падает с ошибкой или записывает некорректные данные
Если приёмка выявила расхождения, они оформляются списком замечаний со ссылкой на пункт ТЗ. Это дисциплинирует обе стороны: разработчик понимает, что именно исправлять, а заказчик не может добавлять новые требования задним числом — новые пожелания оформляются отдельным заданием.
FAQ: частые вопросы о ТЗ в 1С
Сколько времени занимает составление ТЗ?
Для небольшой доработки — от пары часов до рабочего дня, для крупной задачи с интеграциями — несколько дней с учётом обсуждений. Это время окупается: правка текста задания несопоставимо дешевле переделки готового кода.
Можно ли поручить написание ТЗ самому разработчику?
Можно, и это частая практика: разработчик интервьюирует заказчика и оформляет требования. Но подтверждать документ должен заказчик — прочитать и согласовать каждый пункт, иначе ответственность за неверную постановку неявно перекладывается на исполнителя.
Что делать, если требования меняются в процессе разработки?
Изменения фиксируются письменно как дополнение к ТЗ с пересмотром сроков и стоимости. Устные «а давайте ещё» без фиксации — главный источник срыва сроков и конфликтов при оплате.
Нужно ли ТЗ для работы с франчайзи 1С?
Да, причём особенно важно: при работе по договору ТЗ является приложением и определяет объём оплачиваемых работ. Без него спор о том, входила ли доработка в оплату, практически невозможно разрешить объективно.
Чем ТЗ отличается от пользовательской инструкции?
ТЗ описывает, что система должна делать, и пишется до разработки. Инструкция описывает, как пользоваться готовой доработкой, и пишется после. Хорошая практика — сценарии из ТЗ использовать как основу для инструкции.
Что важно запомнить
ТЗ в 1С — письменное задание на доработку: цель, сценарии, объекты, проводки, права и критерии приёмки. Оно составляется до начала разработки, согласуется всеми сторонами и служит единственным основанием для приёмки результата.