В конце января мы провели в московском Робохранилище митап для бизнес-аналитиков. Если вы не смогли побывать на нём ни очно, ни онлайн — рассказываем, о чём шла речь. Да и что уж там — показываем записи выступлений, выкладываем все полезные артефакты и вообще ничего не скрываем!
Артефакты пресейла, или Как работать на пресейлах год и не сойти с ума
Настя Попова, Senior Business Analyst, red_mad_robot
Пресейл — самый первый этап проекта, когда нужно разобраться с задачей, собрать образ результата и сформулировать коммерческое предложение. Обычно в пресейле участвуют sales-менеджер и команда производства, в которую входит аналитик. И все участники хотят от пресейла разного: клиент хочет сделать дешевле, sales-менеджер — быстрее, а аналитик и команда — качественнее.
Проблематика аналитика на этом этапе:
отраслевая принадлежность — нужно разбираться в новых сферах рынка;
ограниченность времени — пресейлы длятся 1–2 недели;
неопределённость — клиент может прийти с абстрактными видением задачи.
Чем ниже зона неопределённости, тем качественнее оценка — это цель аналитика.
Пресейлы в red_mad_robot мы условно делим на два типа:
RFP-пресейл (request for proposal) — на нём обычно есть техническое задание. Аналитик на таком пресейле изучает запрос, собирает вопросы, проводит бизнес- и технический брифы, собирает фичер-лист и оценивает его с командой.
Пресейл для идеи — когда к нам приходят стартапы или офлайн-бизнесы, и нужно помочь клиенту сформулировать задачу. Для этого аналитик глубоко изучает запрос и проводит глубокий бизнес-бриф, а ещё делает вторичное исследование рынка и брейншторм-сессии.
Артефакт — шаблон для конкурентного анализа
После этого составляем приблизительную схему процесса, чтобы примерно представлять, какие у него есть участники и как они друг с другом взаимодействуют. Этот фрейм уточняется при входе в проект, и тогда можно декомпозировать каждый этап, методы и взаимосвязи.
Подробнее читай в презентации и смотри в видео ниже.
Ценность бизнес-аналитика в продуктовых UI/UX-исследованиях
Катя Елисеева, Head of Business Analysis, red_mad_robot
Бизнес-аналитик помогает посмотреть на исследование с точки зрения бизнеса и продукта, проводит конкурентный анализ и понимает потребности пользователя. Он связывает этапы исследования и разработки. И помогает «приземлить» полёт мысли исследователей и проверяет техническую реализуемость.
Этапы UX-исследования:
Получение вводных от клиента.
Формирование и уточнение гипотез.
Бенчмаркинг/тренды.
Проверка исследованиями — качественными (подготовка прототипов для интервью, подготовка гайдов и досок в Miro для интервью и сами интервью) и количественными (подготовка опроса для анкет и кросс-таблиц).
Обработка результатов исследования.
Презентация и защита перед клиентом.
В исследовательской команде четыре роли. Методолог — капитан корабля, формирует методологию исследования, обозначает сроки и методы, общается с командой клиента по методологии, результатам и выводам. Исследователь проводит полный цикл исследования, анализирует данные и оформляет результаты. Бизнес-аналитик — «сопровождающий» исследования: анализирует рынок конкурентов и тренды и собирает бенчмарки. Дизайнер делает дизайн-макеты, может быть привлечён со стороны клиента.
Подробнее про участие бизнес-аналитика в продуктовых исследованиях скоро выпустим отдельный материал. А пока смотри всё выступление и ответы Кати на вопросы в видео ниже и читай презентацию.
Применение методологии «Три амиго» для разработки цифрового продукта
Ира Мягкова, Business Analyst, red_mad_robot
Совместное проектирование — процесс, в котором команда разработчиков, дизайнеров и других стейкхолдеров работают вместе, чтобы определить, создать и уточнить требования для новых функций или улучшения существующих. Для разработки это важно, потому что такая синергия помогает создавать продукт, соответствующий ожиданиям клиента и рынка.
Классический процесс разработки цифрового продукта начинается с проработки аналитиком требований и проектирования фичи. После этого требования отправляются на ревью всем участникам проектной команды. Если фича сложная, то итераций по уточнению требований и повторных ревью может быть несколько. В итоге это влияет на скорость разработки и качество функции. И это проблема.
В поисках способов, как можно быстро проектировать сложные фичи, мы наткнулись на методологию «Три амиго». Её суть в совместной работе и обдумывании бизнес-спецификации или фичи — это помогает выровнять ожидания от фичи до начала разработки, сразу делать правильно, сократить время разработки и раньше отслеживать риски.
Мы используем «Три амиго» при проектировании фич высокой и средней сложностей. Признаки, по которым мы определяем сложную фичу:
подразумевает процесс из нескольких шагов,
связана с другой функциональностью,
находится в зоне высокой неопределённости,
требует для проектирования привлечения других ролей, кроме аналитика,
связана с высокими рисками (если мы узнаём о них на первых шагах проектирования).
Артефакт — оптимизированный шаблон методологии
Как это происходит на практике и что получается в результате — читай в презентации и смотри в ролике ниже.
Делимся железной экспертизой от практик в нашем телеграм-канале red_mad_product. А полезные видео складываем на YouTube-канале. Присоединяйся!
