- PVSM.RU - https://www.pvsm.ru -
Юрий Андрейкович, Senior Product Manager в Wrike, рассказал на конференции ProductSense [1] в Минске, когда и зачем надо удалять фичи из продукта.
Я работаю в Wrike [2] — это сервис для совместной работы и управления проектами. В Wrike более миллиона пользователей, но наши прямые клиенты — это компании, которые платят за сотрудников. Таких примерно 17 тысяч.
Я не раз сталкивался с необходимостью удалять фичи из продукта, а иногда ко мне приходили с запросом: «У нас есть несколько тысяч пользователей, они чем-то пользуются, а мы хотим это удалить. Действуй». Я расскажу, на каких этапах жизненного цикла продукта стоит задуматься об удалении фичей и какие подводные камни можно обойти.
Давайте разберемся, зачем вообще удалять фичи из продукта. Лишняя фича — это та, без которой продукту станет лучше, а лишний продукт — тот, без которого бизнесу будет лучше. Удалять фичи и продукты стоит по нескольким причинам:
В жизненном цикле продукта есть несколько этапов, когда удалять фичи удобно и полезно. Я расскажу, на что обратить внимание и какие инструменты использовать, чтобы принять решение.
Делаем новую фичу
Вы решили добавить новую фичу в продукт. Вам кажется, что это хорошая идея, но может быть наоборот. Лучше убить фичу до того, как начать что-то делать. Есть хорошие инструменты, чтобы проверить гипотезу: аналитика, кастдев, анализ рынка. Если после исследований поймете, что ничего добавлять не надо — вы молодцы.
Проверяем гипотезы
По интервью и аналитике не всегда можно понять, нужно ли делать фичу. Более ценны метрики и обратная связь реальных пользователей, поэтому приходится делать прототип. Старайтесь не запускать его на всю аудиторию, потому что удалять или вносить значительные изменения будет сложнее и болезненнее. Чтобы упростить задачу, можно запустить прототип на часть аудитории или создать изолированную среду для тестовых фич. В Wrike мы используем Labs — это закрытая секция в сервисе, где любой пользователь может включить экспериментальную фичу и оставить обратную связь.
В Labs пользователи предупреждены, что экспериментальные фичи мы можем отключить в любое время. Поэтому они не завязывают процессы на этих фичах.
Готовимся к релизу на всех пользователей
После того, как вы обкатали фичу на какой-то части аудитории, надо проанализировать результаты. Есть опасная история «мы уже сделали», когда фича написана и ее можно запускать хоть сегодня. Но нужно остановиться и убрать всё, что не нужно пользователям.
Например, в SEMrush [4] сделали аналитику для маркетологов и запустили в тестовых группах. Потом проанализировали, что было полезно. Неудачные эксперименты убрали и запустили на всю аудиторию около 30% функционала. Ценность продукта выросла, а ресурсы не стали тратить ни сейчас, ни в будущем.
Что-то сломалось
Если фичу уже сделали, она может в какой-то момент сломаться. Вероятно, вы узнаете об этом от службы поддержки или из упавших тестов. Однако не всегда непременно нужно чинить фичу или добавлять фикс в бэклог.
Например, для внутренних команд мы сделали скоринг пользователей, который они могли интегрировать к себе. Когда сервис уже должны были интегрировать, мы узнали, что он не работает больше месяца. Пропустим историю, почему наш мониторинг не выявил проблему раньше — важнее, что мы не стали сразу исправлять проблему, а решили поговорить с командами.
Оказалось, что у команд либо бэклог забит интеграциями на полгода вперед, либо они уже используют другой сервис, либо у них серьезные проблемы в процессах и им сейчас не до этого.
Никто бы не пользовался скорингом в следующие полгода. Поэтому мы не стали ничего восстанавливать, а наоборот, закрыли сервис и отложили до лучших времен. Занимайтесь приоритетными продуктами и фичами и вовремя избавляйтесь от ненужных, чтобы не тратить ресурсы.
Много тикетов с низким приоритетом
Служба поддержки получает заявки с проблемами пользователей. Проанализировав их, вы увидите области продукта или фичей, которыми не любите заниматься. Проверьте, так ли они нужны, и если не нужны, запланируйте их удаление. Если решите оставить фичи, выделите ресурсы для исправления ошибок и мониторьте их состояние.
Делаем новую версию
Когда продукт уже зрелый, в его коде накопилось много устаревшего и ненужного. Иногда приходится принимать болезненное решение о большом рефакторинге или переписывании технической части функционала.
Если объем технической задачи очень большой, отнеситесь к рефакторингу и переписыванию, как к новому продукту. Разберитесь в проблемах и аналитике, чтобы одновременно убрать ненужные фичи и увеличить ценность продукта.
Команда перегружена
Сделали новую версию, потом новую фичу или продукт, увлеклись — и появилось еще пять продуктов. В какой-то момент команда начинает гореть, потому что нужно всё это поддерживать. Люди демотивированы и ничего не успевают. Чтобы этого избежать, разберитесь со всеми продуктами: проведите интервью, соберите аналитику, проанализируйте результаты. Избавьтесь от ненужных или менее приоритетных продуктов или передайте другим командам, у которых есть ресурсы.
Фича блокирует развитие или масштабирование
Бывает, что какая-то фича накладывает ограничения на масштабирование и рост продукта. В Wrike мы столкнулись с тем, что одна из корневых возможностей, которой пользовались тысячи пользователей, мешала нормально масштабироваться и развивать продукт. Несмотря на риски в краткосрочной перспективе, мы провели большую работу и удалили фичу, параллельно изменяя архитектуру приложения.
Регулярные ревью
Запланируйте ревью раз в полгода: вместе с аналитиком и UX-специалистом посмотрите данные и проанализируйте, что происходит. Так вы быстрее сообразите, какие фичи или продукты могут стать кандидатами на удаление.
Когда вы уже нашли проблемную фичу, встает вопрос, удалять или не удалять. Чтобы не ошибиться, нужно проанализировать все данные:
При удалении фичи вам нужно подумать о рисках:
Работать с рисками надо в два этапа: оценить и минимизировать.
Оцените риски:
Когда вы качественно оценили риски, постарайтесь их минимизировать:
Я выделил три сценария удаления фич: плохой, спорный и универсальный. Но каждая ситуация уникальна, поэтому один и тот же сценарий может быть хорошим в одном случае и плохим — в другом.
Плохой
Вы можете дать фиче медленно умереть, если сильно заняты другими делами. Но вам всё равно придется когда-нибудь это сделать.
Плюс: не нужно напрягаться.
Минусы: фича все еще отнимает ресурсы, пользователи недовольны.
Спорный
Удаляете незаметно. Но есть риск, что пользователи однажды не увидят какого-то экрана, графика или кнопки и поднимут негативную волну. Поэтому удаляйте фичу без предупреждения, только если уверены в маленьких рисках:
Плюс: просто.
Минус: есть шанс недооценить риски.
Универсальный
Иногда фичу можно не удалять, а продать конкуренту. Если эта часть продукта вам не нужна, он может увидеть в ней ценность. Или выделить фичу в отдельный продукт и передать свободной команде.
Если с первого раза фича не взлетела, иногда достаточно ее доделать. Вы думаете, что она никому не нравится, а ее просто сложно найти. Проводите тесты, собирайте обратную связь. Дайте фиче второй шанс.
Полное выступление Юрия Андрейковича. [5]
Автор: Mslk
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/307004
Ссылки в тексте:
[1] ProductSense: http://productsense.io/
[2] Wrike: https://www.wrike.com/
[3] Даниел Канеман: https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BD%D0%B5%D0%BC%D0%B0%D0%BD,_%D0%94%D0%B0%D0%BD%D0%B8%D0%B5%D0%BB
[4] SEMrush: https://ru.semrush.com/
[5] Полное выступление Юрия Андрейковича.: https://youtu.be/wKYofn5Iqn8
[6] Источник: https://habr.com/ru/post/438048/?utm_campaign=438048
Нажмите здесь для печати.