Як провести Discovery на новому проекті: конкретні кроки і приклади

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

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

Життєвий шлях проекту починається з фази Discovery і переходить у фазу Delivery.

В рамках Discovery ми:

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

Є початкові умови, які дозволять провести Discovery:

довіра замовника;
його бажання йти вам назустріч заради гарного результату;
відносна свобода термінів.

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

Немає єдиної схеми, як провести діскавері, але є ефективні сценарії. Наприклад, Double Diamond дизайн-процес:

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

Що відбулося в реальності?

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

Frontstage:загальнодоступний сайт для зовнішніх користувачів.
Backstage:важке desktop-програма + система зберігання і обробки документів співробітниками компанії Х. На backstage діє безліч ролей, його завдання — опрацювати заявки користувачів, що прийшли з frontstage... або якось ще (інтрига).

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

Наша команда: два дизайнера і бізнес-аналітик. Пізніше до нас приєдналися архітектори та інженери з якості.

Крок 1. Discovery Initiation

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

Це найлегший етап, але краще їм не нехтувати.

Вигоди для команди:

Замість насувається гори завдань команда отримує приблизний план, що робити і чого не робити.
З іншого боку, план дисциплінує і задає планку якості: «Ми зробимо це і це, зробимо так, і так. Ми будемо орієнтуватися на артефакти до самого релізу проекту».

Вигоди для відносин з замовником:

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

Що відбулося в реальності?

Вирішили робити короткі спринти за 4-5 днів з щоденними статус-мітингами. Що стосується інструментів:

завдання зберігали в Trello;
користувалися interview cards;
записували інтерв'ю та сесії навчання дефолтних для маку QuickTime Player;
для діаграм і ментальних карт підійшло безкоштовне Гугл-додаток ;
прототипи — Sketch (планували ще Axure і inVision).

Крок 2. Вивчаємо матеріали віддалено

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

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

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

Що стосується backstage, той самий очевидний спосіб ознайомитися з ним — дізнатися, як його освоюють новачки компанії. Якщо ними займається «спеціально навчена людина» — відмінно, ви його чергові падаваны. Часто в компаніях є і навчальні матеріали: інструкції, база знань і відеоуроки.

Вигоди для команди:

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

Вигоди для відносин з замовником:

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

Що відбулося в реальності?

Frontstage

Підтримка сайту надала .csv файл ~13 000 звернень за останні 3 роки. Перша пара тисяч записів показала: типових проблем — не більше п'яти. Наприклад, крім банального відновлення пароля, у разі колективної заявки користувачі не могли додати своїх колег. Ця функціональність на сайті є, але, очевидно, розібратися з нею нелегко.

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

Backstage

Новачкові потрібно в середньому 6 місяців (!), щоб розібратися з backstage-системою. Клієнт надав нам їх стандартне навчальне відео. Роликів було небагато, та враховуючи загальний строк адаптації, погоди вони не роблять.

Можна припустити, що поточний backstage — це монстр. Але ні, система відмінно виконує свої функції, багато з яких дуже специфічні для роботи всієї організації. 15 років розробки народжують продукт, ювелірно налаштований на все зустрічаються завдання. Але це desktop-програма, яка не адаптується під окремі ролі. Ви дивитеся на інтерфейс і бачите десятки контролів, про яких краще відразу забути, тому що будете користуватися тільки п'ятьма-шістьма. Щоправда, в кожній конкретній ситуації, таких інтерфейсів буде багато, і на кожному будуть вони — десятки непотрібних контролів.

Крок 3. Проведення віддалених інтерв'ю

Розуміє клієнт із задоволенням запропонує вам список кандидатур для інтерв'ю. Якщо ні, попросіть його самі.

Навіть саме віддалене уявлення про функції перелічених людей дозволить скласти «interview cards». Це загальні питання про роботу, які так чи інакше доведеться поставити. Завжди залишайте місце на картці для уточнень або інформації, яку не можна було передбачити.

Вигоди для команди:

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

Вигоди для відносин з замовником:

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

Що відбулося в реальності?

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

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

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

На цьому етапі було вирішено розділити наше дослідження на два етапи: спочатку Discovery frontstage-сайту, а потім — backstage-системи.

Крок 4. Результати і артефакти discovery frontstage

