Принцип «Зачем? Что? Как?»
Коротко При сборе требований важнее всего вопрос «Зачем это нужно?», а не «Что это должно делать?» и уж тем более не «Как это должно работать?». Ответ на «зачем» превращает запрошенное решение в требование, которое проектировщики смогут хорошо реализовать, а тестировщики — проверить.
По материалам: Ю. Химонин, «Сбор и анализ требований к программному продукту», версия 1.03, 2009; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., гл. 12.
На этой странице
Главные идеи#
Главная ошибка при сборе требований#
Химонин считает, что самая частая ошибка — складывать образ продукта из ответов на вопрос «Что должен делать продукт?» или, хуже того, «Как он должен работать?». Такие ответы описывают решения. Цель выявления (elicitation) — понять, зачем нужен продукт. Единственный вопрос, который аналитику стоит постоянно задавать себе и заказчику, — «Зачем?».
Решения — это симптом#
Когда заинтересованная сторона говорит «нам нужны три пошаговых мастера» или «используйте такую-то цветовую схему», она описывает решение или деталь реализации. Химонин считает это признаком того, что настоящая потребность ещё не выявлена. Если сделать то, что попросили, есть риск получить дефектный дизайн: пропущенные функции, ограничения платформы, о которых никто не подумал, или других пользователей, чьи интересы не учли.
От запроса к требованию#
Химонин приводит пример примерно такого рода. Пользователь просит автозаполнение для поля «фамилия». Это ответ на вопрос «что». Аналитик спрашивает «зачем». Ответ: операторам нужно как можно быстрее вводить персональные данные клиентов. Это и есть настоящее требование: ускорить ввод персональных данных клиентов операторами. Автозаполнение становится одним из возможных способов — наряду с другими.
Выигрывают две команды. Проектировщики теперь знают цель, а не готовое (и, возможно, не лучшее) решение. Тестировщики получают критерий, который можно проверить: действительно ли ввод данных стал быстрее?
В терминах модели базовых понятий#
На языке BACCM вопрос «зачем?» возвращает от предложенного решения к потребности и ценности, которые за ним стоят. Сразу перейти к «что» или «как» — значит выбрать решение до того, как понята потребность.
Как применять#
- Прислушивайтесь к словам-решениям. «Кнопка», «выпадающий список», «приложение», «отчёт», «интегрировать с», «как в системе X». Каждое такое слово — сигнал спросить «зачем».
- Спрашивайте «зачем», не звуча враждебно. Полезные формулировки: «Что это поможет вам сделать?», «Что происходит сейчас, когда этого нет?», «Как вы поймёте, что это работает?»
- Продолжайте, пока не дойдёте до бизнес-результата. Обычно хватает двух-трёх кругов. Остановитесь, когда ответ — цель, которую признает бизнес: время, деньги, риск, удовлетворённость клиентов, соответствие нормативным требованиям. Для более глубокой цепочки используйте анализ корневых причин.
- Формулируйте требование через потребность. Укажите результат и, если возможно, как его будут измерять. Исходный запрос сохраните как вариант дизайна, связанный с требованием.
- Ищите другие варианты. Когда потребность ясна, перечислите хотя бы два способа её удовлетворить. Если подходит только одно решение, проверьте, действительно ли вы дошли до потребности.
- Уважайте реальные ограничения. Иногда «как» — настоящее ограничение (существующая платформа, нормативное требование, договор). Запишите его как ограничение, с причиной, а не как требование.
Когда выбирают готовый программный пакет, книга BCS делает похожее замечание: требования должны описывать, что нужно, а не как это должно работать, если только это «как» не критично для конкурентного преимущества, а организация должна быть готова подстроить свои процессы под то, что пакет делает хорошо.
Пример#
Управляющий одной из мастерских сети «Мастерская» (вымышленная сеть из 12 веломастерских) просит: «Добавьте в карточку заказа выпадающий список со всеми 200 запчастями».
- Зачем? «Чтобы механики записывали, какие запчасти использовали».
- Почему это важно? «Потому что сейчас они забывают, учёт остатков неверный, и мы дозаказываем слишком поздно».
- И что тогда происходит? «Ремонты ждут запчастей по два-три дня, и клиенты звонят жаловаться».
Требование становится таким: запчасти, использованные в каждом ремонте, надёжно записываются в момент ремонта, чтобы дозаказ делался до того, как запас закончится. Мера успеха: меньше ремонтов, задержанных из-за отсутствия запчастей.
Теперь вариантов дизайна несколько: выпадающий список, сканирование штрихкода, короткий список из 20 самых ходовых запчастей с поиском по остальным или еженедельная инвентаризация. Когда аналитик показывает их механикам, побеждает сканирование. Выпадающий список выполнил бы запрос, но не закрыл бы потребность.
Подводные камни#
- «Зачем» как допрос. Повторяющееся голое «зачем?» может звучать как вызов. Меняйте формулировки и объясняйте, что хотите найти для человека лучшее решение.
- Бесконечные «зачем». За пределами бизнес-цели «зачем» уводит в философию. Остановитесь на результате, под которым подписался бы спонсор.
- Отказ от исходной идеи. Решение, предложенное заинтересованной стороной, может быть хорошим. Сохраните его как вариант; просто не считайте его требованием.
- Игнорирование ограничений. Не каждое «как» — преждевременное решение. Некоторые заданы законом, бюджетом или существующими системами.
Источники и что почитать#
- Ю. Химонин. Сбор и анализ требований к программному продукту, версия 1.03, 2009.
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Гл. 12 (требования к готовым программным пакетам).