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

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

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

Что должно быть в ТЗ до описания доработки

Первый блок — реквизиты среды. Программисту нужно знать, с чем он работает: название конфигурации (например, 1С:Управление торговлей 11), её релиз, версия платформы 1С:Предприятие, режим работы (файловая или клиент-серверная база), наличие расширений и предыдущих доработок. Если конфигурация снята с поддержки или изменена, это критично: от этого зависит способ реализации и стоимость обновлений в будущем.

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

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

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

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

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

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

Пример ТЗ на доработку: реальная формулировка

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

Задача: автоматическая проверка превышения скидки в заказе клиента. Среда: 1С:Управление торговлей 11.5, платформа 8.3.22, конфигурация на поддержке, изменения через расширение. Текущее поведение: менеджер может установить любую скидку, контроля нет. Требуемое поведение: при проведении документа «Заказ клиента» система проверяет скидку по каждой строке; если скидка превышает 15% для группы товаров «Акционные» и 25% для остальных — документ не проводится, пользователю выводится сообщение с номером строки и допустимым значением. Пользователям с ролью «Руководитель продаж» проверка не применяется.

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

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

Функциональные требования: как формулировать проверяемо

Правило одно: требование написано правильно, если по нему можно составить тест. «Система должна работать быстро» — не требование. «Отчёт по продажам за месяц по базе с 500 000 строк движений формируется не дольше 30 секунд» — требование. «Удобный ввод» — не требование. «Подбор номенклатуры в документе осуществляется по артикулу, наименованию и штрихкоду, поиск работает по части строки» — требование.

Описывайте не только основной сценарий, но и граничные случаи. Что происходит, если обязательное поле не заполнено? Если документ проводится задним числом? Если пользователь без нужных прав открывает отчёт? Если в строке нулевое количество? Именно граничные случаи порождают 80% доработок «по факту использования», и дешевле описать их сразу.

Если требований много, группируйте их по объектам: отдельно про документ, отдельно про отчёт, отдельно про права. Внутри группы — нумерация вида 1.1, 1.2. Так на каждый пункт можно сослаться в переписке и в акте приёмки, а программист может отмечать статус реализации по пунктам.

Данные, примеры и критерии приёмки

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

Критерии приёмки — это чек-лист, по которому вы будете принимать работу. Формат: «Доработка считается выполненной, если: 1) заказ со скидкой 20% по обычному товару проводится; 2) заказ со скидкой 20% по акционному товару не проводится, выводится сообщение с номером строки; 3) пользователь с ролью "Руководитель продаж" проводит любой заказ; 4) после обновления конфигурации на следующий релиз доработка сохраняет работоспособность». Каждый пункт проверяется за минуту.

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

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

Как проверить готовую доработку

Основной сценарий

Норма

Действие выполняется, результат совпадает с примером из ТЗ

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

Результат отличается от примера или требует ручных доделок

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

Норма

Пустые поля, нулевые значения и нехватка прав обрабатываются понятными сообщениями

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

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

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

Норма

Доработка в расширении или согласованном механизме, типовое обновление проходит

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

Изменены типовые модули без документирования, обновление ломает доработку

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

Норма

Пользователи видят только разрешённые функции согласно ролям

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

Новые объекты доступны всем или, наоборот, недоступны исполнителям

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

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

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

Сколько деталей достаточно и когда нужен аналитик

Объём ТЗ зависит от задачи. На простую доработку — одна кнопка, одна проверка, одна печатная форма — достаточно 1–2 страниц. На новый блок учёта (например, учёт резервов, которого не было в конфигурации) потребуется 5–15 страниц с описанием процесса, схемой документооборота и примерами проводок или движений. Признак достаточной детализации: программист прочитал ТЗ и задал вопросы только по существу, а не «что вообще нужно сделать».

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

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

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

Доработка точечная: одна проверка, кнопка или печатная формаДостаточно ТЗ на 1–2 страницы по шаблону: среда, текущее поведение, требуемое поведение, пример, критерии приёмки

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

Исполнитель — штатный программист, хорошо знающий базуДопустим сокращённый формат, но критерии приёмки и граничные случаи фиксируйте письменно в любом случае

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

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

Можно ли обойтись без ТЗ, если программист свой и всё понимает?

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

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

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

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

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

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

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

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

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