Что такое ЧТЗ простыми словами
#2 (универсальная структура)
#2 (универсальная структура)
Частное ТЗ в 1С: зачем оно нужно
Частное техническое задание (ЧТЗ) — один из самых полезных инструментов 1С‑аналитика: оно превращает размытые «хотелки» и куски общего ТЗ в понятную, ограниченную по объёму задачу для разработки и тестирования. ЧТЗ удобно использовать как рабочую единицу: аналитик описывает, разработчик реализует, тестировщик принимает, бизнес понимает, что именно получит.
В 1С‑проектах ЧТЗ — это мини‑ТЗ на конкретную доработку или функциональный блок:
· опирается на общее ТЗ / концепцию системы;
· описывает часть конфигурации: процесс, документ, отчёт, интеграцию, обработку;
· служит «контейнером» требований, по которому удобно планировать, оценивать и принимать задачу.
Зачем оно нужно:
· разделить большой проект на независимые куски, чтобы разные разработчики не залезали друг другу в область;
· избежать ситуации «мы по‑разному поняли задачу» и бесконечных переделок;
· иметь понятные критерии, по которым задача считается выполненной и может уйти в прод.
Хорошее ЧТЗ всегда отвечает минимум на четыре вопроса:
1. Что именно нужно изменить или создать в 1С.
2. Зачем бизнесу это поведение и какую проблему оно закрывает.
3. Как это должно работать в терминах 1С: объекты, реквизиты, алгоритм.
4. Как мы поймём, что всё сделано правильно: критерии приёмки и пользовательские сценарии (UAT).
Универсальная структура ЧТЗ для 1С
Структура ЧТЗ может немного отличаться в разных компаниях, но базовый каркас почти везде одинаковый.
Рекомендуемые разделы:
1. Шапка (метаданные задачи).
2. Описание изменений и цели.
3. Исходные данные и контур влияния.
4. Требования к функционалу.
5. Требования к интерфейсу / печатным формам / отчётам.
6. Нефункциональные требования (скорость, ограничения, безопасность).
7. Критерии приёмки.
8. UAT‑сценарии (пользовательская приёмка).
9. Изменения в данных и миграции (если есть).
10. Ограничения, риски, особые условия.
Дальше — разбор, что аналитик обязан прописать в каждом из блоков.
Обязательные разделы ЧТЗ
Шапка: как идентифицировать ЧТЗ
Минимум, который должен быть в начале документа:
· ID ЧТЗ, например: «ЧТЗ‑СКЛАД‑005».
· Название: «ЧТЗ: Списание товара по штрих‑коду в WMS».
· Проект / система: «1С:ERP, контур складского учёта».
· Автор (аналитик), дата.
· Статус: черновик / на согласовании / утверждено.
Этого достаточно, чтобы на документ можно было ссылаться, искать его в базе знаний и отслеживать версии.
Описание изменений и цели
Это короткий блок, который должен быть понятен и бизнесу, и команде проекта:
· что хотим получить в результате;
· какую проблему или боль это решает;
· на каком участке процесса изменения происходят.
Пример формулировки:
· Цель: ускорить списание товара со склада и снизить ошибки учёта.
· Изменение: реализовать сценарий списания по штрих‑коду с мобильного устройства с актуализацией остатков в разрезе ячеек.
Такой абзац помогает человеку, далёкому от 1С, понять, зачем вообще нужна доработка, и не утонуть в деталях.
Исходные данные и контур влияния
Задача аналитика — сразу обозначить, куда «лезем» и что вокруг может пострадать:
· какие объекты конфигурации затрагиваются: документы, справочники, регистры, обработки;
· какие подсистемы / разделы: «Склад», «Закупки», «Продажи», «CRM», «Зарплата»;
· есть ли связь с другими ЧТЗ или пунктами общего ТЗ.
Это помогает:
· разработчику — оценить объём и риски;
· тестировщику — спланировать, где и что проверять на побочные эффекты.
Требования к функционалу: ядро ЧТЗ
Это центральный раздел. Для каждой функции удобно использовать одну и ту же мини‑структуру (часто в виде таблицы):
· ID требования: например, «FR‑СКЛАД‑005».
· Объект(ы): документ, отчёт, обработка, регистр.
· Роли: кто пользуется функционалом (кладовщик, менеджер, бухгалтер, директор).
· Описание логики — шаг за шагом, «как должно работать».
· Исключения и ошибки: что происходит в нестандартных ситуациях.
Пример:
· ID: FR‑СКЛАД‑005
· Объект: Документ «Списание товаров» + мобильная обработка
· Роли: Кладовщик, Зав. складом
· Логика:
o кладовщик сканирует штрих‑код ячейки;
o система показывает список товаров в ячейке;
o кладовщик сканирует товар для списания;
o остаток уменьшается на 1;
o при нулевом остатке система показывает сообщение «Ячейка пустая».
· Исключения:
o если товар не найден в этой ячейке — сообщение «Товар не числится в ячейке Х».
Такой формат одновременно читается как псевдокод для разработчика и как основа тест‑кейса для тестировщика.
Требования к интерфейсу, печатным формам и отчётам
Если доработка затрагивает интерфейсы или отчётность, важно зафиксировать:
· для форм — какие поля, где расположены, какие обязательные, какие доступны только отдельным ролям;
· для печатных форм — макет или пример (можно приложить скрин, PDF, рисунок);
· для отчётов — какие показатели, группировки, отборы и сортировки должны быть.
Оптимально: приложить эскиз/скриншот, а текстом описать только то, что критично и неочевидно.
Нефункциональные требования (NFR)
Даже если доработка кажется маленькой, лучше один раз явно сказать, что такое «нормальная работа» в цифрах.
Что стоит указать:
· ограничения по объёму данных (например, отчёт до 100 000 строк);
· требования к скорости: «формирование отчёта до 5 секунд при типовой нагрузке»;
· важные требования по безопасности: видимость полей по ролям, запрет на изменение отдельных реквизитов и т.п.
Частая ошибка — описать только функционал («что делает») и забыть про качество («как быстро и безопасно это должно работать») — потом команда удивляется, почему система «вдруг» тормозит.
Критерии приёмки
Для каждой функциональной единицы в ЧТЗ должны быть понятные, проверяемые критерии приёмки.
Мини‑шаблон:
· Критерий 1: условие → ожидаемый результат.
· Критерий 2: условие → ожидаемый результат.
· Пограничные случаи: значения на границе, ошибки, исключения.
Пример:
· Критерий ПР‑1: если сумма договора ≤ лимита роли, статус меняется на «Согласовано автоматически» без участия директора.
· Критерий ПР‑2: если сумма > лимита, создаётся задача директору, статус — «На согласовании».
Критерии приёмки:
· дают исполнителю чек‑лист «что обязательно должно работать, чтобы задачу приняли»;
· позволяют аналитику спокойно сказать «выполнено / не выполнено» без вкусовщины;
· ложатся в основу актов приёмки и UAT‑сценариев.
UAT‑сценарии (пользовательская приёмка)
UAT (User Acceptance Testing) — это сценарии, по которым бизнес‑пользователи проверяют, что система реально работает так, как им нужно.
В ЧТЗ удобно оформить UAT в виде таблицы:
· UAT‑ID: «UAT‑СКЛАД‑01».
· Роль: кто тестирует (Кладовщик, Менеджер по продажам).
· Шаги: последовательность действий пользователя в системе.
· Ожидаемый результат: что должно произойти, какие данные измениться, какие отчёты обновиться.
Пример:
· UAT‑ID: UAT‑СКЛАД‑01
· Роль: Кладовщик
· Шаги:
a. Авторизоваться под ролью «Кладовщик».
b. Открыть мобильную обработку «Списание по ШК».
c. Сканировать ячейку и товар.
d. Провести документ.
· Ожидаемый результат:
a. остаток товара в ячейке уменьшился;
b. ошибок не возникает;
c. отчёт по остаткам отражает новые данные.
Зачем это нужно:
· пользователю понятно, что именно он должен проверить, а не просто «посмотреть, как работает»;
· аналитик фиксирует факт реальной приёмки, а не формальное «да, всё нормально».
Изменения в данных и миграции
Если доработка затрагивает:
· структуру регистров;
· массовый перенос, пересчёт, инициализацию данных;
· добавление новых реквизитов, которые нужно заполнить задним числом, —
в ЧТЗ важно описать:
· какие данные и где будут изменены;
· нужны ли разовые обработки / загрузки для миграции;
· как проверить корректность: отчёты, выборки, сверки с существующими данными.
Это резко снижает риск «сломать боевую базу» и потом долго искать, где именно «поехали» цифры.
Ограничения и риски
Последний, но важный раздел — про рамки задачи:
· что явно не входит в реализацию по этому ЧТЗ (чёткий перечень «не делаем»);
· известные риски: возможный рост нагрузки, конфликты с другими блоками, зависимость от настроек;
· предпосылки: например, «работает только при включённом адресном хранении» или «расчёт корректен при заполненных лимитах».
Этот блок защищает и аналитика, и команду от ожиданий «а мы думали, что это тоже будет».
Мини‑чек‑лист для 1С‑аналитика
Чтобы ЧТЗ реально работало как инструмент, а не как «бумага ради бумаги», полезно держать под рукой короткий чек‑лист:
· Есть ID и понятное название.
· Есть краткая цель и описание изменений.
· Понятно, какие объекты 1С и роли затрагиваются.
· Логика описана пошагово для каждого требования.
· Прописаны исключения и ошибки.
· Есть NFR, если есть риск по скорости, объёмам или безопасности.
· Есть критерии приёмки.
· Есть 1–3 UAT‑сценария для ключевых пользователей.
И главный принцип: писать простым языком, через конкретику, а не «удобно», «быстро» и «как обычно». ЧТЗ должно позволить:
· разработчику — писать код без угадываний;
· тестировщику — тестировать без доп. расспросов;
· пользователю — понять, что он получит и как это использовать.
Тогда частное ТЗ становится для аналитика не формальностью, а рабочим инструментом управления задачами и репутацией: чем лучше ЧТЗ, тем меньше сюрпризов на внедрении и выше доверие к вам как к ведущему аналитику.
Частное техническое задание (ЧТЗ) — один из самых полезных инструментов 1С‑аналитика: оно превращает размытые «хотелки» и куски общего ТЗ в понятную, ограниченную по объёму задачу для разработки и тестирования. ЧТЗ удобно использовать как рабочую единицу: аналитик описывает, разработчик реализует, тестировщик принимает, бизнес понимает, что именно получит.
В 1С‑проектах ЧТЗ — это мини‑ТЗ на конкретную доработку или функциональный блок:
· опирается на общее ТЗ / концепцию системы;
· описывает часть конфигурации: процесс, документ, отчёт, интеграцию, обработку;
· служит «контейнером» требований, по которому удобно планировать, оценивать и принимать задачу.
Зачем оно нужно:
· разделить большой проект на независимые куски, чтобы разные разработчики не залезали друг другу в область;
· избежать ситуации «мы по‑разному поняли задачу» и бесконечных переделок;
· иметь понятные критерии, по которым задача считается выполненной и может уйти в прод.
Хорошее ЧТЗ всегда отвечает минимум на четыре вопроса:
1. Что именно нужно изменить или создать в 1С.
2. Зачем бизнесу это поведение и какую проблему оно закрывает.
3. Как это должно работать в терминах 1С: объекты, реквизиты, алгоритм.
4. Как мы поймём, что всё сделано правильно: критерии приёмки и пользовательские сценарии (UAT).
Универсальная структура ЧТЗ для 1С
Структура ЧТЗ может немного отличаться в разных компаниях, но базовый каркас почти везде одинаковый.
Рекомендуемые разделы:
1. Шапка (метаданные задачи).
2. Описание изменений и цели.
3. Исходные данные и контур влияния.
4. Требования к функционалу.
5. Требования к интерфейсу / печатным формам / отчётам.
6. Нефункциональные требования (скорость, ограничения, безопасность).
7. Критерии приёмки.
8. UAT‑сценарии (пользовательская приёмка).
9. Изменения в данных и миграции (если есть).
10. Ограничения, риски, особые условия.
Дальше — разбор, что аналитик обязан прописать в каждом из блоков.
Обязательные разделы ЧТЗ
Шапка: как идентифицировать ЧТЗ
Минимум, который должен быть в начале документа:
· ID ЧТЗ, например: «ЧТЗ‑СКЛАД‑005».
· Название: «ЧТЗ: Списание товара по штрих‑коду в WMS».
· Проект / система: «1С:ERP, контур складского учёта».
· Автор (аналитик), дата.
· Статус: черновик / на согласовании / утверждено.
Этого достаточно, чтобы на документ можно было ссылаться, искать его в базе знаний и отслеживать версии.
Описание изменений и цели
Это короткий блок, который должен быть понятен и бизнесу, и команде проекта:
· что хотим получить в результате;
· какую проблему или боль это решает;
· на каком участке процесса изменения происходят.
Пример формулировки:
· Цель: ускорить списание товара со склада и снизить ошибки учёта.
· Изменение: реализовать сценарий списания по штрих‑коду с мобильного устройства с актуализацией остатков в разрезе ячеек.
Такой абзац помогает человеку, далёкому от 1С, понять, зачем вообще нужна доработка, и не утонуть в деталях.
Исходные данные и контур влияния
Задача аналитика — сразу обозначить, куда «лезем» и что вокруг может пострадать:
· какие объекты конфигурации затрагиваются: документы, справочники, регистры, обработки;
· какие подсистемы / разделы: «Склад», «Закупки», «Продажи», «CRM», «Зарплата»;
· есть ли связь с другими ЧТЗ или пунктами общего ТЗ.
Это помогает:
· разработчику — оценить объём и риски;
· тестировщику — спланировать, где и что проверять на побочные эффекты.
Требования к функционалу: ядро ЧТЗ
Это центральный раздел. Для каждой функции удобно использовать одну и ту же мини‑структуру (часто в виде таблицы):
· ID требования: например, «FR‑СКЛАД‑005».
· Объект(ы): документ, отчёт, обработка, регистр.
· Роли: кто пользуется функционалом (кладовщик, менеджер, бухгалтер, директор).
· Описание логики — шаг за шагом, «как должно работать».
· Исключения и ошибки: что происходит в нестандартных ситуациях.
Пример:
· ID: FR‑СКЛАД‑005
· Объект: Документ «Списание товаров» + мобильная обработка
· Роли: Кладовщик, Зав. складом
· Логика:
o кладовщик сканирует штрих‑код ячейки;
o система показывает список товаров в ячейке;
o кладовщик сканирует товар для списания;
o остаток уменьшается на 1;
o при нулевом остатке система показывает сообщение «Ячейка пустая».
· Исключения:
o если товар не найден в этой ячейке — сообщение «Товар не числится в ячейке Х».
Такой формат одновременно читается как псевдокод для разработчика и как основа тест‑кейса для тестировщика.
Требования к интерфейсу, печатным формам и отчётам
Если доработка затрагивает интерфейсы или отчётность, важно зафиксировать:
· для форм — какие поля, где расположены, какие обязательные, какие доступны только отдельным ролям;
· для печатных форм — макет или пример (можно приложить скрин, PDF, рисунок);
· для отчётов — какие показатели, группировки, отборы и сортировки должны быть.
Оптимально: приложить эскиз/скриншот, а текстом описать только то, что критично и неочевидно.
Нефункциональные требования (NFR)
Даже если доработка кажется маленькой, лучше один раз явно сказать, что такое «нормальная работа» в цифрах.
Что стоит указать:
· ограничения по объёму данных (например, отчёт до 100 000 строк);
· требования к скорости: «формирование отчёта до 5 секунд при типовой нагрузке»;
· важные требования по безопасности: видимость полей по ролям, запрет на изменение отдельных реквизитов и т.п.
Частая ошибка — описать только функционал («что делает») и забыть про качество («как быстро и безопасно это должно работать») — потом команда удивляется, почему система «вдруг» тормозит.
Критерии приёмки
Для каждой функциональной единицы в ЧТЗ должны быть понятные, проверяемые критерии приёмки.
Мини‑шаблон:
· Критерий 1: условие → ожидаемый результат.
· Критерий 2: условие → ожидаемый результат.
· Пограничные случаи: значения на границе, ошибки, исключения.
Пример:
· Критерий ПР‑1: если сумма договора ≤ лимита роли, статус меняется на «Согласовано автоматически» без участия директора.
· Критерий ПР‑2: если сумма > лимита, создаётся задача директору, статус — «На согласовании».
Критерии приёмки:
· дают исполнителю чек‑лист «что обязательно должно работать, чтобы задачу приняли»;
· позволяют аналитику спокойно сказать «выполнено / не выполнено» без вкусовщины;
· ложатся в основу актов приёмки и UAT‑сценариев.
UAT‑сценарии (пользовательская приёмка)
UAT (User Acceptance Testing) — это сценарии, по которым бизнес‑пользователи проверяют, что система реально работает так, как им нужно.
В ЧТЗ удобно оформить UAT в виде таблицы:
· UAT‑ID: «UAT‑СКЛАД‑01».
· Роль: кто тестирует (Кладовщик, Менеджер по продажам).
· Шаги: последовательность действий пользователя в системе.
· Ожидаемый результат: что должно произойти, какие данные измениться, какие отчёты обновиться.
Пример:
· UAT‑ID: UAT‑СКЛАД‑01
· Роль: Кладовщик
· Шаги:
a. Авторизоваться под ролью «Кладовщик».
b. Открыть мобильную обработку «Списание по ШК».
c. Сканировать ячейку и товар.
d. Провести документ.
· Ожидаемый результат:
a. остаток товара в ячейке уменьшился;
b. ошибок не возникает;
c. отчёт по остаткам отражает новые данные.
Зачем это нужно:
· пользователю понятно, что именно он должен проверить, а не просто «посмотреть, как работает»;
· аналитик фиксирует факт реальной приёмки, а не формальное «да, всё нормально».
Изменения в данных и миграции
Если доработка затрагивает:
· структуру регистров;
· массовый перенос, пересчёт, инициализацию данных;
· добавление новых реквизитов, которые нужно заполнить задним числом, —
в ЧТЗ важно описать:
· какие данные и где будут изменены;
· нужны ли разовые обработки / загрузки для миграции;
· как проверить корректность: отчёты, выборки, сверки с существующими данными.
Это резко снижает риск «сломать боевую базу» и потом долго искать, где именно «поехали» цифры.
Ограничения и риски
Последний, но важный раздел — про рамки задачи:
· что явно не входит в реализацию по этому ЧТЗ (чёткий перечень «не делаем»);
· известные риски: возможный рост нагрузки, конфликты с другими блоками, зависимость от настроек;
· предпосылки: например, «работает только при включённом адресном хранении» или «расчёт корректен при заполненных лимитах».
Этот блок защищает и аналитика, и команду от ожиданий «а мы думали, что это тоже будет».
Мини‑чек‑лист для 1С‑аналитика
Чтобы ЧТЗ реально работало как инструмент, а не как «бумага ради бумаги», полезно держать под рукой короткий чек‑лист:
· Есть ID и понятное название.
· Есть краткая цель и описание изменений.
· Понятно, какие объекты 1С и роли затрагиваются.
· Логика описана пошагово для каждого требования.
· Прописаны исключения и ошибки.
· Есть NFR, если есть риск по скорости, объёмам или безопасности.
· Есть критерии приёмки.
· Есть 1–3 UAT‑сценария для ключевых пользователей.
И главный принцип: писать простым языком, через конкретику, а не «удобно», «быстро» и «как обычно». ЧТЗ должно позволить:
· разработчику — писать код без угадываний;
· тестировщику — тестировать без доп. расспросов;
· пользователю — понять, что он получит и как это использовать.
Тогда частное ТЗ становится для аналитика не формальностью, а рабочим инструментом управления задачами и репутацией: чем лучше ЧТЗ, тем меньше сюрпризов на внедрении и выше доверие к вам как к ведущему аналитику.
Полезные статьи для аналитиков
