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

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

Хорошее ТЗ не требует от постановщика знания языка 1С или архитектуры платформы. Достаточно понимать собственный бизнес-процесс и уметь описать его через понятия «что пользователь делает», «какие данные вводит», «что должен получить на выходе». Специфику платформы учитывает разработчик, но он может это сделать только при наличии полной картины требований.

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

Зафиксируйте цель и контекст задачи

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

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

Опишите текущий процесс и его проблему

Разработчик не знает ваш бизнес-процесс. Опишите, как задача решается сейчас: кто, в каком документе, какие действия выполняет, где возникает узкое место. Например: «Менеджер оформляет реализацию, затем вручную пересчитывает скидку в Excel и правит сумму в документе. Из-за этого случаются ошибки в расчётах и расхождения с прайсом».

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

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

Ядро ТЗ — пошаговый сценарий будущей работы. Опишите его в формате «пользователь делает → система делает»: «Менеджер открывает документ "Заказ клиента", нажимает кнопку "Рассчитать скидку". Система проверяет сумму заказа, подставляет процент скидки из соглашения с клиентом и пересчитывает итоговые суммы. Если скидка превышает 15%, документ отправляется на согласование руководителю».

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

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

Определите состав данных и привязку к объектам конфигурации

Перечислите все данные, которые участвуют в доработке: какие поля пользователь вводит, какие рассчитываются автоматически, откуда берутся исходные значения. Для каждого поля укажите тип (число, строка, дата, ссылка на справочник), обязательность и источник.

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

Для отчётов приложите макет желаемого результата — хотя бы таблицу в Excel с примером строк и колонок. Словесное описание «отчёт по продажам в разрезе менеджеров» каждый понимает по-своему; макет снимает двусмысленность полностью.

Скриншоты текущих форм с пометками «сюда добавить кнопку», «это поле сделать обязательным» экономят часы переписки. Разработчик видит точное место изменения, а не ищет его по текстовому описанию.

Укажите требования к правам, интеграциям и производительности

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

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

Пропишите критерии приёмки и тестовые примеры

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

Приложите 3–5 тестовых примеров с конкретными входными данными и ожидаемым результатом. По ним разработчик проверит себя до сдачи, а вы — примете работу без споров о том, «что имелось в виду». Договоритесь также о тестовой базе: проверять доработку нужно на копии рабочей базы, а не на боевых данных.

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

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

Сценарий из ТЗ выполняется от начала до конца

Норма

Результат совпадает с описанным в ТЗ на тестовых примерах

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

Функция работает только на «идеальных» данных, при отклонениях — ошибки

Поведение при незаполненных и ошибочных данных

Норма

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

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

Технические ошибки платформы, аварийное завершение

Обновление конфигурации после доработки

Норма

Доработка сохраняется, выполнена через расширение или аккуратно внесена

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

Доработка стёрта обновлением, конфигурация снята с поддержки без необходимости

Типичные ошибки при составлении ТЗ

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

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

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

Какой объём считается нормальным для ТЗ на доработку 1С?

Для небольшой доработки (новая кнопка, реквизит, простой отчёт) достаточно 1–2 страниц. Для задачи среднего масштаба — 3–7 страниц со сценариями и макетами. Объём меньше страницы почти всегда означает недоописанные требования, а документ на десятки страниц для простой задачи — признак того, что её стоит разбить на этапы.

Нужно ли знать язык программирования 1С, чтобы написать ТЗ?

Нет. Постановщик описывает бизнес-процесс, данные и ожидаемый результат на предметном языке. Термины платформы (регистр, табличная часть, проведение) помогают, но не обязательны — грамотный разработчик переведёт предметное описание в объекты конфигурации сам.

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

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

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

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

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

Даже для задачи на один-два часа зафиксируйте минимум: что должно работать, где, и как проверить результат. Это может быть письмо или сообщение в задач-трекере на три-четыре предложения. Полное отсутствие фиксации приводит к тому, что «мелкая доработка» вырастает в цепочку бесплатных переделок для обеих сторон.