Інструменти самоорганізації розподілених команд. Частина 1: холакратія

Автор: Олександр Крикля, технічний директор і співзасновник компанії Raccoon Gang, яка створює рішення у сфері онлайн-освіти та дистанційного навчання

 

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

 

 

 

Організаційний контекст

В якості консультанта з веб-напрямку я керував відділом у компанії Labster, яка займається створенням навчальних симуляторів лабораторних робіт для університетів на основі віртуальної реальності. По суті, це тривимірна комп'ютерна гра, в процесі якої ви виконуєте лабораторні роботи за різними напрямками: секвенуєте ДНК, ставите хімічні досліди тощо. Компанія є стартапом і виросла за три роки до 60 осіб, її працівники живуть і працюють у Швейцарії, Данії, Індонезії, Україні та США.

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

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

Холакратія є не єдиним організаційним інструментом в нашій компанії. Використовується також підхід OKR (Objectives and Key Results - цілі й ключові результати) і методи вимірювання здоров'я команд на основі OfficeVibe. А всередині технічних команд використовуються Agile підходи - Скрам і Канбан.

 

Холакратія

Детальніше про те, що таке холакратія, і як вона працює, можна почитати тут.

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

 

 

 
Після впровадження холакратії керівники краще усвідомили свою координаційну і лідерську роль

 

 

Холакратія являє собою одну з проекцій організації й вирішує такі основні завдання:

- Робить зрозумілою структуру компанії. Наприклад, стало ясно, що у нас є відділи sales, customer support, research, people & partnership, стало зрозуміло, що в цілому з себе представляє організація, і чим вона займається.

- Робить зрозумілими обов'язки кожного працівника і ролі, які він виконує. Наприклад, виявилося, що є Research-фахівець, і його робота полягає в поданні грантів на дослідження.

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

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

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

- З комічного, але важливого: припинилося перекладання роботи з Васі на Петю, оскільки обов'язки прописані. Наприклад, лід лінку кола не потрібно реагувати на кожну проблему користувачів, тому що є ролі Customer Support (Підтримка користувача) і Bug Tzar (Цар помилок).

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

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

Згадаю одну з рис української й індонезійської ментальності: часто люди чекають на схвалення "згори". Спочатку з працівниками доводилося розмовляти так: «Ти фахівець у цьому, ти прийняв рішення, ти знаєш, що робити - не чекай схвалення згори, бери й роби! Якщо потрібна консультація - знайди людей з потрібною компетенцією, збери невелику нараду, отримай зворотний зв'язок. Але ти приймаєш рішення, як це буде виглядати в підсумку, і тобі координувати цей процес у твоїй зоні відповідальності». Тобто немає витрат на зайву перевірку, зайве схвалення і зайву координацію.

 

 

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

 

 

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

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

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

 

Також Вам можуть бути цікавими такі матеріали:

Agile-лікнеп: що таке agile та кому він підходить

Міфи в Agile

Як компанія Prom.ua створила команду, що самоорганізується

 

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

Процедура розв‘язання теншнів виявила проблеми організаційного і особистого характеру (це важливо!), і приблизно за півроку вдалося вирішити більшість такого "багажу". На даний момент проблеми вирішуються у міру їх появи. Причому багато цих питань не пов'язані з організацією процесу. Але процедура виявлення теншнів дозволила їх спочатку проявити, потім обговорити і, нарешті, знайти шляхи вирішення.

Наприклад, на етапі введення холакратії перший теншн від учасників команди був: занадто багато зустрічей. Було прийнято рішення: зробити Agile-ретроспективу частиною тактичної зустрічі й скасувати керуючі зустрічі для команди взагалі.

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

Звичайно, проявилися і недоліки цієї системи. З'ясувалося, що холакратія не допомагає, якщо у організації є проблеми в цінностях, невизначеність з метою або напрямком руху. Холакратія, прибравши проблеми організаційного рівня, вивела назовні необхідність наявності стратегії й фокусу на кожному рівні компанії згори до самого низу. Щоб формалізувати й внести прозорість в ці процеси, ми скористалися методикою OKR, і вона зарекомендувала себе дуже добре. Про це – у наступній частині статті.

Коментарі