Техническое задание на доработку 1С: структура и ошибки постановки

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

Зачем вообще нужно ТЗ, если можно объяснить на словах

Устное объяснение работает для маленькой правки, когда заказчик и исполнитель сидят рядом. Для чего-то большего у письменного ТЗ есть три практические функции.

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

Во-вторых, оно служит основой оценки. Без текста невозможно сравнить предложения разных исполнителей или понять, что вошло в цену. Как формируется стоимость, я описал в статье про стоимость доработки 1С.

В-третьих, это критерий приёмки. Когда работа сдана, нужно сверить результат с чем-то, кроме памяти и впечатлений.

Размер документа не показатель качества. Две страницы с точными сценариями полезнее двадцати страниц общих слов.

Рекомендуемая структура документа

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

1. Контекст и цель. Одним-двумя абзацами: в чём проблема, кого она касается, какой результат нужен бизнесу. Здесь не место для решений, только для причин.
2. Текущее состояние. Как процесс работает сейчас, в какой конфигурации и версии платформы, какие объекты задействованы, кто пользуется.
3. Требования. Основной раздел, о нём ниже.
4. Ограничения. Что менять нельзя, с чем нужно сохранить совместимость, какие есть технические и организационные рамки.
5. Роли и права. Кто что видит и делает после доработки.
6. Интеграции и обмен данными. Если затрагиваются внешние системы: направление, формат, периодичность, поведение при сбоях.
7. Тестирование и приёмка. Сценарии и критерии.
8. Перенос и внедрение. Как попадёт в рабочую базу, нужно ли обучение, что с историческими данными.
9. Вне рамок. Явный список того, что в эту работу не входит.

Раздел «Вне рамок» кажется лишним, но в спорных ситуациях именно он экономит нервы: то, что не написано как входящее, не должно подразумеваться.

Как формулировать требования, чтобы их можно было проверить

Главный приём: каждое требование должно быть таким, чтобы по нему можно было составить проверку с ответом «да» или «нет». Сравним два варианта.

Плохо: «Нужно сделать удобную проверку остатков при оформлении заказа».

Лучше: «При добавлении строки в заказ покупателя система сравнивает количество с доступным остатком на выбранном складе. Если остатка недостаточно, строка подсвечивается, а при попытке провести документ выводится сообщение с названием номенклатуры и доступным количеством. Пользователь с ролью «Старший менеджер» может провести документ вопреки предупреждению».

Во втором варианте есть триггер, действие, сообщение, исключение и роль. Исполнитель не гадает, а тестировщик знает, что проверять.

Полезный шаблон для сложных случаев записывать требования в виде сценариев: «Если ..., то ...». Например:

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

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

Что обязательно описать про данные

Многие ТЗ описывают интерфейс и забывают про данные. А вопросы по ним проясняются позже и дороже.

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

Если задача касается обмена с внешними системами, отдельно опишите идентификаторы объектов, формат дат и сумм, поведение при повторной передаче и порядок разрешения конфликтов. Типовые ловушки в таких проектах описаны в статье про обмен 1С с сайтом.

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

Решение вместо проблемы. Заказчик пишет: «Добавьте кнопку, которая делает X». Исполнитель добавляет кнопку, но настоящая проблема была в другом, и её можно было решить настройкой или другим подходом. Опишите, зачем нужна кнопка, а способ обсудите.

Описан только идеальный путь. Нет ничего про отказы, ошибки ввода, пересечение с другими документами. Программист додумывает сам, и результат может не совпасть с ожиданием.

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

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

Размытые слова. «Быстро», «удобно», «гибко», «как обычно». Если вам важна скорость, укажите допустимое время на типичном объёме. Если удобство, опишите количество действий или конкретный сценарий работы.

Отсутствие критериев приёмки. Работа «готова», но заказчик считает иначе, и разговор превращается в спор о словах.

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

Роль примеров и макетов

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

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

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

Приёмка и изменение требований

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

Предусмотрите процедуру изменений. Любое новое требование записывается, оценивается по сроку и стоимости, утверждается обеими сторонами. Это не бюрократия, а защита от ситуации, когда проект незаметно вырастает вдвое.

Юридическую сторону договора, ответственность и гарантии обсуждайте с юристом. ТЗ в этом смысле лишь приложение, которое делает обязательства конкретными. Как выстраивать работу с исполнителем в целом, подробнее в статье про договор, NDA и доступы.

Небольшой пример: как выглядит рабочий фрагмент ТЗ

Допустим, нужна доработка: автоматически подставлять в заказ скидку для постоянных покупателей. Слабая формулировка звучит как «скидки для постоянных клиентов». Рабочая версия раскладывает задачу на части.

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

Такой фрагмент занимает полстраницы, но в нём есть всё необходимое для оценки, разработки и проверки. Размер скидки здесь условный, а в вашем документе он будет взят из ваших правил.

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

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

Лучше всего вместе. Заказчик знает процесс и цели, исполнитель знает, как это выражается в платформе и какие вопросы нужно задать. Иногда аналитик пишет документ после интервью, а заказчик утверждает.

Можно ли обойтись без ТЗ на небольшую доработку?

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

В каком формате лучше хранить ТЗ?

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

Как описывать требования к производительности?

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

Если у вас есть идея доработки и нужна помощь с постановкой, посмотрите страницу о доработке и интеграциях 1С или напишите в Telegram.