§5.03 Потребности, требования и ограничения
Время: 60 мин чтение + 40 мин = 100 мин Что узнаешь: почему «список требований» - недостаточное основание для проектирования и какие три уровня нужно различать, чтобы понять, что реально нужно от системы
В одном предложении: потребность - это глубинная нужда роли, требование - проверяемая спецификация системы, ограничение - условие, которое система не может изменить; путать эти три уровня значит строить что-то, что формально соответствует требованиям, но не удовлетворяет реальной потребности.
Сигнатура понятий:
- Потребность — это глубинная нужда роли, которую система должна обеспечивать для своего существования; отвечает на вопрос «зачем эта система нужна этой роли?»; не всегда явная и не всегда может быть прямо сформулирована ролью
- Требование — это проверяемое утверждение о свойстве системы; отвечает на вопрос «что система должна делать или каким быть?»; может быть верифицировано тестом или измерением
- Ограничение (системное) — это условие функционирования системы, которое система не может изменить и должна принять как данность; задаётся надсистемой, регуляторной средой, физической реальностью
Мем, который снимается. «Заказчик знает, что ему нужно - он дал список требований, мы реализуем.» Классическая ловушка системного проектирования. Заказчик формулирует то, что он думает, что ему нужно — это требования. Но за требованиями стоят потребности, которые заказчик часто не осознаёт или не может сформулировать. Реализованные требования могут удовлетворять букву запроса, не удовлетворяя потребности. Известный пример: заказчик просит «более быструю лошадь» — это требование. Потребность - «добраться быстрее». Правильное решение может быть автомобилем.
Определение из источника.
В Pack (PD.FORM.027) три понятия разграничены следующим образом.
Потребность — это то, что роль должна получить от системы, чтобы выполнять свою функцию. Потребности часто неявные: пользователь не говорит «мне нужно доверие к системе», он говорит «ваш интерфейс выглядит несерьёзно». За вторым стоит первое. Системный мыслитель работает не только с явными требованиями, но и с потребностями, которые за ними скрываются.
Требование — это конкретная, проверяемая спецификация системы. «Система должна обрабатывать 1000 запросов в секунду» - требование: оно измеримо и проверяемо. «Система должна быть быстрой» - не требование: это пожелание, которое не может быть верифицировано. Хорошее требование содержит критерий приёмки.
Ограничение (системное) - условие, которое задаётся извне и которое система должна принять, не изменяя его. Бюджет - ограничение. Регуляторный стандарт - ограничение. Физические законы - ограничение. Ограничения не обсуждаются с точки зрения «хотим мы их или нет» - они задают пространство, внутри которого система существует.
Развитие мысли.
Три уровня - потребность, требование, ограничение - образуют иерархию: ограничения сужают пространство решений, требования задают спецификацию внутри этого пространства, потребности определяют, зачем вообще нужна система.
Ошибка проектирования часто возникает, когда начинают с требований, не зная потребностей. Требования могут быть технически выполнены, но система не решает реальную проблему. Другая ошибка - принимать ограничения за требования: «мы не можем выйти за бюджет» - ограничение, «система должна стоить не более X» - требование. Ограничение нельзя нарушить; требование можно пересмотреть, если потребность того требует.
Для личного развития это различение также работает. Потребность: «мне нужно развивать системное мышление». Требование: «я должен тратить минимум 8 часов в неделю на целенаправленное обучение». Ограничение: «у меня сейчас максимум 5 свободных часов в неделю». Смешение этих трёх приводит к тому, что человек либо не движется (видит ограничение как потребность и опускает руки), либо движется в неправильную сторону (выполняет требование, не отвечающее потребности).
Метод - минимальный шаг. Практика «Три колонки» (40 мин):
- Возьмите систему или задачу, над которой работаете. Запишите её название (5 мин).
- Выпишите все формулировки, которые вы или ваши коллеги/заказчики используют, описывая, что нужно от системы, без сортировки (10 мин).
- Разложите эти формулировки по трём колонкам: Потребности (зачем, глубинная нужда), Требования (проверяемые свойства), Ограничения (данности, которые нельзя изменить) (15 мин).
- Для каждого требования задайте вопрос: «Какую потребность оно обслуживает?» Если не можете ответить — это либо лишнее требование, либо потребность ещё не выявлена (10 мин).
Пример из жизни. Ирина - тимлид команды разработки в e-commerce компании. Команда получила задание: «Улучшить checkout». Список требований занял страницу: добавить Apple Pay, убрать лишние шаги, ускорить загрузку страницы, добавить прогресс-бар. Ирина остановилась перед реализацией и применила различение. Потребность заказчика (бизнеса): «увеличить конверсию корзины». Потребность пользователя: «минимальный стресс при оплате». Требования - конкретные механики достижения этих потребностей. Ограничения: платёжный провайдер диктует формат данных, GDPR требует явного согласия. После анализа оказалось, что половина требований была техническими предположениями команды, а не реальными запросами. Три требования были переформулированы под реальную потребность и стали эффективнее.
Типичная ошибка. «Заказчик сказал, чего хочет - наша задача реализовать, а не переспрашивать.» Люди склонны воспринимать высказанные требования как окончательные, потому что они явные и конкретные, а потребности - неявные и неудобные для обсуждения. На самом деле работа с потребностями — это не «переспрашивание», а профессиональный инжиниринг. Реализовать требование без понимания потребности — это риск создать формально правильную, но практически бесполезную систему.
Вторая ошибка - смешивать ограничения и требования. «Нам нельзя тратить больше X» — это ограничение: оно задано средой. «Функция должна стоить не более Y» — это требование: оно задаётся проектировщиком и может быть пересмотрено. Смешение делает ограничения невидимыми и создаёт иллюзию гибкости там, где гибкости нет.
Степени мастерства:
| Степень | Что происходит | Критерий перехода |
|---|---|---|
| 1. Объясняю | Могу объяснить разницу между потребностью, требованием и ограничением | Один раз выполнил практику «Три колонки» |
| 2. Умею | Могу для любого запроса к системе разложить его на три уровня | Есть запись: система + потребности + требования + ограничения |
| 3. Навык | В любом разговоре о системе автоматически уточняю: «это потребность, требование или ограничение?» | Регулярность: в анализах явно разграничиваю три уровня |
| 4. Мастерство | Помогаю командам выявлять потребности за требованиями и не принимать ограничения за данности без проверки | Кейс, где разграничение изменило решение |
Проверка себя.
- Понимание: вы можете объяснить, почему реализация требований не гарантирует удовлетворения потребностей, на конкретном примере.
- Поведение: когда вам дают список требований, вы задаёте вопрос «какую потребность обслуживает каждое требование?» до начала реализации.
- Застревание: если вы не можете ответить, какую потребность обслуживает конкретное требование - либо потребность не выявлена, либо требование лишнее. В обоих случаях нужно вернуться на уровень потребностей.
Что дальше. Потребности, требования и ограничения — это язык взаимодействия ролей с системой. Но кто реально создаёт систему? В любом проекте создания есть три фундаментальные роли: предприниматель, инженер и менеджер - каждая с собственным предметом интереса и ролевым интересом. Следующий подраздел о том, как эти три роли разделяют ответственность за создание системы.