Drive your career as React Developer with Symphony Solutions!
×Закрыть

Світло і тінь ІТ-реальності: як поєднуються РМ/ВА функції

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

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

Головна мета статті — надати читачу-практику дієвий фреймворк для здійснення функцій РМ/ВА. Для цього я покроково розкрию такі ключові питання:

  1. Ідея поєднання РМ/ВА ролей — концептуальна модель бачення.
  2. Ключові фактори успішного практичного поєднання РМ/ВА ролей у делівері-сегменті.
  3. Проблемні аспекти поєднання РМ і ВА. Лайфхаки з практики.
  4. Життєва правда поєднання РМ/ВА ролей.

Рекомендую статтю всім практикам ІТ-управління, а також бізнес-аналітикам.

Вступ

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

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

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

Ідея їх поєднання має в основі різні системні або суто ситуативні причини, наприклад:

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

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

Ідея поєднання РМ/ВА ролей

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

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

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

Ефективність кросфункційної взаємодії в ІТ-сфері формують три основні складові:

  1. Організаційна модель структури бізнесу.
  2. Функціональна наповненість ролей.
  3. Обрані фреймворки організації роботи компанії та її структурних одиниць.

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

Першим інструментом ІТ-управлінця для цього є модель концепту створення проєктної візії (Рис. 1).

Рис. 1. Модель концепту створення проєктної візії

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

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

Центральним зв’язковим елементом є функціональне наповнення ролей. Управлінець має звернути особливу увагу на поєднання функцій проєктного менеджера і бізнес-аналітика як ключових практично у будь-якому проєкті.

У поєднанні функцій РМ/ВА надважливо створити чітку картинку взаємодії об’єктів управління. Тому наступним кроком управлінця є розроблення детальної описової моделі управління взаємодією РМ/ВА ролей (Рис. 2).

Її базис охоплює:

  • Ключові об’єкти управління.
  • Основні функції РМ/ВА.
  • Фокуси уваги створення додаткової цінності міжрольової взаємодії.

Рис. 2. Модель управління взаємодією РМ/ВА ролей

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

Як читати зазначену модель? По-перше, керуватися загальновідомим принципом управління — де ваша увага, там ваші дії. У разі комбінування функцій критично важливо не випускати з поля зору всі ресурсні компоненти. Практична модель допомагає чітко усвідомити зони контролю та об’єкти відповідальності.

По-друге, модель специфікує контрольні напрями процесної роботи РМ і ВА з погляду управління.

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

По-четверте, постійне й тривале занурення у поточну роботу створює ефект звуження управлінського бачення у РМ/ВА. Так званий ефект «тунельного зору» виникає з низки причин:

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

Тому необхідно мати інструмент для критичного самоаналізу та оцінювання ефективності управлінської роботи РМ/ВА. Запропонована модель і є цим інструментом.

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

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

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

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

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

3. Створення опису детальних робочих PM/ВА процесів, за потреби об’єднання їх у єдиний процес. Мета — декомпозиція погодженої візії із визначенням дій і таргетованими результатами взаємодії.

4. Визначення показників якості РМ/ВА процесів для формування показників оцінки бажаної результативності роботи, створення підґрунтя для аналізу і вдосконалення процесів роботи РМ/ВА, а відтак і командної проєктної роботи.

5. Зіставлення і проведення критичного аналізу дій PM/ВА для пошуку і ліквідації вузьких місць РМ/ВА взаємодії та проєктної діяльності.

6. Вибір ефективних інструментів відстеження діяльності PM/ВА для оперативного отримання об’єктивної цільової інформації про бажані показники, що мають критичний вплив на ефективність роботи.

Фактори успішного поєднання РМ/ВА ролей у делівері-сегменті

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

  1. Облік і аналіз ефективності використання робочого часу.
  2. Аналіз ефективності процесного моніторингу.
  3. Контроль делегування.

Йдеться про ситуативний баланс у питанні використання інструментів організаційної ефективності.

