top of page

Лозовицький Дмитро

PM/BA interaction: in the Development Teamwork Process Setup 

Ideal Project Role Characteristics

  1. Visioner & Value Creator

  2. Organizer & Controller

  3. Analyzer & Improver

  4. Critical thinker & Talented executor

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

Взаємодія на проекті, як об'єкт управління, вона в своїй основі залежить від ефективності взаємодії двох ключових ролей PM & BA.

GM -> DM -> PM -> BA -> QA -> TL -> DEV

BA — це не просто людина, яка може як завгодно взаємодіяти. Є чітка ієрархія, конкретне місце на проекті.

Project Role Main Attributes Vision

  1. Purpose (для чого ця роль існує) -> Framework vision (десь вимагається Framework vision) (або в голові в керівництва)

  2. Objects of control (об'єкти роботи) -> Project specific & Framework vision (процеси, активності, артефакти, люди)

  3. Function -> Project specific & Framework vision & Managerial vision

  4. Interaction -> Project specific & Framework vision & Managerial practice & Teamwork practice

  5. Expected results -> Project specific & Framework vision & Managerial estimation & Teamwork practice & Influence Client Expectations

Якщо ви зможете чітко прописати кожен з 5 атрибутів для вашої ролі на вашому проекті ви зробите собі гарну послугу.

 

Сторінка 2

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

Project Role Main Attributes GAPs Analysis approach

Role Attributes

PM

BA

...

1. Purpose



 

2. Object of control



 

3. Function



 

4. Interaction



 

5. Expected results



 

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

Коли відбувається модифікація ролей на проекті чи PM чи BA то ми маємо 7 кроків корекції роботи проектних ролей. Для того щоб відкоригувати або поєднати роботу проектних ролей.

Chain of 7 steps for Project Roles Teamwork CORRECTION

  1. Team's project framework understanding

  2. Main project roles functions analysis

  3. Interdependence of project role function - risk of impact determination on the process and results of the team's work

  4. Possibility of remedial actions assessment

  5. Role and functional teamwork situational adjustment

  6. Teamwork results critical operational analysis in the condition of changed role components

  7. Rollback to the established project teamwork scheme

 

Сторінка 3

В даному дійовому ланцюжку важлива послідовність вашого мислення щодо виконання тією чи іншою ролю тих чи інших речей на проекті. Виконання своїх функцій, проведення своїх активностей, робота зі своїми об'єктами. В даному випадку необхідно аналізувати роботу ролі і коригувати роботу ролі згідно послідовності цих семи пунктів. Тоді у вас не буде проколів. Дуже часто люди бачать, що можна змінити функціональне наповнення ролей на проекті і PM & BA і бездумно "ти сьогодні формував скоуп, ну давай ти тобі додатково докинемо менеджмент ризики, потім ще щось і ще щось". Не думають ні про задвоєння функцій, ні про те що це буде штатити якусь частину роботи, не думають про те як воно відобразиться не тільки на індивідуальних результатах, а й на командах.

Teamwork Phases

(Графік показує криву ефективності команди в залежності від фази)

Focus on result (Y-axis) vs Focus on team relations (X-axis)

  1. Forming (спад на графіку)

  2. Storming (найнижча точка - криза)

  3. Norming (зростання)

  4. Performing (пік ефективності)

  5. Dissolution & Transformation (поступовий спад або завершення)

 

Сторінка 4 (Деталізація BA по фазах)

Forming BA: Бізнес аналітик він не сидить і чекає поки його пустять до стейкхолдера і він нарешті займеться своїм баклогом, дослідженням продукту і так далі. Крім цих речей він може і має сапортити сетап командних процесів. Поки стартує проект він має можливість зосередитись і подивитись а де ми провисаємо з організаційною частиною. Закрити ті чи інші GAP, підказати PM що тут і тут ми маємо робити ось так. Хто як не він має продумати аналітичну структуру процесів разом з PM, описати її та довести цей опис до команди.

Інформаційний вакуум в який попадає команда на початку проекту, він висаджує психіку людей, не варто тримати всю інформацію лише на середній управлінській верхівці проекту і не спускати інформування команді. PM і BA мають вчасно інформувати команду про перебіг подій на проекті (апдейти прилітають часто).

Storming BA: В нас є взаємодія команди між собою або між командою і клієнтом і тут має трапляються issues. BA може вирішувати частину issues, які він може вирішити. Але BA в першу чергу аналізує характер цих issues (чи це є інформаційний вакуум, десь комусь ми щось не до розказали). Чи це є організаційний прокол (хтось щось не застапив, не вчасно відреагував. Чи це технічні issues пов'язані з наданням доступів. BA має підсапортувати PM-а тому що в PM-а роботи буде вистачати. Він може брати на аналізувати характер цих issues. Може і має доводити цю інформацію до PM!

  • KPI робота над продукуванням KPI дозволяє виявляти GAP.

Norming BA: Працює над кількістю і якістю Backlog команди. Тому що під час Storming backlog завжди важливий.

Performing BA: Якщо команда починає перформити краще, більше, то відповідно і BA не буде зівати, тому що BA це та людина, яка біжить перед паровозом. Він створює для команди роботу. Він має дати акцент на швидкість сапорту команди відповідно будь-яких питань.

Dissolution & Transforming BA: Інформаційний контроль, щоб команда не була у вакуумі. Люди виходять з проекту і BA мав передавати тій чи іншій особі інформації про результати роботи, про функції, про обов'язки.

 

Сторінка 5

PM & BA coordination work

  • Everyday communication meetings

  • PM/BA individual and team expertise

  • Leadership by specific tasks

  • Involvement of experts

  • Teamwork on issues

  • Quick team knowledge creation and sharing

PM/BA Leadership activities levels

As improvement driver

As controller - forms and describes new implemented work practice

As expert - presents and provides proofs for next coordination at project level

Creates and leads initiative


 

1. Work issue identification

6. New practice implementation in Teamwork

8. Share new Teamwork practice on Project Level

2. Issue analysis

7. New Practice results discussion on Teamwork level

9. New teamwork practice implementation results analysis and confirmation on Project level

3. Issue resolving (Decision making)

8. Forming new Teamwork practice

10. Make improvements on Framework level

4. Decision testing


 

5. Decision results confirmation


 

Apply "To Pull" approach for current processes improvement

  • For team actions synchronization

  • For quick processes efficiency check

  • For better visibility of achieved results

 

Сторінка 6

Main Teamwork Principals

  • Every team drives its activities till results are gained (Ми всі працюємо на результат)

  • Team sets up quick and direct internal and external communication

  • Everyone is responsible for results

  • All teamwork improvements should be fast and honest

  • Teamwork efficiency analysis is permanent

  • Collective system of decision making

  • Teamwork flexibility to any kind of changes is our priority

Work with Team GAPs

  • Teamwork improvements

  • New solutions and tools providing

  • New knowledge sharing and experience creation

  • Scaling gaps work

[Diagram Flow]

(Circle: Task, Issue, Process Activities GAPS) -> Identification on team level -> Forming work approach -> Testing work approach -> (PM & BA group interaction review testing work approach results) -> Accepting work approach and implementation on cross team's level -> Confirm work approach results on cross teams level -> (Back to Start/Upwards)

Teamwork key success factors

  1. Fast and open Internal team interaction

  2. Team members expertise

  3. Open knowledge sharing practice

  4. Autonomy in actions

  5. Responsibility for results

 

Сторінка 7

Swarming practice

Іноді на проектах для вирішення великих або складних завдань варто застосувати "рій" з людей.

Advantages of swarming

  • Broader team understanding (люди в реальному режимі часу в залежності від складності поставленої задачі частково ігнорують рольове наповнення, але вони повністю залучаються в процес вирішення цієї задачі. (для проведення investigation, критичних issues або блокерів на рівні команди).

  • Real-time artifacts review (колектив породжує певні речі швидше)

  • Potential time savings

  • Faster interaction

Limitations

  • Need to plan work precisely

  • Fast artifacts creation in ongoing updating

Best interaction practices and team activities

Really needed Team activities:

  1. Provide more context for questions in communication

  2. Check Business Requirements every day

  3. Make updates in Confluence and Jira tickets every time and in time

  4. Quick refinement and sync-up PM/BA/Team sessions

  5. PM/BA permanent clarification work on Team

  6. Separate Stakeholders sync-up for difficult cases

  7. Runs planning

  8. KPI and lesson learned review

  9. Retro

  10. Clear and fast communication inside the team

Best practices

  1. Business Requirements quick updates

  2. Question in Chat and Jira Tickets

  3. Refinement and clarification sessions

 

Сторінка 8 (Матриця: Teamwork Phases / Roles)

Teamwork phases

PM

BA

PM/BA

Forming

• setup teamwork framework and processes

 

• understanding of team needs

• organizational & Analytical Support of teamwork processes setup

 

• project and product domain knowledge transfer to the team

• Information team support

Storming

• Teamwork GAP's resolving

 

• Conflict management

• Teamwork and client interactions issues analysis

• Teamwork KPI creation and implementation

Norming

• Teamwork life cycle normalization

 

• SDLS compliance

• Quantity & quality of SOW for DEV team

• Teamwork improvements creation, implementation and support

Performing

• Teamwork process efficiency increasing and control

 

• Team members reintegration

• Quick teamwork support

 

• Information team support

• Knowledge Transfer best practices implementation

 

• Teambuilding practices

Dissolution & Transformation


 

• Control the process of team members reintegration

 

• Combine roles and functions practices analysis and control

 

Чи бажаєте ви, щоб я структурував цю інформацію в єдиний документ (наприклад, PDF) або зробив короткий підсумок (summary) основних ідей?

bottom of page