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

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

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

Ниже разобрана практическая структура технического задания, применимая и для небольших доработок типовых конфигураций (1С:Бухгалтерия, Управление торговлей, ЗУП), и для более крупных задач по автоматизации. Материал ориентирован на руководителей, главных бухгалтеров и внутренних специалистов, которые ставят задачи штатному или внешнему программисту.

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

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

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

Из каких разделов состоит рабочее ТЗ

Универсальная структура технического задания для доработки 1С включает шесть блоков. Для простой задачи каждый блок может занимать два-три предложения, для крупной — отдельный документ с приложениями.

• Цель и контекст. Какая бизнес-проблема решается и почему текущий механизм не подходит. Пример: «Менеджеры вручную считают скидки в Excel, из-за этого ошибки в 5–7 документах в неделю».
• Описание текущего процесса. Как пользователь выполняет операцию сейчас: какие документы создаёт, куда вносит данные.
• Описание требуемого результата. Пошаговый сценарий «как должно стать»: что пользователь нажимает, что система делает автоматически.
• Данные и правила расчёта. Конкретные поля, формулы, условия, примеры на реальных цифрах.
• Ограничения. Права доступа, производительность, совместимость с обменами, запрет на изменение типовых объектов.
• Критерии приёмки. Проверяемый список: «при вводе документа с этими данными результат должен быть таким-то».

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

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

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

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

Пример пары «плохо — хорошо»

Плохо: «Сделать отчёт по долгам клиентов». Хорошо: «Нужен отчёт "Дебиторская задолженность по срокам". Пользователь: финансовый контролёр. Отборы: организация, период, контрагент. Колонки: контрагент, договор, сумма долга, разбивка по интервалам просрочки (до 7 дней, 8–30, 31–60, свыше 60). Долг считается по данным взаиморасчётов на дату формирования отчёта. Пример заполнения — во вложении (скриншот из Excel, которым пользуемся сейчас)».

Зачем в ТЗ примеры данных и контрольный пример

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

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

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

Что обязательно указать в ограничениях и нефункциональных требованиях

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

• Обновляемость конфигурации. Если конфигурация типовая и стоит на поддержке, прямо укажите: «доработку выполнять через расширение или внешнюю обработку, типовые объекты не изменять». Иначе каждое обновление превратится в платную работу по переносу изменений.
• Обмены и интеграции. Если база обменивается данными с сайтом, другой конфигурацией или ЭДО, перечислите это — изменение состава документа может сломать выгрузку.
• Права доступа. Кто должен видеть новую кнопку или отчёт: все пользователи или только определённые роли.
• Производительность. Если отчёт строится по большому объёму данных, укажите ожидание: «формирование за разумное время при объёме N документов в месяц» — и дайте разработчику доступ к копии рабочей базы для проверки.
• Исторические данные. Нужно ли пересчитывать прошлые документы или новая логика действует только для новых.

Как принимать выполненную доработку

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

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

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

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

Контрольный пример из ТЗ

Норма

Результат в программе совпадает с расчётом в задании

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

Суммы или поведение отличаются — фиксируйте расхождение с данными

Граничные значения: ноль, пустые поля, максимальная скидка

Норма

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

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

Ошибка платформы, зависание, отрицательные суммы без пояснений

Смежные механизмы: печать, обмены, отчёты

Норма

Работают как до доработки

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

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

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

Норма

Изменения в расширении или внешней обработке, типовые объекты не тронуты

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

Изменены типовые модули без согласования — обновление станет проблемой

Типичные ошибки заказчика и как их избежать

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

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

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

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

FAQ

Нужно ли писать ТЗ на совсем маленькую доработку, например добавить одну колонку?

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

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

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

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

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

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

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

Что делать, если после приёмки нашлась ошибка?

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

Можно ли использовать шаблон ТЗ из интернета?

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