+38 (093) 717 34 58
Інтерв’ю зі стейкхолдерами

Інтерв’ю зі стейкхолдерами

Найближча онлайн-практика 19 Грудня о 11:00

Про тренерку:

Іста Чебан
Іста Чебан
Product Designer, Kyivstar

  • Працювала у USABILITYLAB, Ista.space, 24Print
  • Займається впровадженням підходу продуктового дизайну в командах, проєктуванням інтерфейсів, дослідженнями

Кому підійде:

  • Дизайнерам
  • Дослідникам
  • Менеджерам
  • Загалом усім, хто задіяний у створенні продукту

Що будемо робити:

  • Навчимося будувати діалог із замовником та командою
  • Сформуємо очікування про фінальний результат проєкту
  • Поставимо метрики та домовимося про механізми співпраці
  • Створимо артефакт для початку роботи над проєктом

Розклад:

11:00
Знайомство та підготовка

13:00
Перерва

14:00
Проведення інтерв'ю

16:00
Фідбек-сесія

Інтро

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

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

На інтерв’ю ви:

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

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

Практика
Структура

Існує базовий набір питань, які ви маєте розглянути під час інтерв’ю:

  • Команда
  • Ціль проекту
  • Монетизація
  • Цільова аудиторія
  • Метрики
  • Завдання бізнесу, дослідника, дизайнера і розробника
  • Формат результату роботи
  • Ресурси і обмеження
  • Ризики

Користь цього набору питань:

1. У вас сформується певне розуміння проєкту: хто, що, чому, що це за проєкт;

2. Ваш замовник буде чіткіше бачити і розуміти сутність проєкту;

3. Ви зможете поставити запитання бізнесу на рівні бізнесу;

4. Замовник зрозуміє, що ваша ціль — допомогти його компанії досягнути мети, а не просто намалювати гарну картинку;

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

А тепер розберемо кожне питання окремо:

1. Команда

  • Узгодьте наступні питання:

Хто бере участь у проєкті?

Які основні учасники?

Як ви будете з ними взаємодіяти?

Які аспекти проєкту необхідно узгоджувати і з ким?

Наприклад, ви берете участь у розробці сайту. Хто на проєкті маркетолог, SEO спеціаліст, delivery manager, розробник? Як можна з ними сконтактувати? Які є їхні вимоги до проєкту, які обмеження?

  • Ризики (що станеться, якщо цього не узгодити):

У вас може з’явитись замість 1 замовника – 10. Кожен буде вносити свої правки. Вам буде незрозуміло, чиї рекомендації виконувати. Процес може затягнутись.

  • Застосування:

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

2. У вас буде перелік контактів усіх учасників проєкту;

3. У вас будуть прописані зони відповідальності для кожного учасника. Ви будете знати, до кого звертатись в кожному конкретному випадку.

2. Мета

  • Узгодьте наступні питання:

Що хоче отримати бізнес завдяки проєкту?

  • Важливо пам’ятати:

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

  • Зазвичай бізнес переслідує одну або декілька цілей:

Збільшення прибутків;

Оптимізація процесів;

Скорочення витрат;

Тестування, дослідження або експеримент (нової фічі, моделі роботи тощо).

  • Ризики (що станеться, якщо цього не узгодити):

Ви витратите час на виконання непотрібних дій;

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

Різним учасникам команди буде складно домовитись, бо вони по-різному будуть бачити ціль.

  • Застосування:

Ви розумієте, на чому необхідно фокусуватись в роботі;

Ви зможете говорити з замовниками їхньою мовою, обґрунтувати свої рішення потребами бізнесу;

Ви валідуєте свою задачу і розумієте, чи пов’язана вона з досягненням мети бізнесу.

  • Важливо:

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

3. Монетизація

  • Узгодьте наступні питання:

На чому заробляє бізнес?

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

  • Застосування:

Полегшує комунікацію із замовником;

Допомагає підтримувати правильний фокус роботи.

4. Цільова аудиторія

  • Узгодьте наступні питання:

Хто буде використовувати додаток, фічу, сайт — те, що ви створюєте?

  • Важливо пам’ятати:

Інколи бізнес може цього не знати. В цьому разі ви можете запропонувати йому провести дослідження і аргументувати його доцільність.