Першим важливим аспектом організаційної ефективності діяльності РМ/ВА є результативне управління робочим часом. Для будь-якого учасника проєкту час стає критичним ресурсом через значний обсяг навантаження. З огляду на це, варто зосередити увагу на створенні ситуативного балансу щодо:

  • Витрати часу РМ/ВА на планування і виконання поставлених робочих завдань. Важливим у питанні є відсутність перевитрати часу на зайві планові активності.
  • Прозорості для команди та клієнта. Прозорість (читай зрозумілість та обґрунтованість) витрачання часу в очах команди та клієнта стає елементом професійної довіри у побудові стосунків.
  • Аналізу ефективності використання часу. Прокрастинація (самопрокрастинація чи/і її колективна форма) як явище стає проказою у роботі офісних працівників ХХІ століття. Важливо виявити непродуктивні втрати часу.

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

Важливо зосередити увагу на таких показниках процесного здоров’я:

  • Кількість процесів у моніторингу РМ/ВА, щоб розуміти обсяг організаційного навантаження на проєктну роль, побудувати процесну карту проєкту, розрахувати інші показники.
  • Реальний відсоток охопленості (підконтрольності) процесів. Цей якісний показник формується за результатами суб’єктивної оцінки РМ/ВА реальної кількості підконтрольних йому процесів, а також об’єктивної оцінки команди щодо того самого показника. Під терміном підконтрольності розуміємо швидке отримання фактичної інформації про процес (його показники), участь у процесній роботі (виконання або контроль процесних активностей), створення і постановку процесних операційних і стратегічних завдань, автоматизацію активностей тощо. Ми можемо управляти лише тим, що контролюємо фактично.
  • Кількість/відсоток результативних і ефективних процесів. Важливо розуміти принципову різницю між результативністю та ефективністю. Завдання будь-якого менеджера — фізичне налагодження результативних процесів. Після чого відбувається ітеративне підвищення їхньої ефективності. Маємо пам’ятати про це.
  • Кількість/відсоток критичних процесних ескалацій. Якісний показник здоров’я проєктних процесів. Важливий компонент оцінювання організаційної зрілості командної процесної роботи. На практиці поступово має наближатися до нульового значення. Контролює РМ. Потенційний вклад ВА полягає у розробці швидких і дієвих інструментів реагування на критичні ескалації.

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

  • Залучення лідерів команд до співпраці. Важливим аспектом ефективного управління є створення реальної командної роботи. Головними помічниками РМ/ВА є безпосередні лідери проєктних команд. Опора на них створює сприятливий емоційний робочий фон, а також демонструє вияв довіри і поваги до колег. Окрім того, це є реальною фізичною допомогою у виконанні щоденної роботи РМ/ВА.
  • Делегування роботи, коли це можливо. Не варто витрачати зайвий час на те робоче завдання, яке може краще і швидше за вас виконати вузькоспеціалізований фахівець. РМ/ВА має завжди пам’ятати про необхідність дотримання балансу у своїй роботі через поєднання функцій керівника і виконавчого працівника.
  • Визначення термінів, зон відповідальності та цільових результатів під час делегування.
  • Ідентифікація контрольних точок процесу (проміжні та швидкі результати від виконання делегованих завдань).

Проблемні аспекти поєднання ролей РМ і ВА. Лайфхаки з практики

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

  1. Фахового рівня спеціаліста, якого пропонують на роль РМ/ВА.
  2. Рівня «сеньйоріті» самої проєктної команди. Що професійнішою є проєктна команда, то легше буде поєднувати фахівцю функції РМ/ВА.
  3. Рівня організаційної та фахової підготовки клієнта і його команди. Що нижчий рівень розуміння специфіки ІТ-розробки з боку замовника, то більше часу буде вимагати залучення РМ/ВА для налагодження співпраці з ним (і менше часу залишатиметься на операційну роботу).
  4. Ефективності та адаптивності обраного або створеного фреймворку проєктної роботи і функціонального наповнення ролей проєкту.
  5. Рівня і системи проєктного трансферу знань і досвіду.
  6. Рівня розгляду, швидкості та системи ухвалення проєктних рішень, здійснення рольової підтримки внутрішнім менеджментом компанії.
  7. Психоемоційного стану кандидата на роль РМ/ВА і проєктної команди.

