Стоит ли включать столь востребованную функцию, которая в корне неверна?
В нашем основном продукте у нас есть запрос на функцию, который был в течение нескольких лет, который запрашивался довольно много раз. Его технически легко реализовать, проблема в том, что он в корне изменит концепцию того, что делает инструмент, и, вероятно, вызовет больше сообщений об ошибках, так как люди неправильно используют новую функцию, чтобы соответствовать новой концепции (которую мы не сможем обойти). У нас есть отдельная функция, которая хорошо справляется с этой проблемой, но мы по-прежнему получаем запросы на реализацию новой.
Должны ли мы
- прислушивайтесь к нашим пользователям и внедряйте новую функцию, даже если она меняет представление о том, что делает продукт и что мы хотим от него, и увеличивает расходы на поддержку
- добавить еще несколько статей поддержки, объясняющих, как использовать обходной путь
- сделать обходной путь более очевидным в пользовательском интерфейсе, чтобы пользователи чаще находили его
- что-то другое
10 ответов
Реализуйте это как плагин.
- Он будет доступен для пользователей, которые действительно этого хотят, но не будут принципиально менять ваш продукт.
- Большинство пользователей не будут устанавливать его, поэтому ваша база поддержки будет меньше.
- Это не помешает пользователям, которые его не используют.
В "Мифе о мифическом человеке" (который вы прочитали, не так ли?) Брукс произносит слова о том, что "концептуальная целостность архитектуры - это самая важная вещь". Это означает, что если запрошенная функция нарушает концептуальную целостность общего дизайна вашего продукта, вам, вероятно, следует продолжать избегать ее реализации, независимо от того, сколько она запрашивается. Или вам нужно изменить архитектуру так, чтобы запрошенная функция вписывалась в пересмотренную архитектуру.
Один из продуктов, над которым я работаю, имеет "очень востребованную функцию", которая была добавлена. Он ведет себя не так, как любая другая функция продукта. Это ужасная бородавка. Но так как соревнование делает это, мы должны были сделать это. Но вместо того, чтобы оставаться верным нашей архитектуре (которая в корне отличается от конкурентов в этой области), мы добавили в нее особенности конкурса, вплоть до глупых деталей.
Я все еще горько возмущаюсь тем фактом, что эта функция была загружена в систему с нарушенной семантикой по отношению к остальной части продукта. Чтобы втирать соль в рану, я должен был представить новую функцию как "величайшую вещь после нарезанного хлеба" для нашей клиентской базы - это действительно больно.
Сказав это, никто не жаловался (как я думаю, что они должны) о функции. Наверное, иногда привыкаешь. Это еще одно отличие, которое соревнование может использовать против нас.
(И обратите внимание: я был не против того, чтобы функция была реализована в стиле, совместимом с обычным способом работы нашего продукта; я была только против того, чтобы она была реализована в стиле, используемом нашим конкурентом - потому что другие связанные функции работают аналогично сломанной реализации в их системе, тогда как наша система более вменяема и дружелюбна.)
Это тяжело. Иногда рынок побеждает.
Если эта функция противоречит философии вашего продукта, это означает, что продукт не соответствует ментальной модели ваших пользователей. Последствия этого намного больше, чем просто отсутствующая особенность. Вам нужно проникнуть в головы пользователей и выяснить, как приспособить вашу модель к их ожиданиям или направить их ожидания к вашей модели.
Достаточно подумать об этом, и это может стать отличной возможностью для вас.
На это почти невозможно ответить, так как мы не знаем точно, о чем вы говорите.
Сказав, что некоторые моменты:
- Число пользователей, которым действительно нужна эта функция, вероятно, намного выше, чем вы думаете, так как большинство пользователей никогда не будут регистрировать отзывы.
- Вы описываете "обходной путь", это подразумевает, что у вашего продукта либо есть проблема, либо необходимо изменить его интерфейс.
Я был бы склонен осуществить это, поскольку это сделает Ваших клиентов счастливыми.
Один из вариантов - дать им пункт меню, который направляет их к обоим методам.
Возможно, какой-нибудь мастер, который поможет им решить, какой обходной путь использовать.
Хотя это и не вопрос программирования, я видел, что за эти годы многие люди боролись с этим типом проблем.
Вам нужно задать себе несколько вопросов
1) Проводили ли вы или руководство анализ затрат и выгод? Спросите себя "Как будет функционировать.."
- увеличивать объем продаж? т.е. будет больше людей покупать его
- уменьшить продажи? т.е. потеря клиентов, которые откладываются
- повлиять на обслуживание клиентов?
2) Если продукт радикально изменится - имеет ли смысл выделять его на весь новый SKU?
3) Менеджмент получит то, что хочет в итоге. Хотите ли вы работать с ними, чтобы предоставить своим клиентам наилучший опыт и быть героем или против них и искать другие возможности.
Я бы попытался изменить дизайн пользовательского интерфейса, чтобы сделать его более понятным для пользователей. В конце дня клиент оплачивает счета, чтобы у нас была обязанность удовлетворить их потребности. Когда то, о чем они просят, вызовет больше проблем, мы возвращаемся к тому, чтобы предложить другое решение, чтобы мы не создавали больше ошибок в будущем, и мы все еще оставляли клиентов довольными.
Я бы пошел с тем, что имеет более потенциальную рентабельность инвестиций. Будете ли вы увеличивать прибыль за счет реализации этой функции? Если да, то превышает ли это стоимость поддержки новой функции? Если потенциальная прибыль больше, чем ваша стоимость поддержки, я бы предложил использовать эту функцию.
Если нет никакой выгоды, которая может быть достигнута ни в финансовом отношении, ни путем снижения затрат на поддержку, то нет смысла делать это.
Объявите обходной путь как решение для запроса тем, кто запросил это. Сделайте обходной путь более заметным в пользовательском интерфейсе / проще в использовании.
Определите "наших пользователей". Это 5% от вашей базы пользователей, 80%, 95%? Достаточно ли вы опросили их, чтобы выяснить, действительно ли это то, что нужно подавляющему большинству пользователей, или это просто мошенническая группа пользователей (они могут быть самыми трудными и трудными для удовлетворения).
Я думаю, что это должно быть установлено в первую очередь. Если это большая часть вашей пользовательской базы и это добавляет им ценность, то я постараюсь найти компромисс, где вы встретитесь посередине, не ставя под угрозу целостность вашего продукта, но все же предлагая клиенту альтернативное решение, которое все равно удовлетворить их потребности.
Я бы сделал простое предположение о стоимости (с точки зрения юзабилити) в сравнении с выгодой, по крайней мере, в качестве важного фактора. Например, если эта функция, вероятно, поможет 45% пользователей, но усложнит использование программы для остальных 55%, не делайте этого.