Как писать ТЗ для программиста 1С

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

Особенность 1С в том, что постановщик задачи чаще всего не разработчик, а бухгалтер, менеджер или руководитель отдела. Поэтому ТЗ для 1С должно описывать не код и не объекты метаданных, а бизнес-процесс: кто, что, когда и зачем делает в программе, какие данные откуда берутся и как должен выглядеть результат.

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

Когда ТЗ обязательно, а когда достаточно короткого описания

Не каждая задача требует полноценного документа. Для мелких правок — добавить колонку в отчёт, изменить формулу в печатной форме — достаточно короткого описания из 5–10 предложений: что сейчас, что должно быть, пример данных. Такой формат экономит время обеих сторон.

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

Маршрут решения

Как выбрать формат постановки

Правка затрагивает только внешний вид формы или отчётаДостаточно короткого описания со скриншотом и примером желаемого результата

Меняется логика проведения документов или расчётыПишите полное ТЗ с описанием алгоритма и примерами расчёта на конкретных цифрах

Создаётся новый блок учёта или интеграцияНужно расширенное ТЗ с описанием процесса, ролей, источников данных и тестовых сценариев

Вы не можете сформулировать задачу в двух абзацахСначала проведите интервью с пользователями и зафиксируйте процесс, иначе ТЗ получится размытым

Структура ТЗ: что должно быть в документе

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

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

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

1. 1
   Опишите проблему и цель доработки одним абзацем
2. 2
   Зафиксируйте текущий процесс: кто и как выполняет работу сейчас
3. 3
   Опишите целевой процесс шаг за шагом с указанием документов и данных 1С
4. 4
   Приложите макеты отчётов и печатных форм в Excel или на скриншотах
5. 5
   Приведите пример расчёта на конкретных цифрах, если меняется алгоритм
6. 6
   Сформулируйте 3–5 сценариев приёмки: действие и ожидаемый результат
7. 7
   Укажите ограничения: производительность, права доступа, обновляемость конфигурации

Как описывать процесс и алгоритмы, чтобы программист не переспрашивал

Главное правило: описывайте действия пользователя и системы в терминах 1С. Вместо «программа должна учитывать скидку» пишите: «При проведении документа "Реализация товаров и услуг" сумма скидки по каждой строке рассчитывается как процент из поля "Скидка %" в шапке документа; итоговая сумма строки = количество × цена × (1 − скидка/100). Скидка не применяется к товарам из группы "Акционные"».

Обязательно приводите числовой пример: «Реализация: 10 шт. по 1000 руб., скидка 5% → сумма строки 9500 руб.». Программист сверит свою реализацию с вашим примером, и расхождение вскроется до сдачи работы, а не после.

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

Макеты, примеры и критерии приёмки

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

Критерии приёмки формулируйте как проверяемые сценарии: «При проведении реализации со скидкой 5% по двум строкам в отчёте "Комиссия менеджеров" сумма комиссии равна X» — такой пункт можно проверить за минуту, и он однозначен. Избегайте формулировок «отчёт должен работать корректно» — корректность без критериев не проверить.

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

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

Расчёт на тестовых данных

Норма

Результат совпадает с примером из ТЗ до копейки

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

Суммы расходятся или зависят от порядка ввода строк

Отмена и перепроведение документа

Норма

Движения стираются и формируются заново без дублей

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

Остаются «хвосты» в регистрах, итоги удваиваются

Поведение при пустых данных

Норма

Понятное сообщение пользователю или корректный пустой результат

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

Ошибка платформы или аварийное завершение

Права доступа

Норма

Пользователь видит только то, что указано в ТЗ

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

Доработка доступна всем или недоступна целевой роли

Типовые ошибки постановщика

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

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

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

Объём, формат и согласование

Для доработки средней сложности достаточно 3–7 страниц текста плюс макеты. Слишком короткое ТЗ оставляет простор для трактовки, слишком длинное с избыточными деталями читают невнимательно. Оптимум — документ, который можно прочитать за 15–20 минут и по которому можно проверить результат.

Ведите ТЗ в редактируемом формате (Word, Google Docs) с нумерацией пунктов — на пункты удобно ссылаться в переписке: «по п. 4.2 нужно уточнение». Зафиксируйте версию документа, с которой программист согласовал оценку: все последующие изменения — это изменение объёма работ и, возможно, стоимости и сроков. Это нормальная практика, а не конфликт.

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

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

Часто задаваемые вопросы

Можно ли писать ТЗ устно или в переписке?

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

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

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

Что делать, если в ходе работы выяснилось, что ТЗ неполное?

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

Нужно ли в ТЗ указывать сроки и стоимость?

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

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

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

Сколько итераций правок считается нормой?

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