Зацікавлені сторони проекту. Персони

Сьогодні ми поговоримо про термін “Персона” та його застосування в бізнес-аналізі.

Це нова назва для зацікавлених осіб або це щось інше? А якщо це щось інше? То навіщо нам, аналітикам це потрібно?

Справа в тому, що ми все життя працювали із “Зацікавленими сторонами”, ми навчилися їх виявляти та аналізувати. Ми навчилися розробляти вимоги для них на вищих рівнях. Ми вміємо розробляти стратегії комунікації для взаємодії з зацікавленими сторонами. Найбільш просунуті із нас працюють  зі супротивом до змін, що демонструють ці зацікавлені сторони. Один із важливих документів, які ми складали щодо зацікавлених сторін, - так званий список зацікавлених сторін, ролей і зон відповідальності. У всякому випадку цей документ так називався у другій версії “Babok Guide”, але вже в третій версії цей документ назвали “Список зацікавлених сторін, карта зацікавлених сторін або список персон”. В “Babok Guide 3.0”  дано твердження,але нам не дали роз'яснення з приводу терміну “Персона”. Для початку згадаймо визначення зацікавлених сторін і навіщо вони нам необхідні.

 Нам дуже важливо розуміти, хто саме в нашій ініціативі зацікавлені сторони, оскільки зацікавлені сторони займають центральну роль в бізнес-аналізі.

Насправді “Babok Guide” не дуже багатослівний про термін зацікавлені сторони. В перекладі  з англійської це звучить так:

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

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

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

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

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

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

Перший рівень: 

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

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

 Другий рівень:

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

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

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

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

Тому до термінів внутрішні та зовнішні,  які ми обговоримо з вами пізніше,  ми будемо додавати “внутрішня або зовнішня сторона” організації, або зовнішня чи внутрішня сторона проекту.

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

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

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

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

Це такі персони як продавці, постачальники, клієнти, підрядники, кредитори, регулятори і так далі. 

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

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

Ми взяли всі зовнішні та внутрішні зацікавлені сторони і розкрили ці визначення, тоді ця тема вже буде вважатися закритою чи є ще інші категорії зацікавлених сторін? 

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

 Ключові зацікавлені сторони Важливі зацікавлені сторони

В “Babok Guide” існує близько 20 згадок про термін “ключові зацікавлені сторони”, але жодного визначення, лише приклади. І це нам не дає жодного чіткого уявлення, чому їх вирішили назвати ключовими.

 Ключові зацікавлені сторони є найбільш важливими зацікавленими особами для компанії або проекту, це є ядро нашої картини світу Зацікавлених сторін. То яке визначення ми можемо підібрати до терміну “ключова зацікавлена сторона”?  Факультет інформаційних технологій Корнельського університету дає таке визначення:

 “Ключові зацікавлені сторони - це підмножина зацікавлених сторін, коли їхня підтримка буде зупинена, це призведе до провалу проекта”.

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

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

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

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

 Визначення Корнельського університету добре підходить для внутрішніх it-проектів А у випадку більш глобальних проектів це визначення може зіграти “поганий жарт”, оскільки ігнорує важливу групу зацікавлених сторін, які ні за яких умов не будуть зацікавлені в успіху вашого проекту. Це такі зацікавлені особи, як конкуренти або всі інші організації, у яких є інші цілі, відмінні від нашого проекту. Якщо ви, наприклад, працюєте над якимось глобальним інженерним проектом, то ці зацікавлені особи мають велику владу та ніколи не підтримують ваш проект. Вони зроблять все, щоб не допустити продовження проекту або мінімізувати якісне виконання проекту.  Вони можуть взагалі не розглядати результату вашого проекту як хороші або бажані зміни для себе і саме тому при побудові стратегії взаємодії з подібними зацікавленими сторонами найбільш правильно буде відшукати ефективний та етичний спосіб нейтралізації загрози, яку вони собою представляють. Саме тому важливо розібратися з тим, хто саме є ключовими сторонами на проекті, і як вони ставляться до цього проекту або ініціативи. 

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

Ми так її і називаємо: важлива зацікавлена сторона.

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

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

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

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

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

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

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

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

Організуймо взаємозв'язок між зацікавленими сторонами та користувачами нашої системи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Розгляньмо дві основні категорії архетипів:  головний герой,  злодій.

Герой бореться зі злом, щоб відновити мир та гармонію, справедливість в суспільстві.

Злодій є головним антагоністом до героя. Ми знаходимо з вами героїв та злодіїв у багатьох історіях наприклад:

 Герої:  Гаррі Поттер, Фродо, Супермен, Геракл, Бетмен, Шерлок Холмс,

 злодії: Волан-де-морт, професор Моріарті, Саурон

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

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

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

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

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

Що в нашому випадку є цілями? Які цілі ми повинні виявляти для формування персон?

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

Вимоги повинні бути незалежними від деталей реалізації.

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

Наприклад: ми з вами створюємо портал з розробки та оренди нерухомості.

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

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

Типи цілей у користувачів: 

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

Наприклад, для внутрішньокорпоративної системи це будуть наступні операції: 

•  відпрацювати запит клієнта

•  сформувати звіт

•  виконати транзакцію

2.  Корпоративні цілі - цілі самої організації: 

3.  збільшити дохід компанії

4.  залучити більше клієнтів

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

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

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

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

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

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

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

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

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

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

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

 Ці два підходи називаються якісний аналіз та кількісний аналіз.

•  якісний аналіз персон

•  якісний аналіз персон з кількісною перевіркою

•  кількісний аналіз персон

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

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

Крім того, ми використовуємо usability testing для спостереження, хоча цей метод для визначення персон застосовується значно рідше.

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

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

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