Как мы используем сети 🥅 для определения приоритетов в разработке

Определение порядка разработки 👻 продукта – одна из самых сложных проблем в управлении продуктом. Мы сталкиваемся с этой проблемой каждый день! Существует множество техник, которые могут помочь в решении. В двух словах, эти техники – чаще всего линейные модели, которые с такой же эффективностью, как интуиция опытного менеджера по продукту. В большом перечне подходов не хватает одного важного элемента - сети.

Сеть фич

Любую 🧑‍🔬🔬 систему можно представить в виде сети. В нашем случае мы работаем с программным продуктом. Каждый узел представляет собой отдельную фичу (функциональность). Все фичи связаны между собой определенными связями, они зависят друг от друга. Возьмем Гугл документы. Есть фича "Документ" и фича "Поиск". Поиск связан с документом, поскольку вы постоянно что-то ищете в документах. Абстрактная сеть функций выглядит как-то так:

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

Одинокие фичи могут быть тупиковыми ☠️, а могут открывать новые горизонты 🌈. Они могут быть там по какой-то причине. Например, вы можете исследовать новые возможности и новые области применения продукта. В Гугл документах это могут быть видеозвонки. Они по-прежнему связаны с такими функциями, как Авторизация, Профиль пользователя, но в целом это периферийная функциональность. Так как же выбрать что разрабатывать и в каком порядке?

Мы считаем, что добавление 5 слабо связанных между собой фич - плохая идея.

Кстати, такая ситуация не редкость. У вас всегда есть целый набор запросов со стороны клиентов, и если вы используете какую-нибудь линейную модель вроде RICE, то эти несвязанные функции попадают в следующий релиз, при этом может оказаться, что у них мало связей. По сути, это похоже на стратегию «Spray and pray» 🙏, когда вы пытаетесь исследовать десятки разных областей без глубины. Этот термин означает стрельбу из автоматического огнестрельного оружия по врагу длинными очередями без прицеливания. Почти во всех случаях такое поверхностное поведение оборачивается катастрофой для продукта. Именно поэтому линейные модели могут не работать на практике, а использование сети фич помогает получать более точное представление о приоритетах.

Добавление нового кластера фич - это настоящее исследование.

Это означает, что вы пытаетесь исследовать новую область с помощью набора последовательных связанных фич. В принципе, когда вы пробуете новую область, она может быть слабо связана с ядром продукта 🔬, но, скорее всего, она образует новый цельный кластер. При этом вы всегда должны думать о совершенно новом продукте или новом модуле, который можно включать/выключать. Многие IT компании придерживаются этой стратегии с большим успехом. У нас целым отдельным кластером является коропоративная вики и списки. Они представляют собой целые кластеры фич, которые связаны с ядром продукта небольшим количеством связей. Обратите внимание, что этот подход хорош, когда ядро продукта достаточно прочное и вы не можете найти новые точки роста внутри ядра. Другая ситуация, когда это может сработать, - кризис. Когда основная функциональность не находит применения на рынке, нужно как можно быстрее попробовать новые области, и это может быть хорошим способом сделать это.

Фичи связанные с ядром приложения.

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

Этот вариант добавления функциональности самый удачный 🍀🤞. Поиск фич, которые связаны с основой приложения и улучшает продукт - основная цель в оценке предложений от пользователей. В нашем продукте комментарии являются фичей, связанной с ядром приложения и существенно повышающие его функциональность.

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