Повторюся: інтерв'ю з кінцевими користувачами дуже корисно. І повноцінного Discovery без них не вийде.

Припустимо, ви провели інтерв'ю і почали орієнтуватись у сфері бізнесу замовника. Як структурувати отриману інформацію?

Визначте стейхолдеров продукту.
Виділіть головні проблеми користувачів (pain points). Може бути корисно їх класифікувати за походженням.
Призначте пріоритет кожної проблеми.
Згадаємо схему Double Diamond. Кожна проблема є запитом на поліпшення (opportunity). Якщо почати питання «How we might..?», то вкажемо і на проблему, і відкриємо можливість пофантазувати над її вирішенням. Наприклад, «How we might help clients get real time feedback from the system?». Записуєте їх.
Проводите сесію мозкового штурму за списком «How we might...» питань. На цьому етапі підключаємо архітекторів і співчуваючих (QA/QC).
Створюєте lo-fi прототипи, якщо це потрібно.
Створюєте Product Vision або Service Blueprint (або що вашій душі завгодно), що дозволить детально і повно описати, як працює нинішній продукт і як буде працювати майбутній.
Складаємо roadmap.

Вигоди для команди:

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

Вигоди для відносин з замовником:

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

Що відбулося в реальності?

Стейкхолдерами стали: всі види зовнішніх користувачів — індивідуальні та організації; всі backstage-команди, безпосередньо стикаються з зовнішніми користувачами в ході своєї роботи.

Майже всі виявлені проблеми ставилися до:

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

Ми внесли всі проблеми в Decision Matrix. Вона будується на двох осях: Urgent — Not Urgent і Important — Not Important. Само собою, критичне значення має квадрант Urgent — Important.

Як ми описали інсайти з допомогою питання «How we might...»: «Як допомогти клієнтам надсилати заявки тільки через сайт?», «Як допомогти клієнтам налаштувати спільну роботу над заявкою?»і так далі.

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

З цим ми прибули в офіс замовника за підтвердженням того, що Discovery йде в правильному напрямку. На цьому ми припиняємо його. Тепер пора взятися за backstage і створити артефакти, які з'єднають обидві системи.

Крок 5. Проведення інтерв'ю на виїзді

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

Спілкуйтеся з представниками всіх функціональних відділів компанії, дивіться в їх монітори і слухайте їх коментарі. Дотримуйтесь ідеології Алана Купера: просите розповісти, як проходить їх день, про що їх професійне спілкування в месенджерах, де вони стикаються з дефіцитом часу.

Можете знову скористатися interview cards, робіть записи, отримаєте дозвіл робити аудіо - і відеозапис, якщо така можливість в компанії передбачена (часто — заборонена).

Вигоди для команди:

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

Вигоди для відносин з замовником:

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

Що відбулося в реальності?

Настав час нам перенестися в офіс компанії Х.

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

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

Крок 6. Результати і артефакти діскавері backstage

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

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

Стейкхолдери: всі види зовнішніх користувачів — індивідуальних і організацій; всі backstage-команди.

Ми пішли по уторованому шляху і розділили виявлені проблеми за походженням. В цей раз не зводили проблеми в Decision Matrix. Всі вони все одно потрапили б в квадрант Urgent — Important.

Як ми описали інсайти з допомогою питання «How we might...»: «Як допомогти юзерам швидше знаходити інформацію в системі?», «Як допомогти юзерам швидко і легко перемикатися між контекстами?», «Як зменшити кількість ручного перенесення інформації в систему?»і так далі.

Сесія мозкового штурму + ментальні карти з участю архітекторів і тестувальників.

В цей час стало ясно, що мета — об'єднати frontstage і backstage в одну платформу з однієї точки входу. Ментальні карти показували, що хочеться зробити багато (дуже багато). Вирішили піти по шляху створення Minimum Viable Product і подальшого його розширення.

Загальний backlog для наочності розбили на завдання, глобальні для платформи і специфічні для frontstage і backstage. Так в MVP потрапили майже всі завдання для frontstage і половина глобальних.

Склали діаграму Гантта для перших місяців фази Delivery. Вона і стала основною roadmap'а проекту.

Висновок

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

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

Опубліковано: 17/09/18 @ 10:15
Розділ Різне

SEO Блог