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

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

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

Материал ниже разбирает практическую структуру ТЗ, способы описания доработок, критерии приёмки и типичные ошибки, которые приводят к перерасходу бюджета и сроков.

Когда нужно полное ТЗ, а когда достаточно короткой постановки

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

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

Маршрут решения

Как выбрать формат постановки

Задача оценивается в несколько часов и затрагивает один объектОформите короткую карточку: цель, объект, ожидаемое поведение, пример

Доработка меняет логику нескольких документов или создаёт новый механизмПишите полное ТЗ со сценариями, примерами расчёта и критериями приёмки

Планируется интеграция с внешней системойДобавьте к ТЗ описание форматов обмена, частоты, обработки ошибок и ответственных со стороны второй системы

Требования самим заказчиком ещё не сформулированыНачните с интервью и описания бизнес-процесса, а не с ТЗ — иначе документ придётся переписывать

Из каких разделов состоит ТЗ для 1С

Рабочая структура, проверенная на практике, включает шесть обязательных блоков. Пропуск любого из них создаёт зону для разночтений.

• Цель и контекст. Какая бизнес-проблема решается, кто будет пользоваться результатом, почему типовой функционал не подходит.
• Текущее состояние. Конфигурация и её версия, режим совместимости, наличие предыдущих доработок в затрагиваемых объектах.
• Функциональные требования. Что система должна делать: новые объекты, изменения существующих, права доступа.
• Сценарии и примеры. Пошаговые действия пользователя с конкретными данными и ожидаемым результатом.
• Нефункциональные требования. Производительность, ограничения по объёмам данных, требования к обновлению конфигурации.
• Критерии приёмки. Проверяемый список условий, при выполнении которых работа считается сданной.

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

Как описывать доработки: объекты, сценарии, примеры

Главное правило формулировок: описывайте поведение системы через объекты 1С и действия пользователя, а не через абстрактные пожелания. Сравните две записи одной и той же задачи.

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

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

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

Примеры расчётов — обязательный элемент

Любое правило с формулой сопровождайте числовым примером. «Скидка 5% при сумме заказа от 100 000 рублей» — недостаточно: неясно, считается ли порог до скидки или после, как округляется результат, применяется ли скидка к сумме с НДС. Пример «заказ на 120 000 руб. с НДС → скидка 6 000 руб. → итого 114 000 руб.» снимает все три вопроса сразу и одновременно служит тестом при приёмке.

Отчёты и печатные формы: как задавать макеты

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

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

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

Раздел приёмки превращает ТЗ из пожелания в контракт. Формулируйте его как проверяемый список: каждый пункт можно подтвердить или опровергнуть конкретным действием в системе.

Пример пункта приёмки: «При проведении реализации контрагенту с лимитом 50 000 руб. и текущим долгом 45 000 руб. на сумму 10 000 руб. документ не проводится, выводится сообщение "Превышение кредитного лимита на 5 000 руб."». Такой пункт тестируется за две минуты и не допускает двух толкований.

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

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

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

Основной сценарий из ТЗ

Норма

Выполняется по шагам, результат совпадает с примером из ТЗ

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

Поведение отличается или требует действий, не описанных в ТЗ

Граничные случаи: пустые поля, нулевые суммы, отмена проведения

Норма

Система выдаёт понятные сообщения, данные не «зависают»

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

Ошибки платформы, некорректные остатки после отмены

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

Норма

Каждая роль видит и может ровно то, что указано в ТЗ

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

Новые объекты доступны всем или недоступны исполнителям

Скорость на рабочей базе

Норма

Операции выполняются за время, приемлемое для пользователей

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

Отчёт или проведение документа занимает минуты

Обновление конфигурации

Норма

Доработки не блокируют установку типовых обновлений

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

Доработки внесены прямо в типовые объекты без расширения, обновление ломается

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

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

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

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

Согласование ТЗ и работа с изменениями

ТЗ подписывают две стороны: владелец задачи от бизнеса (тот, кто будет принимать результат) и исполнитель. Если пользователей несколько, соберите замечания до утверждения документа, а не в процессе разработки — поток «маленьких уточнений» в середине работы удваивает сроки.

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

Частые вопросы

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

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

Сколько страниц должно быть в ТЗ?

Объём определяется задачей, а не нормативом. Точечная доработка умещается в полстраницы, новый блок учёта — в 5–10 страниц. Тревожный признак не маленький объём сам по себе, а отсутствие примеров и критериев приёмки: две страницы с конкретикой лучше десяти страниц общих слов.

Нужно ли в ТЗ указывать, как именно программировать?

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

Что делать, если не могу сформулировать требования?

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

Как оформить ТЗ на исправление ошибки, а не на новую доработку?

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

Можно ли использовать одно ТЗ для нескольких программистов?

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