Автоматизация · 11 мин
Как составить техническое задание для 1С
Как составить техническое задание на доработку 1С: структура ТЗ, описание процессов, ролей и отчетов, типичные ошибки и способы проверки результата.
Техническое задание — главный документ, по которому программист 1С понимает, что именно нужно сделать, а заказчик — что именно он получит. Размытое ТЗ вида «сделайте удобно» почти гарантированно приводит к переделкам, срыву сроков и спорам о стоимости. Четкое ТЗ, наоборот, экономит бюджет: разработчик тратит время на работу, а не на уточняющие вопросы и догадки.
Хорошая новость в том, что для составления рабочего ТЗ не нужно быть программистом. Нужно уметь описать свой бизнес-процесс: кто что делает, какие документы при этом создаются, какие данные откуда берутся и какой результат должен получиться. Вся техническая часть — выбор объектов конфигурации, механизмов и архитектуры — это уже задача разработчика, но он сможет её решить только на основе вашего описания.
Ниже разобрана практическая структура ТЗ для доработки или внедрения 1С: какие разделы включить, как формулировать требования, как проверить готовое ТЗ до передачи в работу и какие ошибки чаще всего приводят к провалу проекта.
Когда ТЗ обязательно, а когда достаточно устной постановки
Не каждая задача требует полноценного документа. Если нужно поправить одну печатную форму или добавить реквизит в справочник, достаточно короткой постановки в системе учета задач: скриншот, что изменить, пример результата. Письменное ТЗ становится обязательным, когда затрагивается несколько объектов конфигурации, несколько ролей пользователей или когда работа оценивается дороже пары дней труда.
Простой критерий: если результат работы можно проверить за пять минут, глядя на один экран, — ТЗ можно сократить до полстраницы. Если для проверки нужно провести цепочку документов, сформировать отчет и сравнить цифры — без подробного ТЗ приемка превратится в спор.
Как выбрать формат постановки
Из чего состоит рабочее ТЗ: структура документа
Универсальная структура, которая подходит для большинства доработок 1С, включает семь разделов. Не обязательно называть их именно так — важно, чтобы информация присутствовала.
- Цель доработки. Одно-два предложения: какую проблему решаем и как поймем, что она решена. Например: «Менеджеры тратят 20 минут на ручной расчет скидки; после доработки скидка должна рассчитываться автоматически при проведении заказа».
- Текущий процесс (как есть). Пошаговое описание того, как задача решается сейчас, со ссылками на конкретные документы и отчеты в базе.
- Целевой процесс (как должно быть). Пошаговое описание новой схемы: кто, в каком документе, какие данные вводит и что система делает автоматически.
- Функциональные требования. Список конкретных требований к объектам: новые реквизиты, правила заполнения, проверки, расчеты, проводки, печатные формы.
- Роли и права. Кто видит и может изменять новые данные, какие ограничения нужны.
- Отчеты и контрольные примеры. Какие отчеты должны строиться, из каких данных, с примером ожидаемых цифр.
- Критерии приемки. Проверяемый список: «при проведении документа X с такими-то данными должно произойти Y».
Для небольших доработок разделы «как есть» и «как должно быть» можно объединить в одну таблицу из двух колонок — так различия видны наглядно.
Как описать бизнес-процесс без технического жаргона
Главное правило: описывайте действия людей и документы, а не объекты конфигурации. Формулировка «менеджер создает заказ покупателя, указывает клиента и товары, система должна автоматически подставить цену из последнего договора» понятна любому разработчику. Формулировка «добавить функцию в модуль объекта» без контекста — нет.
Каждый шаг процесса описывайте по схеме: кто выполняет → в каком документе или форме → какие данные вводит → что система делает автоматически → что является результатом шага. Если на каком-то шаге есть условия («если сумма больше 100 000 — нужно согласование руководителя»), выносите их в отдельный пункт, а не прячьте внутри абзаца.
Особое внимание уделите исключениям. Разработчик реализует ровно то, что написано: если в ТЗ описан только «счастливый путь», то возвраты, частичные оплаты, отмены документов и работа «задним числом» окажутся неучтенными и сломают логику. Пройдитесь по процессу и спросите себя: что бывает нестандартного хотя бы раз в месяц?
Как формулировать функциональные требования
Каждое требование должно быть проверяемым: по нему можно написать тест и однозначно ответить «выполнено» или «не выполнено». Сравните две формулировки: «система должна быстро рассчитывать скидку» — непроверяемо; «при изменении количества в строке заказа скидка пересчитывается автоматически по таблице из приложения 1, без нажатия дополнительных кнопок» — проверяемо.
Практические правила формулировок:
- Указывайте точные названия объектов, как они видны пользователю в программе: документ «Реализация товаров и услуг», справочник «Контрагенты», а не «база клиентов».
- Все правила расчетов приводите с формулами и числовым примером: «Скидка = 5% при сумме от 50 000 до 100 000 руб.; 7% — свыше 100 000. Пример: сумма 120 000 → скидка 8 400, итого 111 600».
- Для печатных форм прикладывайте макет — хотя бы нарисованный в Excel — с указанием, откуда берется каждое поле.
- Для интеграций указывайте направление обмена, перечень передаваемых полей, частоту и что делать при ошибке связи.
- Избегайте слов «удобно», «красиво», «оптимально» без пояснения, что это значит в конкретных действиях.
Роли, права и ограничения
Раздел о правах часто пропускают, и зря: доработка, доступная всем подряд, может дать менеджерам возможность менять закрытые периоды или видеть зарплатные данные. Для каждой новой функции укажите: какие должности с ней работают, кто может только просматривать данные, а кто — создавать и изменять, нужны ли ограничения по организациям, складам или подразделениям.
Если в компании несколько юридических лиц или обособленных подразделений, явно напишите, должен ли пользователь видеть данные «чужих» подразделений. Это влияет и на архитектуру решения, и на трудоемкость: настройка разграничения прав — заметная часть работы.
Отчеты, контрольные примеры и критерии приемки
Отчет — самая спорная часть доработок, потому что «не тот итог» выясняется в самом конце. Чтобы этого избежать, для каждого отчета зафиксируйте: источник данных (какие документы и регистры участвуют), группировки и отборы, формулы итоговых колонок и контрольный пример — набор тестовых данных с заранее посчитанным результатом.
Критерии приемки оформите списком сценариев вида «действие → ожидаемый результат». Например: «Провести заказ на 120 000 руб. → в поле "Скидка" появляется 8 400 руб., сумма документа 111 600 руб., документ проводится без ошибок». Такие сценарии одновременно служат чек-листом для тестирования и защищают обе стороны при приемке.
Как проверить готовое ТЗ перед передачей
Человек, не участвовавший в обсуждении, понимает процесс без устных пояснений
ТЗ понятно только автору; половина логики «в голове»
По каждому пункту можно написать тест и ответить «да/нет»
Есть формулировки «удобно», «быстро», «корректно» без критериев
Описаны возвраты, отмены, частичные случаи и работа задним числом
Описан только идеальный прямой путь процесса
Для каждого расчета и отчета есть числовой пример с результатом
Формулы есть, но сверить результат не с чем
Согласование, изменения и типичные риски
ТЗ должны увидеть все, чью работу оно меняет: не только руководитель, но и те, кто будет нажимать кнопки. Практика показывает, что половина важных уточнений появляется именно от рядовых пользователей — они знают про исключения, о которых управленцы не подозревают. Дайте им прочитать раздел с целевым процессом и соберите замечания до старта разработки, а не на приемке.
Зафиксируйте порядок внесения изменений: любые новые пожелания после согласования ТЗ оформляются отдельным дополнением с оценкой влияния на сроки и стоимость. Иначе проект превращается в бесконечную «движущуюся мишень», где невозможно ни закончить работу, ни предъявить претензии.
Отдельный риск — работа с копией базы. Все разработка и тестирование должны вестись только на копии; прямое указание в ТЗ и в договоре о том, что приемка выполняется на тестовой базе с заранее подготовленными данными, защищает рабочую информацию от повреждений.
Сколько времени занимает составление ТЗ и кто должен его писать
Оптимальная схема: ТЗ пишет тот, кто владеет процессом (руководитель отдела, главный бухгалтер, внутренний аналитик), а разработчик задает уточняющие вопросы и фиксирует технические ограничения. Если ТЗ полностью пишет программист со слов заказчика, он невольно подменяет описание задачи готовым решением — и заказчик теряет возможность проверить, решена ли его проблема, а не какая-то другая.
По срокам ориентируйтесь на пропорцию: ТЗ на доработку в 2–3 недели разработки обычно требует 2–5 рабочих дней на сбор требований, описание и согласование. Попытка сэкономить этот этап почти всегда оборачивается большими потерями на переделках.
Что важно запомнить
Хорошее ТЗ описывает процесс, роли, данные и правила расчетов словами бизнеса, содержит числовые примеры и проверяемые критерии приемки. Согласуйте его с реальными пользователями до старта, ведите разработку на копии базы и по возможности используйте расширения вместо изменения типовой конфигурации.
Частые вопросы о ТЗ для 1С
Кто должен писать ТЗ — заказчик или программист 1С?
Основу пишет заказчик, потому что только он знает процесс, исключения и желаемый результат. Программист дополняет документ техническими ограничениями и задает вопросы по неоднозначным местам. Если нет ресурса на самостоятельное описание, закажите платный этап обследования: аналитик со стороны исполнителя опишет процесс, а вы его утвердите.
Какого объема должно быть ТЗ?
Объем вторичен, важна полнота. Точечная доработка умещается в 1–2 страницы, типовая доработка документооборота — в 5–15 страниц, проект внедрения — в несколько десятков. Тревожный признак не маленький объем, а отсутствие примеров, формул и критериев приемки.
Нужно ли в ТЗ указывать объекты конфигурации — регистры, справочники, документы?
Нет, если вы не уверены в технической части. Опишите, какие данные где вводятся и какие отчеты нужны — выбор объектов и архитектуры это зона ответственности разработчика. Ошибочное техническое предписание в ТЗ хуже его отсутствия: исполнитель формально выполнит требование, но решение окажется неудачным.
Что делать, если требования изменились в середине разработки?
Оформите изменение письменным дополнением к ТЗ: что меняется, почему, как это влияет на сроки и стоимость. Устные «а давайте еще вот так» — главная причина сорванных сроков и конфликтов при оплате. Небольшие уточнения, не меняющие логику, можно фиксировать перепиской, но с явным подтверждением обеих сторон.
Как принимать работу, если я не разбираюсь в 1С технически?
Вам и не нужно: приемка строится на сценариях из раздела критериев приемки. Возьмите тестовую базу, выполните каждый сценарий руками и сверьте результат с тем, что записан в ТЗ, включая числовые примеры. Если все сценарии проходят, а исключения обрабатываются как описано, — работу можно принимать.
Можно ли использовать чужой шаблон ТЗ из интернета?
Как отправную точку — да, но не как готовый документ. Шаблоны полезны списком разделов, однако ценность ТЗ в конкретике вашего процесса: ваших документах, исключениях и контрольных цифрах. Скопированные формулировки без привязки к вашей базе дают ложное ощущение полноты.