Как провести исследование перед разработкой веб-сервиса

Сформулируйте решение, которое предстоит принять

Исследование полезно, когда команда понимает, какую неопределённость оно снимает. Например, стоит ли автоматизировать существующий процесс, кому нужна первая версия и можно ли получить необходимые данные. Запрос «изучить всё про рынок» трудно завершить: у него нет границы достаточности и понятного влияния на проект.

Запишите исходную гипотезу отдельно от подтверждённых фактов. Высказывание заказчика о неудобстве текущего инструмента является важным сигналом, но не доказательством одинаковой потребности у всех пользователей. Согласуйте вопросы, источники и ограничения исследования. Это помогает избежать отчёта, который только красиво пересказывает первоначальную идею.

Изучите существующий путь

Попросите участников показать, как они решают задачу сегодня. Важны документы, исключения, ручные согласования и причины задержек. Не ограничивайтесь вопросом о желаемых функциях: человек может предложить привычный интерфейс, хотя основная проблема находится в недоступных данных или неопределённой ответственности.

Руководство GOV.UK по discovery связывает этот этап с пониманием проблемы, пользователей и ограничений до решения о разработке. Для коммерческого проекта состав работ адаптируют к задаче. Не нужно механически копировать чужой процесс или выдавать определённое число интервью за универсальный стандарт достаточности.

Составьте карту рисков

Сначала проверяйте предположения, ошибка в которых делает проект бессмысленным или резко меняет стоимость. Полировка названий кнопок не поможет, если поставщик запрещает необходимый обмен. Техническую пробу можно провести до детального дизайна, когда именно доступность интеграции определяет жизнеспособность будущего сервиса.

Отделите наблюдения от интерпретаций

В заметках храните, что произошло, как участник это объяснил и какой вывод сделала команда. Эти уровни не тождественны. Один человек может редко пользоваться функцией из-за неудобного доступа, другой — из-за отсутствия самой потребности. Одинаковое внешнее поведение не всегда имеет одинаковую причину.

Не превращайте небольшое качественное исследование в точные рыночные проценты. Оно помогает обнаруживать задачи и противоречия. Для оценки распространённости могут понадобиться другие данные и методика. Если доступа к части аудитории нет, укажите ограничение в выводах и не замещайте отсутствующие наблюдения мнением команды.

Учебный пример: сервис согласования

Компания хочет автоматизировать согласование заявок. Первоначально предполагается пять последовательных руководителей. Разбор реальных случаев показывает, что большинству заявок нужны два согласования, а дополнительные зависят от суммы и типа закупки. Команда описывает правила ветвления и отдельно проверяет исключения, вместо создания одинакового длинного маршрута для всех.

Прототип первой версии содержит один распространённый тип заявки, понятные статусы и передачу ответственному. Редкие случаи остаются в согласованном ручном процессе. Это не означает отказ от развития: исследование позволяет определить, какие наблюдения после запуска подтвердят необходимость следующего шага и когда стоит пересмотреть первоначальный состав MVP.

Передайте выводы в разработку

Итоговый комплект включает карту пользователей, текущий процесс, проверенные предположения, ограничения и сценарии первой версии. У каждого требования должно быть основание и ожидаемое поведение. Список пожеланий сохраняют отдельно с объяснением, почему они пока не вошли в объём.

Обозначьте решения, которые остаются открытыми, их владельцев и влияние на оценку. Исследование может привести к изменению идеи, покупке готового инструмента или отказу от разработки. Полезный результат измеряется качеством принятого решения, а не количеством страниц отчёта. После этого можно обоснованно оценивать сроки, сопровождение и стоимость владения сервисом.

Каким должен быть результат технической пробы до разработки

Выберите одно рискованное предположение, например возможность получить документы из внешней системы с нужными правами. Для пробы задайте входные данные, допустимый результат и срок прекращения исследования. Задача не в создании маленькой копии всего продукта.

В отчёте сохраните проверенный сценарий, ограничения доступа, недостающие методы и влияние на архитектуру. Если проба не подтвердила возможность, это полезный результат: можно изменить состав или получить данные другим способом до большой разработки. Демонстрационный код не следует автоматически считать готовым к эксплуатации. Отдельно оцените обработку ошибок, наблюдаемость и безопасность, прежде чем включать его в рабочую систему.