Поєднання ролей РМ і ВА вимагатиме від кандидата чіткого усвідомлення ризик-факторів:

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

На противагу проблемним аспектам поєднання РМ/ВА ролей пропоную використовувати такі управлінські практики:

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

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

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

3. Визначення чітких правил виконання робочих завдань. Прості, зрозумілі та обов’язкові контрольні кроки у вашій і командній роботі допоможуть усім зрозуміти послідовність дій та сформувати чіткі очікування від процесу і результатів. Правила варто узгоджувати як у письмовій, так і в усній формі. Головне пам’ятати про те, що правила мають забезпечувати контрольну, виконавчу та креативну складові процесу управління. Наприклад: «Критикуєш — пропонуй, пропонуєш — доводь через практичні результати, що маєш слушність, довів — виконуй, виконав — навчи інших».

4. Створення правил прийому та ескалації зворотного зв’язку. Можливість донесення альтернативної інформації є ключовим фактором у питаннях формування довіри та ефективності робочих стосунків у колективі та з клієнтом. За статистикою, понад 30 % проєктних помилок пов’язані із порушенням ланцюжків ескалації та отримання об’єктивного і вчасного зворотного зв’язку. Вміння слухати і чути іншу точку зору є одним із головних елементів побудови довіри. Проєктний менеджер має розробити та узгодити форми, періодику, тематику і час отримання такої інформації. І це ще на фазі ініціації проєкту у компанії, адже завжди діє принцип: «Що раніше ми отримаємо інформаційний сигнал, то краще відреагуємо».

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

6. Своєчасне оновлення робочого календаря івентів і зустрічей. Важливе для економії робочого часу, а також підконтрольності проєктних процесів. Присутність на ключових зустрічах є необхідною для налагодження особистого контакту, встановлення довіри, формування позитивного іміджу в очах колективу та клієнта. Використовуйте інструменти синхронізації пленерів та календарів. Головним завданням для фахівця, який поєднує функції проєктного менеджера і бізнес-аналітика, є не проґавити шанс в особистому спілкуванні донести свою та командну позицію. Особистий контакт не замінить навіть 10 листів. Пам’ятаймо про це!

7. Незволікання у діях. Будь-яке несвоєчасно ухвалене управлінське рішення спричиняє багато додаткових ризиків і руйнує професійну довіру команди та клієнта. Ваші вчасні дії — це створені можливості!

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

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

9. Упорядкування проєктної та аналітичної документації. Це критичний фактор швидкого пошуку потрібної інформації. Хаос породжує ризики, а документальний безлад може завдати непоправної шкоди проєкту. Невчасні оновлення документації, її несистемне ведення і заповнення призводять до непорозумінь із клієнтом. З’являються ризики втрати ділової репутації для команди, а в деяких випадках і самої ІТ-компанії. Тому основна порада — формувати в команді безкомпромісну звичку обов’язкового апдейту проєктної та аналітичної документації за правилом 24 годин.

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

11. Оновлення і вдосконалення всього із застосуванням принципу здорового глузду. Надзусилля, як і недозусилля, — це завжди неоптимальне використання ресурсів! Маємо пам’ятати, що ефективний управлінець/аналітик завжди діє з принципу «розумної достатності» у виконанні своїх завдань.

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

Життєва правда про поєднання РМ/ВА ролей

