Дозволити користувачам збирати вимоги самостійно або направляти їх?

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

1) Скажіть користувачам: "Гаразд, я не можу щось створити для вас, якщо ви навіть не можете це описати. Чому ми не збираємося разом через кілька тижнів, коли ви знаєте, що вам потрібно".

2) Зустріньтесь з користувачами кілька разів і допоможіть їм зрозуміти, чого вони хочуть, провівши їх за допомогою хорошого сократівського методу. "Вам потрібно відстежувати X?", "Як щодо Y?", "Вам потрібна функціональність Z?"

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

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

Я мушу визнати, що іноді вибираю варіант 3)

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

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

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

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

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

Приблизно та сама проблема, що була згадана вище (№3), і проблема, яка залишає вам все одно робити №2.

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

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

ДОПОЛНЕННЯ: цей процес називається "аналіз систем та проектування" aka Consulting, і його ніколи не слід робити безкоштовно

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

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

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

Справжня майстерність полягає у виборі правильного підходу в потрібний час.

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

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

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

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

Але здобути цю майстерність - це майже форма мистецтва, особливо коли домен не пов'язаний з інженерною дисципліною. Ваші очевидні запитання можуть здатися загрозливими для замовника, ваша присутність in situ може бути непотрібною, ваше нерозуміння соціальної структури вашої цільової аудиторії може порушити ще неміцні зв’язки.

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

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

У будь-якому випадку: переписування фрагмента коду ніколи не переважає перед написанням вимог.

ps, можливо, ви думаєте, що я виступаю за метод водоспаду. Я не вірю у "великий дизайн наперед", але я вважаю, що зусилля з аналізу домену повинні бути пропорційні зусиллям щодо впровадження. Можна зробити кілька циклів (прототип, випуск кандидатів тощо).

Однозначно варіант 2, якщо ваші користувачі не розробники (навіть тоді варіант 2 може знадобитися).

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

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

Ви не хочете стрибати у Варіант №2, коли вони ледве можуть сформулювати те, що хочуть, оскільки це зробить весь процес повільнішим та більш засмучуючим (якщо тільки вони вже не мають чіткого уявлення про те, що хочуть, коли прийдуть до вас, але на мій досвід це дуже рідко). Змусьте їх збирати свої ідеї разом. Запропонуйте їм написати щось на папері, по можливості опишіть, що вони хочуть у існуючих системах (наприклад, "ми хочемо, щоб веб-сайт, наприклад, blahblah.com, але з цими відмінностями ... нам потрібен інструмент, який виконує завдання" Як продукт X " , але користувальницький інтерфейс також повинен виконувати завдання B ... "). Тоді настав час почати вдосконалювати те, що вони хочуть, у дуже конкретні вимоги, які ви можете використовувати для побудови системи.

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

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

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

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

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

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

По-друге, користувачі не обов'язково знають, що їм потрібно, і зазвичай не знають, чого хочуть, в будь-якому діючому сенсі.

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

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