Як перенести клієнта з макетів інтерфейсу користувача на набір реальних вимог?

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

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

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

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

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

Ще вам можуть знадобитися:

• Описи використання або описи робочого процесу: Тільки тому, що ви знаєте, як виглядає екран, чи знаєте ви, як погано вводяться дані? Чи знаєте ви, як переходити між екранами у ВСІХ випадках? Ви також можете включити сюди обробку помилок.

• Опис системи на високому рівні: Дещо пояснює, для чого складається ця система, для чого ці 25 екранів, і що вони роблять.

• Модель даних: Чи можна зробити висновок моделі даних з цих екранів? Чи є модель даних, яку необхідно використовувати, чи ви вільні створити власну, щоб виконати роботу?

• Технічні вимоги: чи є конкретні технолігії, які повинні використовуватися через ліцензування або з інтеграційних причин?

• Вимоги до продуктивності: Якщо є екран пошуку, чи є очікування того, що можна шукати і наскільки швидкою має бути відповідь? Що щодо відповідей на інші види дій? Можуть чи повинні бути деякі з них асинхронні (користувач подає роботу та повертається пізніше)?

• Вимоги безпеки: Чи зберігає додаток потенційно чутливі / особисті дані, і якщо так, то які дані і що потрібно зробити, щоб захистити їх? Чи потрібно дотримуватися певного рівня відповідності (наприклад, відповідність PCI для здійснення платежів кредитною карткою)?

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

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

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

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

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

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

Я б просив:

Опис проблеми загального / високого рівня

Використовуйте випадки / розповіді користувачів

Вимоги до виконання

Необхідні технології / платформа (Windows, Linux, Web)

Все, що FrustratedWithForms має у своїй відповіді

Щось досягає 80% зусиль із розвитку, спрямоване на 20% випадків використання бахроми. Знімки екрана не розкажуть про випадки використання, таким чином ви опинитесь у темряві протягом 80% свого активного розвитку.

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

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

Ви не можете просто перекинути інформацію про стіну і розраховувати повернути всі свої сподівання та мрії у вигляді програмного пакету. Розробка програмного забезпечення просто не працює таким чином. Незалежно від того, чи є ви магазин Agile або водоспад, для успіху чи провалу проекту необхідне чітке керівництво клієнта.

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

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

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

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

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

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

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

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

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

Після того, як ви зрозумієте, які цілі, ви можете почати працювати з макетами дизайну інтерфейсу, які у вас є, і "інженером зворотного зв'язку" використовувати випадки та історії користувачів із них, виходячи з того, як різні екрани підходять один до одного. Формат розповідей користувачів, ймовірно, добре спрацює з нетехнічною аудиторією. Формат As a <user type>, I want to <action> so that <reason>працює з точки зору того, щоб розробники та клієнти / користувачі розмовляли однією мовою. Як тільки ви зможете почати користувацькі історії, я застосував би підхід до розробки прототипів.

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

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

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

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

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

Якщо у вас є якась ідея, спробуйте придумати приклади речей, які ви не знаєте, як зробити ("чи буде список шаблонів для вибору одним глобальним списком чи будь-який з них користувачем, або щось інше? Якщо це не користувачеві я повинен дозволити двом людям редагувати його відразу? Що повинен показувати інтерфейс користувача, якщо хтось інший редагує його? Чи є екран для цього? Після того, як хтось використовує шаблон для тих, що використовуються шаблони, а потім шаблон редагується чи повинна ця зміна поширюватися на те, що вони зробили за допомогою шаблону? ").

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

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

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

Потрібно знати межі та діапазони для кожного поля в додатку. Наприклад, якщо поле - це номер телефону, чи очікують вони, що ви обробляєте +1? Які поля обов’язкові для заповнення? Що вони хочуть, щоб програма робила, якщо користувач вводить "abc" у поле # телефону? Чи всі 25 екранів у тому порядку, з яким повинні перейти всі користувачі?

В іншому випадку просто створіть усе як текстові поля, і ви закінчите! Хочете зробити ставку на те, що перейде, як свинцевий куля?