Частное техническое задание (ЧТЗ) — это подробный документ под одну конкретную задачу или подсистему внутри большого проекта.
Если упростить:
· ТЗ — «карта» для всей системы (например, внедрение 1С:ERP во всей компании).
· ЧТЗ — «увеличенное фото» одного участка:
o подсистема закупок;
o блок управления запасами;
o интеграция с маркетплейсом;
o доработка отчёта;
o новый модуль уведомлений.
ЧТЗ отвечает на два базовых вопроса:
· что именно нужно сделать (в рамках этой части проекта);
· как именно это должно работать, чтобы бизнес остался доволен.
Для аналитика это:
· опора в разговорах с заказчиком («мы договаривались вот об этом»);
· база для ТЗ разработчикам и тестировщикам;
· документ, по которому потом принимают работу.
Чем ЧТЗ отличается от обычного ТЗ
По сути, это «уровни зума».
· ТЗ
o описывает систему или проект целиком;
o фиксирует цели, рамки, общую архитектуру, крупные модули;
o читают топ‑менеджment, заказчик, руководители направлений.
· ЧТЗ
o детализирует одну часть из ТЗ: конкретный модуль, процесс, интеграцию;
o уходит в детали: поля, алгоритмы, роли, ограничения;
o читают аналитики, разработчики, тестировщики и «владелец процесса» с бизнес‑стороны.
Практический критерий:
если по ТЗ ещё нельзя писать конкретный код и делать тест‑кейсы — нужен ЧТЗ.
Зачем бизнесу и команде нужен ЧТЗ
Для бизнеса:
· понятная формулировка: что получите на выходе именно по этому блоку;
· меньше сюрпризов: «а мы думали, что будет по‑другому»;
· основа для оценки сроков и бюджета.
Для аналитика:
· структурированный контейнер для требований: бизнес‑, функциональных, нефункциональных;
· удобный формат для ревью с заказчиком и командой;
· защита при спорах: «вот документ, вот версия, вот журнал изменений».
Для разработки и тестирования:
· единый источник правды: какие поля, какие проверки, какие сценарии;
· понятные критерии приёмки (что считается «сделано»).
Типовая структура ЧТЗ (каркас)
Структура может отличаться по компаниям, но базовая логика примерно такая.
1. Введение
· Название ЧТЗ: «Подсистема закупок», «Интеграция с маркетплейсом X», «Отчёт по оборачиваемости» и т.п.
· Кратко: что автоматизируем и для кого.
· Ссылки: на общее ТЗ, регламенты, схемы процессов.
2. Цели и задачи
· Зачем вообще этот документ и доработка;
· какую бизнес‑проблему решаем:
o «уменьшить просрочки поставок»,
o «сократить время обработки заказа»,
o «увидеть маржинальность по клиентам».
· как поймём, что цель достигнута (пара‑тройка метрик).
3. Описание процесса: как сейчас и как должно быть
· As‑is: коротко про текущий процесс (можно схемой);
· To‑be: как должен работать процесс после внедрения/доработки.
Для аналитика это важный раздел: тут выравнивается понимание между бизнесом и командой.
4. Требования к системе
Здесь как раз удобно разделять:
· Пользовательские требования
«Пользователь должен уметь…» — на языке ролей и процессов.
· Функциональные требования
«Система должна…» — конкретные действия, алгоритмы, поля, отчёты.
· Нефункциональные требования
«Система должна обеспечивать…» — скорость, надёжность, права доступа, количество пользователей и т.п.
Этот раздел — основа будущих задач разработчикам и тестов QA.
5. Интеграции и данные
· с какими внешними системами общаемся (банк, маркетплейс, CRM, складское оборудование);
· какие данные передаём и принимаем, как часто, в каком формате.
6. Критерии приёмки
· какие сценарии должны успешно выполняться;
· какие отчёты/формы/документы должны быть;
· какие показатели должны соблюдаться (например, время формирования отчёта ≤ N секунд).
Этим разделом аналитик сильно облегчает жизнь себе и тестировщикам: меньше разночтений «работает / не работает».
7. Журнал версий и изменений
· отдельная таблица с версиями ЧТЗ;
· кто менял, когда, что именно и почему;
· как это повлияло на сроки и бюджет.
Это уже подробно разобрано в предыдущем материале, но в развернутой статье можно упомянуть как обязательный блок.
Как работать с ЧТЗ аналитикам: по шагам
Шаг 1. Собрать входные данные
· интервью с заказчиком и ключевыми пользователями;
· изучение текущих регламентов, отчётов, форм;
· разбор «болей»: где теряются деньги/время, где сотрудники страдают.
На этом этапе вы формируете черновик целей и пользовательских требований.
Шаг 2. Согласовать цели и границы
Перед тем как уходить в детали:
· проговорить и зафиксировать, что явно входит в рамки, а что точно не делаем в этом ЧТЗ;
· ещё раз проверить, как ЧТЗ связан с верхнеуровневой бизнес‑целью.
Это экономит массу сил — меньше «давайте ещё вот это, заодно».
Шаг 3. Расписать требования
· из пользовательских требований вытянуть функциональные: сценарии, поля, проверки, отчёты;
· отдельно сформулировать нефункциональные: скорость, количество пользователей, ограничения по ролям.
Важно каждый пункт писать так, чтобы его можно было проверить: через сценарий или цифру.
Шаг 4. Прогнать документ через ревью
· с бизнес‑заказчиком и ключевыми пользователями — на предмет смысла и терминов;
· с разработчиками — на реализуемость, вопросы по логике;
· с тестировщиками — на проверяемость и полноту критериев приёмки.
После обсуждений — зафиксировать версию ЧТЗ и запись в журнале версий.
Шаг 5. Сопровождать ЧТЗ по ходу проекта
Реальность меняется:
· появляются новые требования;
· бизнес что‑то переосмысляет;
· всплывают ограничения платформы или внешних систем.
Задача аналитика:
· не позволять изменениям «улетать в мессенджеры»;
· отражать их в ЧТЗ и журнале версий;
· честно фиксировать влияние на сроки и бюджет.
Типичные ошибки работы с ЧТЗ
1. ЧТЗ «в голове» или в переписке
Риски очевидны:
· никто не видит полной картины;
· всё держится на одном человеке;
· при смене аналитика или конфликтах защищаться нечем.
2. ЧТЗ = просто список задач разработчику
В таком виде:
· теряется связь с бизнес‑целями;
· пользователям сложно понять, что получится на выходе;
· критерии приёмки размыты.
ЧТЗ должен держать и бизнес‑смысл, и системные детали.
3. Нет актуальности: документ «умер» после первой версии
Проект живёт, а ЧТЗ — нет.
Решение:
· вести журнал версий;
· при существенных изменениях обновлять ЧТЗ и ссылаться на версии в задачах/трекерах.
Вывод для аналитика
ЧТЗ — не «ещё один формальный документ», а:
· рабочий инструмент, который связывает ожидания бизнеса, реальные задачи разработчиков и критерии приёмки;
· защита от хаоса: видно, о чём договорились, что поменяли и почему;
· ваша профессиональная опора: по нему судят о качестве аналитики в проекте.
Если упростить:
· ТЗ — «карта» для всей системы (например, внедрение 1С:ERP во всей компании).
· ЧТЗ — «увеличенное фото» одного участка:
o подсистема закупок;
o блок управления запасами;
o интеграция с маркетплейсом;
o доработка отчёта;
o новый модуль уведомлений.
ЧТЗ отвечает на два базовых вопроса:
· что именно нужно сделать (в рамках этой части проекта);
· как именно это должно работать, чтобы бизнес остался доволен.
Для аналитика это:
· опора в разговорах с заказчиком («мы договаривались вот об этом»);
· база для ТЗ разработчикам и тестировщикам;
· документ, по которому потом принимают работу.
Чем ЧТЗ отличается от обычного ТЗ
По сути, это «уровни зума».
· ТЗ
o описывает систему или проект целиком;
o фиксирует цели, рамки, общую архитектуру, крупные модули;
o читают топ‑менеджment, заказчик, руководители направлений.
· ЧТЗ
o детализирует одну часть из ТЗ: конкретный модуль, процесс, интеграцию;
o уходит в детали: поля, алгоритмы, роли, ограничения;
o читают аналитики, разработчики, тестировщики и «владелец процесса» с бизнес‑стороны.
Практический критерий:
если по ТЗ ещё нельзя писать конкретный код и делать тест‑кейсы — нужен ЧТЗ.
Зачем бизнесу и команде нужен ЧТЗ
Для бизнеса:
· понятная формулировка: что получите на выходе именно по этому блоку;
· меньше сюрпризов: «а мы думали, что будет по‑другому»;
· основа для оценки сроков и бюджета.
Для аналитика:
· структурированный контейнер для требований: бизнес‑, функциональных, нефункциональных;
· удобный формат для ревью с заказчиком и командой;
· защита при спорах: «вот документ, вот версия, вот журнал изменений».
Для разработки и тестирования:
· единый источник правды: какие поля, какие проверки, какие сценарии;
· понятные критерии приёмки (что считается «сделано»).
Типовая структура ЧТЗ (каркас)
Структура может отличаться по компаниям, но базовая логика примерно такая.
1. Введение
· Название ЧТЗ: «Подсистема закупок», «Интеграция с маркетплейсом X», «Отчёт по оборачиваемости» и т.п.
· Кратко: что автоматизируем и для кого.
· Ссылки: на общее ТЗ, регламенты, схемы процессов.
2. Цели и задачи
· Зачем вообще этот документ и доработка;
· какую бизнес‑проблему решаем:
o «уменьшить просрочки поставок»,
o «сократить время обработки заказа»,
o «увидеть маржинальность по клиентам».
· как поймём, что цель достигнута (пара‑тройка метрик).
3. Описание процесса: как сейчас и как должно быть
· As‑is: коротко про текущий процесс (можно схемой);
· To‑be: как должен работать процесс после внедрения/доработки.
Для аналитика это важный раздел: тут выравнивается понимание между бизнесом и командой.
4. Требования к системе
Здесь как раз удобно разделять:
· Пользовательские требования
«Пользователь должен уметь…» — на языке ролей и процессов.
· Функциональные требования
«Система должна…» — конкретные действия, алгоритмы, поля, отчёты.
· Нефункциональные требования
«Система должна обеспечивать…» — скорость, надёжность, права доступа, количество пользователей и т.п.
Этот раздел — основа будущих задач разработчикам и тестов QA.
5. Интеграции и данные
· с какими внешними системами общаемся (банк, маркетплейс, CRM, складское оборудование);
· какие данные передаём и принимаем, как часто, в каком формате.
6. Критерии приёмки
· какие сценарии должны успешно выполняться;
· какие отчёты/формы/документы должны быть;
· какие показатели должны соблюдаться (например, время формирования отчёта ≤ N секунд).
Этим разделом аналитик сильно облегчает жизнь себе и тестировщикам: меньше разночтений «работает / не работает».
7. Журнал версий и изменений
· отдельная таблица с версиями ЧТЗ;
· кто менял, когда, что именно и почему;
· как это повлияло на сроки и бюджет.
Это уже подробно разобрано в предыдущем материале, но в развернутой статье можно упомянуть как обязательный блок.
Как работать с ЧТЗ аналитикам: по шагам
Шаг 1. Собрать входные данные
· интервью с заказчиком и ключевыми пользователями;
· изучение текущих регламентов, отчётов, форм;
· разбор «болей»: где теряются деньги/время, где сотрудники страдают.
На этом этапе вы формируете черновик целей и пользовательских требований.
Шаг 2. Согласовать цели и границы
Перед тем как уходить в детали:
· проговорить и зафиксировать, что явно входит в рамки, а что точно не делаем в этом ЧТЗ;
· ещё раз проверить, как ЧТЗ связан с верхнеуровневой бизнес‑целью.
Это экономит массу сил — меньше «давайте ещё вот это, заодно».
Шаг 3. Расписать требования
· из пользовательских требований вытянуть функциональные: сценарии, поля, проверки, отчёты;
· отдельно сформулировать нефункциональные: скорость, количество пользователей, ограничения по ролям.
Важно каждый пункт писать так, чтобы его можно было проверить: через сценарий или цифру.
Шаг 4. Прогнать документ через ревью
· с бизнес‑заказчиком и ключевыми пользователями — на предмет смысла и терминов;
· с разработчиками — на реализуемость, вопросы по логике;
· с тестировщиками — на проверяемость и полноту критериев приёмки.
После обсуждений — зафиксировать версию ЧТЗ и запись в журнале версий.
Шаг 5. Сопровождать ЧТЗ по ходу проекта
Реальность меняется:
· появляются новые требования;
· бизнес что‑то переосмысляет;
· всплывают ограничения платформы или внешних систем.
Задача аналитика:
· не позволять изменениям «улетать в мессенджеры»;
· отражать их в ЧТЗ и журнале версий;
· честно фиксировать влияние на сроки и бюджет.
Типичные ошибки работы с ЧТЗ
1. ЧТЗ «в голове» или в переписке
Риски очевидны:
· никто не видит полной картины;
· всё держится на одном человеке;
· при смене аналитика или конфликтах защищаться нечем.
2. ЧТЗ = просто список задач разработчику
В таком виде:
· теряется связь с бизнес‑целями;
· пользователям сложно понять, что получится на выходе;
· критерии приёмки размыты.
ЧТЗ должен держать и бизнес‑смысл, и системные детали.
3. Нет актуальности: документ «умер» после первой версии
Проект живёт, а ЧТЗ — нет.
Решение:
· вести журнал версий;
· при существенных изменениях обновлять ЧТЗ и ссылаться на версии в задачах/трекерах.
Вывод для аналитика
ЧТЗ — не «ещё один формальный документ», а:
· рабочий инструмент, который связывает ожидания бизнеса, реальные задачи разработчиков и критерии приёмки;
· защита от хаоса: видно, о чём договорились, что поменяли и почему;
· ваша профессиональная опора: по нему судят о качестве аналитики в проекте.
Полезные статьи для аналитиков
