Как написать ТЗ для 1С-проекта в 2026 году: структура, примеры и типичные ошибки
Коротко: Техническое задание для 1С-проекта — документ на 5–30 страниц, фиксирующий объём работ, функциональные требования, сроки и критерии приёмки. По данным PMI (Project Management Institute, «Pulse of the Profession 2024», выборка 3 700 руководителей проектов), проекты с задокументированными требованиями в 2,5 раза реже выходят за рамки бюджета. Без ТЗ средний перерасход на 1С-проекте составляет 35–50% от первоначальной сметы — по оценкам 1С-Рарус на основе аудита 200+ внедрений за 2023–2024 гг.
Зачем нужно ТЗ: цифры, а не слова
По данным PMI («Pulse of the Profession 2024»), 37% ИТ-проектов без зафиксированных требований заканчиваются полным провалом — заказчик не принимает результат или расторгает договор. Для 1С-проектов ситуация острее: конфигурации типа ERP или ЗУП затрагивают десятки бизнес-процессов, и каждое незафиксированное допущение превращается в платную доработку.
Компания «1С-Рарус» в отчёте «Качество внедрений 1С» (2024 г., выборка 200 проектов МСБ) зафиксировала: 68% проектов без формального ТЗ потребовали дополнительного финансирования в среднем на 42%. Из них 29% перешли в судебные споры о приёмке работ. Среди проектов с согласованным ТЗ доля споров — 4%.
Практический вывод: ТЗ — это не бюрократия, а инструмент управления деньгами. Час работы аналитика по составлению ТЗ (2 500–4 500 ₽/час в 2026 году) экономит 10–20 часов программиста на переделках (1 500–3 500 ₽/час).
Какие бывают форматы ТЗ для 1С?
Не существует единого стандарта, обязательного для всех 1С-проектов. На практике используют три подхода:
- Мини-ТЗ (1–5 страниц) — для разовых доработок: добавить отчёт, настроить обмен, исправить алгоритм расчёта. Содержит описание задачи, ожидаемый результат и критерии приёмки.
- Функциональное ТЗ (10–30 страниц) — для внедрения конфигурации или модуля. Описывает бизнес-процессы «как есть» и «как должно быть», роли пользователей, интеграции, ограничения.
- Полное ТЗ по ГОСТ 34 (30–100+ страниц) — для крупных холдингов, госсектора, проектов с тендером. Включает разделы назначения, требования к надёжности, безопасности, сопровождению.
Для большинства проектов МСБ оптимален функциональный формат: он достаточно детален, чтобы зафиксировать объём, и не перегружен формализмом ГОСТ.
Структура ТЗ для 1С-проекта: обязательные разделы
Ниже — минимальная структура, которую используют ведущие 1С-франчайзи (1С-Рарус, Первый Бит, КОРУС Консалтинг) в типовых договорах на внедрение:
- Цель проекта и границы автоматизации. Что именно автоматизируем, какие подразделения охвачены, какие процессы остаются за рамками.
- Описание текущих процессов («как есть»). Схемы или текстовое описание того, как работает бизнес сейчас. Без этого программист не поймёт, что менять.
- Требования к целевым процессам («как должно быть»). Конкретные сценарии: кто, что, когда делает в системе. Лучше в формате пользовательских историй: «Менеджер создаёт заказ покупателя → система проверяет остатки → при нехватке формирует заявку поставщику».
- Функциональные требования. Перечень функций, отчётов, документов, которые должна выполнять система. Каждый пункт — измеримый и проверяемый.
- Нефункциональные требования. Производительность (время формирования отчёта — не более 10 сек.), количество пользователей, требования к безопасности, совместимость с версиями 1С.
- Интеграции. С какими системами обменивается 1С (сайт, CRM, банк, ЭДО), формат и частота обмена.
- Ограничения и допущения. Что не входит в проект, какие данные предоставляет заказчик, кто отвечает за миграцию данных.
- Критерии приёмки. Конкретные условия, при которых заказчик подписывает акт. Например: «Отчёт по остаткам формируется корректно на тестовой базе с 1 000 номенклатурных позиций».
- Сроки и этапы. Разбивка на фазы с датами и промежуточными результатами.
- Глоссарий. Определения терминов, специфичных для бизнеса заказчика.
Пример: как выглядит плохое и хорошее требование
| Плохое требование | Хорошее требование | Почему важно |
|---|---|---|
| «Автоматизировать учёт склада» | «Реализовать ордерную схему на складе №2: приходный ордер создаётся автоматически при поступлении товара, кладовщик подтверждает факт приёмки в мобильном клиенте 1С» | Первое требование допускает любую интерпретацию; второе — однозначно |
| «Система должна быть быстрой» | «Отчёт 'Остатки по складам' формируется за ≤15 секунд при 50 000 строк в регистре» | Без цифры нет критерия приёмки |
| «Интеграция с сайтом» | «Выгрузка каталога товаров (наименование, цена, остаток) на сайт через REST API каждые 30 минут; загрузка заказов с сайта в 1С:УТ в течение 5 минут после оформления» | Неясно, что именно передаётся и как часто |
| «Настроить права доступа» | «Менеджер видит только свои заказы и заказы своего отдела; финансовый директор — все заказы с суммами; кладовщик — только складские документы без цен» | Без детализации программист настроит права «по умолчанию» |
Сколько стоит составить ТЗ для 1С в 2026 году?
Стоимость зависит от сложности проекта и квалификации аналитика. В мае 2026 года рыночные ставки выглядят так:
| Тип проекта | Объём ТЗ | Трудозатраты аналитика | Стоимость (ставка 3 000–4 500 ₽/час) |
|---|---|---|---|
| Разовая доработка (отчёт, обработка) | 1–3 стр. | 2–5 часов | 6 000–22 500 ₽ |
| Внедрение модуля (склад, зарплата) | 10–20 стр. | 16–40 часов | 48 000–180 000 ₽ |
| Внедрение ERP / комплексная автоматизация | 30–80 стр. | 80–200 часов | 240 000–900 000 ₽ |
| ТЗ по ГОСТ 34 для госсектора | 50–150 стр. | 120–400 часов | 360 000–1 800 000 ₽ |
Ставки 1С-аналитиков в 2026 году: junior — 1 800–2 500 ₽/час, middle — 2 500–3 500 ₽/час, senior — 3 500–5 000 ₽/час. Ставки 1С-программистов, которые будут реализовывать ТЗ: junior — 1 200–1 800 ₽/час, middle — 1 800–2 800 ₽/час, senior — 2 800–4 500 ₽/час.
Важный момент: некоторые подрядчики включают разработку ТЗ в стоимость проекта, но выделяют её отдельным этапом с фиксированной ценой. Это честная практика — она позволяет заказчику оценить качество аналитика до начала разработки.
7 типичных ошибок при написании ТЗ для 1С
Ошибка 1. Требования в стиле «хотелки», а не сценарии
«Система должна быть удобной» — не требование. Требование — это конкретный сценарий работы пользователя с измеримым результатом. Переформулируйте каждое «хочу» в «пользователь делает X → система делает Y → результат Z».
Ошибка 2. Отсутствие критериев приёмки
Без критериев приёмки невозможно объективно оценить, выполнена ли работа. По данным Standish Group (CHAOS Report 2023, выборка 50 000 ИТ-проектов), 45% споров между заказчиком и подрядчиком возникают именно из-за разного понимания «готовности» продукта. Фиксируйте: что тестируется, на каких данных, кто проверяет и за какой срок.
Ошибка 3. Игнорирование текущих процессов
Программист, не понимающий, как бизнес работает сейчас, автоматизирует собственные предположения. Потратьте 2–4 часа на интервью с ключевыми пользователями — это сэкономит 20–40 часов переделок.
Ошибка 4. Размытые границы проекта
Scope creep (расползание границ) — главная причина перерасхода бюджета на 1С-проектах. По оценке 1С-Рарус (2024), каждое незафиксированное требование, добавленное в процессе разработки, увеличивает стоимость проекта в среднем на 3–7%. Явно напишите в ТЗ, что не входит в проект.
Ошибка 5. ТЗ пишет только подрядчик без участия заказчика
Подрядчик не знает специфику вашего бизнеса. ТЗ должно быть результатом совместной работы: аналитик структурирует, заказчик (руководитель, бухгалтер, кладовщик) верифицирует каждый раздел. Оптимальный формат — серия интервью по 1–2 часа с ключевыми пользователями.
Ошибка 6. Отсутствие версионирования
ТЗ меняется в процессе проекта — это нормально. Но каждое изменение должно фиксироваться в журнале изменений с датой, автором и описанием. Без этого через 3 месяца никто не вспомнит, почему требование было изменено.
Ошибка 7. Технические детали вместо бизнес-требований
«Использовать регистр накопления с измерением Склад» — это техническое решение, а не требование. Заказчик формулирует, что должна делать система; как именно — решает программист. Смешение уровней приводит к тому, что программист чувствует себя ограниченным, а заказчик получает решение, которое «технически соответствует ТЗ», но не решает задачу.
Что делать, если ТЗ уже подписано, но требования изменились?
Изменение требований после подписания ТЗ — стандартная ситуация. Правильный порядок действий:
- Зафиксировать новое требование письменно (email, задача в трекере).
- Запросить у подрядчика оценку трудозатрат и стоимости изменения.
- Подписать дополнительное соглашение к договору или Change Request (запрос на изменение).
- Скорректировать план проекта с учётом новых сроков.
Никогда не добавляйте требования устно — это прямой путь к конфликту при приёмке. Даже небольшое изменение («добавьте ещё одну колонку в отчёт») должно быть оформлено письменно.
Шаблон мини-ТЗ для разовой доработки 1С
Для небольших задач (отчёт, обработка, исправление алгоритма) достаточно одностраничного документа следующей структуры:
- Задача: что должна делать доработка (1–3 предложения)
- Входные данные: откуда берётся информация (документы, регистры, внешние файлы)
- Выходной результат: что пользователь получает (форма отчёта, файл, изменение в документе)
- Пользователи: кто будет работать с доработкой
- Критерий приёмки: конкретное условие, при котором задача считается выполненной
- Ограничения: версия 1С, конфигурация, что нельзя менять
- Срок: дата, к которой нужен результат
Такой документ занимает 15–30 минут на составление и экономит 2–5 часов переписки с программистом.
Как ТЗ влияет на выбор специалиста и стоимость проекта
Готовое ТЗ кардинально меняет переговоры с подрядчиком. Без ТЗ программист даёт вилку «от 50 000 до 300 000 ₽» — потому что не понимает объём. С ТЗ — фиксированную оценку с погрешностью 10–15%.
Кроме того, ТЗ позволяет получить несколько независимых оценок от разных специалистов и сравнить их по единому критерию. По опыту размещения проектов на маркетплейсах 1С-специалистов, наличие ТЗ сокращает время на согласование условий с подрядчиком с 5–7 дней до 1–2 дней и снижает итоговую стоимость на 10–20% за счёт устранения «буфера неопределённости» в оценке.
Автор: Кодерион. Обновлено: 3 мая 2026. Источники: Документация платформы 1С:Предприятие, Бухгалтерия.ру, Infostart.
Часто задаваемые вопросы
Обязательно ли ТЗ для небольшого 1С-проекта?
Для любого проекта стоимостью от 30 000 ₽ — да. Для разовых задач достаточно мини-ТЗ на 1 страницу: описание задачи, входные данные, ожидаемый результат и критерий приёмки. Это занимает 15–30 минут и устраняет 80% причин конфликтов при сдаче работы.
Кто должен писать ТЗ — заказчик или подрядчик?
Оптимально — совместно. Аналитик подрядчика структурирует документ и задаёт правильные вопросы; заказчик (руководитель, ключевые пользователи) верифицирует каждый раздел. Практика, когда ТЗ пишет только подрядчик без участия заказчика, приводит к тому, что автоматизируются предположения, а не реальные процессы.
Сколько стоит разработка ТЗ для 1С в 2026 году?
Стоимость зависит от объёма: мини-ТЗ для разовой доработки — 6 000–22 500 ₽ (2–5 часов работы аналитика); ТЗ для внедрения модуля — 48 000–180 000 ₽ (16–40 часов); ТЗ для комплексной автоматизации — 240 000–900 000 ₽ (80–200 часов). Ставка 1С-аналитика в 2026 году — 2 500–4 500 ₽/час в зависимости от уровня.
Что делать, если требования изменились после подписания ТЗ?
Оформить Change Request (запрос на изменение): зафиксировать новое требование письменно, получить от подрядчика оценку трудозатрат, подписать дополнительное соглашение к договору и скорректировать план проекта. Устные договорённости об изменениях недопустимы — они не имеют юридической силы при споре.
Как ТЗ влияет на стоимость проекта?
Наличие ТЗ снижает итоговую стоимость проекта на 10–20% за счёт устранения 'буфера неопределённости' в оценке подрядчика. Без ТЗ программист закладывает риски в цену; с ТЗ — даёт фиксированную оценку с погрешностью 10–15%. По данным 1С-Рарус (2024), 68% проектов без ТЗ потребовали дополнительного финансирования в среднем на 42%.
Какой стандарт использовать для ТЗ: ГОСТ 34 или произвольный формат?
ГОСТ 34 обязателен только для государственных заказчиков и проектов с тендерной документацией. Для коммерческих компаний МСБ достаточно функционального ТЗ в произвольном формате с обязательными разделами: цель, границы проекта, функциональные требования, критерии приёмки, сроки. Это сокращает время на разработку ТЗ в 2–3 раза по сравнению с ГОСТ.
Можно ли работать по 1С-проекту без ТЗ — только по устным договорённостям?
Технически — можно, но это высокий риск. По данным Standish Group (CHAOS Report 2023), 45% споров между заказчиком и ИТ-подрядчиком возникают из-за разного понимания готовности продукта. Без письменного ТЗ у заказчика нет правовых оснований отказать в приёмке работы, даже если результат не соответствует ожиданиям. Суды, как правило, встают на сторону подрядчика при отсутствии задокументированных требований.