Как написать ТЗ программисту 1С: практическое руководство

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

Хорошее ТЗ — это не формальный документ, а рабочий инструмент. Оно фиксирует, что именно должно измениться в конфигурации, как это проверить и кто подтверждает результат. Для типовых конфигураций 1С (Бухгалтерия, Управление торговлей, ЗУП, ERP) грамотное ТЗ сокращает время разработки в разы, потому что программисту не приходится угадывать логику учёта.

Составить такое задание может и не технический специалист. Главное — опираться на конкретные бизнес-процессы, примеры документов и проверяемые критерии приёмки, а не на абстрактные пожелания. Ниже — пошаговая схема и готовые формулировки.

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

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

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

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

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

Рабочее ТЗ для доработки 1С удобно строить по фиксированной схеме. Она одинаково подходит и для небольшой задачи на несколько часов, и для проекта внедрения.

1. Общие сведения: конфигурация, релиз, режим работы (файловая или клиент-серверная база), наличие расширений и предыдущих доработок.
2. Цель: какой бизнес-результат должен быть достигнут и для каких пользователей.
3. Текущее поведение: как процесс работает сейчас, пошагово, со ссылками на конкретные документы и отчёты.
4. Требуемое поведение: как должно работать после доработки, с примерами расчётов и форм.
5. Критерии приёмки: проверяемый список «сделано / не сделано».
6. Ограничения: что менять нельзя, требования к обновляемости конфигурации, сроки.

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

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

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

Всегда указывайте источник данных. Если нужна новая колонка в отчёте, напишите, откуда берётся значение: из какого реквизита документа, регистра накопления или справочника. Если вы не знаете технику — приложите скриншот и напишите «значение должно совпадать с полем X в карточке Y». Программист сам найдёт нужный объект метаданных.

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

Пример формулировки задачи

Слабая формулировка: «Нужно, чтобы менеджеры видели долги клиентов». Сильная формулировка выглядит так:

Задача: отчёт «Дебиторская задолженность по менеджерам» в УТ 11. Доступ: раздел «Продажи», права — роль «Менеджер по продажам». Данные: задолженность по документам реализации, сгруппированная по менеджеру и контрагенту, с разбивкой по срокам: не просрочено, 1–7 дней, 8–30 дней, более 30 дней. Срок оплаты берётся из соглашения с клиентом; если не указан — считать 14 дней от даты реализации. Приёмка: на тестовой базе по контрагенту «ООО Пример» сумма в отчёте совпадает с данными карточки взаиморасчётов на выбранную дату.

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

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

Как учесть обновляемость и сохранность типовой конфигурации

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

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

Как организовать приёмку результата

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

Проверку выполняйте на копии рабочей базы с реальными данными, а не на пустой тестовой. Пустая база скрывает проблемы с производительностью и с нестандартными данными, которые накопились за годы учёта.

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

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

Поведение на типовых документах

Норма

Доработка работает на стандартных проведённых документах

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

Работает только на примере, который показывал исполнитель

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

Норма

Незаполненные поля и непроведённые документы обрабатываются корректно или с понятным сообщением

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

Программа выдаёт ошибку или молча считает неверно

Типовой функционал

Норма

Смежные механизмы (проведение, отчёты, права) работают как раньше

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

После доработки сломалось то, что работало до неё

Обновляемость

Норма

Доработка вынесена в расширение или список изменённых объектов передан

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

Типовой код изменён, перечень изменений отсутствует

Частые ошибки заказчика и как их избежать

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

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

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

FAQ: частые вопросы о ТЗ для 1С

Нужно ли в ТЗ описывать техническую реализацию?

Нет, если вы не разработчик. Опишите бизнес-результат и критерии проверки, а выбор механизма (запрос, СКД, расширение) оставьте исполнителю — он подберёт вариант, который проще поддерживать. Исключение — случаи, когда вы осознанно ограничиваете решение, например требуете не изменять типовой код.

Как оценить адекватность сроков, которые назвал программист?

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

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

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

Достаточно ли скриншотов вместо текстового описания?

Нет. Скриншот показывает, что есть сейчас, но не объясняет желаемую логику и граничные случаи. Оптимально — связка: короткое текстовое описание плюс скриншоты и примеры как иллюстрации.

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

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

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

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