5. Метрики

  • Узгодьте наступні питання:

Як ми зрозумієте, що задача/проєкт виконані успішно? Добре працює?

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

  • Застереження:

Інколи бізнес некоректно розуміє або взагалі не розуміє слово метрики(!). Тому варто бути обережними з цим терміном, інакше ризикуєте отримати некоректні відповіді.

  • Застосування:

Клієнт розумітиме, що для вас важливо отримати гарний результат роботи;

Чітко сформульовані очікування вбережуть вас від конфліктів і непорозумінь по завершенню проєкту.

  • Важливо пам’ятати:

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

6. Завдання бізнесу

  • Узгодьте наступні питання:

Що буде робити бізнес для реалізації цілей проєкту, для втілення ідеї в життя?

  • Застосування:

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

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

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

7. Завдання дослідника

  • Узгодьте наступні питання:

Що нам варто з’ясувати, щоб досягти результату, реалізувати проєкт максимально ефективно?

Чи є у замовника певні сумніви, питання, прогалини в знаннях, які треба заповнити?

Наприклад, бізнес може розуміти, хто їх ЦА, але не знати, як покупці приймають рішення про покупку і чому обирають той чи інший продукт.

  • Застереження:

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

  • Застосування:

Формує розуміння необхідності дослідження у клієнта.

8. Завдання дизайнера

  • Узгодьте наступні питання:

Яку задачу замовник хоче, щоб ви виконали?

Чи допоможе виконання цієї задачі досягненню мети?

  • Важливо пам’ятати:

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

Наприклад, бізнес хоче, щоб ви спроєктували інтерфейс або провели інтерв’ю.

  • Застосування:

Замовник починає краще розуміти, що він хоче від вас, і що він це отримає;

Ви розумієте, що конкретно хоче отримати від вас замовник;

Ви можете визначити обсяги роботи і необхідних для її виконання ресурсів.

9. Формат результату роботи

  • Узгодьте наступні питання:

В якому форматі замовник отримає від вас результаті?

  • Наприклад:

    Поговоримо про формат кікофу:

    В першу чергу, kickoff meeting – це зустріч. Не листування, не чат.

    Це може бути відеоконференція. Однак, усі камери повинні бути обов’язково увімкнені. Вам необхідно бачити, що усі залучені в процес. Тому домовтеся про це заздалегідь.

    Тривалість і обсяг питань

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

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

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

    Стейкхолдери

    На цій зустрічі повинні бути присутні:

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

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

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

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

    В будь-якому випадку, ваша робота і результат будуть не ефективні. Відносини зі стейкхолдером зіпсуються. А довіра до вас, як до спеціаліста, підірвана.

    Як проводити зустріч

    • Будьте сміливі, говоріть впевнено, це допоможе всім учасникам налаштуватись на роботу і бути зібраними;
    • Краще здаватися не обізнаним та нудним на kickoff, ніж створювати не робочі рішення;
    • Допомагайте один одному в процесі;
    • Один запитує — інший фіксує відповіді;
    • Один розгубився — інший допомагає;
    • Заохочуйте всіх учасників зустрічі до роботи в Miro;
    • Попросіть їх записати, наприклад, те, за що кожен відповідальний і з якими питаннями можна до нього звертатись.

    Початок розмови

    — Вітаю, мене звуть “Олександр”, зі мною в команді “Ліза” та “Віталій”.

    — Наша задача на сьогодні разом навчитись проводити kickoff.
    — Перед тим, як ми почнемо — давайте познайомимось.
    — Давайте по черзі скажемо, як вас звати та які ролі в команді ви займаєте і потім я розкажу, що сьогодні буде відбуватись.
    — Відповіді учасників команди.
    — Раді з вами познайомитись.

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

    Документ

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

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

    Важливо пам’ятати: зафіксовані в документі домовленості можна буде змінювати потім з потреби, однак, у вас буде підстава змінити термін виконання і ціну. Ви домовлялись про один вид робіт, а тепер потрібен зовсім інший.

Макет;

Записи юзер-тестів, які показують, що рішення ефективно працює за визначеними метриками;

Результати інтерв’ю, якщо це research-прокет.

  • Ризики:

