Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Як провести вдалий онбординг ІТ-проєкту. Підхід структурованого менеджменту для 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 у підході структурованого менеджменту

Якою ж є роль проєктного менеджера і бізнес-аналітика чи поєднання цих посад у запропонованому підході? Однією із найважливіших! Достатньо детально розглянути активності та їхній розподіл за ролями у фреймворку (дані наведено просто для прикладу). Завдяки запропонованому підходу на основі принципу «конструктора» ми з легкістю можемо змоделювати будь-яке необхідне комбінування взаємодії/поєднання функцій. Достатньо лише розподілити фокуси уваги РМ/ВА за типами активностей в межах блоків.

Однак в управлінській практиці складається стандарт класичного фокусування під час взаємодії та/або поєднання ролей РМ/ВА:

  1. Основний фокус уваги у роботі PM:
    • практика налаштування усіх процесів;
    • контроль ефективності виконання роботи командою;
    • створення планів діяльності та контролю їх виконання.
  2. Основний фокус уваги у роботі BA:
    • дослідження продукту чи сервісу, який доведеться розробляти чи вдосконалювати;
    • створення і коригування беклогу, підтримка процесу його управління;
    • передача продуктових та бізнесових знань і досвіду розробницьким командам.
  3. Основний фокус уваги у спільній роботі PM і BA:
    • налаштування командної взаємодії та роботи;
    • робота із вдосконалення якості процесів;
    • робота над кращою залученістю і взаємодією із клієнтом;
    • робота над якістю делівері;
    • робота над поліпшенням показників задоволеності клієнта;
    • ризик-менеджмент.

Маючи зазначений орієнтир і використовуючи вищезапропонований фреймворк, читач-практик легко зможе втілити потребу в комбінуванні функцій РМ/ВА на конкретному проєкті.

Критичні помилки та ризики під час онбордингу проєкту

З власного досвіду розповім про головні помилки під час онбордингу ІТ-проєкту з боку РМ і ВА, яких варто уникати.

Відсутність підготовки. У цій ситуації, як правило, РМ і ВА розраховують на можливість так званого гнучкого орієнтування у процесі ІТ-проєкту, апелюючи до критерію гнучкості та неможливості необхідного планування через постійно змінні умови діяльності клієнта. Насправді у менеджера завжди має бути чіткий і зрозумілий план дій. Так, ми маємо бути адаптивними, але без плану ризикуємо занурити проєкт і діяльність команди в управлінський хаос, породжений змінними запитами самого клієнта. Ця практика призведе до великих управлінських проблем, що межують із ризиком цілковитого провалу.

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

Відсутність структурованого бачення. Може призвести до недовіри як усередині команди, так і з боку клієнта.

Неузгодженість у баченні процесів, які відбуваються між командою, менеджментом і клієнтом. Ризик відсутності єдиного стратегічного та оперативного бачення вирішення викликів спричиняє небажані управлінські ініціативи на всіх рівнях взаємодії. У кінцевому результаті призводить до хаосу.

Небажання вимірювати управлінську ефективність (або приховування цього). Така практика породжує ризик системної помилкової оцінки підконтрольності процесів проєкту, їх об’єктивного стану і призводить до цілковитого розбалансування.


Тепер зосередимо увагу на типових ризиках.

  • Втрата управлінської ініціативи в діях. Якщо ми не контролюємо процес, значить, хтось його контролює за нас. Ініціативність і дієвість є запорукою хорошої взаємодії з клієнтом, а отже, динаміки розвитку проєкту загалом.
  • Ігнорування «слабких сигналів». Спричиняє поступове накопичення незадоволеності як з боку команди та менеджменту, так і з боку клієнта. Тож треба давати чесний, прямий фідбек.
  • Сподівання, що всі ключові процеси самоналаштуються. Це призводить до втрати контролю, можливості управлінського впливу. ІТ-управлінець завжди має реально, а не номінально керувати процесами.
  • Несвоєчасне реагування на бар’єри. Блокування команди чи процесів діяльності спричиняє операційний колапс. Треба забезпечувати якнайшвидше вирішення будь-яких питань, розробляючи ефективні комунікаційні та ескалаційні ланцюжки.
  • Несистемне планування. Практика планування є інструментом певного моделювання нашої діяльності. Не варто відмовлятися від цього.
  • Невиконання або часткове виконання ухвалених управлінських рішень. У цьому разі рветься ланцюжок реагування «причина — наслідок — результат — коригування дій — необхідний результат». Ми маємо забезпечувати стовідсоткову виконавчу дисципліну в усіх аспектах.
  • Відсутність чіткості управлінського бачення. Якщо ми не розуміємо, куди йти, як можемо вести команду і проєкт в правильному напрямку?
  • Брак координації та кооперації дій. Призводить до розбалансування і потенційних конфліктів. Тому відразу варто подбати про швидку, відкриту та пряму комунікацію;
  • Страх втрат через неправильні дії. Бездіяльність через страх потенційних втрат — наш найгірший ворог. Помилку можна виправити, а от втрачену можливість повернути не вдасться. Несвоєчасність дій унеможливлює утворення «шансів» («вікон можливостей»).
  • Невизначення потенційних переваг. Спричиняє хибну оцінку ситуації, а відтак і низку подальших управлінських помилок. Нам потрібна всебічна і швидка оцінка.

