Новий погляд на використання Cynefin фреймворку

💡 Усі статті, обговорення, новини про HR — в одному місці. Приєднуйтесь до HR спільноти!

Вітаю, мене звуть Тетяна Голуб. За свою кар’єру я пройшла шлях від першого Скрам Майстра в Райффайзен Банку і Менеджера програм у Люксофті до консультанта розвитку менеджерів та організацій. Більше 13 років я працюю з розвитком команд та зростанням лідерів.

Кілька тижнів тому я побачила у колег допис у Linkedin щодо використання Cynefin фреймворку. У коментарях до допису була довга дискусія на тему того, що цей фреймворк використовується лише ДО старту проекту для оцінки середовища або для оцінки середовища будь-якого проекту.

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

Коротко про фреймворк Cynefin

Фреймворк Cynefin (вимовляється валлійською Киневин, а не Синевин) авторства професора Дейва Сноудена розглядає 4 середовища:

Order — зрозуміле середовище, де очевидні причинно-наслідкові зв’язки. Система в такому середовищі працює за чіткими правилами, процесами та інструкціями. Тому тут працюють кращі практики (Best practice).

Приклад: виробництво дронів або робота відділення банку (на кожен крок є чітка інструкція).

Complicated — складне середовище, де більшість процесів зрозуміло. Однак є новий, незнайомий компонент, для аналізу котрого нам необхідна зовнішня експерта підтримка. Це простір для гарних практик (Good practice).

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

Complex — ускладнене середовище, де єдиний спосіб зробити крок вперед- це рухатися невеличкими кроками (ітераціями). Тут не допоможуть ніякі кращі, добрі практики. Лише inspect and adapt гнучких практик (emergent practice)

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

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

Прикладом хаотичного середовища є період Covid-19, коли з одного боку для стабілізації ситуації вводили обмеження (режим масок та закриття кордонів). А з іншого боку, саме в цей період люди почали застосовувати те, що працювало в інших сферах- radical repurposing. Це і є новітні практики (Novel practice).

Ну і до чого цей фреймворк до найму людей

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

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

З командою менеджерів ми щонедавно виконували цю вправу в miro і ось як приземлив один з менеджерів свої проекти.

Наступним кроком підготувати список питань — кейсів про ваші проекти, які відповідають тому чи іншому домену. Навіщо ця забава? запитаєте ви. Справа в тому що ми досить часто оцінюємо soft&hard skills відірвано від контексту.

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

Case 1

Кандидат розповідає, що працював у стабільному проекті, де рідко траплялися нетипові історії. Стабільний проект (order domain), котрий давно провадили у реальне середовище. Команда складалася з 10 людей, він не був єдиним сеньорним розробником. У вас проект з вимогливим замовником, обмежений бюджет (всього два розробника), вимоги, що змінюються на льоту (complex domain).

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

Case 2

Кандидат звик, що проекти в котрих він працював, завжди все несеться (complex). Команди завжди були як морські піхотинці (метафора спец назу), котрі в рамках ітерацій по шматочку реалізовували круті проекти, працювали над удосконаленням процесів. Кандидат каже, що трохи втомився шукати роботу і готовий до «більш стабільного проекту». Ваш проєкт нещодавно видав в прод, команда вигадує сама собі задачі — знаходить що порефакторити, що покращити (order domain). Бізнес ще не знає, куди далі рухатися з продуктом.

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

Cynefin фреймворк — історії колег, котрі замінять для вас оцінку 360

В одному зі своєї виступів Дейв Сноуден запропонував відмовитися від оцінки 360. Причинами його пропозиції було твердження, результати оцінки 360 є далекі від реальності. Натомість професор Сноуден пропонує залучити для оцінки Cynefin фреймворк також різних колег, але формат доволі цікавий.

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

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

Complicated — попросіть дати фідбек-історію колегу, яку запрошують в команду як експерта для допомоги зі специфічною задачу, для якої немає компетенції в команді

Complex — нехай колега (член скрам команди) дасть фідбек, розповідаючи історії, як він взаємодіє з колегою на регулярній основі в рамках роботи над задачами спринту, коли постійно змінюються вимоги та очікування.

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

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

Замість вишеньки на торті

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

Теми: HR, найм, порада, фреймворк