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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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