Техническое задание на доработку 1С должно отвечать на три вопроса: что меняем, зачем и как проверить, что всё сделано. На практике это семь разделов: общие сведения (термины, цели, системы), описание текущего бизнес-процесса, требования к функционалу на уровне объектов метаданных, влияние на отчётность, роли и права, интерфейс и сценарий тестирования. Такой документ даёт программисту точную постановку, руководителю — обоснованную оценку, а через год — ответ на вопрос «почему это сделано так».
Ниже — структура, которую я использую сам и прошу от аналитиков, с примером формулировок и чек-листом проверки ТЗ перед передачей в разработку.
Зачем ТЗ на доработку 1С, если «всё и так понятно»
Типовая постановка «добавьте в отчёт колонку с менеджером» порождает сразу несколько вопросов: какой менеджер — из документа, из карточки контрагента или ответственный на дату? Что выводить, если его нет? Нужна ли колонка в других вариантах отчёта? Ответы программист получит либо до разработки, либо после — в виде переделок.
Хорошее ТЗ решает четыре задачи:
- Оценка. Программист видит, какие объекты меняются, и оценивает трудоёмкость, а не угадывает.
- Согласование. Заказчик подписывает конкретный результат, а не ожидания.
- Приёмка. Есть сценарий и критерии — спор «так задумывалось» снимается.
- Сопровождение. Новый специалист через год понимает смысл доработки без археологии в коде.
Структура технического задания на доработку 1С
Название
Название сразу говорит, о каком объекте речь: «ТЗ на доработку отчёта „Анализ продаж“», «ТЗ по задаче 1234: контроль лимита кредита», «ТЗ на разработку загрузки табеля из Excel». Номер задачи из системы учёта заявок связывает документ с историей обсуждения.
1. Общие сведения
- Термины и сокращения. Всё, что может быть понято двояко: «реферал», «отгрузка» в смысле конкретного документа, РН — регистр накопления.
- Цели изменений. Какую проблему бизнеса решаем и как поймём, что решили: «бухгалтер сверяет реферальные выплаты за минуты, а не вручную по таблице».
- Область применения. Конфигурация и её редакция (например, ЗУП 3.1 или ERP 2.5), базы, в которых будет работать доработка, наличие расширений и интеграций, которые она может задеть.
2. Описание бизнес-процесса
Текущее состояние: кто, что, когда и в какой последовательности делает, в каких документах это отражается и что именно не устраивает. Если процесс меняется — второй абзац с целевой схемой. Без этого раздела программист реализует буквальную формулировку, а не смысл.
3. Требования к функционалу и способ реализации
Центральный раздел. Здесь бизнес-требования переводятся на язык конфигурации: какие реквизиты, регистры, формы, отчёты, из каких данных и по каким правилам.
Пример формулировки для 1С:ЗУП:
В документ «Приём на работу» добавить реквизит «Реферальная программа» (Булево) и реквизит «Реферер» (СправочникСсылка.Сотрудники). «Реферер» доступен и обязателен к заполнению, только если установлен флаг «Реферальная программа». При проведении документа записывать данные в новый регистр сведений «Реферальная программа»: измерение «Сотрудник», ресурсы «Реферер», «Дата приёма». Разработать отчёт «Реферальная программа» с колонками: № п/п, Реферал, Реферер, Дата трудоустройства; отбор по периоду приёма и подразделению.
Чем конкретнее источник данных («из регистра такого-то, на дату документа»), тем точнее оценка и меньше вопросов. Отдельно укажите способ внедрения: расширение конфигурации или изменение основной конфигурации — от этого зависит стоимость будущих обновлений.
Полезно добавить в раздел пограничные случаи: что делать при пустых данных, при сторнировании, при повторном проведении, при загрузке из обмена.
4. Влияние на отчётность
Меняются ли регламентированные или управленческие отчёты? Если доработка пишет в регистры, которые читают типовые отчёты, это обязательно фиксируется — иначе «неприятный сюрприз» всплывёт при сдаче отчётности.
5. Роли и права доступа
Нужны ли новые роли, в какие профили и группы доступа их добавить, кто должен видеть новый отчёт или реквизит. Имена ролей лучше давать с префиксом проекта, чтобы их было легко отличить от типовых. Если права не меняются — так и пишем.
6. Интерфейс
В какой подсистеме и разделе разместить новый объект, нужна ли команда на форме, в каком месте формы появится реквизит. Для существующего инструмента — «остаётся в разделе такой-то».
7. Порядок тестирования
Если нет отдельной программы и методики испытаний, сценарий проверки входит в ТЗ:
| Что указать | Пример |
|---|---|
| База | Копия рабочей базы, адрес публикации или путь |
| Пользователь | Профиль «Кадровик», без полных прав |
| Шаги | Создать «Приём на работу», установить флаг, выбрать реферера, провести |
| Ожидаемый результат | В отчёте за месяц строка с реферером и датой приёма |
| Негативные проверки | Без реферера документ не проводится, текст ошибки понятен |
Этот же сценарий программист использует для самопроверки, а при наличии автотестов его удобно превратить в регрессионный тест.
Пример короткой постановки для мелкой задачи
Подробный документ на задачу в два часа не нужен. Минимальная постановка:
Задача: 1240. Отчёт «Анализ продаж» — колонка «Менеджер».
Сейчас: менеджера в отчёте нет, сверяют вручную.
Нужно: колонка «Менеджер» из реквизита «Менеджер» документа реализации;
если пусто — «Не указан». Доступна во всех вариантах отчёта.
Где: раздел «Продажи», отчёт «Анализ продаж».
Проверка: сформировать за сентябрь, сверить три документа выборочно.Пять строк — и программисту не нужно ничего уточнять.
Чек-лист перед передачей ТЗ в разработку
- Понятно, зачем доработка нужна бизнесу, и есть измеримый результат.
- Указаны конфигурация, редакция и способ внедрения (расширение или основная конфигурация).
- Каждое новое поле описано типом, источником данных и правилом заполнения.
- Описаны пограничные случаи: пусто, повторное проведение, обмен.
- Проверено влияние на отчётность и права.
- Есть сценарий тестирования с ожидаемым результатом.
- ТЗ согласовано с тем, кто будет принимать работу.
Сколько стоит хорошее ТЗ
Подробное ТЗ дорого: аналитику нужно провести интервью, изучить конфигурацию и данные, описать процесс. На крупных доработках это заметная часть бюджета. Но экономить здесь обычно невыгодно — переделка готового функционала стоит больше, чем час-два аналитики на старте. Корпоративные заказчики это понимают; небольшим компаниям я предлагаю короткую постановку в формате выше и подробное ТЗ только для задач, затрагивающих учёт и отчётность.
Если внутри компании некому формализовать задачу, могу помочь с постановкой в рамках консультации или взять задачу целиком — от ТЗ до сдачи доработки 1С.
Итог
- ТЗ на доработку 1С отвечает на вопросы «что», «зачем» и «как проверить».
- Семь разделов: общие сведения, процесс, требования к функционалу, отчётность, роли, интерфейс, тестирование.
- Требования описываются на уровне объектов метаданных с источником данных и пограничными случаями.
- Для мелких задач хватает короткой постановки из пяти строк.
- Сценарий тестирования в ТЗ экономит время и на приёмке, и на будущих обновлениях.
