Як провести вдалий онбординг ІТ-проєкту. Підхід структурованого менеджменту для PM/BA
Моя минула стаття на DOU була присвячена поєднанню ролей бізнес-аналітика та проєктного менеджера. Я продовжу узагальнювати досвід, здобутий за шість років на різних посадах в ІТ. Цього разу розповім про запуск ІТ-проєктів і запропоную інструментарій для ефективної роботи проєктного менеджера і бізнес-аналітика. Стаття буде цікава насамперед PM та BA.
Кожен менеджер знає про важливість і значення процесу онбордингу проєкту. Від ефективності його «заведення» і старту робіт буде залежати розвиток і стратегія взаємодії із клієнтом. У цьому контексті хочу навести цитату легендарного практика сучасного менеджменту Іцхака Адізеса: «Реальне розуміння того, що ми контролюємо в процесі управління, допомагає нам уникнути близько 70% помилок!».
Професійний проєктний менеджер чи бізнес-аналітик розуміє важливість повного чеклисту дій ключових ролей під час онбордингу. Цей інструмент може мати різний вигляд та є основою загального проєктного фреймворку. Безумовно, кожен проєкт різний, кожен клієнт має свою специфіку роботи, а ІТ-компанія — власний досвід та експертизу, кожен стартує у своїх умовах...
Усе це робить онбординг проєкту унікальним з погляду імплементації, здобуття і генерації нових знань і досвіду. Тож діяльність PM/BA вимагає чіткого розуміння, абсолютної злагодженості дій у тому, як організувати процеси в команді. З власного досвіду помітив, що допущені помилки управління вимагають значно більших зусиль для виправлення вже на стадії класичної розробки, а іноді можуть стати критичними для цілого проєкту.
Підхід структурованого менеджменту
Одним із головних завдань для ролей PM/BA є створення загального бачення управління для ефективної роботи команди та поширення практики системного мислення. Це завдання вирішується під час онбордингу проєкту, коли відбувається сетап основних робочих процесів, визначаються функції та зони відповідальності спеціалістів, формуються показники оцінювання ефективності командної взаємодії, система відносин і звітність перед клієнтом компанії тощо.
Для вирішення цих завдань я використовую підхід структурованого менеджменту, який розробив власноруч. Він передбачає визначення і групування об’єктів управління.
Блоки проєктної роботи. Будь-який проєкт складається з основних типових блоків роботи ІТ-управлінця: комунікації, роботи над продуктом, налаштування командної роботи, делівері та побудови відносин із клієнтом (інтеграція у роботі із клієнтом) тощо.
Активності та процеси. Будь-який блок роботи містить низку ключових активностей, які своєю чергою формують певні процеси.
Робочі артефакти. Результатом персональної та командної роботи (активностей) завжди є артефакти, які прямо сигналізують про ефективність завдань.
Проєктні ролі. Безумовним рушієм і основою виконання задач є команда. Важливо визначити її ядро.
Вимірювання процесного здоров’я проєкту. Стан отриманих артефактів та їх еталонної змістової готовності (наповненості) сигналізує прямо та опосередковано РМ/ВА про стан ефективності командної роботи під час онбордингу проєкту, а також вказує на можливі «вузькі місця» у процесній складовій.
Використання управлінських метрик для вимірювання загальної якості та контрольованості проходження онбордингу проєкту. Основними управлінськими стратегічними завданнями процесу онбордингу є його контрольованість, ефективність та результативність, узгоджена з клієнтом. Саме тому управлінцю необхідно відразу визначити зрозумілий з погляду оцінки результативності показник (чи показники). Це допоможе проаналізувати запуск проєкту загалом і побудувати довірливі та прозорі відносини з клієнтом.
Фреймворк онбордингу проєкту
Підхід структурованого менеджменту об’єднує описані компоненти в єдиний робочий універсальний фреймворк. Формат оформлення — графічна модель об’єктно-процесного управління компонентами.
Єдиний робочий універсальний фреймворк онбордингу ІТ-проєкту
Як використовувати та читати цю модель? В її основі лежить принцип модульного конструктора «забери зайве або додай потрібне». Залежно від проєктної специфіки РМ/ВА може розширювати або звужувати блоки роботи та відповідне їх наповнення. Усі активності тут погруповані «від початкових до фінальних», що значно полегшує розуміння послідовності налаштування їх у роботі команди. Певні їх види можуть проводитися не тільки послідовно, а й паралельно.
Знаковим є поділ команди на групи ролей: «менеджмент» («уряд», «борд» тощо), «делівері та проєктні менеджери», «бізнес-аналітики». З огляду на проєктну специфіку визначають оптимальний чисельний та кваліфікаційний склад команди.
До першої групи належать фахівців рівня програм — менеджмент, керівники напрямів, залучені у проєкт з боку ІТ-компанії (виконавця робіт). З боку клієнта якісний склад фахівців може бути різним, але, як правило, у великих проєктах до них зараховують спеціалістів рівня борд-менеджменту, так званих кураторів проєкту — decision visioners and makers. Серед їх головних завдань — координування питань розробки та контролю загального перебігу робіт, підтримка команд на різних рівнях роботи, втілення, лобіювання, розгляд критичних проєктних ескалацій тощо.
Делівері та проєктні менеджери опікуються налаштуванням процесів, SDLC, створенням звітності, рольовим формуванням, стафінгом (підбором, наймом, онбордингом) команд тощо.
У коло завдань третьої групи, бізнес-аналітиків, входить дослідження продукту і бізнесу клієнта, формування опису обсягу робіт, передачі необхідних знань і поточне консультування розробницьких команд тощо.
Таким чином поєднання трьох ключових груп ролей створює не тільки основу команди, а й покриває всі головні види діяльності з єдиним керівним центром ухвалення управлінських рішень і впровадження змін. Звичайно, комбінування ролей може бути різним, це залежатиме від конкретної специфіки проєкту. Головне — створити такий фундамент ще до активного онбордингу.
Артефакти роботи проєктної команди
Така модель фреймворку дає змогу чітко погрупувати зони відповідальності та роботи команди залежно від потреб (специфіки). На основі схожого групування впроваджують RACI matrix і використовують її на стадії розробки. Для візуального групування пропоную застосувати підхід «світлофора» («кольорового ліхтаря»), де кожній групі ролей присвоєно свій графічно-кольоровий ідентифікатор. Він має низку переваг:
- швидка ідентифікація належності групи ролей до виду активностей та процесів;
- легке і швидке сприйняття під час читання моделі;
- швидке впровадження змін в активності ролей.
Для ІТ-управлінця, зокрема РМ\ВА, важливим є формування процесу створення і отримання артефактів роботи онбординг-команди. Артефакти є об’єктами ідентифікації здоров’я процесів, їхньої організаційної зрілості та водночас основою вимірювання результативності робіт як для команди, так і для клієнта компанії. Цінність запропонованого підходу допомагає втілити наскрізну «прив’язку» між блоком, сетом активностей (процесів), відповідальними ролями та артефактами роботи учасників.
Важливим додатком до артефактів є їхні темплейти, розроблені командою відповідно до специфіки робіт і сформовані в окрему бібліотеку. Пізніше, у фазі розробки, артефакти використовує і за потреби легко модифікує девелопмент-команда. Також розуміння стан самих артефактів допомагає менеджменту легко оцінити ступінь процесного здоров’я того чи іншого блоку.
Для цього я розробив просту систему оцінки «стану здоров’я» блоків. Серед іншого пропоную використати вищезгаданий підхід «світлофора», де:
- Risks Zone (червоний колір маркування) — стан, коли активності (процеси) не налаштовані, команда їх не контролює, метрики відсутні, а ризики відомі частково та непідконтрольні онбординг-команді;
- Attention Zone (жовтий колір маркування) — стан, коли активності налаштовані частково або із певними застереженнями, частково контрольовані командою, метрики частково присутні та вимірювані, а ризики ідентифіковані, розпочата процедура їх хеджування;
- On Track Zone (зелений колір маркування) — стан, коли процеси налаштовані й повністю контрольовані командою, метрики присутні, визначені та виміряні, а ризики повністю відомі та вже хеджовані.
Онбординг-команда оцінює стан артефактів спільно, на регулярних зустрічах. Ведеться відкрите обговорення через призму запропонованих практичних критеріїв оцінки. Тоді команда має змогу розрахувати зрозумілий показник «здоров’я» проєкту, а саме:
% «здоров’я» проєктного блоку = кількість артефактів (активностей чи процесів) із зеленим маркуванням / загальну кількість артефактів (процесів у блоці) * 100%.
Цей показник дає загальне та деталізоване розуміння РМ\ВА стану організаційної зрілості та результативності активностей блоку. Підсумовування за кожним блоком, своєю чергою, дає змогу оцінити зведений агрегований показник загальної керованості (підконтрольності) онбордингу, який розраховують як в абсолютній, так і відносній величинах:
- рівний кількості 100% контрольованих здорових блоків — абсолютний вираз показника.
- рівний відношенню кількості 100% контрольованих здорових блоків проєкту до загальної кількості блоків помножений на 100% — відносний вираз показника.
Що розуміння цього показника дає РМ\ВА:
- агреговане уявлення про загальну кількість і якість процесів, що створює загальну картину та вказує на зони підвищеної управлінської уваги;
- механізм централізованого та підконтрольного вирішення реєстрації питань, що потребують управлінської реакції. Головним інструментом стає реєстр проєктних онбордингових ескалацій та робочих запитань;
- підстави для створення і розробки на основі попередньо проведеного аналізу плану дій щодо вирішення позначених питань та оптимізації «вузьких місць» в онбординговій діяльності;
- інструмент періодичного ітеративного контролю з удосконалення активностей, процесів і отриманих результатів роботи команди.
Таким чином цей універсальний фреймворк виконує важливі управлінські завдання: коректно та ефективно готує проєктну діяльність до фази активної розробки, забезпечує комплексну та водночас деталізовану картинку управлінської дійсності для клієнта та ІТ-компанії, превентивно виявляє та хеджує основні ризики, створює основу чіткого стратегічного планування роботи ще на фазі онбордингу тощо.
Роль PM/BA у підході структурованого менеджменту
Якою ж є роль проєктного менеджера і бізнес-аналітика чи поєднання цих посад у запропонованому підході? Однією із найважливіших! Достатньо детально розглянути активності та їхній розподіл за ролями у фреймворку (дані наведено просто для прикладу). Завдяки запропонованому підходу на основі принципу «конструктора» ми з легкістю можемо змоделювати будь-яке необхідне комбінування взаємодії/поєднання функцій. Достатньо лише розподілити фокуси уваги РМ/ВА за типами активностей в межах блоків.
Однак в управлінській практиці складається стандарт класичного фокусування під час взаємодії та/або поєднання ролей РМ/ВА:
- Основний фокус уваги у роботі PM:
- практика налаштування усіх процесів;
- контроль ефективності виконання роботи командою;
- створення планів діяльності та контролю їх виконання.
- Основний фокус уваги у роботі BA:
- дослідження продукту чи сервісу, який доведеться розробляти чи вдосконалювати;
- створення і коригування беклогу, підтримка процесу його управління;
- передача продуктових та бізнесових знань і досвіду розробницьким командам.
- Основний фокус уваги у спільній роботі PM і BA:
- налаштування командної взаємодії та роботи;
- робота із вдосконалення якості процесів;
- робота над кращою залученістю і взаємодією із клієнтом;
- робота над якістю делівері;
- робота над поліпшенням показників задоволеності клієнта;
- ризик-менеджмент.
Маючи зазначений орієнтир і використовуючи вищезапропонований фреймворк, читач-практик легко зможе втілити потребу в комбінуванні функцій РМ/ВА на конкретному проєкті.
Критичні помилки та ризики під час онбордингу проєкту
З власного досвіду розповім про головні помилки під час онбордингу ІТ-проєкту з боку РМ і ВА, яких варто уникати.
Відсутність підготовки. У цій ситуації, як правило, РМ і ВА розраховують на можливість так званого гнучкого орієнтування у процесі ІТ-проєкту, апелюючи до критерію гнучкості та неможливості необхідного планування через постійно змінні умови діяльності клієнта. Насправді у менеджера завжди має бути чіткий і зрозумілий план дій. Так, ми маємо бути адаптивними, але без плану ризикуємо занурити проєкт і діяльність команди в управлінський хаос, породжений змінними запитами самого клієнта. Ця практика призведе до великих управлінських проблем, що межують із ризиком цілковитого провалу.
Недостатнє залучення ключових ролей. Ця практика швидко породжує ризик кризи системного бачення проєктної діяльності через те, що неможливо провести всебічну рольову експертизу.
Відсутність структурованого бачення. Може призвести до недовіри як усередині команди, так і з боку клієнта.
Неузгодженість у баченні процесів, які відбуваються між командою, менеджментом і клієнтом. Ризик відсутності єдиного стратегічного та оперативного бачення вирішення викликів спричиняє небажані управлінські ініціативи на всіх рівнях взаємодії. У кінцевому результаті призводить до хаосу.
Небажання вимірювати управлінську ефективність (або приховування цього). Така практика породжує ризик системної помилкової оцінки підконтрольності процесів проєкту, їх об’єктивного стану і призводить до цілковитого розбалансування.
Тепер зосередимо увагу на типових ризиках.
- Втрата управлінської ініціативи в діях. Якщо ми не контролюємо процес, значить, хтось його контролює за нас. Ініціативність і дієвість є запорукою хорошої взаємодії з клієнтом, а отже, динаміки розвитку проєкту загалом.
- Ігнорування «слабких сигналів». Спричиняє поступове накопичення незадоволеності як з боку команди та менеджменту, так і з боку клієнта. Тож треба давати чесний, прямий фідбек.
- Сподівання, що всі ключові процеси самоналаштуються. Це призводить до втрати контролю, можливості управлінського впливу. ІТ-управлінець завжди має реально, а не номінально керувати процесами.
- Несвоєчасне реагування на бар’єри. Блокування команди чи процесів діяльності спричиняє операційний колапс. Треба забезпечувати якнайшвидше вирішення будь-яких питань, розробляючи ефективні комунікаційні та ескалаційні ланцюжки.
- Несистемне планування. Практика планування є інструментом певного моделювання нашої діяльності. Не варто відмовлятися від цього.
- Невиконання або часткове виконання ухвалених управлінських рішень. У цьому разі рветься ланцюжок реагування «причина — наслідок — результат — коригування дій — необхідний результат». Ми маємо забезпечувати стовідсоткову виконавчу дисципліну в усіх аспектах.
- Відсутність чіткості управлінського бачення. Якщо ми не розуміємо, куди йти, як можемо вести команду і проєкт в правильному напрямку?
- Брак координації та кооперації дій. Призводить до розбалансування і потенційних конфліктів. Тому відразу варто подбати про швидку, відкриту та пряму комунікацію;
- Страх втрат через неправильні дії. Бездіяльність через страх потенційних втрат — наш найгірший ворог. Помилку можна виправити, а от втрачену можливість повернути не вдасться. Несвоєчасність дій унеможливлює утворення «шансів» («вікон можливостей»).
- Невизначення потенційних переваг. Спричиняє хибну оцінку ситуації, а відтак і низку подальших управлінських помилок. Нам потрібна всебічна і швидка оцінка.
Зазначені ризики та запропоновані практики з їх хеджування варто усвідомлювати та пропрацьовувати ще на старті.
Кроки PM/BA після онбордингу проєкту
- Підтримка і вдосконалення активностей, процесів і артефактів.
- Забезпечення швидкої та якісної імплементації необхідних змін.
- Поступове підвищення якості роботи розробницьких команд.
- Забезпечення актуальності отриманих результатів з боку клієнта.
- Впровадження і підтримка інновацій у роботі команд.
Висновки
Запитаймо себе: «Що саме робить наші команди, проєкти та загалом компанію справді ефективною?». Безумовно, дієвий і результативний онбординг проєктів. Саме діяльність і взаємодія PM/BA забезпечує практичну ефективність старту проєктних робіт. Зважаючи на мій підхід до побудови єдиного робочого універсального фреймворку онбордингу, пропоную зосередити увагу на створенні таких характеристик команд:
- Розвиток системного мислення. Напрацювання практичного розуміння того, що усі частини проєкту впливають на його загальний перебіг. Це створює ефект усвідомленого управління та ухвалення рішень на всіх рівнях.
- Вдосконалення персональної ефективності та майстерності. Згуртованість колективу навколо процесу постійного навчання і розвитку професійних навичок зумовлює генерування необхідних практик та інструментів усередині команд.
- Напрацювання корисних ментальних моделей поведінки. Бажання переосмислити наявні практики, створити поведінкові моделі та командні переконання допомагає формувати критичний стиль мислення та аналізу в ухваленні рішень.
- Формування загального погляду на управління. Є необхідним компонентом центрального впровадження командних змін.
- Створення і підтримка командних навчальних практик. Здобуття та обмін знаннями та досвідом у команді.
Об’єктивна критична управлінська візія, точний підбір і використання оптимальних методичних інструментів роблять проєкти справді результативними та стратегічно успішними.
