В веб-студии YuSMP Group мы придерживаемся позиции, что проектировать будущие приложения необходимо вместе с клиентом. С таким подходом мы реализовали десятки проектов, которые сейчас успешно работают. В статье мы поделились опытом совместного проектирования.
Как правило, клиент обращается в IT-компанию уже с идеей. У него много планов и представлений о том, каким должен быть продукт, но не всегда заказчик хорошо понимает техническую сторону вопроса. Наша задача — за руку с клиентом пройти путь от замысла к четкому плану действий.
Проводим интервью
Первое, что мы делаем, задаем клиенту ключевые вопросы. Ответы дадут нам понять, как и куда мы будем двигаться дальше.
Вопросы:
- Кто целевая аудитория продукта? Здесь мы выясняем портрет потенциального клиента: пол и возраст, географию, уровень дохода и так далее.
- Какую проблему решает продукт? И действительно ли будущее приложение закрывает боли пользователей?
- Как будет происходить монетизация? Узнаем как клиент видит заработок на продукте, если монетизация вообще предполагается проектом. Например, для социального проекта прибыльность может не учитываться.
- Какой эффект от продукта ожидается? Выясняем, что клиент хочет получить от приложения. Это может быть заработок, упрощение бизнес-процессов, рост или пиар компании, практическая польза и так далее.
- Изучал ли клиент рынок? Важно понять какие решения были у конкурентов, что из этого мы можем взять во внимание, а что сделать по-другому. Если заказчик не проводил мониторинг, мы берем эту задачу на себя.
- Кто будет продвигать продукт? Узнаем, есть ли у клиента свои маркетинговые мощности или потребуется рекомендации от нас.
Обсуждаем роли в системе
Нам важно понимать, кто будет пользоваться продуктом и какие роли будут у пользователей. Например, в системе для учета пассажиров в транспорте и учета времени работы водителей есть две роли:
- роль Водитель;
- роль Пассажир.
В зависимости от роли будут меняться пользовательские истории. То есть интерфейс и функциональности ПО.
Так, водителю перед запуском приложения нужно ввести свой идентификационный номер, медицинские параметры (пульс, давление, наличие алкоголя в крови) и уже непосредственно перед выходом на линию маршрута нажать кнопку “старт”. Соответственно, у пассажира будет другая пользовательская история.
С клиентом мы обсуждаем сколько всего нужно “ролей”, и как они будут взаимодействовать в системе. Так же определяем какие приложения необходимы (веб и мобильное приложение, админ-панель и так далее).
Составляем набор артефактов
Для каждого проекта мы формируем индивидуальный пул артефактов.
- MindMap — это ментальная карта фичей. Здесь обозначаем, какие приложения потребуются
внутри проекта, прописываем роли, (администратор, модератор и так далее), и то, как роли взаимодействуют с будущим приложением. - Пользовательские истории. Раскрываем как каждая роль взаимодействует с системой.
- BPM диаграмма наглядно показывает как роли взаимодействуют с системой и друг другом. Этот артефакт помогает избежать дыр в бизнес-процессах. Когда мы видим перед собой схематичное взаимодействие, сразу становится очевидным, какие важные процессы в приложении остались не задействованными.
- Дизайн-концепт. Обязательно рекомендуем нашим клиентам сделать этот артефакт. Представляет из себя 2-3 варианта экрана будущего продукта.
Каждый артефакт утверждается заказчиком. На данном этапе работы тесно общаемся с клиентом: каждый день вместе обсуждаем подготовленные части бизнес-процесса, чтобы достигнуть наилучшего результата.
Перед началом работы
После проделанного пути, мы получаем набор работ для стадии аналитики и дизайна. Перед началом следующего этапа еще раз вместе с клиентом смотрим на фичи и, при необходимости, сокращаем их для минимального рабочего продукта. Это и является MVP будущего проекта.
P.S.: Очень удобно выделять MVP при помощи цветов на MindMap. Таким образом вы с клиентом видите целостную картину фичей и что является минимальным рабочим продуктом.
Так на дискавери-фазе мы проектируем будущее приложение вместе с клиентом.
No comments.