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