Чи повинен програміст "думати" для клієнта?

Я дійшов до того, що я ненавиджу збирання вимог. Клієнти занадто розпливчасті для власного блага. У спритному середовищі, де ми можемо показати клієнтові роботу до завершення, це не дуже погано, оскільки ми можемо робити невеликі регулярні виправлення / оновлення функціональності.

У типу "водоспад" в оточенні (спочатку потрібно вимоги, майже повний продукт далі) речі можуть стати некрасивими. Таке середовище змусило мене постійно ставити під сумнів вимоги. EG Замовник хоче "автоматично перетворити вхід на номер 1" (з посиланням на Qty в порядку). Але те, про що вони не думають, - це те, що "введення" може бути простим типом. "Х" у текстовому полі може бути "шерстю", я не хочу 1 з цих продуктів "зубної пасти". Але в повітрі так багато вимог, що я могла стояти і виправлятись годинами, розбиваючи те, що вони хочуть. Це просто не здорово.

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

Як можна впоратися з проблемою «мислення для клієнта», не маючи їх занадто багато питань?

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

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

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

Настійно рекомендую працювати шматками. При зустрічі з клієнтом висувайте набір вимог, пов'язаних один з одним, а потім поясніть, як ви маєте намір робити те, що вони хочуть. Також поясніть, чому ви зробили свій вибір. Потім замовник може подивитися на те, що ви надали, і налагодити це. Якщо ви отримаєте відповідь на кшталт "Я ніколи про це не думав, але це справді допоможе", ти знаєш, що ти маєш пульс щодо того, як думає клієнт. ПРИМІТКА: що це не футурити, це вибір правильних функцій, які найкраще відповідають бізнес- проблемі, яку має клієнт.

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

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

Якщо ви їх "писаєте" від занадто багатьох питань, знайдіть кращого клієнта.

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

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

Прочитайте це для отримання додаткової інформації: http://www.joelonsoftware.com/articles/fog0000000356.html

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

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

Якщо ви збираєтеся вимоги, то ваша робота задавати ці питання.

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

Побічним ефектом цього є те, що вам слід допомогти клієнту вдосконалити його вимоги.

Це стосується того, чи робите ви великий дизайн вперед або Agile.

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

У мене були обидва можливі результати:

• замовник задоволений тим, що ви насправді думаєте про те, що він вам каже, він відчуває, що перебуває у правильних руках, або

• клієнт роздратований, тому що ви змушуєте його знову задуматися про його вимоги. Але тоді цей тип клієнтів рано чи пізно буде дратувати вас. Він, безумовно, буде дуже роздратований, якщо пізно дізнається, що ви не думали про нього на початку. Я б сказав: уникайте такого типу клієнтів, якщо можливо :-)

Швидка розробка додатків (RAD) вирішує цю проблему найкращим чином .

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

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

Основна проблема BFUD (Big Up Front design) полягає в тому, що він ізолює розробника від вини, змушуючи замовника укласти договір, який чітко описує, що вони збираються отримати. І на жаль, це робиться в той час, коли ніхто в проекті не має гарного уявлення про те, що дійсно потрібно. Врешті-решт, це просто змушує замовника прийняти те, що ви побудували, тому що він підписався, але з грубою надією.

Якщо замовник не задоволений результатами поставки, це лише перемога пір.

Завдання замовника - передати вам те, що їм потрібно. Ваше завдання - зрозуміти, що їм потрібно досить добре, щоб мати можливість програмувати те, що їм потрібно. Очевидним питанням щодо зміни всіх вхідних даних до одного було б сказати "Чому ви хочете, щоб він змінив весь вхід на 1?" Тоді замовник може пояснити свої міркування, щоб ви зрозуміли потребу, а потім зможете надати не обов’язково те, що вони просять, а те, що їм потрібно. Якщо ви впевнені, що знаєте, що їм потрібно, то я не думаю, що вам обов'язково потрібно «виправляти» свою думку. Вони використовуватимуть продукт і тему "О, це ідеально". Але якщо ви не впевнені, що знаєте, що їм потрібно, вам потрібно буде пояснити, що ви думаєте, і розібратися з замовником. На жаль, там ' s ніякий спосіб виконати цю частину процесу з великою кількістю зв'язку, яка передбачає реальне прослуховування обох частин. Будьте обережні, щоб роздратуватися над ситуацією та сказати те, що ви можете чи не дуже хочете сказати.

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