Нояб. 27

Cтворюємо універсальний підхід управління ІТ проєктом. Погляд менеджера

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

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

У сучасному вітчизняному ІТ-менеджменті практично не приділяють уваги роботі над такою концептуальною річчю, як фреймворк. Зазвичай українські менеджери намагаються залучати відомі, практично виправдані й перевірені методи управління, і це безумовно добре. Але часто у складних і неординарних проєктах ці підходи вимагають переосмислення і трансформації відповідно до специфіки бізнесу клієнта. Саме тоді на перший план виходять питання стратегічного розуміння і бачення можливої організації ефективної проєктної роботи. Сьогодні є чітка потреба у простому, зрозумілому, універсальному підході до побудови робочого процесу, як то кажуть, «з нуля» із можливістю його подальшої модернізації.

Підхід до створення універсального проєктного фреймворку

Для управлінця (РМ/ВА/DM/Prg.M тощо) робочий фреймворк передусім є інструментом ефективної організації та розуміння роботи. За весь час існування ІТ-галузі у світі було створено багато підходів до управління проєктами. Більшість із них базуються на технічних аспектах роботи команд. Наша мета — сформувати та розкрити бачення на створення універсального підходу до розробки фреймворку з погляду управління і цінності, яку може принести цей процес проєкту і клієнту, а також на сам фреймворк як управлінський інструмент. Розгляньмо запропонований авторський концепт універсального проєктного підходу (Рис. 1).

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

Навколо чого ми об’єднуємось як команда? Це цінності (project core value) відповідно до особливостей співпраці з клієнтом.
Як саме наша команда планує втілити цінності в рамках проєктних цілей? Це організація основних компонентів командної роботи (framework core).
Як гнучко можемо контролювати проєктну діяльність на всіх рівнях управління, а також як швидко і легко можемо реалізувати необхідні проєктні зміни? Це адаптивність проєктної роботи.

Ці компоненти та характеристики — основа ефективного управління проєктною роботою. В основі створення фреймворку пропоную використовувати принцип єдності взаємодії всіх компонентів як цілісної системи:

Рис. 1. Концепт створення універсального проєктного фреймворку

Політики (project policies)

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

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

Принципи командної роботи (teamwork principals)

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

Структурований взаємозв’язок об’єктів проєктної роботи (project context diagram)

Щоб зрозуміти проєктну специфіку, треба з’ясувати взаємозв’язок і структуру об’єктів роботи. Створення такої моделі, її постійна підтримка в актуальному стані допоможе команді та клієнту мати:

завжди оновлену загальну картину проєктної дійсності, яка необхідна для відстеження стратегічних змін;
можливості внесення оновлень на основі контекстної інформації у базові робочі домовленості із клієнтом.

Показники ефективності, моделі делівері-процесу (Delivery model based on SDLC type and SDLC KPI’s)

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

Метрики оцінювання ефективності процесу делівері пов’язані із блоками активностей загального процесу роботи ІТ-команди (team workflow) і є джерелом важливої інформації для підвищення якості роботи.

Усі показники ефективності процесу делівері пропоную групувати так:

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

Усю сукупність показників далі розподіляємо не тільки за блоками активностей, а й за рівнями: проєктним, процесним і продуктовим. Такий аналітичний розподіл створює модель огляду показників ефективності делівері-процесу за принципом T-sharp model і є всеохопним за своєю дією. Отримані метрики ефективності також використовують для визначення і ліквідації вузьких місць у роботі.

Робота команди та її найкращі практики (Team workflow and Practices)

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

Також кожен крок і блок процесу роботи команди пов’язаний безпосередньо із практиками як головними чинниками та інструментами постійного вдосконалення.

Структурна модель проєктних активностей і їхніх артефактів (Project activities structure model)

Проєктні активності є вагомим компонентом структурування дій усіх членів команди. Особливо важливим є формування блоків, детального переліку та артефактів як результатів активностей уже на етапі онбордингу проєкту. Закладена від початку структура активностей буде зберігатися і стане основою для наступної проєктної роботи. Стан і результати виконання активностей є основою оцінювання загального показника контрольованості роботи. Що, своєю чергою, сигналізує компанії та клієнту про успішність управління. Для зручності рекомендую розподіляти всі проєктні активності та їхні артефакти за такими групами:

налаштування проєктної комунікації;
робота над продуктом (продуктова візія і функціональність);
налаштування командної взаємодії;
налагодження делівері-процесу і відповідності стандартам роботи клієнта;
проєктне урядування.

Найкращі командні практики роботи допоможуть результативно та ефективно налаштувати всі необхідні активності та створити ефект прозорості та контрольованості роботи загалом.

Усі вищеперелічені компоненти проєктної діяльності поділяємо на дві великі групи (півсфери схеми моделі):

