Как написать техническое задание программисту 1С

Большинство конфликтов между заказчиком и программистом 1С начинается не с плохого кода, а с размытой постановки задачи. Фраза «сделайте, чтобы остатки считались правильно» для разработчика не несёт информации: он не знает, что именно считается неправильно, в каком документе, на каких данных и каким должен быть результат. Хорошее ТЗ экономит бюджет, потому что программист тратит часы на доработку, а не на переписку с уточняющими вопросами.

Техническое задание для 1С имеет свою специфику: система опирается на готовые объекты конфигурации (документы, справочники, регистры, отчёты), и грамотное ТЗ ссылается именно на них, а не на абстрактные пожелания. Чем точнее вы опишете, в каком документе, на какой вкладке и с какими данными должна работать доработка, тем меньше итераций потребуется на сдачу-приёмку.

Ниже разобраны структура документа, правила формулировки требований, способы проверки результата и типичные ошибки заказчиков. Материал подходит и для внутреннего постановщика в компании, и для руководителя, который впервые обращается к фрилансеру или франчайзи.

Зафиксируйте бизнес-задачу, а не желаемое решение

Первая часть ТЗ отвечает на вопрос «зачем». Опишите, какая проблема существует сейчас и что изменится после доработки. Например: «Менеджеры вручную сверяют цены в заказах с прайсом поставщика, это занимает около часа в день и приводит к ошибкам в счетах». Такая формулировка позволяет разработчику понять контекст и, при необходимости, предложить более простое техническое решение, чем то, что вы задумали.

Распространённая ошибка — писать в ТЗ готовое решение на уровне кода: «добавить регистр сведений с измерением Номенклатура». Если вы не разработчик, не диктуйте архитектуру. Опишите ожидаемое поведение системы, а выбор механизма оставьте исполнителю — он лучше знает, как это реализовать в вашей конфигурации без конфликтов с типовым функционалом.

Полезно указать, кто будет пользоваться доработкой: бухгалтер, кладовщик, менеджер по продажам. От этого зависят требования к интерфейсу, правам доступа и скорости работы. Одна и та же задача для опытного оператора и для нового сотрудника может потребовать разного оформления.

Опишите объекты конфигурации и текущее поведение системы

Программисту 1С важно знать, с чем ему предстоит работать. Перечислите конкретные объекты: конфигурация и её редакция (например, «1С:Управление торговлей 11» или «1С:Бухгалтерия 3.0»), документы («Реализация товаров и услуг», «Заказ клиента»), справочники, отчёты и обработки, которые затрагивает задача. Укажите, типовая у вас конфигурация или уже доработанная, — от этого зависит способ внедрения изменений и риски при обновлении.

Отдельно опишите, как процесс работает сейчас: какие документы создаются, в какой последовательности, кем, какие данные заполняются вручную. Это «как есть» станет точкой отсчёта, и разработчик сможет воспроизвести сценарий на тестовой базе, не выпытывая детали по телефону.

Если задача связана с обменом данными (с сайтом, складской системой, банком), приложите формат файлов или описание API, примеры реальных выгрузок и требования к частоте обмена. Слова «настроить синхронизацию с сайтом» без форматов данных превращаются в недели переписки.

Сформулируйте требования проверяемыми сценариями

Каждое требование должно быть проверяемым: по нему можно однозначно сказать «выполнено» или «не выполнено». Плохая формулировка: «отчёт должен формироваться быстро». Хорошая: «отчёт по продажам за месяц по всем менеджерам формируется не дольше 30 секунд на рабочей базе». Плохо: «удобная форма ввода». Хорошо: «в документе „Заказ клиента“ на вкладке „Товары“ добавить колонку „Остаток на складе“, значение подставляется автоматически при выборе номенклатуры».

Описывайте сценарии по схеме «действие → результат»: что делает пользователь, что система должна сделать в ответ, что должно получиться. Обязательно укажите граничные случаи: что происходит, если поле не заполнено, если остаток равен нулю, если документ проводится задним числом. Именно граничные случаи чаще всего становятся источником доработок после сдачи.

Для отчётов и печатных форм приложите макет: таблицу в Excel с примером желаемого результата, скриншот с пометками или заполненный образец. Укажите, откуда берётся каждая колонка и по каким правилам группируются и итогируются данные.

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

Определите формат результата и критерии приёмки

Зафиксируйте, что именно вы получите по итогам работы: внешнюю обработку (файл .epf), расширение конфигурации (.cfe), изменения в основной конфигурации, инструкцию для пользователей, описание для администратора. Для типовых конфигураций на поддержке предпочтительны расширения и внешние механизмы — они не ломают обновления. Прямые изменения типовой конфигурации — крайняя мера, и это решение должно быть осознанным.