Зазначені ризики та запропоновані практики з їх хеджування варто усвідомлювати та пропрацьовувати ще на старті.

Кроки PM/BA після онбордингу проєкту

  1. Підтримка і вдосконалення активностей, процесів і артефактів.
  2. Забезпечення швидкої та якісної імплементації необхідних змін.
  3. Поступове підвищення якості роботи розробницьких команд.
  4. Забезпечення актуальності отриманих результатів з боку клієнта.
  5. Впровадження і підтримка інновацій у роботі команд.

Висновки

Запитаймо себе: «Що саме робить наші команди, проєкти та загалом компанію справді ефективною?». Безумовно, дієвий і результативний онбординг проєктів. Саме діяльність і взаємодія PM/BA забезпечує практичну ефективність старту проєктних робіт. Зважаючи на мій підхід до побудови єдиного робочого універсального фреймворку онбордингу, пропоную зосередити увагу на створенні таких характеристик команд:

  • Розвиток системного мислення. Напрацювання практичного розуміння того, що усі частини проєкту впливають на його загальний перебіг. Це створює ефект усвідомленого управління та ухвалення рішень на всіх рівнях.
  • Вдосконалення персональної ефективності та майстерності. Згуртованість колективу навколо процесу постійного навчання і розвитку професійних навичок зумовлює генерування необхідних практик та інструментів усередині команд.
  • Напрацювання корисних ментальних моделей поведінки. Бажання переосмислити наявні практики, створити поведінкові моделі та командні переконання допомагає формувати критичний стиль мислення та аналізу в ухваленні рішень.
  • Формування загального погляду на управління. Є необхідним компонентом центрального впровадження командних змін.
  • Створення і підтримка командних навчальних практик. Здобуття та обмін знаннями та досвідом у команді.

Об’єктивна критична управлінська візія, точний підбір і використання оптимальних методичних інструментів роблять проєкти справді результативними та стратегічно успішними.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному7
LinkedIn

Схожі статті




9 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Доброго дня, Тарасе! Дякую за коментар! Будь яка активність починається із організації роботи людей. Способи організації є різними за формою, проте, не залежно від форми, мають призводити до одного результату: розуміння того, що, як саме, коли, ким, і з якою результативністю\ефективністю має бути зроблено. Якщо готворити про РМ \ ВА ролі як ролі які є ключовими з точки зору організації роботи команди, то варто відзначити декілька важливих аспектів:
1. РМ і ВА, як управлінцю і аналітику потрібно розуміти цілісно як і чим з точки зору об’єктів управління керувати, як це презентувати клієнту, як показати організаційну частину активностей команди і їх вплив на загальний перебіг проєкту! Що безумовно, жодним чином, не виключає, а навпаки включає, в себе і знання продуктової частини проєкту (продукту, це окреме місце у моїй моделі — цілий блок активностей), і знання того як саме команда має (читайте — буде) приходити до результату.
2. Так загальна управлінська картинка дійсності — це завжди модель — нашими словами фреймворк. Це свого роду універсальна річ (інструмент) яку (який) ми можемо і маємо будувати, імплементувати через навчання наших команд, через створення необхідних інструментів роботи. Тільки так, через грамотну управлінську роботу ми злагоджуємо роботу команди, і робимо зрозумілим та прозорим наш процес роботи — напрацьовуємо траст у клієнта! Це робота не одного місяця, якщо ми говоримо в першу чергу про великі ІТ проєкти, і компанії. У зв’язку із цим нам потрібен фреймворк особливо під час старту наших проєктів! Будь який досвідчений (бувалий) проєктний менеджер чи бізнес аналітик знає це відчуття контрольованості, а від так і прогнозованості резульатів, коли він і команда(и) ідуть чітко як по нотам по пропрацьованому плану дій, чеклісту як завгодно. Скільки організаційних зусиль і ресурсів ми можемо економити маючи і діючи згідно пропрацьованого (апробованого) фреймворку!
3. Якість продукту, як і якість будь якої діяльності яка його створює, визначається якістю процесів проботи команди! Це і є основа для наступного проєктного аудиту! Відповідність процесів до вимог і стандартів якості обраних як орієнтир у роботі проєкту (команд). Так створена, запропонована і апробована модель є універсальним інструментом: на початку проєкту (його онбордингу) як інструмент організації, а надалі як інструмент контролю ефективності внутрішньої роботи команд, і звичайно базаою для проведення аудиту! Саме так, потім базою для проведення аудиту якості!!!
4. Не бачу жодних обмежень чи концептуальних протиріч, щоби дивитися на можливості використання такого методичного інструменту як модель (фреймворк) з різних позицій управління, аудиту, і т.д. Це лише напрацьовує широту візії ІТ управлінця, роблячи його пройесійні навички організації і аналізу глибшими і універсальнішими у можливому їх використанні!

