Техническое задание (ТЗ) — это самый важный документ в любом проекте по изменению 1С. На практике более 70% споров о сроках, стоимости и качестве доработок возникают из-за нечеткого, неполного или противоречивого ТЗ. Эта статья — не просто описание разделов, а детальное руководство по созданию «рабочего» ТЗ на доработку 1С, которое станет железобетонной основой для успешного проекта и защитит интересы как заказчика, так и исполнителя.
Философия ТЗ: почему «сделать чтобы было удобно» — путь к краху проекта?
Плохое ТЗ — это не отсутствие документа, а документ, который:
- Нельзя проверить: Нет четких критериев приемки.
- Толкует двусмысленно: Позволяет трактовать требования по-разному.
- Не учитывает исключений: Описывает только «счастливый путь» (happy path).
- Изолировано от данных: Не учитывает объемы, миграцию истории.
Идеальное ТЗ — это юридически значимый документ и источник истины, который:
- Однозначно описывает ЧТО нужно сделать.
- Не предписывает КАК это сделать технически (это задача исполнителя, если иное не оговорено).
- Позволяет проверить результат (имеет четкие критерии приемки).
- Управляет ожиданиями обеих сторон.
Исчерпывающая структура ТЗ на доработку 1С (с детализацией каждого пункта)
Раздел 1: Общие положения (Контекст)
- 1.1. Наименование проекта: «Автоматизация расчета комиссий для отдела продаж в 1С:УНФ».
- 1.2. Заказчик и Исполнитель: Реквизиты сторон, ФИО и контакты ответственных лиц (с правом подписания протоколов).
- 1.3. Цели и задачи проекта: Кратко, на бизнес-языке. Цель: снизить время расчета мотивации с 3 дней до 2 часов, исключить ошибки ручного расчета. Задачи: разработать механизм расчета по гибким правилам, ввести электронное согласование, создать аналитические отчеты.
- 1.4. Глоссарий: Определения всех ключевых терминов. Например: «Агентское вознаграждение — процент от суммы закрытой сделки, выплачиваемый менеджеру…».
Раздел 2: Текущее состояние (AS-IS)
- 2.1. Описание текущего бизнес-процесса: Схема в нотации BPMN или простой нумерованный список шагов. «1. Бухгалтер раз в месяц выгружает отчет из 1С… 2. В Excel применяет формулы…».
- 2.2. Проблемы и ограничения текущего подхода: *«Высокая трудоемкость (3 дня), частые ошибки из-за человеческого фактора, отсутствие прозрачности для менеджеров, невозможно учесть индивидуальные условия по клиентам.»*
Раздел 3: Требуемое состояние и функциональные требования (TO-BE)
Это ядро ТЗ. Требования должны быть:
- Пронумерованы (для удобства ссылок).
- Сформулированы в виде «User Story» (Как <Роль>, я хочу <Функцию>, чтобы <Получить выгоду>).
- Снабжены критериями приемки (Acceptance Criteria, AC).
Пример детализированного требования:
FUNC-3: Расчет вознаграждения по сложным правилам.
- User Story: Как руководитель отдела продаж, я хочу задавать для каждого менеджера или группы менеджеров многоуровневые правила расчета комиссии, чтобы автоматически рассчитывать мотивацию с учетом разных условий.
- Детализация:
- 3.1. Правило должно задаваться в виде: «Если процент прибыли по сделке от 0% до 10%, то комиссия = 5% от суммы. Если от 10% до 20%, то комиссия = 7% от суммы. Если >20%, то комиссия = 10% от суммы».
- 3.2. Должна быть возможность комбинировать условия по: типу клиента (новый/старый), региону, сумме сделки.
- 3.3. В интерфейсе настройки правил должен быть предпросмотр расчета на тестовых данных.
- Критерии приемки (AC):
- AC 3.1: В справочнике «Менеджеры» появилась закладка «Правила расчета».
- AC 3.2: При проведении документа «Реализация» система автоматически выбирает и применяет актуальное правило для ответственного менеджера, результат сохраняется в отдельном регистре сведений.
- AC 3.3: В отчете «Расчет комиссий» сумма рассчитана идентично эталонному расчету в Excel (приложен файл
Test_Data.xlsx, лист «Сценарий 3»).
Другие ключевые подразделы Раздела 3:
- 3.X. Требования к интерфейсу (UI/UX): Не «сделать удобно», а конкретика. «На форме документа «Заказ покупателя» добавить кнопку «Рассчитать комиссию» справа от поля «Ответственный». Результат расчета выводить во всплывающем окне с возможностью ручной корректировки.» Обязательно приложить макеты (wireframe), созданные в Figma, draw.io или даже четкие скриншоты с нарисованными от руки пометками.
- 3.Y. Требования к отчетам: Формат (печатная форма, Excel, сводная таблица), группировки, отборы, показатели. «Отчет «Анализ выполнения планов» должен выводить данные в разрезе: Менеджер -> Клиент -> Месяц, с графиком в виде гистограммы.»
Раздел 4: Интеграции и обмен данными
- 4.1. Внешние системы: Указать системы, с которыми должна интегрироваться доработка (сайт, CRM, маркетплейс).
- 4.2. Форматы и протоколы: JSON over REST API, SOAP, выгрузка в CSV.
- 4.3. Частота и инициатор обмена: «Выгрузка остатков на сайт каждые 5 минут по расписанию», «Прием заказов с маркетплейса в реальном времени по веб-хуку».
Раздел 5: Нефункциональные требования (NFR)
- 5.1. Производительность: «Расчет комиссии для 5000 документов реализации за месяц должен выполняться не более 10 минут».
- 5.2. Безопасность: «Настройка правил расчета доступна только роли «Руководитель отдела продаж». Менеджеры видят только свои начисления».
- 5.3. Нагрузка: «Система должна корректно работать при одновременной работе до 30 пользователей».
Раздел 6: Миграция исторических данных
- 6.1. Объем данных: «Необходимо перенести историю начислений за 2022-2023 годы (около 40 000 записей)».
- 6.2. Метод миграции: «Разработать обработку, которая загрузит данные из существующего файла Excel (
History_comission.xlsx) в новый регистр. Валидация: контроль сумм и привязки к менеджерам».
Раздел 7: Состав и порядок приемки работ
- 7.1. Этапы поставки: Может быть привязано к итерациям (Agile) или единым релизом (Waterfall). «Этап 1: Настройка правил и расчет. Этап 2: Отчетность и интерфейс согласования.»
- 7.2. Критерии сдачи этапа: «Все функциональные требования с номерами FUNC-1 — FUNC-5 реализованы и соответствуют заявленным критериям приемки (AC)».
- 7.3. Процедура приемки: «Исполнитель предоставляет доступ к тестовой базе. Заказчик в течение 5 рабочих дней проводит тестирование и формирует Протокол испытаний. При отсутствии замечаний подписывается Акт сдачи-приемки.»
Приложения
- Приложение А: Макеты экранных форм и отчетов.
- Приложение Б: Эталонные данные для тестирования.
- Приложение В: Схемы бизнес-процессов (AS-IS и TO-BE).
Типичные ошибки в ТЗ и как их избежать
| Ошибка (что писать НЕ надо) | Как исправить (как писать НАДО) |
|---|---|
| «Система должна работать быстро» | «Операция открытия справочника «Контрагенты» при объеме 50 000 записей должна выполняться не более 3 секунд». |
| «Доработать отчет «Оборотно-сальдовая» под наши нужды» | «В стандартный отчет ОСВ добавить возможность группировки по субконто «Проект» в разрезе каждого счета, с выведением отдельной колонки «Доля в %». Приложен макет (Приложение А1).» |
| «Сделать интеграцию с наш сайт» | «Реализовать выгрузку номенклатуры и остатков в формате YML по протоколу HTTPS на адрес api.site.com/1c/export. Спецификация API в Приложении Б.» |
| [Пустота в разделе исключений] | Добавить раздел «Ограничения и исключения»: «Система не рассчитывает комиссию для документов, находящихся в статусе «Черновик». Расчет для бартерных сделок требует ручного ввода ставки.» |
Жизненный цикл ТЗ: от проекта до сопровождения
- Создание черновика: Ответственный со стороны Заказчика (владелец процесса) формулирует потребности.
- Совместная проработка: Сессии с бизнес-аналитиком Исполнителя. Аналитик помогает структурировать, задает уточняющие вопросы, предлагает решения.
- Согласование и подписание: Документ согласуется со всеми заинтересованными сторонами (пользователи, ИТ-отдел, руководство) и подписывается.
- Базис для оценки: Исполнитель на основе детального ТЗ дает оценку в часах и стоимости. Важно: Цена фиксируется за реализацию требований из ТЗ. Новые требования — это новая оценка.
- Изменение требований: Любое изменение после подписания оформляется Приложением к ТЗ или Протоколом о намерениях с четким описанием изменений в объемах, сроках и стоимости.
Заключение: ТЗ как инструмент управления, а не формальность
Идеально составленное техническое задание на доработку 1С — это не бюрократия, а основной инструмент управления проектом. Оно страхует бюджет, сроки и нервы обеих сторон. Инвестиция времени в создание качественного ТЗ на старте окупается в десятки раз на этапах разработки, приемки и сопровождения.
Начните с самого «болевого» процесса. Опишите его по предложенной структуре, даже если делаете это для внутренних специалистов. Вы сразу увидите, насколько четче станет понимание задачи и сколько «подводных камней» всплывет на этапе проектирования, а не в момент, когда программист уже все сделал.