Как PM-у правильно классифицировать требования

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

Если ты читал мою предыдущую статью про сбор требований (ссылочка ниже), то знаешь - без проведения сбора требований и их фиксации проект быстро превратится в набор ожиданий и предположений. Сейчас же хочу разложить типы требований по полочкам и дать практику: какие они бывают, как их формализовать и как с ними работать на реальных проектах.

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

Примеры:

- Увеличить конверсию в оплату на лендинге с 2% до 3% в течение 6 месяцев;

- Снизить операционные затраты службы поддержки на 20% в год за счёт автоматизации заявок;

- Вывести MVP на рынок за 3 месяца с целью получить N подписок в первый квартал.

Как оформить:

Документ: Business Case / Project Charter / Паспорт проекта. Включи: цель, метрики, целевую аудиторию, ожидаемую экономику (предполагаемые Profits/Losses), ограничения (время/бюджет).

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

Примеры:
- API внешней платёжной системы должно поддерживать webhooks и 3DS;
- Система аутентификации — поддержка OAuth2/Google;
- TLS 1.2+ для всех внешних вызовов, хранение данных в шифрованном виде.

Как оформить:

Документ: System Requirements / Interface Requirements. Указывай формально: протоколы, форматы запросов/ответов, SLA на интеграции, допустимые задержки, требования к логированию и мониторингу.

Описывают поведение системы под набором условий - часто трансформируются в user stories, use cases или функциональную спецификацию.

Примеры:

- Как пользователь с ролью "маркетолог" я могу создать кампанию с набором параметров (целевая аудитория, бюджет, расписание);

- Система должна генерировать отчёт по расходам каждые 24 часа;

- При превышении бюджета маркетинговая кампания переводится в статус "Пауза".

Как оформить:

User stories + acceptance criteria. Для каждой фичи пиши кратко: роль, действие, результат + критерии приёмки.

Как система должна работать: UI/UX, производительность, безопасность, доступность, масштабируемость, поддерживаемость.

Примеры:

- Видеоплеер на сайте: поддерживает HLS, автопереключение качества, буферизация < 1s;

- Время отклика API под нагрузкой 1000 RPS — p95 ≤ 300 ms;

- Доступность сервиса 99.9% (SLA), RTO/RPO для БД — 1 час / 15 минут.

Как оформить:

Матрица нефункциональных требований: категория → метрика → порог → способ тестирования → владелец. Каждое требование должно быть измеримо.

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

Примеры:

- Студент: зарегистрироваться через Google, пройти короткий курс и получить сертификат в течение 2 часов;

- Продавец: посмотреть сводную статистику продаж за неделю и экспортировать CSV;

- Курьер: получить push-уведомление о новой доставке с координатами и временным окном.

Как оформить:

Use cases, user journey maps, прототипы. Для важнейших сценариев — пошаговые сценарии и критерии успешности (время на выполнение, количество кликов).

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

Примеры:

— Описание модулей и их интерфейсов;

— Таблицы с API-контрактами (параметры, форматы, коды ошибок);

— Требования к логированию, метрикам и трассировке.

Как оформить:

Введение, общие описания, конкретные требования, атрибуты качества, ограничения, зависимые системы.

- Спонсор/Заказчик/Ключевые стейкхолдеры определяют бизнес-требования;

- Продакт менеджер/Продакт Оунер/Бизнес-аналитик/Менеджер проекта формируют функциональные и пользовательские требования;

- Архитектор/Техлид/Тимлид/Системный-аналитик — прорабатывают нефункциональные, системные требования и SRS;

- Дизайнеры интерфейсов прорабатывают пользовательские сценарии;

- Инженеры по тестированию пишут тест-кейсы по требованиям.

- К любым требованиям относиться, как к данности, тем более к функциональным и пользовательским.
Решение: Всегда начинай с вопроса: "Зачем это нужно и на что влияет?". Помогает метод "5 почему", т.к. важно понять основную проблему.

- Не фиксировать требования.
Решение: Фиксировать все важные требования и контролировать их изменение в матрице отслеживания требований.

- Писать требования в свободном тексте без критериев приёмки. Решение: всегда добавляй измеримые критерии приёмки задач.

- Смешивать бизнес и технические требования.
Решение: держи уровни раздельно и перекладывай бизнес на функциональные/UX сценарии.

Требования — это не статичный документ, а процесс. Твоя задача как PM — перевести бизнес-язык в технический, сделать требования измеримыми и прозрачными, и организовать входящие изменения так, чтобы они не разрушали экономику и сроки проекта. Чем лучше ты разделяешь уровни требований, тем легче управлять рисками и добиваться качества на этапе реализации.

P.S. Веду ТГ канал про проектное управление, там делюсь опытом управления командами и проектами в IT. https://t.me/ProjectMindsetVS