Как сгруппировать требования в ТЗ на 1С

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

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

Зачем группировать требования и что это даёт проекту

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

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

По каким критериям группировать требования

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

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

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

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

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

Сравнение вариантов группировки

По функциональным областям

Лучше всего согласуется с заказчиком; ограничение — одна доработка может затрагивать несколько областей и потребует перекрёстных ссылок.

По объектам конфигурации

Удобно для оценки трудоёмкости разработчиком; заказчику сложно ориентироваться в терминах конфигурации.

По приоритетам и этапам

Даёт реалистичный план запуска; не заменяет тематическую структуру, применяется только как дополнительный уровень.

По типу работ

Помогает распределить задачи между исполнителями; слабо отражает бизнес-логику и плохо читается заказчиком.

Рекомендуемая структура сгруппированного ТЗ

Для большинства проектов работает трёхуровневая структура. Первый уровень — функциональная область («Управление продажами», «Складской учёт»). Второй уровень — объект или подсистема («Документ “Реализация товаров”», «Отчёт по остаткам»). Третий уровень — конкретное требование с описанием текущего поведения, желаемого результата и критерия приёмки.

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

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

1. 1
   Соберите все пожелания в единый плоский список без потери формулировок источников
2. 2
   Пометьте каждое требование функциональной областью и объектом конфигурации
3. 3
   Объедините дубли и зафиксируйте противоречия для уточнения у заказчика
4. 4
   Разложите требования по группам первого и второго уровня
5. 5
   Присвойте каждой группе и требованию приоритет: критично, важно, желательно
6. 6
   Добавьте к каждому требованию критерий приёмки — как проверить, что оно выполнено
7. 7
   Согласуйте структуру с заказчиком до начала оценки и разработки

Как формулировать требования внутри группы

Группировка не спасёт ТЗ, если сами требования сформулированы расплывчато. Рабочий шаблон для каждого пункта: текущее поведение системы → желаемое поведение → условия и ограничения → критерий приёмки. Например, вместо «сделать удобный отчёт по продажам» — «в отчёте “Продажи по менеджерам” добавить колонку “Валовая прибыль”, рассчитываемую как сумма продаж минус себестоимость по данным регистра партий; отчёт должен формироваться за период не более чем за заданное время на текущем объёме базы».

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

Приоритизация и оценка групп

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

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

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

Проверка полноты сгруппированного ТЗ

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

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

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

Как проверить готовность ТЗ

Покрытие пожеланий

Норма

Каждое исходное пожелание отражено в одной группе, дубли объединены

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

Часть пожеланий потеряна или встречается в нескольких группах с разными формулировками

Тестируемость требований

Норма

У каждого требования есть измеримый критерий приёмки

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

Формулировки «удобно», «быстро», «как в старой программе» без уточнений

Приоритеты

Норма

Каждая группа помечена: критично, важно или желательно

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

Все требования имеют одинаковый приоритет или приоритеты отсутствуют

Зависимости

Норма

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

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

Зависимые доработки стоят в плане в обратном порядке или зависимости не зафиксированы

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

Какой критерий группировки выбрать для небольшой доработки из 10–15 пунктов?

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

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

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

Кто должен выполнять группировку — заказчик или исполнитель?

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

Как быть с требованиями, которые противоречат типовой функциональности 1С?

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

Нужно ли группировать ТЗ при работе по agile-методике?

Да, но структура будет иной: группы превращаются в эпики, требования — в пользовательские истории, а приоритеты — в порядок бэклога. Логика та же: независимо оцениваемые и принимаемые блоки работ.