Автоматизация · 11 мин
Как составить техническое задание для 1С
Пошаговое руководство по составлению технического задания для доработки 1С: структура ТЗ, формулировка требований, приёмка результата, типичные ошибки и FAQ.
Техническое задание для 1С — это документ, который связывает заказчика и разработчика (внутреннего или внешнего). Качество ТЗ напрямую определяет результат: размытое «сделайте удобный отчёт» приводит к переделкам, спорам о стоимости и сроках, а конкретное задание — к работающей доработке за оговорённый бюджет. При этом ТЗ не обязано быть громоздким: для небольшой задачи достаточно одной-двух страниц, но каждая формулировка должна быть проверяемой.
Главная ошибка заказчиков — описывать решение вместо задачи. Фраза «добавьте кнопку» лишает разработчика возможности предложить более правильный вариант, а фраза «менеджер должен видеть задолженность клиента при создании заказа» оставляет пространство для грамотной реализации. Правильное ТЗ фиксирует, что должно получиться и как это проверить, а не как именно писать код.
Ниже разобрана практическая структура ТЗ, применимая к любым конфигурациям 1С — «Управление торговлей», «Бухгалтерия предприятия», «ERP», «Зарплата и управление персоналом» и самописным решениям. Подход одинаков как для доработки типовой конфигурации, так и для разработки отчёта, обработки или интеграции.
Что подготовить до написания техзадания
До того как формулировать требования, нужно понять текущее состояние. Зафиксируйте, какая конфигурация используется, её версия и релиз, наличие уже сделанных доработок, режим работы (файловая или клиент-серверная база), количество пользователей, которых затронет изменение. Эти сведения влияют на трудоёмкость и на способ реализации: например, доработка типового документа в конфигурации на поддержке и в снятой с поддержки — разные по рискам задачи.
Определите владельца задачи — человека, который будет отвечать на вопросы разработчика и принимать результат. Если вопросы решают три разных менеджера с противоречивыми мнениями, ТЗ развалится ещё на этапе уточнений. Один ответственный со стороны заказчика — обязательное условие.
Соберите исходные материалы: скриншоты текущих форм, примеры заполненных документов, образец желаемого отчёта в Excel, описание регламента, которому должна соответствовать печатная форма. Разработчик не знает вашу специфику: то, что очевидно бухгалтеру, для программиста — неизвестная предметная область.
Смотрите в разделе «О программе»
Влияет на риски при обновлении
Иначе требования будут противоречить друг другу
Без примеров формулировки остаются абстрактными
Структура техзадания: обязательные разделы
Рабочая структура ТЗ для 1С включает шесть блоков. Первый — цель и контекст: зачем нужна доработка, какую бизнес-проблему она решает. Например: «Менеджеры тратят до часа в день на ручной расчёт скидок, ошибки приводят к отгрузкам ниже себестоимости». Такой контекст помогает разработчику принимать верные решения в спорных местах.
Второй блок — описание текущего процесса («как есть»): кто, в какой последовательности и в каких документах 1С выполняет операции сейчас. Третий — требуемый результат («как должно быть»): пошаговый сценарий работы пользователя после доработки, с указанием объектов конфигурации, если они известны. Четвёртый — функциональные требования: конкретный перечень того, что система должна делать.
Пятый блок — нефункциональные требования и ограничения: права доступа, производительность, работа в веб-клиенте или тонком клиенте, совместимость с обновлениями. Шестой — критерии приёмки: как заказчик проверит, что работа выполнена. Именно этого раздела чаще всего нет в слабых ТЗ, и именно он превращает споры «сделано / не сделано» в объективную проверку.
Как формулировать требования, чтобы их поняли правильно
Каждое требование должно быть проверяемым. Плохо: «отчёт должен быть быстрым и удобным». Хорошо: «отчёт формируется по кнопке из карточки контрагента за период, выбранный пользователем, и содержит колонки: дата, номер документа, сумма, дни просрочки». Проверяемость означает, что по формулировке можно составить тест и однозначно ответить «да» или «нет».
Описывайте сценарии от лица пользователя: «Менеджер открывает документ "Заказ клиента", нажимает кнопку "Проверить лимит", система сравнивает сумму заказа с остатком лимита контрагента и при превышении выводит предупреждение и блокирует проведение». Такая форма сразу отвечает на вопросы: где находится функция, кто ей пользуется, что происходит в штатной и нештатной ситуации.
Обязательно описывайте граничные случаи: что делать, если данных нет, если документ не проведён, если у пользователя нет прав, если значение отрицательное. Именно на граничных случаях ломается большинство доработок, сделанных по «очевидным» ТЗ. Если поведение в исключительной ситуации не задано, разработчик выберет его сам — и оно может не совпасть с ожиданиями.
Требования к отчётам, печатным формам и интеграциям
Отчёты — самый частый предмет ТЗ. Для отчёта укажите: источник данных (какие документы и регистры участвуют), перечень колонок с точными названиями, группировки и итоги, отборы, которые пользователь сможет менять, период по умолчанию. Приложите макет в Excel с одной-двумя заполненными строками — это устраняет 90% недоразумений.
Для печатной формы приложите образец, утверждённый тем, кто её использует (юрист, бухгалтер, руководитель). Укажите, из какого документа она вызывается, какие поля документа куда попадают, что выводить при пустых значениях. Если форма регламентирована (например, ТОРГ-12), сошлитесь на форму и уточните отклонения от типовой.
Интеграции требуют отдельной тщательности: укажите, с какой системой идёт обмен, в каком формате (файлы, веб-сервис, API), направление и частота обмена, что происходит при ошибке связи, кто отвечает за вторую сторону. Без согласованного формата обмена с владельцем внешней системы ТЗ на интеграцию бессмысленно — разработчик упрётся в недоступность второй стороны.
Критерии приёмки и проверка результата
Критерии приёмки оформляйте как список проверок: «При проведении заказа с суммой выше лимита система выводит сообщение и не проводит документ», «Отчёт за январь по контрагенту Х совпадает с контрольным расчётом в Excel». Каждый пункт — это тест, который заказчик выполняет на своих данных. Такой список защищает обе стороны: заказчик получает предсказуемый результат, разработчик — защиту от бесконечных «а ещё сделайте».
Проверку проводите на копии рабочей базы с реальными данными, а не на пустой демонстрационной. Пустая база скрывает проблемы производительности и ошибки на нестандартных данных: документах с пустыми полями, помеченных на удаление объектах, дублях контрагентов. Проверьте как минимум штатный сценарий, сценарий с ошибкой и работу пользователя с ограниченными правами.
Зафиксируйте порядок устранения замечаний: сколько итераций исправлений входит в стоимость, что считается ошибкой разработчика, а что — новым требованием. Новые пожелания, возникшие после подписания ТЗ, — это отдельная задача с отдельной оценкой, иначе проект никогда не закроется.
Как проверить результат
Операция выполняется по описанию из ТЗ
Поведение отличается или требует лишних действий
Понятное сообщение, система не «падает»
Техническая ошибка или молчаливый неверный результат
Функция доступна нужной роли, недоступна лишним
Видна всем или недоступна исполнителю
Операция выполняется за приемлемое время на реальном объёме
Отчёт или проведение «зависают» на рабочих данных
Типичные ошибки при составлении ТЗ
Первая ошибка — отсутствие критериев приёмки, из-за чего приёмка превращается в субъективную оценку. Вторая — описание решения вместо задачи, которое лишает разработчика возможности предложить оптимальный вариант. Третья — игнорирование граничных случаев и прав доступа: доработка работает у администратора и не работает у рядового менеджера.
Четвёртая ошибка — отсутствие примеров и макетов: «красивый отчёт» у каждого свой. Пятая — попытка включить в одно ТЗ всё сразу: десять несвязанных доработок сложно оценить, тестировать и принимать. Дробите работу на независимые задачи со своими критериями приёмки. Шестая — устные дополнения в мессенджере: всё, что не попало в документ, не существует.
Формат документа и согласование
Для небольших задач достаточно документа на 1–3 страницы в любом текстовом редакторе: структура важнее оформления. Для крупных проектов ТЗ становится частью договора, и к нему предъявляются формальные требования: нумерация требований, версии документа, подписи сторон. Нумеруйте требования (например, ТР-1, ТР-2) — это упрощает ссылки в переписке и акте приёмки.
Согласование идёт в два этапа: сначала внутреннее — с будущими пользователями и их руководителем, затем с разработчиком. Разработчик должен подтвердить, что требования понятны и реализуемы, и дать оценку трудоёмкости. Если оценка сильно расходится с ожиданиями, это сигнал: либо требование понято неверно, либо выбран неверный способ реализации — вернитесь к формулировке.
После согласования зафиксируйте версию документа. Все изменения вносятся новой версией с описанием, что поменялось и почему. Это дисциплинирует обе стороны и позволяет в конце проекта ответить на вопрос, почему результат отличается от первоначального замысла.
Что важно запомнить
Хорошее ТЗ для 1С описывает цель, текущий процесс, требуемый результат в виде пользовательских сценариев, граничные случаи, ограничения и проверяемые критерии приёмки. Примеры и макеты важнее красивых формулировок, а изменения после согласования — только новой версией документа.
Частые вопросы
Можно ли поручить написание ТЗ самому разработчику?
Можно, и это распространённая практика: разработчик интервьюирует заказчика и оформляет ТЗ сам. Но заказчик обязан внимательно прочитать и подтвердить документ, особенно разделы о сценариях и критериях приёмки. Подписанное неглядя ТЗ перекладывает все риски на заказчика.
Насколько подробным должно быть ТЗ для мелкой доработки?
Для задачи на несколько часов достаточно половины страницы: цель, сценарий, пример, критерий проверки. Экономия на описании мелкой задачи оборачивается перепиской и переделками, которые стоят дороже, чем 20 минут на формулировку.
Что делать, если требования меняются в процессе разработки?
Оформляйте изменение новой версией ТЗ: что добавлено, что исключено, как это влияет на сроки и стоимость. Устные «а давайте ещё» без фиксации — главная причина срыва сроков и конфликтов при оплате.
Нужно ли в ТЗ указывать, как именно реализовать задачу в коде?
Нет, если у заказчика нет собственной команды разработки с внутренними стандартами. Способ реализации — ответственность исполнителя. Заказчику важно зафиксировать ограничения: не снимать конфигурацию с поддержки, использовать расширение, обеспечить работу в веб-клиенте.
Кто должен тестировать результат?
Первичную проверку делает разработчик, но приёмку на реальных данных — ключевой пользователь, который будет работать с доработкой ежедневно. Только он заметит неудобства и несоответствия реальному процессу, невидимые со стороны.
Чем ТЗ отличается от постановки задачи в системе учёта заявок?
Задача в трекере — это обычно краткая формулировка для исполнителя. ТЗ — согласованный документ с критериями приёмки, по которому принимают и оплачивают работу. Для внутренних мелких задач достаточно карточки в трекере, но при работе с подрядчиком нужен именно документ.