Що робити, коли користувач запитує функцію, яку ви не реалізуєте?

Що робити, коли користувач запитує про складну функцію, яку ви могли б реалізувати, але ви цього не збираєтесь робити, оскільки 1) це додає зайвих складностей іншим користувачам 2) ви не збираєтеся робити це як варіант, оскільки ви не хочете, щоб панель налаштувань була складною.

Я написав додаток для iOS, і є кілька користувачів, які запитали мене про деякі складні функції, які я не можу зробити через вищезгадані причини. Більшу частину часу я просто відповідав їм, що "ми це врахуємо". Пояснення їм, що вони знаходяться в меншості, яка хоче цієї функції, також не допоможе. Отже, що ти робиш у такому випадку?

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

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

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

Перш за все: пам’ятайте, що додаток не існує, щоб полегшити ваше життя програмістом. Додаток є для обслуговування користувача.

Якщо ви прочитаєте блог Сет Годінса ( http://sethgodin.typepad.com/ ), ви побачите те саме повідомлення, що надходить знову і знову:

1. Надішліть щось (і послухайте відгуки)
2. Не намагайтеся весь час радувати всіх людей.

У мене з вами був подібний випуск із продуктом, який я продаю. У мене були всілякі запити на всілякі функції. Додаток став складнішим, ніж я дуже хотів. Кожен варіант додає складності, чого я хотів уникнути. І зараз у мене складніше, ніж хотілося б.

Це робить задоволення більшої кількості користувачів. І відганяє користувачів, які вважають, що це занадто важко налаштувати.

Наявність простого / розширеного налаштування - це вихід із прив'язки. До певного моменту. Однак це робить ваш розвиток складнішим.

У всіх випадках, коли я отримую запит, я завжди ввічливо відповідаю. Іноді я відверто відмовляюся, хоча це рідко. І де я це роблю, я пояснюю, чому, як правило, це було у відповідь на запит, який вимагатиме оновлення всього інтерфейсу, настільки масштабне завдання, що я просто не поїду туди. У цьому випадку я пояснюю свої причини, але дякую користувачеві за запит.

У ВСІХ випадках, включаючи ті, які я негайно відхиляю, я реєструю їх у базі даних функцій та дефектів для розгляду для наступного випуску. Це дає трохи більше часу, щоб подумати над усім цим, і, можливо, пізніше придумати альтернативу, що не саме те, що було запропоновано, але може додати певної вартості.

Якщо запит на функцію було розглянуто, анотовано, і остаточно (на час розробки) прийнято рішення про його вбивство, я закриваю його. Інакше вони залишаються відкритими для повторного розгляду пізніше.

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

Я думаю, що ви повинні бути чесними зі своїми користувачами. Не кажіть їм: "Ми це врахуємо", якщо ви вже вирішили, що цього не зробите. Це змусить користувачів повірити, що ця функція з’явиться колись і розчарується, оскільки вона ніколи не з’являється.

Зрештою, я вважаю, що це виграє вам найбільше.

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

Зазвичай я роблю три речі, коли знаходжусь у такій ситуації:

1. Думаю двічі, чи може ідея користувача все-таки бути гарною ідеєю. Я навчився не довіряти своєму першому інстинкту. Іноді користувач має рацію, а я помиляюся.
2. Поясніть користувачеві, чому ви не можете включити цю функцію.
3. Поясніть користувачеві, як вона може досягти того, що їй потрібно за допомогою програмного забезпечення, яке вона має

Я думаю, що останній пункт є найважливішим. Більшість користувачів не хочуть , щоб їх пропозиції були реалізовані. Їм просто потрібно вирішити проблему, і вони пропонують найпростіше можливе рішення, яке вони можуть придумати. Можливо, ви зможете знайти краще рішення, яке зможете реалізувати.

Для кожної нашої продукції у нас є "список ідей для майбутніх версій". Тож, що ми говоримо нашим користувачам, це "ми внесемо вашу пропозицію до цього списку" - і це чесно, ми це робимо.

У списку немає пріоритетів, але ми регулярно вибираємо речі з нього та використовуємо їх для подачі наших відстаючих. Ми не приймаємо їх «по порядку», натомість намагаємось визначити, які ідеї дають «найбільше грошей на долар» - найбільшу користь для якомога більшої кількості наших користувачів, за розумні зусилля з розробки.

Запити на характеристики проти концептуальної цілісності продукту, ймовірно, залишаться там назавжди. Але іноді трапляється, що принаймні деякі ідеї, поховані в цих запитах на функції, можуть бути реалізовані, можливо, не зовсім так, як думав той, хто запропонував це, але таким чином, який краще вписується в архітектуру продукту.

Тож моя пропозиція тут: не кажіть просто "Ми це врахуємо". і забудьте цю ідею, як тільки закінчите телефонний дзвінок. Натомість майте інструмент, де ви зберігаєте ідеї та запити щодо функцій, можливо, у трекері випусків, можливо, у Вікі, можливо, у електронній таблиці, що найкраще відповідає вашим потребам.