До начала карантина в AdvanceIT успели провести практическое занятие в курсе BusinessAnalysis по материалам первого модуля. В этом модуле мы учились формировать scope (feature list) продукта и продумывать roadmap его разработки.
![]() |
Практическое занятие на курсе Business Analysis от AdvanceIT |
Работа с требованиями к продукту требует такой перестройки. Вот некоторые важные наблюдения и рекомендации, которые могут быть полезны и вам.
❗️ Список Features составляется не только на основании интервью с заказчиком и изучения стандартов зарегулированных индустрий.
Для этого у UX-дизайнеров, бизнес-аналитиков, Product Manager-ов есть целый ряд инструментов. Все они - не универсальны, дополняют друг друга и могут помочь с валидацией наших гипотез.
Некоторые из них перечислены ниже.
ПО - это капиталовложение его заказчиков. Разработчики - как их партнеры - не имеют морального права не учитывать бизнес-потребности и цели.
Мы рекомендуем использовать следующие инструменты :
📌 Продукты создает и продает бизнес. Бизнес получает выгоду от того, что пользователи пользуются этим продуктом. Задачи, потребности и предпочтения пользователей нужно изучать, даже если у вас нет доступа к ним.
На разных этапах эволюции курса Business Analysis мы пробовали разные инструменты: value stream, persona, сценарии. Сейчас мы рекомендуем:
Если вы счастливчик, у которого есть доступ к пользователям, перечисленные инструменты можно использовать как базис для опросников и при планировании наблюдений.
Вначале требуется исследование контекста, условий, целей и потребностей. Полученную информацию мы анализируем: сравниваем, находим несостыковки и связи, делаем предположения и - предлагаем решение.
За каждой фичей решения стоит ответ на вопросы
"Зачем?" и "Почему?".
|
Некоторые из них перечислены ниже.
Важно помнить, что
инструменты - это визуализированные чеклисты, а не артефакты проекта.
Они помогают аналитику не забыть самое важное и связать между собой собранную информацию.
|
Бизнес заказчиков и Jobs пользователей
📌 Помним, что у нашего продукта есть заказчики и пользователи. И у них разные цели и потребности.ПО - это капиталовложение его заказчиков. Разработчики - как их партнеры - не имеют морального права не учитывать бизнес-потребности и цели.
Мы рекомендуем использовать следующие инструменты :
- Lean Canvas для выявления сегментов потребителей и их основных потребностей и задач продуктов;
- Business Model Canvas для выявления целей, процессов и стейкхолдеров бизнеса, который будет использовать или продавать продукт.
📌 Продукты создает и продает бизнес. Бизнес получает выгоду от того, что пользователи пользуются этим продуктом. Задачи, потребности и предпочтения пользователей нужно изучать, даже если у вас нет доступа к ним.
На разных этапах эволюции курса Business Analysis мы пробовали разные инструменты: value stream, persona, сценарии. Сейчас мы рекомендуем:
- Jobs To Be Done фреймворк для выявления задач пользователя, которые могут попасть в наш продукт. И тех, которые не попадут в него, но нам нужно упростить связь нашего продукта с ними.
- Value Proposition Canvas для формирования ключевых фич нашего продукта для тех Jobs, которые мы автоматизируем.
![]() |
Презентация Value Proposition Canvas на практическом занятии курса Business Analysis от AdvanceIT |
Видение продукта, решение, последовательность разработки
📌 На основе анализа потребностей бизнеса и пользователей аналитик может сформировать видение / концепцию продукта.
Всем известен стандартный шаблон product vision statement. Можно использовать его. При этом, в аутсорсинге совсем не обязательно составлять одно предложение.
На что действительно стоит обратить внимание:
- с чьей точки зрения вы пишите
- с чем сравниваете ваш продукт
➡️ Для B2C продуктов в пункте "Для кого" пишем, как правило, с точки зрения пользователей,
➡️ Для В2В продуктов - с точки зрения заказчиков.
В части, где вы говорите "в отличии от" - сравнивайте не столько с продуктами-конкурент, сколько с конкурентными способами удовлетворения потребности заказчика/ пользователей.
➡️ Для В2В продуктов - с точки зрения заказчиков.
В части, где вы говорите "в отличии от" - сравнивайте не столько с продуктами-конкурент, сколько с конкурентными способами удовлетворения потребности заказчика/ пользователей.
📌 На основании собранной информации и видения продукта формируется решение.
Тут мы рекомендуем:
Тут мы рекомендуем:
- Описание процесса, флоу решения основной проблемы (в нашей программе это Activity diagram, но может быть BPMN, DFD, и пр.). Из него мы можем получить более полный перечень фич для нашего продукта (функции и интеграции).
- Benchmarking и сравнительный анализ конкурентов - это помогает проверить наши гипотезы о востребованности той или иной фичи и найти возможности сделать что-то более привлекательным для потребителей.
- Внешние события бизнеса уточняют этот перечень и помогают приоритизировать его. Внешними событиями могут быть мероприятия, сезонность, планы контрагентов и пр.
![]() |
Практика составления roadmap на курсе Business Analysis от AdvanceIT |
И помните:
📌 ПО, которое мы разрабатываем - это часть (!) организационных изменений в работе или быту тех, кто будет их использовать.
Перевод в новый режим (или формирование новых привычек) должен быть плавным. Внедрение продукта должно сопровождаться организационными переменами. |