Яким чином найкраще розкрити життєвий досвід поєднання РМ/ВА ролей на практиці у концентрованій формі? Звісно, через систематизацію відповідей на запитання. Виділю 10 найбільш популярних і предметних тематичних запитань.

  1. Яка частка комбінацій ролей була б найкращою? Не існує оптимального відсоткового співвідношення. Усе залежить від конкретного проєкту чи ситуації. Десь потрібні більше РМ-скіли, а десь ВА. Насправді головне — це досягнення бажаного результату. Практично «зараховується» лише це!
  2. З чого почати будувати роль, що поєднує PM та BA? На мою думку, з ролі РМ. Оскільки вона є фундаментальною з погляду організації усіх процесів.
  3. Чи можемо ми все налаштувати і відпочити? Напевно так, але лише на короткий час. Оскільки проєктне життя надзвичайно динамічне. Постійно виникають зміни, які вимагають адаптації нашої діяльності.
  4. Чи варто постійно навчати команду та клієнта проєкту? Однозначно так! Це поступове і гарантоване підвищення ефективності роботи, створення лояльності, поетапне будівництво кращого розуміння одне одного, довіри та переконаності у професіоналізмі. Головне не перегнути палицю.
  5. Чи можемо ми поєднувати ролі PM та BA в довгостроковій роботі? З мого досвіду, у великих ІТ-проєктах усе-таки ні. Оскільки значне навантаження і постійні зміни рано чи пізно призводять до професійного та фізично-емоційного вигорання. Хоча, безумовно, все залежить від людини та організації її діяльності.
  6. Чи поєднання ролей PM і BA є найкращим вибором для проєкту? І так і ні. Усе залежить від особистості РМ/ВА, проєкту та команди.
  7. Чи є комбінація ролей РМ/ВА більш ризиковою, ніж використання окремих ролей? Будь-яке поєднання функцій управління спричиняє більше потенційних ризиків. Тому так, на нашу думку, є більш ризиковим. Хоча, звісно, бувають приємні винятки з правил.
  8. Чи означає високий рівень зрілості команди легшу роботу у ролі PM/BA? Так, адже можна швидше та якісніше налаштувати всі необхідні процеси та підтримувати їх із меншою затратою зусиль.
  9. Чи схильна людина, яка поєднує ролі РМ і ВА, частіше вигоряти? Так, і це об’єктивний процес. До цього потрібно бути готовим.
  10. Чи дає роль PM/BA швидкий прогрес у кар’єрі та розвитку компанії? Однозначно так, оскільки фахівець у цій ролі створює об’ємне бачення практично усієї проєктної роботи. Поєднання функцій сприяє швидкій адаптації в компанії. Такі фахівці, як правило, є кандидатами на підвищення після року успішної діяльності на проєкті.

Чи є універсальний рецепт поєднання РМ/ВА функцій? І так і ні. Однозначно практики ІТ-управління мають досліджувати, виявляти проблематику, говорити про структурування та описувати практичні підходи, напрацьовувати методичний базис для розв’язання цікавих завдань.

У цій оглядовій статті я спробував узагальнити та систематизувати практику поєднання РМ/ВА ролей, виходячи із власного багаторічного досвіду.

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

Дивитись відео на тему поєднання ролей PM і BA — тут.

LinkedIn

17 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хорошо понимаю Вас, коллега, т. к. сам прошёл этот путь и выполнял эти роли, как по отдельности, так и в совокупности. Не буду комментировать представленную самодельную модель, но поделюсь некоторым недоумением: не увидел тут никаких референсов на хорошо описанные и продуманные модели BABOK и/или PMBOK.Отчего так?

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

Я не оспариваю работоспособность модели. Возможно в каком-то контексте она прекрасно себя показала. Я выражаю удивление в выборе её дизайна (представления и формулировок). Если внимательно посмотреть на картинку, то сложно найти следующие ключевые слова из классических подходов: NEEDS, SOLUTIONS, VALUE, STAKEHOLDERS, CHANGES, CONTEXTS, SCOPE, COMMUNICATIONS, SCHEDULE, PROCUREMENT, RESOURCE, COST, RISK. Точнее часть из них есть, то же качество или время и деньги, но используются другие термины, а большинства областей знаний из PMBoK & BABoK эта модель не покрывает, что делает её не универсальной, и не очень понятной для применения в других контекстах. Для решения этой проблемы и были придуманы стандарты. Впрочем, это всё вопросы методологии, которые можно оспаривать.

