Решение задачки про RealtimeBoard

Итоги подведены, все победители получили "письмо счастья". Если вы не, пожалуйста, не расстраивайтесь: многие работы были близки к тому, чтобы попасть в топ-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, меню и всплывающие сообщения/реакции на изменения состояний заметки 

тестирование и багофикс.

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

Мой комментарий: грамотная оценка рисков и сроков. К рискам я бы еще добавила непонимание пользователями функционала фичи – нужно предусмотреть обучение (подсказки в интерфейсе, статья в хелп центре). Еще риск – что пользователи не заметят новый функционал, поэтому надо подумать о дистрибуции.