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

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

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

Хорошее ТЗ не обязано быть длинным. Для небольшой доработки достаточно одной-двух страниц, если в них есть конкретика: сценарий использования, пример данных, ожидаемый результат и способ проверки. Ниже разобрана структура документа, правила формулировок и способы контроля результата.

Определите цель и границы доработки

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

Сразу обозначьте, что НЕ входит в работу. Если вы заказываете отчёт по продажам, уточните: нужна ли настройка прав доступа, выгрузка в Excel, рассылка по расписанию. Каждый неозвученный пункт всплывёт на этапе приёмки как «а мы думали, это само собой разумеется».

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

Опишите текущее поведение и желаемый результат

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

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

Если доработка касается расчётов — цен, скидок, налогов, остатков — приведите числовой пример с исходными данными и точным ожидаемым результатом. Пример с конкретными цифрами устраняет 90% разночтений в логике расчёта.

Зафиксируйте сценарии использования и роли пользователей

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

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

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

Приложите макеты и примеры данных

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

Для обменов данными и интеграций укажите формат (XML, JSON, CSV, таблица Excel), направление обмена, периодичность и пример файла. Без образца реального файла разработчик будет ориентироваться на предположения, и первая загрузка почти наверняка выявит несоответствия.

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

Установите критерии приёмки и порядок проверки

Критерии приёмки — это список проверок, по которым вы решаете, выполнена работа или нет. Формулируйте их как тест: «при проведении заказа с товаром X создаётся резерв на складе Y», «печатная форма содержит колонки А, Б, В, итог по сумме совпадает с суммой документа».

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

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

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

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

Соответствие ТЗ

Норма

Каждый пункт ТЗ подтверждён на тестовом примере

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

Разработчик говорит «всё работает», но показать по пунктам не может

Поведение на ошибках

Норма

Система выдаёт понятные сообщения и не создаёт некорректные данные

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

При ошибке вылетает техническое окно или документ проводится с пустыми значениями

Обновление конфигурации

Норма

Доработки внесены расширением, типовое обновление проходит штатно

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

Конфигурация снята с поддержки без предупреждения

Производительность

Норма

Операции выполняются за оговорённое время на реальном объёме данных

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

На трёх тестовых строках работает, на реальных данных зависает

Согласуйте формат, сроки и стоимость

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

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

Определите, что является результатом работы: обновлённая база, файл расширения, инструкция для пользователей. Потребуйте краткое описание внесённых изменений — оно понадобится при следующих доработках и при смене исполнителя.

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

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

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

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

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

Для задачи на несколько часов работы достаточно компактного документа из шести блоков: цель доработки, конфигурация и способ внесения изменений, описание «сейчас / нужно», числовой пример или макет, критерии приёмки, срок и стоимость. Такой документ составляется за 30–60 минут и окупается уже на первой доработке.

Храните ТЗ и переписку по нему в одном месте — в задаче трекера, в папке проекта. При повторных обращениях к тому же разработчику старые ТЗ становятся основой для новых: не придётся заново объяснять устройство ваших процессов.

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

Можно ли дать программисту 1С задачу без ТЗ, если доработка маленькая?

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

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

Исходную постановку даёт заказчик, потому что только он знает бизнес-процесс. Хорошая практика — разработчик на основе вашего описания составляет детальное ТЗ и отдаёт вам на согласование. Это платная, но полезная работа: она выявляет нестыковки до начала кодирования.

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

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

Как понять, что оценка часов от разработчика завышена?

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

Нужно ли в ТЗ указывать, через расширение делать доработку или в конфигурации?

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

Что делать, если разработчик сдал работу, а она не соответствует ТЗ?

Составьте письменный список несоответствий со ссылками на пункты ТЗ и примерами: какие данные ввели, что получили, что ожидали. Исправление ошибок в рамках согласованного ТЗ — обязанность исполнителя и отдельно не оплачивается. Спорные трактовки решайте по числовым примерам и макетам из ТЗ — для этого они и нужны.