Досвідчені РМ-и знають: зміни не оминають жоден проєкт, адже вони відбуваються не час від часу, а постійно. Тому й підходити до роботи з ними потрібно систематично, щоб не сталося так, що зміни затягнули настільки, що вже й керувати ними неможливо.
У статті поділюся, від чого «тікали» ми з командою, та як адаптувалися до переходу від вже звичних процесів у проєкті до чогось нового. Кожен з кейсів показує, чому менеджеру вкрай важливо навчитися працювати зі змінами та не боятися їх. Наявність у PM-а навички роботи зі змінами не тільки економить бюджет та час компанії, а ще й робить процеси більш комфортними, зокрема для команди.
Кейс 1: Kanban замість Scrum — як подолати упередження керівництва
Всі команди в проєкті працювали по методології Scrum. Це подобалось керівництву, адже вся компанія синхронізована, працює однаково, і є відчуття, що оперувати таким процесом простіше. На думку керівництва, завдяки Scrum легше контролювати роботу та оцінювати співробітників.
Технічна команда, з якою працював я, не була ефективною в такому форматі. Метою команди був технічний рефакторинг та розбиття монолітної архітектури на мікросервісну. Але робилось то «по-живому» — поки існуючий продукт активно розвивався.
Проблем в Scrum-підході, що не задовольняли команду, було дві:
- Неможливість спрогнозувати складність задач, адже щодня з’являлися нові нюанси, чи функціональність.
- Постійна зміна пріоритетів задач — проблема, що витікала з першої.
Команда навчилась декомпозувати роботу на маленькі шматки більш-менш однакового розміру, але постійна зміна пріоритетів, послідовності і скоупу заважала ефективному плануванню.
Незважаючи на неефективність Scrum-методології в цій конкретній ситуації, менеджмент в компанії боявся зміни процесу. Особливо слова «Канбан», адже це начебто щось про хаос, відсутність контролю та передбачуваного планування. Насправді зовсім ні, але зараз не про це.
Як впровадити зміну і допомогти команді з переходом?
Почали все з цілей та business benefits. Перш за все потрібно було попередити стейкхолдерів, що приймають рішення, адже команда outsource, а прийняття рішень на стороні клієнта. Далі — пояснити недоліки поточного переходу — фрустрація команди, непрацюючий підхід, постійно змінюючийся скоуп, відчуття хаосу — і переваги нового. Після цього варто було побороти страхи нового підходу: як моніторити, як контролювати, як планувати (спойлер: lead time+cycle time вирішують ці питання дуже просто).
Ми запропонували клієнту спробувати новий режим протягом місяця і порівняти результати. Клієнт дав згоду на експеримент.
Етап execution зміни був простий, адже команда була більш ніж готова до введення змін. З місяць всі адаптувались до нового процесу, провели декілька ітерацій і покращили певні підходи та інші моменти. Постійно комунікували зі стейкхолдерами щодо процесу та прогрессу.
Через місяць команді дали зелене світло продовжувати в цьому руслі, але страх у клієнта все одно залишився, адже всі інші команди продовжували працювати по Scrum, а тут Kanban. З цього часу почався етап утримання (sustain the change) зміни, який полягав в основному у проговоренні на рівні керівництва, постійній комунікації та моніторингу того, що відбувається.
Команда працювала в новому підході більше року. За цей час вона стали зразком для декількох інших команд, що хотіли впровадити те ж саме. Нажаль, в них не вийшло «продати» керівництву цю ідею, навіть маючи ефективний приклад під боком, але то вже інша історія. Головне, що тут в конкретній команді нам вдалося впровадити більш ефективний підхід. 🐇 Твої +5% додаткової знижки на будь-який курс для проджект-менеджерів! Просто додай у форму реєстрації на курс промокод «Пасхалка 5% 🐇
Кейс 2: Неприємна зміна, яка врешті перетворилась в адаптацію
Клієнт вирішив покращити розробку і T-shape-нути команди, щоб краще тестували код, писали тести і відповідали за все самі. Рішенням проблеми виявилась досить неприємна зміна — скорочення ролі QA/AQA.
Більшість команд не були готові до таких нововведень, тому був запропонований і втілений план адаптації та поступової зміни.
- Обміркувати проблему та зрозуміти, навіщо потрібні зміни: start with Why?
- З’ясувати, як команда ставиться до такої зміни та чи готова до цього.
- Зрозуміти, що заважає реалізації змін (barriers) та що може сприяти (enablers).
Причиною зміни було бажання покращити команди, зробити їх більш незалежними (такими були тільки команди розробки) та дати більше відповідальності.
Основною проблемою, яка хвилювала команду (resistance to change), була відсутність якісних вимог, що спричинило доопрацювання.
Найбільша цінність QA полягала в розумінні і подальшому тестуванні вимог.
Після того, як ціль була зрозуміла, а відправна точка означена — команди з QA-інженерами почали готувати план переходу. Процес підготовки був довгий, тому одразу до результату: ми спробували перенести цю функцію в початок процесу, навантаживши PO додатковою роботою, і розвантаживши його новою роллю — BA. По суті, зміна звелась до переходу ролі тестування на початок процесу, де і виникало найбільше бізнесових помилок, і як наслідок — rework.
За рік команда успішно адаптувалась до нового процесу, де розробники відповідали за код, його якість та доставку, а аналітики з РО — за зрозумілість і точність вимог.
Замість висновків
Менеджмент змін — це дійсно складно. Потрібно знати моделі та фреймворки, яка документація та метрики є важливими, як комунікувати з командою та впроваджувати зміни так, щоб це не зламало процеси. Гарна новина — цьому можна навчитися, питання тільки в тому, на своїх помилках чи на досвіді експертів 😉