Необходимо ли включать очень требуемую функцию, которая является существенно неправильной? [закрытый]

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

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

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

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

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

I ' я буду склонен внедрять его, так как это сделает ваших клиентов счастливыми.

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

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

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

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

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

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

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

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

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

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

1) Есть ли у вас или менеджмент, сделали анализ затрат и выгод? Спросите себя: «Как эта функция…»

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

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

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

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

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

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

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

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

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