Заказчик требует мобильное приложение для регистрации заявок. Как проверить, что это потребность, а не преждевременно выбранное решение?
Нужно отделить бизнес-потребность от предложенного способа её удовлетворения. Аналитик выясняет, какую проблему должен решить заказчик, какой результат считается успешным, кто получает пользу и какие ограничения обязательны; затем сравнивает мобильное приложение с другими вариантами решения.
Если требуемая функция является лишь одним из способов достичь цели, её следует зафиксировать как гипотезу решения, а не как окончательное требование.
Разделение потребности и решения сформировалось как ответ на распространённую проблему: заказчик часто описывает не исходную проблему, а знакомый ему способ автоматизации. Если сразу принять такой способ за требование, команда может качественно реализовать ненужный продукт.
В инженерии требований поэтому различают потребности бизнеса, требования к результату и варианты решения. Такой подход позволяет сначала понять, какую ценность нужно создать, а затем обоснованно выбрать средство её получения.
Фраза «нужно мобильное приложение» не объясняет, почему оно необходимо. За ней могут скрываться разные потребности: сократить время регистрации заявки, дать сотрудникам возможность работать вне офиса, уменьшить число ошибок или обеспечить доступность сервиса для определённой группы пользователей.
Если принять приложение как обязательное решение без проверки причины, возникают риски:
Сначала аналитик уточняет исходную проблему: в какой ситуации возникает неудовлетворённость, кто с ней сталкивается, как она решается сейчас и какие потери создаёт. Важно получить наблюдаемый результат, например сокращение времени регистрации или снижение доли заявок с ошибками.
Затем фиксируются критерии успеха и ограничения. Критерий должен описывать измеримый эффект или проверяемое свойство результата, а ограничение — обязательное условие, например работу при нестабильной связи или соблюдение внутреннего регламента.
После этого формулировка «мобильное приложение» переводится в гипотезу: «мобильный канал может обеспечить требуемый результат для пользователей, работающих вне офиса». Гипотезу проверяют через интервью, наблюдение за процессом, анализ данных и быстрый прототип.
Следующий шаг — сравнение вариантов: мобильное приложение, адаптивная веб-форма, чат-бот, доработка существующего рабочего места или изменение самого процесса. Сравнение проводят по критериям ценности, стоимости, сроков, рисков, охвата пользователей и соответствия ограничениям.
Компромисс состоит в том, что ранний выбор решения иногда действительно нужен: например, из-за обязательной платформы, закупленного оборудования или установленного регламента. Но даже тогда аналитик должен явно отделить такие ограничения от предположений и проверить, какую часть решения ещё можно изменить.
Служба доставки заявила, что курьерам требуется мобильное приложение для оформления возвратов. Анализ показал, что главная проблема заключалась не в отсутствии приложения, а в задержке передачи данных: курьеры часто работали без связи, а повторный ввод сведений оператором создавал ошибки.
Рассматривались три варианта. Полноценное приложение обеспечивало автономную работу, но требовало наибольших затрат на разработку и сопровождение. Адаптивная веб-форма была дешевле, однако плохо решала проблему отсутствия связи. Изменение процесса с локальным сохранением данных в уже используемом приложении имело меньший охват функциональности, но быстрее устраняло основную причину задержек.
Выбрали доработку существующего приложения с накоплением данных до восстановления связи. Решение обосновали тем, что оно напрямую влияло на целевой показатель — время передачи возврата, — не требовало отдельного продукта и снижало риск обучения пользователей. В данном примере требование к мобильному приложению оказалось не потребностью, а одним из возможных вариантов реализации.
1. Достаточно ли спросить заказчика: «Какую проблему вы решаете?»
Нет. Такой вопрос полезен, но ответ может остаться на уровне общего мнения. Нужно дополнительно проверить текущий процесс, реальные потери, затронутых пользователей, частоту проблемы и критерий, по которому будет принято решение.
Надёжная проверка сопоставляет слова стейкхолдера с наблюдаемыми фактами: метриками, примерами обращений, длительностью операций, ошибками и ограничениями контекста. Иначе аналитик рискует заменить одно предположение другим.
2. Всегда ли следует избегать фиксации конкретного решения в требовании?
Нет. Конкретное решение допустимо, если оно является обязательным ограничением или уже принято на уровне, имеющем соответствующие полномочия. Например, организация может быть обязана использовать определённую платформу.
Однако даже в этом случае полезно отдельно зафиксировать бизнес-цель, ожидаемый результат и причины выбора. Это позволяет не перепутать обязательное ограничение с привычкой заказчика и не потерять возможность оптимизировать остальные части решения.
3. Как понять, что найденная потребность сформулирована достаточно хорошо?
Она должна быть независима от конкретной технологии, связана с заинтересованным пользователем или бизнес-результатом и проверяема через наблюдаемый критерий. Формулировка «нужна мобильность» слишком расплывчата, а «курьер должен передавать данные о возврате не позднее пяти минут после события даже при временном отсутствии связи» уже задаёт проверяемый результат.
При этом нельзя преждевременно превращать потребность в детальную спецификацию. На раннем этапе важно сохранить пространство для сравнения вариантов, а технические и функциональные требования уточнить после выбора обоснованного решения.