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

    Справді досвічені менеджери-практики розуміють, що без певної схеми (підходу) до організації (тобто фрейму в тому чи іншому вигляді) неможливо ефективно керувати будь якими ІТ проєктами, особливо великими 500+ чоловік, 30+ команд розробки наприклад. Фахові проєктні менеджери знають реальні проєкти на «колінках» і «на око» не робляться. З таких якраз нефахових підходів і «ростуть ноги» майбутніх факапів... Організація роботи команд розробки потрібна усім проєктам БЕЗ ВИКЛЮЧЕННЯ, практики справді знають це))! Інше питання у її форматі, виді, структурі, наповненості необхідним інструментарієм, способах впровадження! А хто сказав, що менеджер має мислити лише категоріями проєктів??? Ні це не так, хороший фахівець має завжди мислити широко! А робочий фреймворк абсолютно не заперечує мислення категоріями продукту! Просто необхідно знати, де ця візія міститься в ньому, і як вона поєднується із управлінськими підходами)! Колеги, пропонуйте, вдосконалюйте, апробуйте, доводьте ефективність ваших підходів, пишіть і діліться знаннями! До цього зокрема у кінці статті я і закликаю)! Чи щось заважає ??? ;)

  • Як провести вдалий онбординг ІТ-проєкту. Підхід структурованого менеджменту для PM/BA

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

  • Як провести вдалий онбординг ІТ-проєкту. Підхід структурованого менеджменту для PM/BA

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

  • Як провести вдалий онбординг ІТ-проєкту. Підхід структурованого менеджменту для PM/BA

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

    Підтримав: Valerie Denissiuk
  • Як провести вдалий онбординг ІТ-проєкту. Підхід структурованого менеджменту для PM/BA

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

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

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

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

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

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

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

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

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

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

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

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

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

    Підтримав: Ivan Rudiuk