В управлении требованиями есть классика — четыре сущности: требования, допущения, ограничения, исключения.

Обычно в этой корзине черт ногу сломит. За требования в гибридных проектах отвечает руководитель, а в гибких — скорее всего бизнес-аналитик. В целом оба без особых полномочий. Что усложняет процесс наведения порядка.

Требования — хотелки наших стейкхолдеров, которые важно обсуждать.

Допущения — неизменные условия до конца реализации работ. Их важно постоянно мониторить. Их изменение может повлиять не только на план работ, но и на цель проекта/продукта.

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

Исключения — то, чего не должно быть. Не обсуждается. Скорее всего вообще регулируется стандартами и законом.

Но есть ещё пятая сущность, которую мало кто выделяет. Логическое (архитектурное) «надо». Системные необходимости. То, без чего система не соберётся. Тут уже не «мы хотим», а «иначе не работает».

Я предлагаю разобраться — в каком порядке собираются требования и как из них строить бэклог.

➖➖➖➖➖

Системные необходимости — это то, без чего система не работает как система. Архитектурное требование.

Откуда они берутся? Из архитектуры системы. Из того, как система устроена. Из того, что должно быть связано с чем. Из логики работы. Их можно вывести из требований, потому что если требования — это «что хотим», то необходимости — это «что надо, чтобы это стало возможным».

У всего есть своя логика. Только системная логика непонятна руководителю или пользователю. Не надо биться в истерике, в попытках что-то доказать или объяснить. Используйте метафору — идеально человеческий организм. Представьте, что CRM — человек. Есть природные требования к тому, что должно работать внутри человека, чтобы определенные функции были возможны. Например, чтобы говорить вслух нужен отлаженный механизм связок + дыхание + данные (знания). Можно и без связок, но тогда нужен специальный дорогостоящий аппарат.

Почему они важнее хотелок? Потому что хотелка может подождать, а необходимость — нет. Значит, для верной расстановки приоритетов важен вес. И он будет у всех сущностей разный.

Допущения — 5 (редко когда идёт в бэклог — только в том случае, когда мы доделываем что-то, что является основной текущего проекта), Исключения — 4 (например, работы по безопасности), Необходимости — 3, Ограничения — 2, Требования — 1.

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

➖➖➖➖➖

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

Шаг 1. Собрать общий список требований. Чего всем надо. Что хотят заказчики, что хотят пользователи, что хотят остальные стейкхолдеры. Проверить, что каждое требование соответствует INVEST. Понятно, измеримо, достижимо.

Шаг 2. Составить список необходимостей для этих требований. Что надо, чтобы эти требования стали возможны? Пока список будет сказочный. Слишком большой. Слишком идеальный. Мы его потом скорректируем.

Шаг 3. Составить список допущений. Что есть и что не изменится до конца проекта. Что мы принимаем как данность. Какие условия считаем неизменными.

Шаг 4. Вернуться к необходимостям. Исправить. Дополнить или убрать. Что-то из необходимого уже есть, что-то стало невозможным из-за допущений. Корректируем.

Шаг 5. Определить исключения. Чего не должно быть. Что мы сознательно не делаем и что выносим за границы проекта.

Шаг 6. Вернуться к необходимостям. Дополнить. После исключений картина меняется. Что-то из необходимого теперь не нужно, что-то появилось новое. Корректируем.

Шаг 7. Составить список ограничений (допусков, наших возможностей). Бюджет, сроки, ресурсы, технологии. Всё, что мы не можем изменить, но можем обсуждать (расширять).

Шаг 8. Вернуться к необходимостям. Скорректировать. После ограничений картина становится реалистичной. Что-то из необходимого невозможно, что-то возможно. Корректируем финально.

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

Такие штуки хорошо делать в формате модерируемого совещания. 8-12 часов, все ключевые стейкхолдеры и команды и реестр требований готов.

➖➖➖➖➖

Как считать приоритет? Я рекомендую три критерия:

Простота реализации (1–5), где 5 — максимально просто, а 1 — максимально сложно.

Релевантность основной цели (1–5), где 5 — максимально релевантно, а 1 — минимально релевантно.

Ресурсность (1–5), где 5 — не нужно ничего особенного, а 1 — нужно много денег или особые специалисты и оборудование.

Формула: Приоритет = (Простота × Релевантность × Ресурсность) × Вес сущности.

Где вес сущности: допущения — 5, исключения — 4, необходимости — 3, ограничения — 2, требования — 1.

Вы берёте каждое требование, оцениваете по трём критериям, перемножаете, умножаете на вес сущности и получаете итоговый приоритет.

Пример. Требование: «Добавить кнопку «Купить» на страницу товара». Простота: 5. Релевантность: 2. Ресурсность: 5. Вес: 1 (требование). Приоритет: 5 × 2 × 5 × 1 = 50.

Необходимость: «Интеграция с платёжной системой». Простота: 2. Релевантность: 5. Ресурсность: 3. Вес: 3 (необходимость). Приоритет: 2 × 5 × 3 × 3 = 90.

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

У вас есть обоснование: почему это вперёд, а это — назад.

➖➖➖➖➖

Необходимости не должны конфликтовать с допущениями и исключениями. Если конфликтуют — вернитесь и пересмотрите.

Необходимости должны учитывать ограничения. Если необходимость невозможна из-за ограничений — либо ограничения надо обсуждать, либо сворачивайте удочки.

Требования проверяются на INVEST.

Вес сущности — не догма. Это рабочая договорённость. Если для вашего проекта важно другое — штош, меняйте.

Ну и цикл не для галочки. Нормально возвращайтесь и пересматривайте.

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