← На главную

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

Учет целевой аудитории и регламентов заказчика

Перед тем как приступать к написанию документа, выясним, для кого именно составляется ТЗ и какие стандарты приняты в компании. Существует два основных сценария:

1. ТЗ как внутренний документ для разработчика. В этом случае фокус делается на технической архитектуре, объектах метаданных, алгоритмах проведения и интерфейсных решениях.
2. ТЗ как приложение к договору с заказчиком. Здесь упор делается на бизнес-цели, описание пользовательских сценариев и критерии приемки выполненных работ.

Важно предварительно уточнить у заказчика или руководителя проекта, используются ли в организации корпоративные шаблоны, стандарты ГОСТ (например, ГОСТ 34.602-89 или ГОСТ 19.201-78) или формат Частного технического задания (ЧТЗ). Использование слишком сложного ГОСТ-формата там, где требуется небольшая локальная доработка, может усложнить согласование, а излишне краткое описание приведет к непониманию со стороны программиста.

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

Проанализируем проверенную на практике универсальную структуру ТЗ, которая подходит для большинства задач по доработке конфигураций 1С:

1. Описание задачи со слов заказчика (Бизнес-контекст). Краткое изложение проблемы, которую необходимо решить, с точки зрения конечных пользователей и бизнеса.
2. Описание решения от постановщика/аналитика. Постановка задачи на техническом языке, опирающаяся на логику работы 1С.
3. Спецификация изменяемых и создаваемых объектов. Четкий перечень элементов конфигурации, требующих добавления или корректировки.
4. Сценарии тестирования и критерии приемки (Acceptance Criteria). Условия, при выполнении которых задача считается полностью решенной.
5. Вопросы для согласования и допущения. Несогласованные моменты или ограничения, влияющие на ход разработки.

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

Технические детали 1С, которые обязательно отражаются в ТЗ

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

1. Способ реализации и архитектурный подход:
   • Применение расширения конфигурации (.cfe) — приоритетный способ, позволяющий оставить типовую конфигурацию на поддержке.
   • Создание внешних обработок или печатных форм (.epf / .erf).
   • Доработка основной конфигурации со снятием объектов с поддержки (применяется при невозможности реализации через расширения).
2. Использование Библиотеки стандартных подсистем (БСП):

   Если в конфигурации используется БСП, в ТЗ следует заложить использование типовых механизмов: дополнительных реквизитов и сведений, прикрепляемых файлов, подсистемы печати, версионирования и вариантов отчетов.

3. Детализация метаданных:

   Для каждого нового или дорабатываемого объекта укажем требуемые типы данных, длину, точность и состав табличных частей. Для документов фиксируем режим проведения (оперативный или неоперативный) и правила формирования движений по регистрам накопления, сведений или бухгалтерии.

4. Права доступа и RLS:

   В документе необходимо явно прописать, к каким ролям и профилям групп доступа будут относиться новые функции, а также требуется ли настройка ограничений на уровне записей (RLS) по организациям, складам или подразделениям.

5. Интерфейс и обработка ошибок:

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

Определение готовности задачи (Критерии приемки)

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

В сценарии приемки фиксируются:

1. Исходные данные в системе перед началом выполнения операции.
2. Последовательность действий пользователя в интерфейсе.
3. Ожидаемый результат (созданные документы, сформированные движения по регистрам, печатные формы или итоговые показатели в отчете).

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