Критерии приёмки — это чек-лист, по которому вы будете проверять работу. Сформулируйте его до начала разработки: «при проведении документа X с условиями Y формируются движения Z», «печатная форма выводится из кнопки „Печать“ и совпадает с приложенным макетом», «при незаполненном поле система выдаёт сообщение и не проводит документ». Каждый пункт проверяется на тестовом примере.

Договоритесь, на какой базе происходит приёмка: на копии рабочей базы с реальными данными или на демонстрационной. Проверка на реальных данных выявляет проблемы производительности и особенности учёта, которые не видны на пустой базе.

Контрольные точки

Как проверить результат при приёмке

Сценарий из ТЗ на тестовых данных

Норма

Результат совпадает с описанным в ТЗ, включая граничные случаи

Тревожный признак

Работает только «идеальный» сценарий, на ошибочных данных — сбой или молчание

Типовые операции, не связанные с доработкой

Норма

Проведение документов, отчёты и обмены работают как раньше

Тревожный признак

После доработки сломались смежные механизмы

Печатные формы и отчёты

Норма

Совпадают с макетом, итоги сходятся с данными документов

Тревожный признак

Расхождения в суммах, пустые колонки, неверные группировки

Согласуйте сроки, этапы и порядок изменений

Разбейте крупную задачу на этапы с промежуточной сдачей. Это позволяет рано заметить, что разработчик понял задачу иначе, и скорректировать курс до того, как потрачен весь бюджет. Для каждого этапа укажите ожидаемый результат и способ его проверки.

Пропишите порядок внесения изменений: сколько итераций правок входит в стоимость, что считается исправлением ошибки (бесплатно), а что — новым требованием (оплачивается отдельно). Классический конфликт возникает именно здесь: заказчик считает «это же очевидно, что так должно работать», а исполнитель — «этого не было в ТЗ». Чем подробнее сценарии и граничные случаи, тем меньше поводов для спора.

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

Типичные ошибки заказчика при постановке задачи

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

Вторая ошибка — копирование чужих ТЗ «под себя» без адаптации. Конфигурации, учётные процессы и версии платформы различаются, и готовый шаблон из интернета нужно переписывать под ваши объекты и сценарии, иначе он вводит разработчика в заблуждение.

Третья ошибка — отсутствие примеров данных. Разработчик не знает вашей номенклатуры, контрагентов и особенностей заполнения документов. Приложите скриншоты реальных документов, примеры «правильного» и «неправильного» результата — это сокращает количество уточняющих вопросов в разы.

Минимальный шаблон ТЗ для доработки 1С

Для небольших задач достаточно документа на 1–3 страницы по следующей структуре: цель и текущая проблема; конфигурация и её состояние; список затрагиваемых объектов; сценарии работы по схеме «действие → результат» с граничными случаями; макеты отчётов и печатных форм; формат результата (расширение, обработка, изменение конфигурации); критерии приёмки; сроки и порядок согласования правок.

Для крупных проектов (внедрение, интеграция, перевод учёта) добавьте разделы: описание ролей пользователей и прав доступа, требования к производительности, план миграции данных, порядок опытной эксплуатации. Такие проекты разумно начинать с обследования — отдельного оплачиваемого этапа, по итогам которого составляется детальное ТЗ.

Частые вопросы

Нужно ли ТЗ, если доработка совсем маленькая?

Да, но в сокращённом виде. Для задачи на 1–2 часа достаточно письма или сообщения с описанием: где и что должно работать, пример желаемого результата и как вы проверите готовность. Это занимает 10 минут и исключает ситуацию «я думал, вы имели в виду другое».

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

Исходную постановку (цель, сценарии, примеры) всегда даёт заказчик, потому что только он знает учётный процесс. Программист может оформить это в полноценное ТЗ после обследования — такая услуга обычно оплачивается отдельно и окупается точной оценкой сроков и стоимости.

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

Зафиксируйте изменение письменно как дополнение к ТЗ и попросите исполнителя оценить влияние на сроки и стоимость до начала переделки. Устное «заодно сделайте ещё вот это» — главный источник конфликтов и перерасхода бюджета.

Как оценить, адекватна ли оценка трудоёмкости от исполнителя?

Попросите разбить оценку по пунктам ТЗ и объяснить самые дорогие позиции. Размытая оценка одним числом без детализации — повод запросить второе мнение у другого специалиста. Подробное ТЗ как раз позволяет сравнивать оценки разных исполнителей предметно.

Можно ли использовать готовый шаблон ТЗ из интернета?

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

Что делать, если принятая доработка сломалась после обновления конфигурации?

Это типовая ситуация для прямых изменений типовой конфигурации. Заранее договоритесь с исполнителем о гарантийном сроке и условиях доработки после обновлений. Чтобы снизить риск, по возможности требуйте реализации через расширение конфигурации — расширения переживают обновления значительно легче.