Как составить техническое задание для 1С-разработчика: шаблон, примеры и типичные ошибки

Коротко: Техническое задание для 1С-разработчика — это документ на 3–15 страниц, который описывает бизнес-процесс, входные/выходные данные, логику работы и критерии приёмки. Без ТЗ 60% проектов выходят за бюджет или срок. Минимальный шаблон включает 6 блоков: цель, контекст, функциональные требования, ограничения, сроки и критерии готовности. Составить базовое ТЗ можно за 2–4 часа по готовому шаблону.

Зачем нужно ТЗ и что происходит без него?

Отсутствие технического задания — главная причина конфликтов между заказчиком и 1С-разработчиком. По данным практики проектов на Koderion.ru, 58% споров о доплате возникают именно тогда, когда требования были переданы устно или в мессенджере. Разработчик делает «как понял», заказчик ожидал «как представлял» — и в итоге переделки съедают 20–50% бюджета.

Конкретный пример: компания заказала доработку печатной формы накладной без ТЗ. Разработчик потратил 8 часов (16 000 ₽), но заказчик хотел другой шрифт, логотип и порядок колонок. Ещё 6 часов переделок — итого 28 000 ₽ вместо плановых 12 000 ₽. Простое ТЗ на 1 страницу с макетом и списком полей закрыло бы вопрос с первого раза.

Сколько стоит разработка с ТЗ и без него?

Из каких блоков состоит ТЗ для 1С-разработчика?

Стандартное техническое задание для задачи в 1С содержит 6 обязательных блоков. Для небольших доработок (до 20 часов) достаточно 1–3 страниц. Для крупных проектов внедрения — 10–50 страниц с приложениями.

Блок 1. Цель и бизнес-контекст

Опишите, зачем нужна доработка и какую проблему она решает. Не «сделать отчёт», а «сократить время формирования еженедельного отчёта по остаткам с 2 часов до 5 минут». Хорошая цель содержит измеримый результат. Этот блок занимает 3–5 предложений и помогает разработчику принимать решения при неоднозначных ситуациях.

Блок 2. Описание текущего процесса

Опишите, как процесс работает сейчас: кто участвует, какие документы создаются, где возникают ошибки или потери времени. Можно использовать простую схему «Кто → Что делает → В какой системе → Что получает на выходе». Этот блок занимает 0,5–2 страницы и часто выявляет требования, о которых заказчик забыл упомянуть.

Блок 3. Функциональные требования

Это ядро ТЗ. Каждое требование формулируется как «Система должна...» и содержит конкретное действие. Пример плохой формулировки: «Удобный интерфейс». Пример хорошей: «Форма подбора товара должна фильтровать номенклатуру по артикулу, наименованию и остатку на складе в режиме реального времени». Список требований нумеруется — это упрощает обсуждение и приёмку.

Блок 4. Технические ограничения

Укажите конфигурацию 1С (например, «1С:Бухгалтерия 3.0.148.21»), режим работы (файловый или клиент-серверный), наличие типовой конфигурации или снятие с поддержки, интеграции с внешними системами. Это критично: доработка в типовой конфигурации стоит в 1,5–2 раза дешевле, чем в сильно изменённой.

Блок 5. Сроки и приоритеты

Укажите желаемую дату готовности и, если есть, промежуточные контрольные точки. Отдельно выделите «must have» (без чего нельзя запустить) и «nice to have» (желательно, но не критично). Это позволяет разработчику предложить MVP за меньший бюджет, если сроки поджимают.

Блок 6. Критерии приёмки

Опишите, как вы поймёте, что задача выполнена. Например: «Отчёт формируется за 30 секунд при базе 500 000 строк», «Форма не вызывает ошибок при выборе более 1000 позиций», «Данные совпадают с текущим ручным расчётом на тестовой выборке из 20 документов». Без критериев приёмки разработчик считает задачу готовой, а заказчик — нет.

Шаблон ТЗ для типовых задач 1С

7 типичных ошибок в ТЗ для 1С и как их избежать

Ошибка 1. «Сделать как в Excel»

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

Ошибка 2. Требования в мессенджере

Переписка в Telegram или WhatsApp не является ТЗ. Разработчик не обязан перечитывать 200 сообщений. Даже краткий документ в Google Docs лучше, чем чат. Зафиксированные требования — это защита и заказчика, и исполнителя.

