На прошедшем митапе для бизнес-аналитиков нас спросили о Definition of Ready — критериях готовности задачи к передаче в анализ. Рассказываем об этом подробнее и делимся нашим чек-листом.

Definition of Ready, или сокращённо DoR, — это критерии, по которым задачу из бэклога можно взять в работу. То есть, если PBI (Product Backlog Item) отвечает критериям DoR, то команда может взять её на планировании спринта в разработку.

На одном проекте наша команда встраивалась в процесс разработки уже существующего продукта и реализовывала некоторые отдельные фичи. При этом у клиента уже была своя большая команда разработки всего мобильного приложения (аналитики, разработчики, QA, дизайнеры и т. д.). Мы столкнулись с проблемой: при планировании новых фичей мы постоянно что-то упускали, и важные детали всплывали уже в процессе разработки.

Например, мы не согласовали техническое решение с командой, которую может частично затронуть фича или у которой уже были какие-то наработки в этом направлении. Мы просто не знали, что такая команда есть, а клиент (РО фичи) не знал, что мы не знаем 😊 Или мы создавали новый диплинк при доработке фичи, а оказывалось, что он уже есть.

Чтобы раз и навсегда избавиться от этой проблемы, мы придумали два решения: внедрили практику «Три амиго», в которую вовлекали команду клиента, и сделали чек-лист для разработки фичи.

Feature checklist — это список критериев, которые нужно учесть и выполнить перед передачей задачи в разработку.

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

Мы собрали его на основе процессов и особенностей клиента с учётом тех «граблей», на которые уже натыкались с командой. Это примерный набор возможных критериев, который закрыл потребности нашего проекта.

🔗 Поэтому смело забирайте шаблон себе и дополняйте в зависимости от нужд вашей команды.

Сегодня в канале рубрика #разборка ↗️

Мы собрали вопросы об инструментах, метриках и рабочих челленджах аналитика, которые вас волновали, и задали их Ире Мягковой, бизнес-аналитику red_mad_robot. Делимся ответами:

1️⃣ Какие ИИ-инструменты или сервисы вы используете для решения рутинных задач аналитика?

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

Сейчас есть много источников с прекрасными рабочими промптами. Например, недавно на «Хабре» вышла статья о том, как провести исследование рынка и продукта с помощью ChatGPT.

Ещё мы используем @daisygpt_bot — помощника на основе искусственного интеллекта, который помимо текстовых запросов может генерировать картинки и позволяет общаться голосом.

2️⃣ Как изменилось качество выполнения задач с применением ИИ-инструментов?

Всё зависит от задачи. Если говорить про базовые (написание требований, погружение в контекст), то да — качество результата осталось на высоком уровне, время на выполнение сократилось, общая производительность выросла.

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

3️⃣ Зачем использовать продуктовые метрики?

Это позволяет компаниям оценивать текущее состояние продукта на рынке, выявлять узкие места, определять потенциальные возможности для развития и постоянно совершенствовать пользовательский опыт.

Метрик достаточно много (индекс лояльности пользователя, конверсии в целевое действие и т. д.), и важно следить не только за ключевой, но и за метриками других уровней.

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

4️⃣ Как учесть метрики продукта при проектировании?

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

5️⃣ Какие вызовы и препятствия возникают при совместном проектировании, и как вы их преодолеваете?

Совместное проектирование даёт команде возможность объединить знания, навыки и опыт участников для создания качественных и эффективных решений. Конечно, бывают и трудности.

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

JBTD — это теория, которая помогает понять, почему люди принимают решение о покупке. Если вы не знакомы с JTBD, вот несколько полезных материалов, которые помогут детально погрузится в особенности использования методологии и инструменты:

Что такое Jobs To Be Done (JTBD)
Jobs To Be Done исследование. Часть 1
Что такое Работа и как её описать? (JTBD Statement)
Гайд по Job Stories
4 силы прогресса в JTBD

В следующих постах исследователи Лиза Косырева и Валера Черевков поделятся опытом применения LLM в теории Работ (Jobs To Be Done) на одном из проектов.

Почему LLM удобно использовать в работе с JBTD:
✅с помощью LLM мы проверяли, не упустили ли важные контексты и работы
✅ LLM сильно экономит время на генерацию Job Stories — когда есть сложности с формулированием своих мыслей, можно обратиться к LLM и воспользоваться её удачной формулировкой.

Что стоит также учитывать при использовании LLM при работе с JTBD.

Плюсы:
✅ Помогает проверить, не упущены ли важные контексты и работы в JTBD.
✅ Экономит время на генерацию Job Stories.
✅ Может помочь сформировать описание к персоне.

Минусы:
❌LLM может усложнять информацию, делая её нечитабельной.
❌Не всегда генерирует JTBD в нужном формате.
❌Не всегда может качественно сгенерировать четыре силы прогресса.

И вот некоторые рекомендации по работе с LLM в рамках JTBD:
1️⃣ Обучите LLM, задав требования и ограничения по работе с JTBD.
2️⃣ Уточняйте запросы, чтобы получить понятные и читабельные JTBD.
3️⃣ Используйте референсы, если с первого раза не получается добиться нужного результата.
4️⃣ LLM может быть полезен для формирования описания персоны по JS.
5️⃣ Выберите LLM, выдающий наиболее корректные результаты (для нас это был GPT-4 в режиме Data Analyst).

LLM – хороший помощник как источник вдохновения, но пока вряд ли сможет самостоятельно без помощи человеческой руки анализировать интервью по JTBD (мы никогда не оставляли чистые формулировки от GPT, всегда трансформировали, отталкиваясь от них), но мы верим, надеемся и ждем.

Привет!
Мы в red_mad_robot проводим исследование того, как люди выбирают и используют краудфандинговые платформы (Boomstarter, Планета.ру, Kickstarter и т. д.).

Ищем авторов, готовых поделиться опытом размещения проектов и взаимодействия с этими или похожими платформами.

Напишите @SvetaShirokova, если готовы помочь ❤️