Як провести Discovery на новому проекті. Приклад:
- Oleh Voroniak
- 18 січ.
- Читати 8 хв
Життєвий шлях проекту починається з фази 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;
для діаграм та ментальних карт підійшов безкоштовний Google-додаток draw.io ;
прототипи - в 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 might we..?, то вкажемо і на проблему, і відкриємо можливість пофантазувати над її вирішенням. Наприклад, «How might we help clients get real time feedback from the system?». Записуєте їх.
Проводьте сесію мозкового штурму за списком "How might we..." питань. На цьому етапі підключаємо архітекторів та тих, хто хоче нам допомогти(QA/QC).
Створіть прототипи lo-fi, якщо це потрібно.
Створюєте Product Vision або Service Blueprint (або що вашій душі завгодно), що дозволить докладно та повно описати, як працює нинішній продукт та як працюватиме майбутній.
Складаємо roadmap.
Вигоди для команди:
Вірне уявлення про систему та її проблеми – перевірений народний засіб, щоб не зробити, що не треба.
Команда логічно, крок за кроком рухається у напрямку створення вимог.
Вигоди для відносин із замовником:
Суперечки пріоритетності завдань буде вирішено вже цьому етапі.
Замовник знаходить перше бачення майбутнього продукту, коли ще не написано жодного рядка коду і не намальовано жодної сторінки.
Що сталося насправді?
Стейкхолдерами стали: всі види зовнішніх користувачів - індивідуальні та організації; все backstage-команди, безпосередньо стикаються із зовнішніми користувачами під час своєї роботи.
Майже всі виявлені проблеми належали до:
процесів (наприклад, багато організацій, які звертаються до Х із заявками, вимагають особливого, нестандартного підходу; служба підтримки розривається між різними інструментами, впровадженими протягом багатьох років; складно швидко виявити термінову заявку);
зручності інтерфейсу;
комунікації;
технічним обмеженням системи;
людському фактору (розкривається #інтрига: користувачі користуються не тільки сайтом, але ще й надсилають свої заявки з вкладеннями просто по email або навіть наземною поштою. Скільки зусиль вимагає обробка таких заявок для компанії Х?).
Ми внесли всі проблеми у Decision Matrix. Вона будується на двох осях: Urgent – Not Urgent та Important – Not Important. Звісно, критичне значення має квадрант Urgent - Important.
Як ми описали інсайти за допомогою питання "How might we...": "Як допомогти клієнтам надсилати заявки тільки через сайт?", "Як допомогти клієнтам налаштувати спільну роботу над заявкою?" і таке інше.
Крок 5. Проведення інтерв'ю на виїзді
Сама організація є носієм унікальних бізнес-вимог до продуктів, якими користується. Тому дізнатися про бізнес-процеси, перебуваючи за її межами, складно.
Спілкуйтеся з представниками всіх функціональних відділів компанії, дивіться у їхніх моніторах і слухайте їхні коментарі. Дотримуйтесь ідеології Алана Купера: просіть розповісти, як минає їхній день, про що їхнє професійне спілкування в месенджерах, де вони стикаються з дефіцитом часу.
Можете знову скористатися interview cards, робіть записи, отримайте дозвіл робити аудіо- та відеозапис, якщо така можливість у компанії передбачена (часто заборонена).
Вигоди для команди:
Ви спілкуєтеся з кінцевими користувачами ентерпрайз-системи. Не потрібно в голові уявляти, що вони відчувають і чим дихають.
Зараз ваша команда як ніколи відчує себе в одному човні. У вас бачать майбутнє вирішення повсякденних проблем.
Вигоди для відносин із замовником:
Ви побачите самі: багато дій співробітників клієнтів монотонні або повторюються.
Якщо ви дбайливо поставитеся до того, чим компанія замовника користується зараз, це теж буде на вашу користь: багато хто з побоюванням ставиться до радикальних рішень. Навіть якщо ви можете аргументувати рішення почати все з нуля і побудувати щось нове, пам'ятайте: ваша аудиторія займається своєю роботою не перший рік, вона може сумніватися, що ви вивчили всі підводні камені їх діяльності. Це особливо важливо, якщо цей продукт розробляли штатні співробітники компанії. Покажіть повагу до їхнього продукту. Зрештою, те, що ви зробите в результаті, може так і залишитися незатребуваним, а наявні інструменти справляються. Ви це знаєте, і вони це знають.
Що сталося насправді?
Настав час нам перенестись до офісу компанії Х.
Backstage-користувачі – більше десятка різних відділів, через які проходять заявки. Багато заявок вимагають багатосторінкового перекладу чи регулярної зовнішньої експертизи — загалом завдань вистачає. У цьому функції у команд майже перетинаються.
Щодня було розписано на сесії. Ми поспілкувалися із представниками всіх відділів. Все, що вдалося записати, звели в одну таблицю, і вже після приїзду навели порядок.
Крок 6. Результати та артефакти дискавері backstage
На цей момент у ключовій команді з нашого боку залишився один дизайнер, але додався ще один бізнес-аналітик. Тепер можна було створити один із найважливіших артефактів Discovery — Service Blueprint.
Це діаграма, яку можна побудувати за принципами нотації BPMN.
Стейкхолдери: всі види зовнішніх користувачів - індивідуальних та організацій; всі backstage-команди.
Ми пішли своїм шляхом і розділили виявлені проблеми з походження. На цей раз не зводили проблеми в Decision Matrix. Усі вони все одно потрапили б у квадрант Urgent-Important.
Як ми описали інсайти за допомогою питання "How might we...": " Як допомогти користувачам швидше знаходити інформацію в системі?", "Як допомогти користувачам швидко і гладко перемикатися між контекстами?", "Як зменшити кількість ручного перенесення інформації в систему" ?» і таке інше.
Сесія мозкового штурму + ментальні карти за участю архітекторів та тестувальників.
У цей час стало ясно, що мета - об'єднати frontstage і backstage в одну платформу з однією точкою входу. Ментальні карти показували, що зробити хочеться багато (дуже багато). Вирішили піти шляхом створення Minimum Viable Product і подальшого його розширення.
Загальний backlog для наочності розтрощили завдання, глобальні для платформи та специфічні для frontstage та backstage. Так у MVP потрапили майже всі завдання для frontstage та половина глобальних.
Склали діаграму Гантта для перших місяців фази Delivery. Вона і стала основною roadmap'а проекту.
Висновок
Проведення фази Discovery проекту потребує часу та зусиль. Але, якщо діяти за планом, вона пройде гладко і без стресу. Discovery побудує фундамент взаємовідносин клієнта та вашої команди. Вона забезпечить кредит довіри, якщо замовник побачить уважне ставлення до проекту на його старті. Для дослідників це можливість проявити фантазію в необхідних напрямках.
А з погляду дизайну проведення фази Discovery — підтвердження, що основна робота дизайнера над проектом відбувається ще до прототипу або першої намальованої форми.
Джерело:
Коментарі