Zalando: подорож теренами Agility

Заснована 2008-го Zalando — провідний європейський онлайн-продавець модних товарів. Компанія реалізовує стратегію диджиталізації моди. З 2015-го до 2017-го року чисельність працівників, задіяних у цифровому просторі, зросла більш ніж удвічі (з 800 до 1 700 осіб), що зараз складає 14% від усього персоналу.

У розмові з представниками McKinsey Ерік Боумен (Eric Bowman), віце-президент Zalando з інженерних питань, розповів, як у компанії прищеплюється філософія організаційної гнучкості.

Як Ви визначаєте поняття «Agility»?

Суттю Agility є реагування на змінювальний контекст, у якому функціонує бізнес. А в основі цього лежить здатність працювати «в паралелі» та мінімізувати кількість точок, де можуть гальмуватися ваші рішення або дії. Уявіть, що ви йдете крізь зарослі кущів. Аби швидко змінити напрям руху, потрібно відрізати «колючки» з рослин (рис.1). Є чимало місць, де може «застрягнути» ваша команда — технологія, оргстуктура, культура, спосіб мислення. Тож «у сухому залишку» Agility — це усунення «колючок» та «шипів».

Які переваги отримує ваша компанія від гнучкості організації?

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

Рисунок 1 В Zalando основою Agility є паралелізм роботи та мінімізація точок координації зусиль.

Як виглядала ситуація в Zalando 2014-го, коли Ви очолили інженерний напрям?

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

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

Чи не могли б Ви розповісти про основні етапи зростання Zalando?

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

Рисунок 3 Для масштабування Agility потрібні два елементи.

Що означає поняття «радикальної гнучкості»?

Ми спробували інтегрувати всі найдієвіші підходи, які є в нашому секторі; а також взяли ідеї Дена Пінка (Dan Pink), що обертаються навколо понять «мета», «автономія» та «майстерність». Це і стало основою організації діяльності та мотивування команд (рис.4). Особливо сильний відгук засада автономії знайшла в технічних фахівців. Ціллю всього цього було формування паралелізму, що означає спроможність окремих частин організації приймати і втілювати рішення, не створюючи при цьому перепони для роботи інших команд. Не менш важливо було максимально звузити «парасолю» централізованого координування.

Яка оргструктура потрібна для реалізації такої стратегії?

Організаційні структури більшості компаній налаштовані на досягнення консенсусу та оптимізацію процесів прийняття рішень. Проте філософія Agility обертається навколо гнучкості прийняття рішень. І тому тим, хто звик до певних підходів, доводиться змінювати свій спосіб мислення. Структура «наскрізної власності», де люди контролюють свою роботу від «А до Я», та де часта реструктуризація — це норма, є абсолютно необхідним «інгредієнтом» agile-організації.

Але як саме виглядає оргстуктура цього типу?

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

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

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

І третій елемент — це оптимальний обсяг навантаження. Потрібна можливість заглиблення в справу, що надзвичайно важливо в процесі масштабування, коли ваша робота невпинно складнішає. Ми привчаємо людей до думки, що інколи потрібно зменшити обсяг завдань (але не розмір винагороди!), аби мати змогу глибоко зануритися в те чи інше питання.

Як Ви усуваєте структури, які більше не працюють?

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

Що є унікального в управлінні agile-організацією?

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

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

Загалом, довіра — це основа підзвітності та автономії. Підзвітність (на відміну від відповідальності) неможливо розподілити. Ми хочемо, аби люди не лише приймали рішення, але й особисто відповідали за результат (і щоб не було «цапів-відбувайлів»). І ще, хочемо, аби співробітники мали автономію. Проте автономія без підзвітності перетворюється на відпустку. Коли щось йде не так і люди приймають невдалі рішення, ми проводимо аналіз — запитуємо: «Добре, а як ви до цього прийшли?». Автономії навчаються — її потрібно заслужити. Для цього потрібні хороші судження, що робляться на основі досвіду, та досвід, який набувається завдяки неправильним судженням.

Які процеси є для Вас найважливішими?

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

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

А як визначаються очікування?

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

Якщо взяти технологічну сферу — як у ній працює Agility?

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

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

Які головні висновки Ви зробили, освоюючи світ Agile?

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

За матеріалами "The journey to an agile organization at Zalando", The McKinsey Quarterly.