Робота з клієнтами, які не знають, чого хочуть

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

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

Кілька порад:

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

• Задайте питання . Коли ви закінчите задавати питання, запитайте ще кілька. Клієнти рідко зустрічаються з деталями, оскільки вони насправді не думають про це. Єдиний спосіб, коли ви збираєтеся отримати необхідну інформацію - це вилучити їх з них.

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

• Зв'язок є ключовим фактором . не просто говорити з клієнтом, отримувати інформацію, вибивати якийсь код і не говорити з ними, поки це не буде зроблено. Завжди підтримуйте контакт з клієнтом. Задавайте питання протягом усього процесу. покажіть їм досягнутий прогрес і отримайте відгуки. Це полегшить життя кожного в довгостроковій перспективі.

Практично будь-яка книга самодопомоги, яку ви підберете для спілкування, дасть вам певну варіацію цього:

• Шукайте спочатку зрозуміти, потім зрозуміти

Це походить із 7 книжок звичок, але всі вони є деякими варіантами методу " активного слухання ". Мета - не просто зрозуміти, а донести до них те, що ви зрозуміли.

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

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

Я відчуваю твій біль ....

Погана новина: залежно від того, з якими саме клієнтами ви маєте справу, це, як правило, бізнес.

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

Я мав епічний приклад цього трапитися пару років тому - проект, який спочатку потребував 10 тижнів, кодування перетворився на 15-місячну переробку повторної ітерації. У цьому випадку це було головним чином через те, що різні менеджери та відділи клієнтської компанії хотіли різних речей, тому вони продовжували надсилати роботу назад, підробляти та повторно налаштовувати (наше програмне забезпечення базується на підписці, і це був головний клієнт, тож це не було фінансової шкіри з нашої спини - просто велика технічна роздратованість насправді).

Тому в основному моя порада така:

Якщо це конкретно ваша галузь і ці клієнти (це великий ІФ), тоді просто звикайте до цього. Подумайте про це як про спритну роботу, орієнтовану на обслуговування (саме так, в моїй теперішній концерт, більш-менш). :)

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

Перш за все, ви повинні прийняти той факт, що клієнти насправді не знають, що шукають, поки не бачать. Вони можуть вам зараз сказати, що їм потрібна функція X. Покажіть їм функцію X, тоді вони зрозуміють, що те, що їм дійсно потрібно, є функцією Y або іншою варіацією функції X.

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

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

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

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

Однак мій досвід полягає в розробці додатків / платформ. На щастя, мені рідко доводиться стикатися з питаннями естетики, як це роблять веб-дизайнери.

Після багатьох дратівливих переписувань я зараз працюю над тим, що я називаю повним розкриттям.

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

Якщо його великий проект (більше, ніж скажімо, 5 днів роботи), я також буду прототипом. Це дає їм шанс змінити свою думку без масових змін коду в моєму кінці.

Це не завжди працює, але, принаймні, я знаходжуся в становищі, коли клієнт знає, що це вони передумують, а не я неправильно реалізую.