Замовник не зможе використати результат вашої роботи;

Вам доведеться перероблювати;

Ви втратите замовника, час, гроші.

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

10. Ресурси та обмеження

Ресурси – це будь-які матеріальні та нематеріальні об’єкти, а також індивіди, які можна застосувати для роботи по проєкту.

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

  • Обмеження:

Будь-які обставини, які безпосередньо впливають на роботу проєкту, встановлюють певні рамки та вимоги, унеможливлюють певні роботи.

Наприклад: час, законодавство, доступність стейкхолдерів, експертів, юзерів.

  • Узгодьте наступні питання:

Які є ресурси для виконання проекту?

Які є вимоги учасників до проекту?

Які є обмеження?

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

  • Застосування:

Ви зрозумієте, чи зможете працювати в цих обмеженнях;

Ви можете сформулювати план роботи та її обсяги.

11. Ризики

  • Узгодьте наступні питання:

Чому може не вийти?

Що може піти не так?

Що можна зробити, щоб уникнути цього?

Як можна компенсувати?

Наприклад, замовник хоче круту анімацію в продукті, але це неможливо реалізувати на певній платформі. Або ж сезон відпусток може зірвати плани із затвердження макетів. Або замовник не впевнений у відповіді ринку.

  • Застосування:

Ви зможете сформулювати план Б на випадок, коли щось пішло не так.

Інтро
Проведення

Поговоримо про формат інтерв’ю:

В першу чергу, kickoff meeting – це зустріч. Не листування, не чат.

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

Тривалість і обсяг питань

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

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

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

Стейкхолдери

На цій зустрічі повинні бути присутні:

  • Представник бізнесу, який поставить вам задачу;
  • Менеджер, який буде керувати процесом;
  • Спеціалісти з різних відділів, залучених в проекті;
  • Людина, яка буде її фасилітувати фіксувати всі домовленості в документ.

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

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

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

В будь-якому випадку, ваша робота і результат будуть не ефективні. Відносини зі стейкхолдером зіпсуються. А довіра до вас, як до спеціаліста, підірвана.

Як проводити зустріч

  • Будьте сміливі, говоріть впевнено, це допоможе всім учасникам налаштуватись на роботу і бути зібраними;
  • Краще здаватися не обізнаним та нудним на kickoff, ніж створювати не робочі рішення;
  • Допомагайте один одному в процесі;
  • Один запитує — інший фіксує відповіді;
  • Один розгубився — інший допомагає;
  • Заохочуйте всіх учасників зустрічі до роботи в Miro;
  • Попросіть їх записати, наприклад, те за що кожен відповідальний і з якими питаннями можна до нього звертатись.

Початок розмови

— Вітаю, мене звуть “Олександр”, зі мною в команді “Ліза” та “Віталій”.

— Наша задача на сьогодні разом навчитись проводити kickoff.
— Перед тим як ми почнемо — давайте познайомимось.
— Давайте по черзі скажемо як вас звати та які ролі в команді ви займаєте і потім я розкажу, що сьогодні буде відбуватись.
— Відповіді учасників команди.
— Раді з вами познайомитись.

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

Документ

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

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

Важливо пам’ятати: зафіксовані в документі домовленості можна буде змінювати потім з потреби, однак, у вас буде підстава змінити строки виконання і ціну. Ви домовлялись про один вид робіт, а тепер потрібен зовсім інший.

Структура
Результат

Результат

Щоб перевірити, чи кікоф пройшов ефективно і досягнуто коректного результату, існує перевірочна розповідь:

Наша ціль: _______________________.

Для її досягнення ми створимо рішення:  _________________.

Яким будуть користуватися _____________.

І платити нам за _______________.

Наша мета буде досягнута, коли ____________________.

Для її досягнення учасник (наприклад, розробник) зробить ________.

Учасник 2 (наприклад, дизайнер) зробить ___________ і ________.

У нас може не вийти, якщо ____________________.

Але в такому випадку ми зробимо ________.

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

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

Цінність інтерв’ю:

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

Користь від вирішеної задачі має перевищувати витрачені зусилля

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

Проведення
Записатися на практику

19 Грудня. 11:00 – 16:30 UAH

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

Зареєструватися на участь у спринті