Пример технического задания для 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)
• Есть критерии приёмки (как проверить, что готово)
• Указан срок и ответственный со стороны заказчика
• Документ имеет дату и версию

Читайте также: передать ТЗ проверенному 1С-разработчику

Готовое ТЗ можно сразу разместить на бирже 1С Koderion и получить оценки исполнителей.

Читайте также: SLA с подрядчиком 1С: шаблон соглашения и разбор ошибок

Читайте также: 7 ошибок адресного хранения в 1С:УТ 11.5

Читайте также: Регламент удалённой работы с 1С: шаблон и разбор ошибок

Как оценить задачу 1С в часах: алгоритм из 4 шагов

ТЗ готово – дальше нужна цифра. Оценка «на глаз» промахивается в разы, поэтому считают по частям.

Шаг 1. Декомпозиция до кусков по 2–4 часа. Если элемент оценивается как «ну, часов двадцать» – он не разобран. Разбирайте до уровня «написать запрос к регистру», «собрать макет СКД», «добавить отбор по складу». Куски крупнее 8 часов почти всегда оказываются вдвое дороже.

Шаг 2. Три оценки на каждый пункт. Оптимистичная (всё гладко), реальная, пессимистичная (полезли чужие доработки, база на 300 ГБ). Итог считают по формуле (О + 4×Р + П) / 6. Пример для отчёта по остаткам:

Шаг 3. Добавить время вне кода. Разбор чужой конфигурации, снятие копии базы, перенос доработки в рабочую базу, обновление описания, созвоны с бухгалтером. На типовой задаче это 25–40% сверх «чистой» разработки. В примере выше 10 часов превращаются в 13.

Шаг 4. Умножить на ставку. При 2 000 ₽/час получаем 26 000 ₽ – и эта цифра уже защищаема построчно, а не «мне кажется, тысяч тридцать».

Отдельный случай – задача с неизвестной внутренностью: обмен с чужим API, разбор самописной конфигурации без документации. Здесь сначала берут 2–4 часа на исследование, и только после него дают оценку. Попытка оценить задачу 1С вслепую заканчивается либо конфликтом, либо трёхкратным буфером в цене.

Как проверить оценку разработчика и не переплатить

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

Признаки слабой оценки:

• Одно число без разбивки. «40 часов» без списка работ – это не оценка, а ощущение.
• Ноль вопросов по ТЗ. Исполнитель, который реально прочитал документ, обычно задаёт 5–10 уточняющих вопросов: версия релиза, объём базы, что делать с закрытыми периодами.
• Цифра дана без взгляда на базу, хотя конфигурация снята с поддержки. Там доработки идут в 1,5–2 раза дольше типовых.
• Оценка заметно ниже остальных. Из трёх коммерческих предложений крайние обычно отбрасывают: самое дешёвое почти всегда означает, что человек не понял задачу.

Четыре вопроса исполнителю:

1. Что входит в часы – только код или ещё тестирование и перенос в рабочую базу?
2. Какие допущения вы заложили? (Ответ вида «считал, что база файловая и до 20 ГБ» сразу показывает риски.)
3. Что произойдёт, если объём вырастет – вы предупредите заранее или предъявите счёт по факту?
4. Сколько стоит гарантийная правка после сдачи и в какой срок?

Фикс или почасовка. Фиксированная цена работает, когда ТЗ подробное, а объём – до 30–40 часов. Дальше исполнитель либо закладывает буфер +30%, либо начинает экономить на тестировании. Крупные и исследовательские задачи берут по часам, но с лимитом: согласуйте стоп-сумму (например, +20% к оценке), при достижении которой работа останавливается и стороны пересогласовывают бюджет. Это лучше, чем узнать о перерасходе постфактум.

И практическое правило: сравнивайте оценки только по одному и тому же ТЗ. Если один считал по документу, а второй по устному описанию в чате, разница в цене ничего не значит.

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

Обязательно ли составлять ТЗ для небольшой доработки 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С-аналитик переводит это в технические требования и согласовывает с заказчиком. Это снижает риск разночтений до минимума.

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

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

Готовы делегировать доработку – подберите 1С-программиста под задачу.