Марина Мельник

У період, коли бізнес переживає серйозну турбулентність або перебуває на вимушеній паузі, є простір, щоби переглянути підходи та практики. Багато великих компаній, маючи широкий портфель проєктів, розпорошуються й не вміють вибрати ключовий проєкт для реалізації. Як результат, усі вони робляться «на трієчку», команда вигоряє, бюджети та терміни зриваються. Навіть потенційно крутий проєкт може прогоріти, якщо процеси всередині компанії не налагоджені. І, на жаль, такі ситуації більше про повсякденність, ніж про рідкісні випадки. Марина Мельник До мене звернулась Олена Асланова, директорка проєктного офісу ТОВ «Омега», частиною якого є Varus – мережа продуктових магазинів. На прикладі цього кейсу покажу, як впровадження традиційних для IT практик дає змогу успішно реалізовувати проєкти в інших сферах. Що було на початку роботи з Varus? Ось виклики, з якими зіткнулася компанія: паралельно працювали над безліччю проєктів; не було виділених команд для роботи над певними проєктами; затягувалися терміни та постійно змінювався або розростався обсяг; люди втрачали фокус на проєктних завданнях і постійно надавали перевагу операційним. Це не виняткові виклики конкретної компанії. Це класична картина, з якою я стикаюся, співпрацюючи з великими українськими компаніями, і не лише в роздрібній торгівлі. Проєкти затягуються, виходять за межі бюджету, співробітники вигоряють та звільняються, а цілі не виконуються. Для розв’язання цих проблем ми вирішили впровадити у традиційний ритейловий бізнес гнучкі практики, більш поширені в ІТ – Agile (Scrum, Kanban, SAFe). Що зробили для Varus? Навчання Agile-практик топ-менеджерів Varus ми розділили на два дні. День 1. Agile та Scrum: вертолітний погляд. Ми працювали над такими питаннями. Чому Agile, а не класика? Принципи та цінності. Особливості внутрішньокомандної взаємодії. Ролі, артефакти та події у Scrum. Робота із клієнтом. Збір вимог. День 2. Agile-планування та розроблення. Гнучке планування або планування Agile. Техніки оцінювання Agile-проєктів. Release та Sprint планування. Метрика продуктивності команди. Робота кількох команд. Планування взаємодії. Результат тренінгу Ми склали портфель усіх проєктів компанії: для кожного проєкту сформували короткий опис; визначили критерії важливості: повернення інвестицій, швидкість реалізації, впізнаваність; учасники оцінили проєкти за критеріями важливості – виставили пріоритети; пріоритети завізовані керівництвом; визначили кількість пріоритетних проєктів, які можна реалізувати одночасно; склали короткий список проєктів, взятих у реалізацію. У результаті ми обрали три проєкти з найбільшим пріоритетом, у тому числі VarusTo Go. Це означає, що фокус змістився в його бік: першочерговий розподіл ресурсів, більше свободи в прийнятті рішень менеджером. Поетапна реалізація проєкту Теоретично реалізація проєкту складалася з аналізу та визначення вимог, їхнього подальшого виконання, тестування, оцінювання результату, перегляду нинішніх вимог та їхнього доповнення, якщо це потрібно. Менеджерка проєкту Юлія Пилипенко адаптувала це до проєкту та на практиці з командою зробила наступне: Склали план поетапної реалізації: перша частина – підготовка до відкриття пілотного об’єкта (три місяці) та друга – тиражування формату зі створенням формат-буку за цим проєктом (десять місяців): розробили критерії приймання кожного етапу; організували прозору звітність усіх етапів проєкту; отримані результати вивели на дошку згоряння в зрозумілій формі. Впровадили Agile-практики в реалізацію кожного етапу проєкту: щотижневі статус-зустрічі з командою верхнього рівня та щоденні зустрічі з виконавцями завдань; швидке реагування на тимчасові відхилення; щотижневий ризик-менеджмент – аналізувати чинники негативного впливу на проєкт та запобігати їм. Як результат: команда не відчувала напруження та невизначеності. Це допомогло утримувати постійно високу мотивацію співробітників, дало можливість легко впроваджувати зміни та керувати проєктом (часом, бюджетом, командою), краще відстежувати якість результату. Проєкт був реалізований у два етапи, як ми сказали вище. Відкриття пілотного об’єкта відбулося за три місяці, а на другому етапі було відкрито ще два об’єкти. В обох частинах залучили різну кількість працівників/підрядників. Найголовніше: проєкт реалізували у рамках бюджету із допустимими відхиленнями, закладеними в ризиках. Agile-практики Чому такий IT-прийом, як Agile-практики, спрацював у ритейл-бізнесі? Насправді все просто. Scrum (Скрам), один з Agile-підходів, – гнучка методологія, що дає змогу налагодити процеси в будь-якій сфері, про що говорить навіть Джефф Сазер, її засновник. Звичайно, спочатку Скрам призначався для IT, а якщо точніше – для створення програмного забезпечення. Але автор методології наполягає, що це чудове рішення для будь-якого напряму: ритейл, виробництво, будівництво, освіта тощо. Такий прийом – чудовий спосіб налагодити процеси всередині компанії будь-якої величини, що призведе до досягнення поставленої мети.