fbpx
+38 099 5197809

Agile-трансформація: які помилки керівники мають виправити негайно?

Три проблеми, що гальмують перехід компанії на гнучкий підхід (Agile) до розробки продукту

Чимало керівників уже усвідомило необхідність Agile-трансформації для своїх організацій. Не гаючи часу, вони дають розпорядження підлеглим «Застосувати Agile!» і дивуються, чому швидкий перехід на гнучкі технології виявився негнучким і повільним. До того ж, спроби власноруч проконтролювати процес «переходу» більше шкодили, ніж допомагали.

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

  • Ми уже почали Agile-трансформацію: що робимо не так?
  • Чому перехід на гнучкі підходи в нашій компанії просувається так повільно?
  • В кому проблема? В чому проблема? Як її усунути?

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

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

Що ж гальмує запровадження Agile-трансформацій?

Відповідаючи на це запитання, аджайл-гуру В’ячеслав Москаленко, єдиний в Україні сертифікований Scrum-тренер від Scrum.org, звертає увагу на низку проблем, що заважають компаніям перейти від каскадної моделі (waterfall) до гнучкої (agile). Ми обговоримо їх у цій та наступних статтях.

В’ячеслав уже підготував до аджайл-трансформацій понад 1000 фахівців у різних куточках світу, зокрема, близько 600 власників продукту (Product Owners) для таких компаній, як BMW, Deutsche Bank, Singapore Airlines та ін. Ви можете поставити своє запитання В’ячеславу щодо Agile-трансформації вашої компанії.
Отже, проаналізуймо типові причини поразок керівників у переході на гнучкий підхід.

ОРГАНІЗАЦІЙНИЙ ДАРВІНІЗМ

Вам знайомий термін «Організаційний дарвінізм»? Динозаври вимерли через нездатність адаптуватися. Так само зникнуть з лиця землі й компанії, нездатні змінюватися в епоху стрімкого розвитку технологій, не кажучи про виклики пандемії. Змінюйся — або згинеш. У цьому сенс питання.

Докладніше на тему «Як вижити організації в сучасному світі» див. відео В’ячеслава Москаленка за цим посиланням на YouTube-каналі Agile.Live.

Чи розуміє керівництво свою роль у Agile-трансформації? Наскільки гнучкі (agile) самі керівники? Відповідь на ці питання визначить долю вашої компанії уже в найближчому майбутньому.

РІЗНИЦЯ МІЖ ПІДХОДАМИ

Каскадна модель і гнучкий підхід

Річ не в тім, що каскадна модель суттєво поступається гнучкому підходу, коли йдеться про розробку продукту чи сервісу. Адже waterfall (англ. водоспад, тому її ще називають водоспадною моделлю або вотерфолом) цілком доречний у керуванні проектами в галузях, де «гнучкість» не завжди потрібна.

Наприклад, спорудження хмарочоса. Архітектори розробили план, будівельники його реалізували. До чого тут «гнучкість»? Навряд чи в ході ітерацій хмарочос трансформується у естрадно-циркове училище, іподром чи бібліотеку. Що було заплановано, те буде виконано — «згідно з вимогами», «відповідно до інструкцій», «як погоджено», «як затверджено», «згідно з планом», «у визначений термін» тощо.

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

Що коли «результат», який уперше побачать аж за півроку, не сподобається замовнику? Що коли конкуренти розробили за цей час нову технологію, внаслідок чого «результат» застарів іще до виходу на ринок?
З точки зору старого менеджменту, вотерфолу, — все чудово, завдання «виконано у вказаний термін», «згідно з інструкціями», навіть «за побажаннями замовника»!

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

Докладніше про різницю між вотерфолом і аджайл на прикладі ітеративно-інкрементального підходу див. відео В’ячеслава Москаленка на його авторському україномовному Ютуб-каналі «Все про Аджайл і Скрам».
За різними оцінками, порівняно з представниками старої школи, гнучкий підхід допомагає вивести продукт на ринок на 15-40% швидше.

ТРИ ПРОБЛЕМИ

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

  • Людський фактор.
  • Брак знань або досвіду.
  • Директивні методи керування.

Проблема 1: Людський фактор

