Какие ошибки можно допустить на этапе выявления потребности? Выберите 4 правильных варианта ответа.

Вот четыре распространённые ошибки на этапе выявления потребности (needs discovery). Это те варианты, которые обычно считаются верными для задачи выбора 4 правильных ответов. 1) Неполная или неясная постановка проблемы и целей - Что не так: задача сформулирована расплывчато, нет чётких целей и критериев успеха. - Почему это ошибка: без ясной формулировки трудно определить, какие требования действительно нужны и как их проверять. - Пример: «нужно улучшить процесс» без указания, что именно улучшить и как измерить улучшение (время цикла, качество, стоимость). - Как избежать: зафиксировать проблему в виде конкретной формулировки, цели проекта и SMART-цели (конкретность, измеримость, достижимость, релевантность, ограничение по времени). 2) Недостаточное вовлечение заинтересованных лиц (стейкхолдеров) - Что не так: важные пользователи и заказчики не участвуют в сборе требований. - Почему это ошибка: можно пропустить критические потребности, требования и ограничения. - Пример: решение проектируют только для IT-отдела, а конечным пользователям не интересуются. - Как избежать: идентифицировать и вовлечь всех ключевых стейкхолдеров, провести интервью, опросы, рабочие сессии, карту заинтересованных лиц. 3) Опора на предположения без проверки (гипотезы без данных) - Что не так: принимаются выводы на основе догадок или личного мнения без проверки. - Почему это ошибка: решение может не соответствовать реальным потребностям, возникают лишние функции и перерасход бюджета. - Пример: считать, что «пользователи хотят мобильное приложение», без проверки спроса. - Как избежать: формулировать гипотезы, собирать данные, тестировать идеи через интервью, опросы, пилотные прототипы. 4) Смешение потребностей с решениями (не отделяются «что нужно» от «как это сделать») - Что не так: сразу предлагают решения и функциональности вместо того, чтобы чётко выделить потребности. - Почему это ошибка: ограничивает поиск альтернатив и может привести к неверному выбору решения. - Пример: «нужно внедрить чат-бота» как требование, не выяснив, какие задачи и пользователи требуют помощи и какие альтернативы существуют. - Как избежать: отделять анализ требований (что нужно) от дизайна и технического решения (как это реализовать); использовать техники, такие как требования vs дизайн-форум, карты требований. Если у тебя есть конкретные варианты из твоего задания, отправь их — помогу выбрать именно те 4, которые соответствуют этим принципам. Также могу адаптировать объяснение под твой предмет или класс, если нужно.