Как написать техническое задание 1С

Техническое задание (ТЗ) на доработку 1С — это документ, который связывает заказчика и разработчика: он фиксирует, что должна делать система, в каких условиях и как будет проверяться результат. Качество ТЗ напрямую определяет стоимость и сроки проекта: расплывчатое задание приводит к бесконечным уточнениям, переделкам и спорам о том, что именно входило в объём работ.

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

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

Какие требования собрать до написания ТЗ

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

Отдельно изучите текущую конфигурацию: её название и версию, наличие доработок, режим поддержки (на поддержке, частично снята, полностью снята). Это критично для разработчика: доработка типовой конфигурации на поддержке и изменённой базы — разные по трудоёмкости задачи. Укажите в ТЗ точное название и релиз конфигурации, например «1С:Управление торговлей, редакция 11» с номером релиза.

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

Структура технического задания на доработку 1С

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

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

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

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

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

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

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

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

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

Этот раздел чаще всего пропускают, и зря. Укажите, каким ролям доступна новая функциональность: «доработка доступна пользователям с ролью „Менеджер по продажам", остальным — только просмотр». Если доработка затрагивает проведение документов, опишите ожидания по скорости: например, проведение документа на 500 строк не должно заметно замедляться по сравнению с текущим состоянием.

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

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

Критерии приёмки: как проверить, что работа выполнена

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

Готовьте тестовые примеры заранее, на этапе написания ТЗ: конкретные документы с конкретными суммами и ожидаемыми итогами. Если для расчёта премии вы указали пример «оклад 100 000, коэффициент 1,2, итог 120 000», то при приёмке вы просто воспроизводите пример и сверяете цифры. Проверяйте не только «счастливый путь»: добавьте сценарии с пустыми данными, отрицательными остатками, отменёнными документами.

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

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

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

Воспроизведение примеров из ТЗ

Норма

Результаты совпадают с ожидаемыми цифрами

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

Расхождения в расчётах или система выдаёт ошибки

Поведение на граничных данных

Норма

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

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

Ошибки платформы, «молчаливые» неверные результаты

Типовые операции

Норма

Существующие документы и обмены работают как раньше

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

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

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

Норма

Функционал виден только указанным ролям

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

Доработка доступна всем или недоступна целевым пользователям

Типичные ошибки при написании ТЗ для 1С

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

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

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

Шаблон и порядок согласования ТЗ

Минимальный рабочий шаблон ТЗ выглядит так: шапка (конфигурация, релиз, дата, автор), цель доработки, область действия и исключения, нумерованные функциональные требования с примерами, нефункциональные требования, критерии приёмки с тестовыми сценариями, порядок передачи результата. Для небольших доработок достаточно 2–4 страниц; объёмные проекты дробите на несколько ТЗ по подсистемам.

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

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

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

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

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

Насколько подробно описывать алгоритмы?

Достаточно подробно, чтобы по описанию можно было составить тест и однозначно проверить результат. Формулы расчётов, источники данных и поведение в исключительных случаях описывайте полностью; внутреннюю реализацию (какие запросы и функции использовать) оставьте разработчику, если у вас нет обоснованных требований к ней.

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

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

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

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

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

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

Чем ТЗ отличается от частного технического задания (ЧТЗ)?

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