Функция, которую все просили и почти никто не использовал: чему учат такие релизы

У продукта бывает очень знакомая история. На встречах функцию просили громче остальных. Команда её сделала, показала, выпустила — и через несколько месяцев оказалось, что ей почти никто не пользуется. Первая реакция обычно оборонительная: «Надо лучше рассказать», «пользователи ещё не привыкли», «в следующем релизе доделаем рядом ещё пару вещей».

Я стараюсь не начинать с таких объяснений. Сначала стоит принять простой факт: просьба о функции и реальная потребность — не одно и то же. Человек может точно описать то, что мешает ему сегодня, но предложить не лучший способ это исправить. Наша задача — не обидеться на его просьбу и не защищать свою реализацию, а разобраться, что произошло между разговором и настоящей работой.

Просьба часто маскирует работу, которую нужно сделать

Допустим, клиенты просили «выгрузку в Excel». Команда сделала сложный конструктор отчётов. А потом им пользуются два человека. Легко решить, что функция не нужна. Но причина может быть другой: людям на самом деле требовалось раз в неделю быстро понять, какие заказы задерживаются. Они просили знакомый инструмент, потому что не видели короткого пути внутри системы.

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

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

Нулевое использование — не приговор и не повод прятать цифры

Неиспользуемая функция неприятна, потому что в ней лежат часы работы и чьи‑то надежды. Но именно поэтому её опасно оставлять вне разговора. Если команда не смотрит на использование, продукт постепенно становится складом вещей «на всякий случай». Каждая по отдельности кажется небольшой, а вместе они усложняют интерфейс, тестирование, поддержку и будущие изменения.

Я бы сначала проверил три уровня.

Дошёл ли пользователь до функции? Возможно, она находится не там, где её ждут. Возможно, к ней ведёт непонятное название или нужна роль, которой нет у нужного человека. В таком случае отсутствие использования говорит о пути, а не о ценности.

Попробовал ли и получил ли результат? Один клик ещё не использование. Важно, завершает ли человек действие. Если он открыл экран и вышел, стоит посмотреть, чего не хватило: данных, доверия, времени, понятного следующего шага.

Возвращается ли к ней в подходящей ситуации? Некоторые функции нужны раз в квартал, и дневной счётчик для них бессмысленен. Но для каждой можно назвать естественный повод. Если повод наступал, а функция не помогла, разговор становится предметнее.

Такая проверка защищает и от обратной ошибки: не стоит удалять полезный инструмент только потому, что он не похож на ежедневную ленту. Контекст важнее красивой средней цифры.

Что спросить у тех, кто просил

Не нужно начинать разговор с вопроса «почему вы не пользуетесь?». Он звучит как упрёк и заставляет человека оправдываться. Гораздо лучше вернуться к его рабочему дню: «Помните ситуацию, из-за которой вы просили это? Она повторялась в последнее время? Как вы решали её в последний раз? Что было неудобно?»

Ответы часто удивляют. Бывает, что процесс изменился и проблема исчезла. Бывает, что пользователь нашёл более быстрый обходной путь. Бывает, что функцией пользуется другой человек, а мы смотрели не на ту роль. Бывает, что запрос родился на общей встрече и за ним не стояло регулярной задачи вовсе.

Важнее всего не пытаться собрать подтверждение уже принятых решений. Интервью полезно, даже если после него не появляется новая задача. Отдельно я писал о том, почему разговор без готового решения всё равно даёт команде ориентир.

Четыре причины, которые встречаются чаще всего

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

Функция появилась не в момент потребности. Если полезный отчёт нужно искать в меню до того, как возник вопрос, он проигрывает обычному чату. Иногда правильное решение — не развивать отдельный раздел, а показать нужную подсказку там, где человек уже работает.

Функция требует слишком много подготовки. Конструктор может быть мощным, но если для первого результата нужно заполнить десять полей, обычный пользователь вернётся к таблице. Это не означает, что сложные возможности всегда плохи. Просто им нужен другой путь входа: шаблон, пример, готовый сценарий.

