Автор: Руслан Мамедов, менеджер проектів, Prom.ua (r.mamedov@prom.ua)

Від ієрархії до холакратії

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

Структура нашої “великої команди”, яка в даний момент відділилася в окремий бізнес, мала приблизно такий вигляд:

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

Насправді здавалося, що всі зони розвитку повністю закривались однією з Agile-методологій і фреймворком типу SAFE. Так ми спочатку і діяли: команда розробки відмінно справлялася зі своїми завданнями і постійно покращувала процеси завдяки Scrum.

Але навіть Agile був недостатньо гнучкий для нашого бізнесу – одна команда обслуговувала п‘ять продуктів у різних країнах. І одна лише наявність свого власного законодавства в різних державах призводила до того, що на підтримку витрачалося 40% робочого часу, що було дуже відчутно.

Навіть Agile був недостатньо гнучкий для нашого бізнесу – одна команда обслуговувала п‘ять продуктів у різних країнах

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

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

Самоорганізація: впровадження

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

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

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

Ми вирішили для початку зробити «пілот» з найактивнішою командою – розробниками і тестувальниками

Ми вирішили для початку зробити «пілот» з найактивнішою командою – розробниками і тестувальниками

Передавали команді цю роль класичним способом:

1. Зібрали всіх і показали, наскільки неефективним є посередництво в спілкуванні між людьми.

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

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

4. Запросили замовників – для спрощення комунікації.

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

Далі ми вирішили віддати команді пошук ресурсів. Причому як матеріальних (гроші на апгрейд устаткування, навчання, купівлю “смачненького” тощо), так і нематеріальних – у вигляді роботи інших професіоналів, типу web- або data-аналітиків, суміжних команд бухгалтерії і адміністративного департаменту. З матеріальними ресурсами все було досить просто:

1. Бюджети озвучуються всій команді.

2. Створюється Google-документ, в якому кожен пише, що він хоче купити, куди хоче сходити на навчання або як ще бажає витратити гроші.

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

Така схема працює. Завдяки їй у нас з’явилися Mac, SSD у кожного в комп’ютері, хороші монітори, ми їздимо на профільні конференції, ділимося своїми знаннями з колегами з інших команд тощо. У середньому ця зміна на 30% збільшила швидкість випуску кінцевого продукту. Причому нам це взагалі нічого не коштувало.

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

У систему, що самоорганізовується, не можна впускати людину з “суперсилою”

Навіщо це все?

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

Найяскравіший результат – це створення нашою командою нового продукту Bigl.ua. Він схожий на п‘ять інших, які ми – як вся компанія – розробляли раніше, але позбавлений фундаментальних проблем, які не дозволяли захопити ширшу аудиторію, скажімо, для Prom.ua.

Як виявилося, команда з 30 людей за три місяці може зробити чудовий продукт. Безумовно, нам потрібен був досвід, отриманий раніше, та технічні рішення, які розробляли інші команди задовго до нас, без цього нічого б не вийшло. Втім, практика свідчить, що п‘ять хороших менеджерів все одно не можуть ефективно слідкувати за настільки великим обсягом завдань у такий стислий термін. Тому ініціативу в свої руки взяли команди. Тепер уже не тільки команда розробки, але й команда продукту і каталогу (продуктового маркетингу). Вони самі говорили про те, що потрібно робити, аби досягти нашої “великої нахабної мети”.

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

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

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

Керівник має розуміти, що мотивує і рухає команду вперед – і “продавати” їй кожну бажану зміну

Які є проблеми?

Безумовно, в пласкій структурі управління колективом є не тільки позитивні моменти, але й складнощі. Ось деякі з них:

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

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

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

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

У людях потрібно постійно підтримувати самомотивацію, показувати, що їхня робота важлива, і чому

У людях потрібно постійно підтримувати самомотивацію, показувати, що їхня робота важлива, і чому

5. У систему не можна впускати людину з “суперсилою”. Наприклад, якогось директора, який раптом скаже: «а тепер ви розбийтесь на три команди» або «ваше бачення – нісенітниця, робіть, як я кажу». Звісно, керівнику діяти так зазвичай швидше, аніж «продавати» людям свої ідеї. Однак це з великою ймовірністю демотивує людей і відіб’є у них бажання розвивати колектив.

6. Усі зустрічі дуже сильно розтягуються. Оскільки у кожного є право голосу, він намагається переконати всіх у своїй правоті і може навіть саботувати ухвалення якогось вочевидь хорошого рішення просто тому, що воно належить не йому. Потрібно вчити людей проводити наради і давати їм інструменти для того, щоб вони могли швидко і ефективно домовлятися: голосування, planing poker, WSJF тощо.

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

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

На рівних