Должны ли вы включить столь востребованную функцию, которая в корне неверна?[закрыто]

Question

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

Должны ли мы

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

Answer 1

Реализуйте его как подключаемый модуль.

• Это будет доступно для пользователей, которые действительно этого хотят, но коренным образом не изменит ваш продукт.
• Большинство пользователей в конечном итоге не установят его, поэтому ваша база поддержки будет меньше.
• Это не будет мешать пользователям, которые им не пользуются.

Answer 2

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

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

Answer 3

В "Мифическом человеко-месяце" (который вы читали, не так ли?) Брукс говорит слова о том, что "концептуальная целостность архитектуры - это самое важное".Это означает, что если запрашиваемая функция нарушает концептуальную целостность общего дизайна вашего продукта, вам, вероятно, следует продолжать избегать ее внедрения, независимо от того, насколько она востребована.Или вам нужно изменить архитектуру таким образом, чтобы запрашиваемая функция вписывалась в пересмотренную архитектуру.

Один из продуктов, над которым я работаю, имеет "очень востребованную функцию", которая была добавлена.Он ведет себя в отличие от любой другой функции продукта.Это ужасная бородавка.Но поскольку это делают конкуренты, мы должны были это сделать.Но вместо того, чтобы оставаться верными нашей архитектуре (которая в корне отличается от архитектуры конкурентов в этой области), мы подражали особенностям конкурса вплоть до глупых деталей.

Я все еще горько возмущен тем фактом, что эта функция была внедрена в систему со сломанной семантикой в отличие от остальной части продукта.Чтобы посыпать соль на рану, мне пришлось представить новую функцию нашей клиентской базе как "величайшую вещь со времен нарезки хлеба" - это действительно ранило.

Сказав это, никто не жаловался (как, я думаю, и следовало бы) на эту функцию.Вероятно, иногда к этому привыкают.Это еще одно отличие, которое конкуренты могут использовать против нас.

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

Это тяжело.Иногда рынок побеждает.

Answer 4

Ответить на этот вопрос почти невозможно, поскольку мы не знаем точно, о чем вы говорите.

Сказав это, некоторые моменты:

• Число пользователей, которым действительно нужна эта функция, вероятно, намного выше, чем вы думаете, поскольку большинство пользователей никогда не регистрируют отзывы.
• Вы описываете "обходной путь", это означает, что либо у вашего продукта есть проблема, либо его пользовательский интерфейс нуждается в изменении.

Я был бы склонен внедрить это, так как это сделает ваших клиентов счастливыми.

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

Answer 5

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

Answer 6

Хотя это и не вопрос программирования, я видел, как довольно много людей на протяжении многих лет боролись с такого рода проблемами.

Вам нужно задать себе несколько вопросов

1) Провели ли вы или руководство анализ затрат и выгод?Спросите себя "Как будет работать функция .."

• увеличить продажи?т. е.будет ли больше людей покупать это
• снизить продажи?т. е.потеря клиентов, которые откладывают
• повлиять на обслуживание клиентов?

2) Если продукт радикально изменится - имеет ли смысл выпустить из него совершенно новый артикул?

3) Руководство в конце концов получит то, что они хотят.Хотите ли вы работать с ними, чтобы предоставить своим клиентам наилучший опыт и быть героем, или против них и искать другие возможности?

Answer 7

Определите "наши пользователи".Это 5% вашей пользовательской базы, 80%, 95%?Достаточно ли вы опросили их, чтобы выяснить, является ли это тем, чего хочет подавляющее большинство пользователей, или это просто группа пользователей-мошенников (им может быть сложнее всего угодить).

Я думаю, что это должно быть установлено в первую очередь.Если это большая часть вашей пользовательской базы и это повышает ценность в их глазах, то я бы попытался достичь компромисса, при котором вы встречаетесь посередине, не ставя под угрозу целостность вашего продукта, но все же предлагая клиенту альтернативное решение, которое по-прежнему отвечало бы его потребностям.

Answer 8

Объявите об обходном пути как о решении запроса тем, кто его запросил.Сделайте обходной путь более заметным в пользовательском интерфейсе / более простым в использовании.

Answer 9

Я бы выбрал то, что имеет больший потенциал окупаемости инвестиций.Увеличите ли вы прибыль, внедрив эту функцию?Если да, превышает ли это стоимость поддержки новой функции?Если потенциальная прибыль превышает ваши расходы на поддержку, я бы предложил использовать эту функцию.

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

Answer 10

Я бы ограничился простым предположением о соотношении затрат (с точки зрения удобства использования) и выгоды, по крайней мере, в качестве основного фактора для взвешивания.Например, если функция, скорее всего, поможет 45% пользователей, но усложнит использование программы для остальных 55%, не делайте этого.