Что вы делаете, когда пользователь запрашивает функцию, которую вы не будете реализовывать?

10

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

Я написал приложение для iOS, и есть несколько пользователей, которые спрашивали меня о некоторых сложных функциях, которые я не могу сделать по причинам, изложенным выше. Большую часть времени я просто отвечал им, что «мы примем это во внимание». Объяснение им, что они в меньшинстве, которое хочет, чтобы эта функция тоже не помогла. Итак, что вы делаете в таком случае?


источник
4
Точно не ответ на ваш вопрос, но в вашем примере: вы можете легко иметь очень простой интерфейс и множество функций, скрывая расширенные параметры под чем-то вроде «расширенных параметров». Путь слишком много приложений , только сделать один или другой, совершенно излишне.
MGOwen
Вы не можете избежать неприятностей с опьяненными пользователями. Они где-то видели, и теперь они хотят это в своем приложении. Я пережил это слишком часто. Лучший вариант - вызвать два слова «Расписание» и «Стоимость».
Абхи
Поднимите мою цену, пока я не смогу утопить свою распродажу вины в запахе свежих зеленых спинок!
Эван
Положите его в очередь, приоритет = -1
ConditionRacer

Ответы:

12

Я думаю, что вы делаете правильные вещи. Вы не можете угодить всем, и вы не должны! Будьте вежливы и профессиональны, но вам не нужно делать все, о чем вас просят.

Г__
источник
9

Вам нужно прийти к компромиссу. Ваш пользователь (причина, по которой приложение существует) говорит, что оно не соответствует ни одной из его потребностей.

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

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

JohnFx
источник
2
Имеет смысл, если вы имеете дело с приложением, которое используют несколько пользователей (например, корпоративное приложение), но это излишне, если вы пытаетесь успокоить одного пользователя приложения iOS, у которого десятки тысяч других пользователей , Если вы будете тратить все свое время на попытки умиротворить 0,01% своих пользователей, вы сойдете с ума и обанкротитесь.
Муравей
1
Вы делаете много предположений там. Принципиально, что боль этого одного пользователя не передается другим. Еще один хороший способ разориться - игнорировать желания / потребности ваших клиентов.
JohnFx
6

Если вы прочитаете блог Сета Годинса ( http://sethgodin.typepad.com/ ), вы увидите, что одно и то же сообщение приходит снова и снова:

  1. Отправьте что-нибудь (и послушайте отзывы)
  2. Не пытайтесь угодить всем людям все время.

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

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

Простая / расширенная настройка - выход из положения. До точки. Это делает ваше развитие более сложным, хотя.

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

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

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

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

quickly_now
источник
2

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

В конечном счете, это принесет вам наибольшую пользу, я верю.

Пит
источник
1

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

Захари К
источник
1

Я обычно делаю три вещи, когда нахожусь в такой ситуации:

  1. Я дважды думаю, может ли идея пользователя быть хорошей идеей в конце концов. Я научился не доверять своему первому инстинкту. Иногда пользователь прав, а я не прав.
  2. Объясните пользователю, почему вы не можете включить эту функцию.
  3. Объясните пользователю, как она может достичь того, что ей нужно, с помощью программного обеспечения, которое у нее есть

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

nikie
источник
1

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

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

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

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

Док Браун
источник