Ідеологічний базис (Ideology part) — основа меж взаємодії та розуміння проєктного контексту.
Імплементаційний базис (Implementation part) — детальне бачення операційної взаємодії.

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

Створення імплементаційної групи

Для впровадження фреймворку потрібно створити імплементаційну групу з такими ролями: програм-менеджер (Prg.M), делівері-менеджер (DM), проєктний менеджер (PM), бізнес-аналітик (ВА), архітектор (Arch.L), девелопмент-лід (Dev.L). Концепт її заснування має низку переваг:

Забезпечення широти експертних думок.
Централізоване створення і драйв необхідних ініціатив.
Формування внутрішнього консалтингового напряму роботи проєкту.
Контроль формування необхідної бази управлінського досвіду.
Створення джерела синергії взаємодії у проєктній команді.

Рекомендую максимально використовувати графічне моделювання як найбільш наочний та зрозумілий стейкхолдерам інструмент. Наприклад, для створення процесних діаграм — BPMN-нотацію, загальні структурні схеми тощо. Деталізація компонентів фреймворку має поєднуватися зі створенням окремих інструктивних і описових матеріалів для:

SDLC KPI’s — описові таблиці та формули розрахунку.
Teamwork Principals — короткий та чіткий опис ідей принципів.
Project Policies & Basic Agreements, Team Practices — корпоративні або кастомні (спеціалізовані) під проєкт шаблони (templates) з описом застосування.
Project Data Context — контекстна діаграма з описом.
Team workflow — BPMN-діаграма з описом застосування.
Project Activities — структурна діаграма з описом (більше про це читайте у моїй попередній статті).

Усі деталізовані та описані графічно компоненти логічно згрупувати у комплексну схему для цілісного сприйняття. Розгортання такої деталізації має відбуватися навколо ядра проєктного фреймворку. Додатковий текстовий опис раджу збирати в одному інформаційному ресурсі (наприклад, Confluence).

Підтримка проєктного фреймворку (project framework maintenance) як один із видів проєктних активностей має свої особливості:

У робочій групі впровадження фреймворку має бути спеціаліст, який виконуватиме функцію проєктного методолога. Цю роль може виконувати будь-який фахівець із команди імплементації фреймворку.
Впровадження підходу вимагає чіткого планування дій як у проєктній команді, так і з боку клієнта. Для цієї активності вже на етапі діскавері та онбордингу проєкту необхідно виділяти достатню кількість часу.
Зміни у будь-якому проєкті є фактичною його константою. Тому імплементаційна команда має враховувати необхідність гнучкої реакції на потенційні оновлення фреймворку.
Робоча група має відразу створити інструкції та поширити інформацію щодо впровадження робочих компонентів фреймворку в середовищі команд розробки.
Фреймворк-методолог має забезпечити ефективний зворотний зв’язок із командою та замовником для коригування дій із впровадження підходу.

Основні складнощі при впровадженні

Проєктна робота — це завжди виклик для управлінця, адже не буває двох абсолютно однакових проєктів. Так і впровадження проєктного фреймворку у роботу є унікальним управлінським і методологічним досвідом для ІТ-фахівця будь-якого рівня. Серед головних викликів впровадження проєктного фреймворку у роботу ІТ-команд можна виділити:

Навчання проєктних команд, які можуть мати фахівців із різноманітним досвідом проєктної роботи.
Формування єдиного бачення проєктних дій згідно із фреймворком роботи. Створення синергії дій усіх учасників проєкту є важливим чинником набуття продуктивності команд.
Швидке вдосконалення проєктного фреймворку. В ІТ-проєктах важливим є вміння швидко і якісно впровадити зміни. Цей процес вимагає повної залученості імплементаційної групи, що не завжди просто з погляду робочого і часового навантаження.

Висновки

Запропонований фреймворк є відкритою для вдосконалень практично апробованою моделлю. Для вдосконалення підходу пропоную керуватися принципами:

Забезпечення комплексної управлінської візії.
Критичного аналізу ланцюжка каскаду наслідків реалізації змін.
Дотримання універсальності у виборі методичних інструментів роботи ІТ-команд.
Формування альтернативних поглядів на імплементацію фреймворку конкретного ІТ-проєкту.

Серед питань про створення універсального фреймворку роботи проєкту можу виділити такі:

Дослідження застосування цього підходу в різних доменних експертизах. Створення статистики та визначення особливостей застосування.
Формування та опис широкої бази знань і досвіду рольової участі ІТ-фахівців у впровадженні проєктного фреймворку.
Визначення подальших перспективних компонентів структури фреймворку.

Саме таке бачення побудови та принципи застосування створюють єдність сприйняття запропонованої практичної моделі.

Відео із серії відкритих ЕРАМ-вебінарів із кросфункційної взаємодії/поєднання функцій РМ/ВА:

Щоби не пропустити нові статті Дмитра Лозовицького — підписуйтеся на нього у телеграм-боті Стрічки DOU.