Более практический вопрос: делали ли вы сравнение моделей компетенций для PM и BA, чтобы выявить насколько эти роли пересекаются в требуемых навыках?

Дмитро стаття дійсно виглядає як серьозне опрацювання практики та можливих підходів, або «фреймоворків» для такої мікс ролі.
Прото на мою думку головна «помилка» закладена в суцільно філософському протиріччі — що обрати — специалізацію чи об’єднання? Що дає більше переваг та недоліків? І для кого?
Якщо простими словами: Що сіньору вже зрозуміло і без статті, до джун не сприйме глубинно і з статтею....або в нього немає вибору :(. Або що може бути «корисно» для компаніі — може бути «некорисним» для працівника.
Глобально якщо не брати до уваги фінансові аспекти,та всі інші похідні — я не бачу переваг від міксів ролей, тому що на мою думку кращий результат буде на стику протиричь, конкуренції різних цілей і вимог. А коли різне обєднується в одній людині — він\вона не може «протирічіти» сам с собою, тобто це як бухгалтер і аудитор в одній особі.
Але може я не правий і стаття допоможе багатьом. Дякую.

Едуарде, дякую за оцінку, і коментарі)! Так, власне, дана стаття створена мною для допомоги тим, хто має швидко зорієнтуватися, як можна самоорганізуватися і яких помилок уникнути в результаті необхідності (ну або бажання) поєднання РМ/ВА ролі на проєкті. Звісно, що базове протиріччя закладене вже у ідеї такого рольового поєднання в одній людині, але ж на практиці це існує. А це значить, що нам потрібно напрацьовувати методичні підходи до вирішення таких нетривіальних задач) Власне роблю це базуючись на своєму РМ\ВА\РО досвіді) Дана тема знайшла свій живий відгук під час проведення відкритого вебінару, власне в першу чергу у фахівців рівня джуна, мідла, і не тільки. Буду радий поспілкуватися детальніше по питанню при нагоді) Дякую!

Чудова стаття з точки зору побудови. Але це НЕ про Бізнес Аналіз, це розширена методика проектного менеджменту.

Максиме, так це візія поєднання ролей (у випадку такої потреби у компанії чи проєкті) в основі якої лежить роль РМа як системної проєктної ролі! У ній я даю візію, поєднання зон відповідальності, точок контролю, необхідних інструментів які використовують як РМ так і ВА (залежно від існуючої практики). Роль ВА у даному підході є не менш важливою у питаннях пошуку гепів і створення додаткової цінності (про що власне і йдеться), це я зобразив у своїй моделі. НЕ мав на меті розкриття суто використання аналітичних технік, адже це окрема тема! Дякую.

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

Доброго дня, Денисе! Дякую за валідні коментарі) Так такий досвід був і є значним. Були різні проєкти і команди. Від класичного Waterfall, до SAFe & LESS практики) Найменша команда від 5 чоловік, набільша до 13 чоловік. Кількість команд різною була від 1 до 4 максимально. Тривалість проєкту від 3 місяців до 2 років. Проєкти різного роду були: автоматизація торговельної і виробничої діяльності (різіні системи), останні 6 років лише класичний ІТ девелопмент. Чи завжди була така практика вдалою, ні не завжди. На мою суб’єктивну думку дійсно вдалою була десь у 30 % випадків. Під контекстом вдалості, розумію в першу чергу бажану результативність ролей. Про складнощі і потенційні наслідки такого поєднання ролей, я якраз і писав в тому числі. Чи варто довгостроково поєднувати ці ролі за необхідності, як і казав, це складне багатофакторне питання, яке залежить від особистості кандидата і контексту робочої ситуації, компанії, клієнта. Та проте, таке поєднання це, як правило, завжди великий додатковий вклад енергетичних, психоемоційних та часових зусиль людини) Іноді звичайно надто великий. Зате досвід просто неоціненний! Із малими ІТ проектами і командами питань і проблем як правило не виникало.

