3.3 ФОКУСИРОВКА НА ПОЛЬЗОВАТЕЛЕ
Авторы раздела:
Потапова Е. Г.
Алферов П. А.
Ожаровский А. В.
Коротких С. С.
Понимание потребностей пользователя — это ведущий вектор разработки продуктов в коммерческом секторе, и сегодня он неуклонно становится таковым в разработке государственных услуг. Большинство современных подходов к созданию продуктов и услуг (Agile, Lean, дизайн-мышление и т. д.) предполагает, что сбору и пониманию потребностей пользователя требуется уделять особое внимание. Ниже описан ряд компонентов и инструментов Agile, позволяющих собрать и проанализировать пользовательский опыт.
Понимание потребностей пользователя — это ведущий вектор разработки продуктов в коммерческом секторе, и сегодня он неуклонно становится таковым в разработке государственных услуг. Большинство современных подходов к созданию продуктов и услуг (Agile, Lean, дизайн-мышление и т. д.) предполагает, что сбору и пониманию потребностей пользователя требуется уделять особое внимание. Ниже описан ряд компонентов и инструментов Agile, позволяющих собрать и проанализировать пользовательский опыт.
3.3.1 ВИДЕНИЕ ПРОДУКТА
3.3.1 ВИДЕНИЕ ПРОДУКТА
Время чтения: 6 мин.
Видение продукта — это небольшой документ, объясняющий, над каким продуктом работает команда, для кого (каких пользователей) этот продукт нужен, какие основные функции он выполняет, каким потребностям удовлетворяет, какую ценность несет и какие ограничения имеет.
Время чтения: 6 мин.
Видение продукта — это небольшой документ, объясняющий, над каким продуктом работает команда, для кого (каких пользователей) этот продукт нужен, какие основные функции он выполняет, каким потребностям удовлетворяет, какую ценность несет и какие ограничения имеет.
Очень важно, чтобы команда проекта и заинтересованные стороны одинаково понимали и разделяли видение продукта. Также рекомендуется, чтобы команда проекта разрабатывала видение продукта в сотрудничестве с заинтересованными сторонами. Это необходимо для согласованной работы и формирования коллективной ответственности за продукт. Гибкий подход предполагает определение целей на долгосрочную перспективу, но допускает возможность их корректировки по мере получения более точного понимания требуемого результата (видение продукта можно и нужно корректировать по результатам обратной связи от пользователей).
Глубинное интервью — один из распространенных инструментов понимания потребностей пользователей.
Команда практически сразу решила описать видение своего продукта. В первые же дни работы участники команды спланировали и провели глубинные интервью с несколькими горожанами — потенциальными пользователями приложения, а чуть позже устроили сессию дизайн-мышления. Таким образом у команды проекта «Спортивная страна» сформировалось представление о том, что пользователи хотят получить удобный сервис, с помощью которого смогут попробовать себя в различных видах спорта, участвовать в интересующих спортивных мероприятиях и вести историю собственных спортивных достижений. Также стало понятно, что некоторых пользователей могла бы заинтересовать интеграция приложения с различными фитнес-браслетами, но после обсуждения команда приняла решение отложить эту функцию до реализации следующего поколения продукта.
3.3.2 ПОЛЬЗОВАТЕЛЬСКАЯ ИСТОРИЯ
3.3.2 ПОЛЬЗОВАТЕЛЬСКАЯ ИСТОРИЯ
Пользовательская история (user story) — способ описания требований к разрабатываемому продукту, сформулированная в форме краткого описания применения продукта от лица пользователя. История должна быть написана простым языком с формулировками, понятными самому пользователю. Каждая пользовательская история ограничена по размеру и сложности. Пользовательская история — быстрый способ документировать требования заказчика, так чтобы не приходилось разрабатывать обширные формализованные документы и впоследствии тратить ресурсы на их поддержание. Как правило, разработчик и заказчик подготавливают пользовательские истории в тесном взаимодействии. Особое значение имеет формат истории, в которой всегда должны быть прописаны роль автора требования, требование и цель требования.
Формат пользовательской истории: Как <роль пользователя>, я <что-то хочу получить>, <с такой-то целью>.
Примеры:
Примеры:
- Как мама активного сына, я хочу видеть все доступные спортивные секции неподалеку, чтобы выбрать подходящие занятия для ребенка.
- Как спортивный горожанин, я хочу знать обо всех спортивных мероприятиях неподалеку, чтобы участвовать в них.
- Как профессиональный спортсмен, я хочу вести историю спортивных достижений, чтобы достигать больших высот.
3.3.3 РЕГУЛЯРНАЯ ДЕМОНСТРАЦИЯ ПРОДУКТА
3.3.3 РЕГУЛЯРНАЯ ДЕМОНСТРАЦИЯ ПРОДУКТА
Демонстрация, или обзор спринта (демоверсии), — совещание, которое проводится в конце спринта с целью получить обратную связь от конечных пользователей и заинтересованных сторон по созданному инкременту продукта и внести изменения в бэклог продукта. Цель обзора спринта — внесение улучшений в продукт.
Важно понимать, что обзор спринта направлен не только и не столько на формальную приемку инкремента продукта, сколько на получение новой информации и развитие командного взаимодействия. Все участники стремятся к одному — в короткие сроки и качественно завершить проект (продукт). По итогам обзора спринта команда получает данные для внесения изменений в бэклог продукта и принимает решение о выпуске продукта.
Важно понимать, что обзор спринта направлен не только и не столько на формальную приемку инкремента продукта, сколько на получение новой информации и развитие командного взаимодействия. Все участники стремятся к одному — в короткие сроки и качественно завершить проект (продукт). По итогам обзора спринта команда получает данные для внесения изменений в бэклог продукта и принимает решение о выпуске продукта.
По завершении каждого спринта команда проекта «Спортивная страна» проводит встречу, где демонстрирует свои наработки и получает объективную обратную связь от заказчиков продукта. Это позволяет команде «сверить часы» и лучше спланировать следующий спринт с учетом пожеланий заказчика и конечного пользователя. К примеру, по итогам первого спринта стало понятно, что на данном этапе разработки функционал по ведению истории спортивных достижений не является приоритетным, поэтому в ходе следующего спринта стоит вкладывать в развитие этого направления меньше ресурсов, а сконцентрироваться на формировании реестров спортивных секций и учреждений.
3.3.4 РАБОТА С ОБРАТНОЙ СВЯЗЬЮ
3.3.4 РАБОТА С ОБРАТНОЙ СВЯЗЬЮ
Постоянный контакт с пользователями и заинтересованными сторонами — фундамент гибких подходов. Постоянная проверка гипотез, сверка предположений с реальностью — это то, что позволяет добиться высокой эффективности, гибкости проекта и гарантированно поставлять ценность конечному потребителю. Команда должна стремиться периодически и оперативно получать обратную связь от заказчика и обязательно от конечных пользователей.
Периодичность и форма сбора обратной связи определяются договоренностью с заказчиком и пользователями, например по окончании каждого спринта (при необходимости это вполне можно делать и чаще) или через определенный промежуток времени, например раз в месяц.
Периодичность и форма сбора обратной связи определяются договоренностью с заказчиком и пользователями, например по окончании каждого спринта (при необходимости это вполне можно делать и чаще) или через определенный промежуток времени, например раз в месяц.
Команде важно регулярно получать обратную связь, после того как она внесла изменения/дополнения в продукт, чтобы учитывать пожелания и рекомендации пользователей при планировании следующих шагов по развитию продукта. Для этого команда проекта «Спортивная страна» приглашает пользователей продукта на демонстрацию новых версий, проводит фокус-группы, которым предлагает оценить новый функционал, а также собирает информацию в социальных сетях. Любой канал коммуникации с пользователем позволит собрать больше информации для дальнейшего развития проекта и продукта в необходимом направлении. По итогам первого спринта команда поняла, что пользователи хотят видеть в первую очередь компактное и удобное мобильное приложение, веб-решение интересует целевую аудиторию несколько меньше.