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

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

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

Объём ТЗ зависит от задачи. На мелкую доработку печатной формы достаточно одной страницы с примером макета. На доработку обмена данными или нового блока учёта потребуется документ на 5–15 страниц с описанием сценариев, форматов файлов и обработки ошибок. Ниже разобрана структура, которая подходит для большинства задач.

Что подготовить до написания ТЗ

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

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

1. 1
   Зафиксируйте название конфигурации и номер релиза
2. 2
   Определите роли пользователей, которые будут работать с доработкой
3. 3
   Соберите примеры данных: скриншоты, файлы, печатные формы
4. 4
   Опишите текущий процесс: кто, что и в какой последовательности делает сейчас
5. 5
   Сформулируйте бизнес-цель: какую проблему решает доработка

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

Рабочая структура ТЗ для 1С включает шесть блоков. Первый — цель и контекст: зачем нужна доработка и какую бизнес-проблему она решает. Второй — описание текущей ситуации: как процесс выполняется сейчас и что в нём не устраивает. Третий — требования к доработке: сценарии «как должно быть». Четвёртый — перечень изменяемых объектов конфигурации. Пятый — примеры данных и макеты. Шестой — критерии приёмки и порядок сдачи работ.

Не смешивайте разделы: требования не должны прятаться внутри описания проблемы. Разработчик должен иметь возможность пройтись по списку требований и отметить каждое как выполненное. Удобный приём — нумеровать требования (Т-1, Т-2, …) и ссылаться на эти номера в переписке и акте приёмки.

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

Как формулировать требования, чтобы их поняли правильно

Каждое требование должно быть проверяемым. Вместо «отчёт должен строиться быстро» пишите: «отчёт по продажам за месяц по базе с 500 000 строк регистра должен формироваться не более 30 секунд». Вместо «добавить проверку контрагента» — «при записи документа "Реализация товаров и услуг" проверять заполненность ИНН контрагента; если ИНН пустой, выводить сообщение и не проводить документ».

Описывайте поведение через сценарии: действие пользователя → реакция системы → результат в данных. Указывайте не только основной сценарий, но и граничные случаи: что происходит при отмене проведения, при повторной загрузке файла, при пустых значениях, при недостатке прав. Именно граничные случаи чаще всего становятся источником доработок после сдачи.

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

Как описать изменения объектов конфигурации

Если вы знаете, какие объекты будут затронуты, перечислите их явно: документы, справочники, регистры сведений и накопления, отчёты, обработки, роли, подсистемы. Для каждого объекта укажите, что меняется: добавляется реквизит с таким-то типом и обязательностью, создаётся новый регистр с такими-то измерениями и ресурсами, добавляется команда печати.

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

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

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

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

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

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

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

Как проверить готовое ТЗ перед отправкой

Каждое требование можно проверить одним действием

Норма

Есть объект, действие и ожидаемый результат

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

Формулировки «удобно», «быстро», «корректно» без критериев

Примеры данных

Норма

Приложены скриншоты, файлы, макеты печатных форм

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

Только словесное описание

Граничные случаи

Норма

Описаны отмена проведения, повторная загрузка, пустые значения

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

Описан только идеальный сценарий

Контекст

Норма

Указаны конфигурация, релиз, роли пользователей

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

Разработчику придётся выяснять это самому

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

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

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

Шаблон ТЗ: краткий образец

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

1. Общие сведения
Конфигурация: Управление торговлей 11, релиз 11.5.x
Пользователи: менеджеры по продажам (роль «Менеджер»)
2. Цель
Автоматически контролировать превышение скидки при продаже.
3. Текущая ситуация
Скидка указывается вручную, контроль отсутствует.
4. Требования
Т-1. При проведении «Реализации товаров» проверять скидку по каждой строке.
Т-2. Если скидка > 15%, документ не проводится, выводится сообщение
с номером строки и размером скидки.
Т-3. Пользователю с ролью «Руководитель продаж» проверка не применяется.
5. Реализация
Способ: расширение конфигурации, типовые объекты не изменяются.
6. Примеры
Приложение 1 — скриншот документа с примером строк.
7. Критерии приёмки
П-1. Документ со скидкой 20% не проводится, сообщение содержит номер строки.
П-2. Документ со скидкой 10% проводится штатно.
П-3. Под ролью «Руководитель продаж» проводится любой документ.

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

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

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

Сколько стоит составление ТЗ и входит ли оно в стоимость доработки?

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

Что делать, если я не знаю, какие объекты конфигурации нужно менять?

Это нормально. Опишите задачу на языке процесса: кто, что и в какой последовательности делает, какие данные вводит и что получает на выходе. Выбор объектов и способа реализации — работа разработчика; потребуйте от него короткое описание решения до начала кодирования.

Нужно ли ТЗ для совсем мелкой доработки?

Да, но в сокращённом виде. Достаточно нескольких строк: цель, один сценарий «как должно быть», пример и критерий проверки. Даже короткая письменная фиксация защищает обе стороны от разночтений.

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

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

Чем ТЗ отличается от частного технического задания (ЧТЗ)?

ЧТЗ — детализированный документ по конкретному блоку работ в рамках уже согласованного общего проекта. Для одиночной доработки достаточно одного ТЗ; ЧТЗ появляются в крупных внедрениях, где общий проект разбивается на этапы и каждый этап описывается отдельно.