У команды нет договорённости, что считать использованием. Тогда отчёт видит один отдел, решение принимает другой, а пользователь не понимает, зачем ему тратить время. Продукт не исправляет такую организационную дыру автоматически.

Нужно ли сразу удалять функцию

Удаление — не наказание. Это один из возможных способов вернуть продукту ясность. Но решение лучше принимать не по раздражению, а по фактам.

Сначала я бы проверил, был ли у функции честный шанс: была ли она доступна нужным людям, понятна ли её польза, наступал ли реальный повод для использования, наблюдали ли мы за правильной аудиторией. Затем — оценил стоимость жизни функции: насколько она усложняет интерфейс, тесты, документацию, поддержку и следующую доработку.

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

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

Как не накопить склад функций

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

Это похоже на хороший roadmap: в нём есть не только обещание сделать, но и причина, по которой именно это стоит проверять. Тогда «добавить функцию» перестаёт быть автоматическим ответом на любую просьбу.

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

Как провести разбор без поиска виноватого

После слабого релиза легко устроить разбор в стиле «кто согласовал эту идею». От этого люди начинают защищать прошлые решения, а полезные факты исчезают. Мне ближе другой вопрос: какую гипотезу мы проверяли и что теперь о ней знаем? Он не снимает ответственности, но переводит разговор из личной оценки в работу с реальностью.

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

Полезно записать решение в одном предложении. Например: «Не развиваем конструктор до тех пор, пока не подтвердим, что финансовому менеджеру нужен именно самостоятельный отчёт, а не еженедельная подборка по шаблону». Такая запись оставляет команде память о причине. Через полгода идея может вернуться — и не придётся снова спорить, почему она уже выглядела очевидной.

В этом нет ничего стыдного. Продуктовая работа всегда состоит из ставок. Стыдно не ошибиться; невозможно. Дорого — не замечать ошибку, потому что релиз уже прошёл и кому-то неудобно признать, что пользователи выбрали другой путь.

Иногда проблема не в функции, а в запуске

Бывает и противоположная ситуация: решение действительно полезно, но команда выпустила его так, будто само присутствие новой кнопки всё объяснит. В сложном продукте этого почти никогда не хватает. Пользователь может не узнать о возможности, не связать её со своей задачей, не иметь права доступа или бояться испортить данные.

Тогда помогает не массовая рассылка с перечнем новинок, а конкретный сценарий. Кому эта возможность нужна? В какой день он с ней столкнётся? Что он увидит сначала? Как поймёт, что получил результат? Иногда достаточно показать готовый шаблон в нужном месте, добавить аккуратную подсказку или дать одному человеку пройти путь вместе с поддержкой.

Но обучение не должно быть оправданием плохого интерфейса. Если после короткого объяснения человек всё равно не может повторить действие сам, вернуться нужно к пути. Настоящая ценность не требует помнить инструкцию на десять шагов каждую неделю.

Что меняется в следующем релизе

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

Полезно заранее назвать, какой сигнал ждём после изменения. Если мы сделали шаблон, должны ли люди чаще завершать отчёт? Если переместили действие в карточку заказа, должны ли его использовать именно в момент работы с заказом? Без такого ожидания новый релиз рискует стать ещё одной версией на складе предположений.

Какие метрики здесь помогают

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

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

Вопросы перед следующей доработкой

• Какой последний реальный случай стоит за просьбой?
• Кто выполняет эту работу и в какой момент дня?
• Как он справляется сейчас и чего это ему стоит?
• Как будет выглядеть результат, ради которого стоит изменить привычку?
• Когда и по какому сигналу мы признаем гипотезу неверной?

Функция, которой никто не пользуется, не обязательно означает, что команда плохо работает или пользователь «неправильный». Чаще это честное столкновение гипотезы с реальностью. Если не прятать этот момент, он даёт продукту больше пользы, чем ещё одна галочка в списке релизов.

Хороший продукт развивается не от количества просьб. Он развивается от способности замечать, какую работу человек действительно пытается сделать, и вовремя менять решение, когда первоначальная догадка не сработала.