Дмитрий, мне понятно все, что вы говорите в этом комментарии. В то же время, ничего из вышеприведенного у меня не получается применить как ответ на мой вопрос.

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

Я немного не понял. Статья называется «онбординг», все тело статьи — о том, как проводить аудит проекта.

Несколько вопросов:
— как автор понимает онбординг проекта? По определению, это the action or process of ... familiarizing a new customer or client with one’s products or services. Т.е. я ожидал набор активностей для ознакомления всех сторон проекта с тем, как он будет проведен. В статье представлен шаблон аудита проекта — кто ответственен, за какую область, какой статус сейчас, как сделать его выше и т.п.
— я что-то не так прочел?

Аналогичные мысли. Словно наелся мух с котлетами. Onboarding имеет свой набор активностей, часть которых соответствует представленной картинке, только причём здесь тогда аудит и оценки?...

Владимир, модель это основа структуривания и группирования активностей управленца во время онбординга проекта. Она в последующем времени основа для проектного контроля (аудита, если взять вопрос коллеги), так как большинство приведенных активностей и процессов переходят в следующие фазы управления проектом. Оценка подконтрольности прохождения (сетапа) основных проектных активностей по методу светофора, необходима управленцу для понимания общей динамики картинки того, что реально сделано командой для успешного прохождения онбординга. Фишка подхода не просто в перечне основных обязательных онбординг активностей, а и в понимании того, как их целостно видеть, и конечно оценить успешность их прохождения на этапе онбординга. В любом случае, это визия, моя визия, структурирование концепции, которое прошло неоднократную аппробацию практикой.

Идею я понял, но давайте тогда разделять:
1 — Онбординг, это набор определённых активностей и артефактов, которые из этого должны получится. И здесь ваша визия не уникальна и повторяет общие практики из тяжелых методологий.
2 — Аудит, это инструмент контроля, проверяющий в основном наличие артефактов, которые должны были получится в результате онбординга.

Перейдемо на українську. Стаття ж називається

Як провести вдалий онбординг

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

Денисе, у статті наведений цілий підхід (читайте інструмент). Концепт бачення із врахованим практичним досвідом у фахівців завжди дають хороший результат! Однаково важливими є і досвід і безумовно знання продукту. Фокус у статті в першу чергу на управлінських діях фахівця під час онбордингу проєкту. Саме помилки управлінця можуть бути критичними, особливо під час старту проєкту. Адже він керівник, і має мати комплексну візію того що, коли і як має відбуватися) Це знають усі менеджери) Вивід продукту на ринок це окрема тема) У статті фокус уваги більше на візії і інструменті готовому, як шаблон, для застосування управлінцем. А «Реальне розуміння того, що ми контролюємо в процесі управління...» не означає, що менеджер не має розуміти продукт) У тексті статті чітко відзначений і цей поінт) Дякую вам за коментар!

Кожен менеджер знає про важливість і значення процесу онбордингу проєкту. Від ефективності його «заведення» і старту робіт буде залежати розвиток і стратегія взаємодії із клієнтом. У цьому контексті хочу навести цитату легендарного практика сучасного менеджменту Іцхака Адізеса: «Реальне розуміння того, що ми контролюємо в процесі управління, допомагає нам уникнути близько 70% помилок!».

К сожалению, текст статьи не соотносится с цитатой.
Цитата же о знании доменной области — ПМ с опытом менеджмента успешно завалит проект, а ПМ, который разбирается в применении продукта — сможет вывести его на рынок.

Підписатись на коментарі