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

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

Якщо ви не розумієте, з чого починати, як підійти до організації та виконання замовлення, влаштуйте 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. Всі учасники команди розуміють, як саме вони мають взаємодіяти один з одним, а також які внутрішні дедлайни, ресурси і обмеження у них є.

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

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