Решение задачки про RealtimeBoard
@proproductИтоги подведены, все победители получили "письмо счастья". Если вы не, пожалуйста, не расстраивайтесь: многие работы были близки к тому, чтобы попасть в топ-3, не дотянули совсем чуть-чуть. Где-то была хорошая идея, но недостаточно качественная проработка метрик и сроков; где-то замечательное описание, но не подходящая под задание идея. К сожалению, у меня нет возможности в деталях прокомментировать каждую работу, но давайте разберем одну из них вместе. Мои комментарии – курсивом, пунктуация и структура автора.
Идея
Когда продакт-менеджер работает со стикером с одной и той же идеей на разных досках
Он хочет, чтобы изменения, сделанные в стикере на одной из досок, автоматически применялись на остальных досках
Чтобы ему не нужно было вручную обновлять содержание стикера на каждой доске, где используется стикер с идеей.
Детали:
- пользователь может перевести стикер в состояние Smart Sticky и выбрать, на какие существующие доски его применить
- выбранный Smart Sticky клонируется на всех указанных досках
- изменение содержания/цвета/шрифта/размера/тегов на Smart Sticky на любой доске означает аналогичное изменение стикеров-клонов на других досках
- пользователь может отменить состояние Smart Sticky для стикера - созданные стикеры-клоны остаются на своих досках, но уже независимо друг от друга, без применения изменений
- таким образом стикер может прожить полный жизненный цикл, побывав на всех досках продуктовой команды с минимальными ручными манипуляциями: высокоуровневые идеи -> брейнсторминг -> планирование/сторимаппинг/бэклог -> спринт/канбан доска.
Ограничения:
- 1 smart sticky на доску для бесплатного плана
- бесконечное количество для платных планов.
Ограничение было выбрано, исходя из количества доступных досок для бесплатного плана на https://realtimeboard.com/pricing/. Для трех досок трех умных стикеров должно быть достаточно, чтобы пощупать фичу.
Мой комментарий: хорошая идея – не слишком сложная в воплощении, но и достаточно оригинальная. По заданию детализация не требовалась, но автор продумал основной сценарий использования. Минус (который наблюдался почти во всех работах): ключевое слово в задании – активация, превращение посетителей в пользователей, которые выполняют какое-то важное действие в продукте. Активация подразумевает совершенно разные вещи для разных продуктов, и идти надо было от определения, что такое активация для RealtimeBoard. Опять же, по заданию мы хотим увеличить аудиторию продакт-менеджеров – почему фича будет полезна именно для них? Какая "боль" заставит их пользоваться нашим сервисом?
Метрики
Предложила бы измерять такие показатели:
- Время от регистрации до апгрейда на team plan - вырастет, если пользователи будут пользоваться фичей, т.к. чтобы оценить добавившийся функционал нужно время;
- Соотношение (количество новых стикеров)/(количество досок) на команду - уменьшится, если пользователи будут пользоваться фичей, т.к. клонированные тикеты не будут считаться вновь созданными.
Retention и paid team subscriptions не просядут, т.к. задачу, которую помогает решить новая фича, можно решить и существующими способами. Т.е. мы не дразним и потом забираем у пользователя инструментарий, а предлагаем ему выбрать между дефолтным и продвинутым инструментарием.
Мой комментарий: предложенные метрики – хорошие, но достаточно косвенные. Нам нужен прямой показатель, что мы что-то улучшили или ухудшили. И, раз нам нужно увеличить количество активаций продактов, надо понять, как мы это будем мерять (в зависимости от того, как мы определили активацию). К примеру, можем сравнить процент пользователей, которые создали доску после регистрации (если это наша "активация"). Ну и стандартный фреймворк для описания метрик: основная метрика - метрики продукта (что с ними происходит из-за нашей фичи) - метрики фичи (все ли работает корректно, пользуются ли ей, как ей пользуются, можем ли мы что-то улучшить). Например, еще один хороший показатель на уровне фичи – соотношение количества "умных стикеров" на количество досок; в идеале оно должно быть больше единицы.
Оценка внедрения
Риски:
- базы данных приложения может не поддерживать клонирование заметок
- возможное проседание перфоманса: зависит от структуры запросов и текущей архитектуры
- тестирование может оказаться трудоемким из-за потенциальных хитрых кейсов: что если конфликтные изменения будут применены одновременно и т.п.
Оценивая время, которые может понадобиться для разработки, я исхожу из такой декомпозиции:
дизайн: внешний вид smart sticky и меню
разработчик:
- добавление smart sticky состояния для заметки
- перевод заметки из дефолтного состояния в smart sticky
- применение изменений smart sticky на все доски, к которым она принадлежит
- перевод заметки из состояния в smart sticky в дефолтный
- юай для smart sticky, меню и всплывающие сообщения/реакции на изменения состояний заметки
тестирование и багофикс.
Для реализации фичи должно быть достаточно одного двухнедельного спринта, в зависимости от сложности архитектуры приложения.
Мой комментарий: грамотная оценка рисков и сроков. К рискам я бы еще добавила непонимание пользователями функционала фичи – нужно предусмотреть обучение (подсказки в интерфейсе, статья в хелп центре). Еще риск – что пользователи не заметят новый функционал, поэтому надо подумать о дистрибуции.