Ошибка 3. Отсутствие примеров данных

Абстрактные формулировки типа «рассчитать наценку» порождают разночтения. Приложите 5–10 строк тестовых данных с ожидаемым результатом. Это снимает 80% вопросов на этапе разработки.

Ошибка 4. Игнорирование edge cases

Что происходит, если поле пустое? Если дата в прошлом? Если пользователь нажал кнопку дважды? Разработчик реализует «счастливый путь», а на реальных данных система падает. Опишите хотя бы 3–5 граничных случаев.

Ошибка 5. ТЗ без версии и даты

Если ТЗ менялось в процессе разработки, а версии не фиксировались — неизбежен конфликт «я просил вот это, а не то». Каждая редакция должна иметь дату и краткое описание изменений.

Ошибка 6. Требования к интерфейсу вместо требований к функции

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

Ошибка 7. Нет ответственного со стороны заказчика

Если разработчик не знает, к кому обращаться с вопросами, он либо делает по своему усмотрению, либо простаивает. В ТЗ укажите конкретного человека (имя, контакт), который принимает решения по задаче в течение 24 часов.

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

Оптимальная схема в 2026 году — совместная. Заказчик описывает бизнес-процесс и ожидаемый результат, разработчик или аналитик переводит это в технические требования и согласовывает с заказчиком. Стоимость составления ТЗ силами 1С-аналитика — 3 000–8 000 ₽ за задачу среднего размера или включается в стоимость проекта. Это вложение окупается: экономия на переделках в среднем составляет 25 000–80 000 ₽ на проект.

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

Как ТЗ влияет на стоимость и сроки разработки?

Разработчик оценивает задачу точнее, когда понимает её полностью. Без ТЗ оценка содержит «буфер неопределённости» — обычно +30–50% к реальным часам. С подробным ТЗ оценка точнее, а финальная стоимость реже превышает плановую. По статистике проектов на Koderion.ru за 2025–2026 год: задачи с ТЗ закрываются в срок в 78% случаев, без ТЗ — только в 41%.

Чек-лист: ТЗ готово к передаче разработчику

• Указана цель с измеримым результатом
• Описан текущий процесс (кто, что, где)
• Функциональные требования пронумерованы и начинаются с «Система должна...»
• Приложены примеры данных или макеты
• Указана версия конфигурации 1С
• Обозначены граничные случаи (минимум 3)
• Есть критерии приёмки (как проверить, что готово)
• Указан срок и ответственный со стороны заказчика
• Документ имеет дату и версию

Автор: Кодерион. Обновлено: 22 мая 2026. Источники: Бухгалтерия.ру, Infostart, ИТС 1С.

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

Обязательно ли составлять ТЗ для небольшой доработки 1С?

Для задач до 4 часов достаточно краткого описания на 0,5–1 страницу с примером данных и критерием готовности. Для задач от 8 часов полноценное ТЗ обязательно — иначе риск переделок и споров об оплате резко возрастает.

Сколько стоит составление ТЗ для 1С силами аналитика?

Составление ТЗ 1С-аналитиком стоит 3 000–8 000 ₽ для задач среднего размера (8–20 часов разработки). Для крупных проектов внедрения — 20 000–80 000 ₽. Обычно окупается за счёт сокращения переделок.

Что обязательно должно быть в ТЗ для 1С-разработчика?

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

Можно ли передать требования к 1С устно или в мессенджере?

Нет. Устные требования и переписка в мессенджерах не являются ТЗ и не защищают ни заказчика, ни разработчика. По статистике, 58% споров о доплате возникают именно при отсутствии письменного ТЗ.

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

Задачи с ТЗ закрываются в срок в 78% случаев против 41% без ТЗ. Чёткие требования сокращают количество итераций согласования с 2–5 до 0–1 и ускоряют приёмку результата с 5–14 до 1–3 дней.

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

Оптимально — совместно. Заказчик описывает бизнес-процесс и ожидаемый результат, разработчик или 1С-аналитик переводит это в технические требования и согласовывает с заказчиком. Это снижает риск разночтений до минимума.

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

Оформить дополнение к ТЗ с датой и описанием изменений. Если изменения существенные — пересогласовать стоимость и сроки. Каждая редакция ТЗ должна иметь версию и дату, чтобы избежать споров о том, что было согласовано изначально.