Повільне впровадження Agile-підходу не обов’язково пов’язане з небажанням керівників здобувати нові знання чи навички. Менеджери — звичайні втомлені люди.

Замість концентрації на Agile, втомлений керівник не вникає в його специфіку і за звичкою розпорошує енергію на «керування», контроль і мікроменеджмент — як кажуть українці, суне свого носа до чужого проса.
Коли підлеглі «роблять щось не так», хто їм висловить догану? Начальник береться власноруч «розрулювати» ситуацію, щоб усі зрозуміли, як треба робити правильно. Хіба здатна зграйка найманців самостійно знайти рішення без його мудрого напучення?

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

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

Проблема 2: Брак знань та досвіду

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

Ще одна перепона — скептицизм. Практики скаржаться на теоретиків, які «пройшли тренінг або прочитали книжку і вже беруться навчати про Agile, хоч самі жодного продукту не розробили». Справді — книжкові коучі навряд чи допоможуть. Проте скепсис керівників може дорого коштувати в епоху стрімких темпів розвитку й постійних змін. Що заважає звернутися до практиків, таких як Сергій Прохоренко, визнаного у світі фахівця з SAFe — масштабованої гнучкої розробки, чи В’ячеслава Москаленка, гуру із запровадження SCRUM?

На противагу «теоретикам», принциповою рисою Agile.Live якраз і є практичність. Серед клієнтів, з якими випадала нагода співпрацювати — Microsoft, Lufthansa, JP Morgan та ін. світові компанії, про «практичність» яких говорити зайве.

Третій блокатор застосування Agile — нерозуміння керівниками ролей, своїх та колег у межах Agile-моделей, таких як Scrum. Найбільше труднощів виникає у зв’язці «топ-менеджер — власник продукту (Product Owner)». Цю проблему ми докладніше проаналізуємо в окремій статті. Витікає вона зі старого директивного стилю.

Проблема 3: Директивний стиль керування

Куди легше «віддати розпорядження» іншим, щоб змінювалися вони, поки лідер залишається в зоні комфорту. («Вперед, орли! А я за вами. Пожартував. Ідіть-но самі»).

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

Директивному стилю притаманні:

  • Залежність організації від рішень однієї особи.
  • Бюрократія, процедури, вертикальна багаторівневість системи.
  • Гаяння часу на погодження дрібниць з керівною особою або погодження дріб’язкових питань на різних рівнях організації.
  • Нерозуміння керівником ролей або неповага до ролі співробітників.
  • Порушення керівником меж (або рамок, англ. frames; framework — модель, методологія, що має чітко окреслені межі, «рамки»), втручання в роботу співробітників.

ЩО РОБИТИ

Щоб прискорити перехід на Agile, покращити його або запровадити правильно, керівникам насамперед варто:

  • Усвідомити власну відповідальність за Agile-трансформацію. Ніякий чарівник в особі натренованих співробітників не змінить ситуацію на краще, якщо до цього не готовий керівник.
  • Підвищити власну компетентність. Однієї книги чи семінару недостатньо для запровадження змін на системному рівні. Для відчутного результату, вочевидь, варто приділити час для здобуття ґрунтовних знань та навичок.
  • З’ясувати, прийняти й поважати новий розподіл ролей в парадигмі гнучкого підходу — власних та колег.
  • Чітко зрозуміти поняття «меж» і «автономії» (про це докладно в наступній статті).
  • Зрозуміти різницю між «старою школою» та гнучким підходом, директивним стилем та Agile. Цю проблему ми також докладно обговоримо на ресурсах Agile.Live.

Долучіться до спільноти Agile.Live, щоб бути в курсі розвитку Agile, професійно розвиватися й досягати цілей краще й швидше.

ДОЛУЧИТИСЯ ДО AGILE.LIVE

Дізнатися більше про тренінг «Професійне лідерство в гнучкій організації»
Графік тренінгів і вебінарів
Підписатися на Telegram-канал Agile.Live
Підписатися на You-канал Agile.Live
Подивитися україномовний YouTube-канал В’ячеслава Москаленка «Все про Скрам і Аджайл»

Анонси публічних тренінгів

Ви замовили
Вебінар Консалтинг Тренінг