Разработка и Конфигурация · 12 мин
Как написать техническое задание для 1С
Как составить техническое задание на доработку 1С: структура ТЗ, описание бизнес-процессов, требования к отчётам и интеграциям, типичные ошибки и критерии приёмки.
Техническое задание на доработку 1С — это документ, который определяет, что именно должен сделать разработчик, в какие сроки и по каким критериям результат будет принят. Качество ТЗ напрямую влияет на стоимость работ: расплывчатая формулировка «сделайте удобно» превращается в десятки уточняющих вопросов, переделки и споры о том, входила ли та или иная доработка в изначальный объём.
Хорошее ТЗ для 1С отличается от абстрактного пожелания тремя признаками: оно описывает бизнес-процесс в терминах объектов конфигурации (документы, справочники, регистры, отчёты), содержит проверяемые критерии приёмки и фиксирует границы работ — что делаем, а что осознанно не делаем. Такой документ одинаково понятен заказчику, который не знает внутреннее устройство 1С, и разработчику, который не знает специфику бизнеса заказчика.
Ниже разобрана практическая структура ТЗ, правила описания процессов и требований, а также ошибки, из-за которых доработки срываются по срокам и бюджету.
Определите цель и границы доработки
Прежде чем описывать функции, ответьте на вопрос: какую бизнес-проблему решает доработка. «Нужен отчёт по продажам» — не цель. Цель звучит так: «руководитель отдела продаж тратит два часа в день на ручную сводку данных из трёх отчётов, нужен один отчёт, который формируется за минуту». Такая формулировка позволяет разработчику предложить оптимальное решение, а не слепо следовать букве требования.
Отдельным разделом зафиксируйте границы работ. Укажите, какие конфигурация и релиз используются (например, «1С:Управление торговлей 11.5», «1С:Бухгалтерия 3.0»), работа ведётся в типовой конфигурации или уже доработанной, есть ли расширения. Перечислите, что в работу не входит: обучение пользователей, перенос исторических данных, доработка смежных отчётов. Это защищает обе стороны от «а мы думали, это включено».
Опишите бизнес-процесс «как есть» и «как должно быть»
Разработчик не участвует в ваших ежедневных операциях, поэтому процесс нужно описать пошагово: кто, что и в какой последовательности делает. Для 1С удобен формат: роль пользователя → действие в системе → результат. Например: «Менеджер создаёт заказ покупателя → указывает согласованную скидку → система проверяет, не превышает ли скидка 15% → при превышении заказ отправляется на согласование руководителю».
Описание «как есть» помогает разработчику понять контекст и найти типовой механизм, который частично закрывает задачу. Описание «как должно быть» фиксирует целевое состояние. Разница между ними — и есть объём доработки. Если процесс сложный, приложите схему или таблицу с вариантами: что происходит при обычном сценарии, при отказе, при возврате, при частичном исполнении.
Не забывайте про исключительные ситуации — именно они ломают доработки после внедрения. Что делать, если документ уже проведён, а данные изменились? Что происходит при отмене проведения? Как обрабатываются дубли контрагентов? Каждый такой случай либо опишите в ТЗ, либо явно укажите, что поведение определяется типовым механизмом.
Привязывайте требования к объектам конфигурации
Главная специфика ТЗ для 1С — требования должны опираться на объекты метаданных. Вместо «нужно хранить данные о транспортных средствах» пишите: «создать справочник "ТранспортныеСредства" с реквизитами: госномер (строка, обязательный), марка (ссылка на справочник), грузоподъёмность (число)». Такая формулировка не оставляет пространства для двойной трактовки.
Для документов укажите: какие реквизиты шапки и табличных частей нужны, какие из них обязательные, что происходит при проведении (какие регистры заполняются), какие проверки выполняются до проведения. Для отчётов — источник данных, группировки, отборы, период, внешний вид результата. Для обработок — кто запускает, входные данные, что делает, что выводит.
Если вы не знаете, какой объект нужен, опишите задачу в терминах данных: что вводит пользователь, что система должна запомнить, какие сводные цифры потом нужны. Разработчик сам выберет тип объекта, но ему нужна полная картина данных.
Сформулируйте требования к отчётам, печатным формам и интеграциям
Отчёты — самая частая причина переделок. Чтобы этого избежать, приложите к ТЗ макет: таблицу в Excel или скриншот с примером желаемого результата, заполненный тестовыми данными. Укажите по каждой колонке, откуда берётся значение, какие нужны итоги и группировки, какие отборы должен уметь задавать пользователь. Отдельно опишите поведение при пустых данных: показывать нули, пустые строки или скрывать раздел.
Для печатных форм приложите образец документа и укажите, какие поля заполняются из каких реквизитов, какие — вручную, какие — вычисляются. Если форма регламентирована (счёт-фактура, ТОРГ-12), уточните, достаточно ли типовой формы или нужны изменения.
Интеграции требуют максимальной конкретики: с какой системой обмен, по какому протоколу (файлы, HTTP-запросы, веб-сервисы), в каком формате данные, с какой периодичностью, кто отвечает за вторую сторону. Обязательно опишите обработку ошибок: что происходит, если внешний сервис недоступен, вернул ошибку или прислал неполные данные.
Определите права, производительность и критерии приёмки
Укажите, какие роли пользователей будут работать с новым функционалом и какие ограничения нужны: кто может создавать документы, кто только просматривать, кто согласовывать. Если в конфигурации настроено разграничение прав по организациям или подразделениям, новые объекты должны его учитывать — пропишите это явно.
Если доработка затрагивает большие объёмы данных (обработка тысяч документов, отчёт за год по крупной базе), зафиксируйте ожидания по скорости: «отчёт за месяц должен формироваться не дольше одной минуты на текущей базе». Без такого требования разработчик может сдать формально правильный, но практически неприменимый результат.
Критерии приёмки — самая важная часть ТЗ. Сформулируйте их как проверяемый сценарий: исходные данные → действие → ожидаемый результат. Например: «Создать заказ со скидкой 20% → при проведении система выдаёт сообщение и не проводит документ → после согласования руководителем документ проводится, в регистре продаж появляется запись». Такие сценарии становятся готовым чек-листом приёмки и исключают споры.
Как проверить результат
Движения в регистрах соответствуют описанию в ТЗ
Документ проводится, но данных в регистрах нет или они неполные
Цифры сходятся с ручным расчётом по макету
Итоги расходятся, пустые строки ломают группировки
Движения удаляются, система возвращается в исходное состояние
Остаются «хвосты» в регистрах или связанных объектах
Ограниченная роль видит и делает только разрешённое
Пользователь без прав видит новые документы или отчёты
Соберите ТЗ по рабочей структуре
Готовое ТЗ удобно оформить по единой структуре. Она подходит и для небольшой доработки, и для крупного проекта — меняется только глубина проработки разделов.
- 1Сформулируйте цель: какую проблему решаем и как поймём, что она решена
- 2Укажите конфигурацию, версию и границы работ (что не входит)
- 3Опишите процесс «как есть» и «как должно быть» по шагам с ролями
- 4Перечислите объекты: документы, справочники, регистры, отчёты, обработки — с реквизитами и логикой
- 5Приложите макеты отчётов и печатных форм с тестовыми данными
- 6Опишите права, требования к скорости и обработку ошибок
- 7Запишите критерии приёмки в виде проверяемых сценариев
- 8Согласуйте ТЗ с будущими пользователями до передачи разработчику
Перед передачей разработчику покажите ТЗ тем, кто будет работать с результатом: бухгалтеру, менеджеру, кладовщику. Пользователи почти всегда находят пропущенные сценарии — например, вспоминают про ситуацию, которая случается раз в квартал, но ломает всю логику. Дешевле дописать ТЗ, чем переделывать готовую доработку.
Типовой механизм, расширение или доработка конфигурации
Полезный раздел ТЗ — пожелание по способу реализации, если вы его понимаете. Часть задач решается настройкой типового функционала без программирования: дополнительные реквизиты и сведения, пользовательские отчёты на СКД, настраиваемые рассылки. Это дешевле и не усложняет обновления.
Если нужен код, предпочтительный вариант — расширение конфигурации: оно не снимает конфигурацию с поддержки и упрощает обновления. Прямая доработка конфигурации оправдана, когда расширением задачу не решить (глубокое изменение типовых механизмов проведения), но требует учитывать стоимость сопровождения при каждом обновлении. Если вы не уверены, попросите разработчика в оценке указать предлагаемый способ реализации и его последствия для обновлений.
Способы реализации
Подходит для дополнительных полей, простых отчётов, рассылок. Дёшево, не мешает обновлениям. Ограничение: только то, что умеет типовая конфигурация
Подходит для новых объектов, печатных форм, доработки форм и модулей. Сохраняет поддержку. Ограничение: не все механизмы доступны для переопределения
Подходит для глубоких изменений типовой логики. Максимальная гибкость. Ограничение: усложняет и удорожает каждое обновление
Полезный приём — попросить разработчика до начала работ написать по ТЗ короткое «решение»: какие объекты создаст, какие типовые механизмы использует, что видит рискованным. Две страницы такого текста выявляют разночтения в ТЗ раньше, чем начнётся кодирование, и экономят недели переделок.
Ответы на частые вопросы
Кто должен писать ТЗ — заказчик или разработчик?
Исходное ТЗ пишет заказчик, потому что только он знает бизнес-процесс. Разработчик может помочь перевести требования на язык объектов конфигурации и дополнить техническими деталями — такая совместная проработка обычно входит в этап анализа и оценки. Полностью перекладывать написание ТЗ на исполнителя рискованно: он опишет то, что умеет и хочет делать, а не то, что нужно бизнесу.
Насколько подробным должно быть ТЗ?
Достаточным для однозначной проверки результата. Для небольшой доработки (одна печатная форма, простой отчёт) хватает 2–4 страниц с макетом. Для нового блока учёта — 10–20 страниц с описанием процессов и сценариев приёмки. Признак недостаточной детализации: разработчик задаёт много вопросов по сути, а не по уточнению формулировок.
Что делать, если требования меняются в процессе разработки?
Фиксируйте изменения письменно как дополнение к ТЗ с пересмотром сроков и стоимости. Устные «а давайте ещё вот так» — главный источник конфликтов и перерасхода бюджета. Небольшие уточнения формулировок без изменения объёма можно оформлять комментариями к документу, но любое новое требование — только через согласованное изменение.
Нужно ли в ТЗ описывать перенос данных из старой системы?
Да, если доработка предполагает работу с историческими данными. Укажите источник данных (другая конфигурация 1С, Excel, сторонняя система), объём, период, правила соответствия справочников и что делать с расхождениями. Перенос данных — отдельная нетривиальная задача, и её забывание в ТЗ регулярно срывает запуск.
Как проверить, что разработчик сделал именно то, что в ТЗ?
Прогоните сценарии приёмки из ТЗ на копии базы с реальными данными: создайте документы, проверьте движения в регистрах, сформируйте отчёты и сверьте с ручным расчётом по макету. Проверьте исключительные случаи: отмену проведения, пустые данные, права ограниченной роли. Только после этого подписывайте акт и переносите доработку в рабочую базу.
Можно ли написать ТЗ, не зная терминологии 1С?
Можно, если описывать задачу через данные и действия: что вводит пользователь, что система запоминает, какие цифры и документы должны получиться на выходе. Приложите примеры заполненных документов и желаемых отчётов. Термины «справочник», «регистр», «движения» разработчик подставит сам — ему важнее полнота бизнес-логики, чем правильная терминология в исходном тексте.
Что важно запомнить
Рабочее ТЗ для 1С строится на трёх опорах: пошаговое описание процесса, привязка требований к объектам конфигурации и проверяемые сценарии приёмки. Приложите макеты отчётов и печатных форм, зафиксируйте границы работ и согласуйте документ с будущими пользователями до передачи разработчику. Любые изменения в процессе — только письменным дополнением к ТЗ.