Що таке UnFix

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

Management 3.0 – глобальний концепт, проте він скоріше стосується культури, а не власне проєктування організації.

Тож Юрген Аппело розробив нову модель формування і роботи організації — unFix. Ця стаття — переклад матеріалу з сайту unFix, де глобально пояснюється концепт моделі. Погнали!

Давайте спершу прояснимо, чим не є unFIX.

1. Модель unFIX не є фреймворком. Визначення “фреймворк” передбачає важливу опорну структуру. Але нічого опорного в unFIX немає. Все необов’язково. Найкраще її характеризує фраза “бібліотека шаблонів”.
2. Модель unFIX не пропонує жодних процесів. Метою unFIX є охоплення лише шаблонів проєктування організації та організаційної структури. Поради щодо процесів Юрген радить шукати в інших фреймворках.
3. Модель unFIX призначена не лише для ІТ. Усе в бібліотеці шаблонів unFIX може застосовуватися до різних департаментів, підрозділів і компаній. Ця модель не містить вбудованої гіпотези стосовно розробки програмного забезпечення.
4. Модель unFIX не спрямована згори вниз. На відміну від багатьох інших моделей і фреймворків, бібліотека шаблонів unFIX пропонує висхідний підхід. Ви не можете побудувати одразу щось велике. Ви повинні почати з чогось малого.
5. Модель unFIX не є заміною. В інших моделях і фреймворках є багато хороших речей, які не варто викидати. Ми просто сподіваємося, що за допомогою unFIX ви усунете негативні аспекти і збережете хороше.

То що таке unFix і як це працює?

Команди

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

Існує сім типів команд:

• Команда потоку цінності
• Команда фасилітації
• Команда можливостей
• Команда управління
• Команда платформи
• Команда досвіду
• Команда партнерства

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

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

Команда потоку цінності (Value Stream Crew)

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

Потік цінності може включати регулярні випуски продуктів або оновлення послуг, оскільки зазвичай сам продукт або послуга і є носієм потоку цінності. Часто ці команди застосовують ощадливі (lean) та гнучкі (agile) практики або такі методи, як Kanban і Scrum, щоб керувати безперервним постачанням цінності. Деталі процесу належать до юрисдикції команд. Утім, керівна група або форум можуть запропонувати окремі вказівки або навіть встановити обмеження.

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

Команда фасилітації (Facilitation Crew)

Єдина її мета — допомогти іншим командам виконувати роботу добре. Команди фасилітації не мають власного потоку цінності. Натомість вони гарантують безперебійну роботу команд потоку цінності на Базі. Прикладом може бути команда скрам-майстрів або аджайл-коучів.

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

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

Команда можливостей (Capabilities Crew)

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

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

Команда платформи (Platform Crew)

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

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

Команда досвіду (Experience Crew)

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

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

Команда партнерства (Partnership Crew)

Команда партнерства виконує майже таку ж роль, як і команда досвіду. Тоді як Experience Crew зосереджується на клієнтах і користувачах, Partnership Crew зосереджується на постачальниках, партнерах, фрілансерах, співробітниках і незалежних підрядниках. Будь-яка фізична чи юридична особа, з якою ваша компанія підписує контракти через закупівлі або кадрові ресурси, може потрапити в фокус команди партнерства.

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

Команда управління (Governance Crew)

Команда управління – це команда менеджерів. Вона складається з кількох керівників, які є менеджерами кожного в Базі. У випадку, коли компанія складається з однієї Бази, Команда управління — це виконавча команда.

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

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

Бази

Усі команди працюють на Базі чисельністю від кількох до кількох сотень людей. На цій базі є кілька команд із семи стандартних типів, організованих навколо одного або кількох потоків цінності. База діє як повноцінний незалежний бізнес. Вона містить усі необхідні навички для проєктування, розробки та постачання продуктів, від Design Thinking до DevOps і від Lean Startup до Lean Manufacturing.

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

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

Форуми

Форум — це група людей з різних команд. Назва “Форум” вказує на його основну мету — об’єднувати однодумців задля спілкування та спільного прийняття рішень. Може бути DevOps Forum, UX Forum, Growth Hackers Forum тощо. У традиційних організаціях офіс управління проєктами (PMO) можна перетворити на форум, а в більш гнучких компаніях менеджери з продуктів можуть мати власний форум. Керівники Бази можуть вирішити, які форуми потрібні, оскільки деякі форуми відіграють важливу роль у структурі організації.

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

Масштабування

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

Координацію між Базами можна здійснювати на Асамблеях (подібно до людей, які координують свою роботу на Форумах). Ці Асамблеї є добровільними структурами, які дозволяють представникам Баз координувати способи роботи, переходячи через кордони однієї Бази.

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

Модель unFix натхнена інноваційними компаніями, зокрема Haier і Tesla, різноманітними фреймворками гнучкого масштабування та такими книгами, як Team Topologies, Dynamic Reteaming і Organization Design.

А поки ми і ніхто, крім Юргена, ще не проводимо тренінги з unFIX, давайте покращувати культуру в командах. Приєднуйтеся до найближчих тренінгів із Management 3.0 — ми відновлюємо офлайн-івенти!