Аплодую такому аналізу. Можливо варто в заголовку вказати що насправді не варто так робити але якщо змусили, то головне при цьому не писати софт для боїнгів і атомних електростанцій.
Будь яке поєднання це не 50+50 а 100+100. І особливо воно небезпечне для ролей які мають між собою домовлятися і балансувати для прийняття оптимальних рішень. Самому з собою надто легко домовлятися, тому якщо в тому переважає ПМ — занепад продукту, якщо переважає БА — команда загнеться. Те саме відновиться до BA/QA сумісників. Ці ролі вимагають різних і часто протилежних когнітивних здібностей

Дмитре, дякую за цю високу оцінку! Ваші коментарі дуже влучні і валідні) Продовження буде, працюю над цим)

особливо воно небезпечне для ролей які мають між собою домовлятися і балансувати для прийняття оптимальних рішень

Вот, кстати, да. Ещё в приснопамятном Microsoft Solutions Framework была табличка с указанием того, какие роли можно сочетать в одном человеке, а какие — очень не рекомендуется.

Я бы сравнил объединение ролей PM/BA со всесезонной резиной: вроде работает и зимой и летом, но и там и там не очень. Если проект небольшой и без сложной бизнес логики (аналог «езжу редко и только в хорошую погоду») то такой подход может сэкономить бюджет. В противном случае — мнимая экономия, которая выливается в плохое качество и/или большое число переделок.

Цікава стаття, дякую. Я би все-таки не радила поєднувати ці дві ролі в одній людині, крім випадків коли проект маленький або у фазі сапорту.

Мої спостереження такі — є два поширені сценарії РМ (проджекта) і ВА (або продакта) 2-в-1:
1. Проджектова робота займає 90% часу, бізнес-аналіз робиться за залишковим принципом (10%). На такі активності як юзер тестинг і аналіз даних часу не залишається зовсім.
2. Проджектова робота займає майже увесь робочий день («перша зміна»), а потім пізно ввечері робиться ВА/продуктова робота («друга зміна», коли ніхто не відволікає). Наслідок — вигорання.

Дякую, Галино! Запропонована у статті візія є власне результатом вже існуючої у діяльності ІТ компаній практики поєднання таких ролей. Власне, я також наголошую на ризику вигорання працівника, як в основному матеріалі, так і у висновках до статті. Частина рекомендацій спрямована на превентивні заходи щодо усунення реально існуючого ризику такого вигорання. Головною метоє є надання інструментарію та візії для ефективного функціонування фахівція, що вимушено чи добровільно вже поєднує, або планує поєднати зазначені ролі, через вплив тих чи інших проєктних обставин та\або вимог бізнесу. У своїх відповідях на актуальні питання по темі, я чітко вказую на те, що у випадку великих ІТ проєктів, я зі свого досвіду також не рекомендую поєднувати дані ролі у довгостроковій перспективі. Хоча, знову ж таки, все сильно залежатиме від особистості працівника і умов діяльності проєкту. Були і позитивні виключення із правил. Дякую за ваші коментарі!

Не совсем понимаю почему ПМ работа занимает 90% капасити. ПМ как раз должен стремиться себя разгрузить чтобы иметь достаточное капасити на превентивную работу по рискам и возможностям. Чтобы ПМ был эффективен у него не должен над головой висеть дамоклов меч обязанностей и митингов которые выжигают и его энергию и время. Это слишком стрессовый режим который приводит к выгоранию.

Я не рекомендую связывать ПМ+БА кроме стартового трамплина в IT. Если мидл+ объединяет эти две роли, он только зря тратит своё карьерное время и недополучает ПМ навыки и пододвигает себя поближе к двери и к тухлым вакансиям.

Если есть любовь к ПМ+БА то будет лучше пойти в Продакт Менеджеры и не тратить своё жизненное время на этот костыль.

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