Лабораторна робота №14 (2 години)
Тема: Управління командою (Team Management) та Status Reports
Практика вирішення проблемних ситуацій у команді (модель Брюса Такмана), розподіл відповідальності за допомогою RACI-матриці та навички професійної комунікації із замовником у разі виникнення проблем (написання Status Report).
Мета: Навчитися діагностувати стадію розвитку команди, чітко розподіляти ролі без дублювання обов’язків та правильно подавати “погані новини” клієнту через структуровані звіти.
Технологічний стек: Google Docs / MS Word (для написання звіту та матриці).
Завдання
Як PM, ви працюєте з людьми, а не лише з таблицями. Люди конфліктують, вигорають і не завжди розуміють, хто за що відповідає. Крім того, саме ви є “обличчям” команди перед замовником.
У цій роботі ви розв’яжете управлінський кейс і напишете офіційний звіт.
Перелік завдань:
- Визначити стадію розвитку команди за моделлю Такмана (Tuckman) за описом ситуації.
- Побудувати матрицю RACI для процесу “Реліз нового функціоналу”.
- Написати Status Report для замовника на основі кризового сценарію.
Хід виконання роботи
Крок 1. Аналіз командної динаміки (Модель Такмана)
Прочитайте наступний кейс:
“Ваша команда (Backend, Frontend, QA, Designer) працює разом уже 3 тижні. Останні кілька днів на Daily-мітингах відчувається напруга. Frontend-розробник постійно сперечається з Дизайнером щодо відступів на кнопках. QA скаржиться, що Backend віддає код на перевірку пізно ввечері, змушуючи його перепрацьовувати. Усі намагаються довести свою правоту і перетягнути ковдру на себе, продуктивність впала.”
У своєму звіті дайте відповіді:
- На якій стадії за моделлю Такмана (Forming, Storming, Norming, Performing, Adjourning) зараз знаходиться ця команда? Обґрунтуйте чому.
- Що як Project Manager ви маєте зробити ПРЯМО ЗАРАЗ, щоб вивести команду на наступний етап? (Опишіть 1-2 конкретні дії, наприклад: “Провести 1-on-1 з…”, “Організувати спільний дзвінок для…”).
Крок 2. Побудова матриці відповідальності (RACI)
Щоб уникнути конфліктів формату “Я думав, що це зробить він”, використовується матриця RACI:
- R (Responsible): Хто безпосередньо робить роботу ручками.
- A (Accountable): Хто несе фінальну відповідальність (приймає роботу). Завжди тільки ОДНА людина!
- C (Consulted): З ким радяться ДО виконання роботи (двостороння комунікація).
- I (Informed): Кого просто ставлять до відома ПІСЛЯ завершення (одностороння комунікація).
Створіть у звіті таблицю RACI для абстрактного процесу “Розробка та Реліз нової фічі”.
Розподіліть літери (R, A, C, I) по комірках. Пам’ятайте головне правило: в кожному рядку має бути мінімум один R і точно один A.
| Задача / Крок |
PM |
Tech Lead (Backend) |
Frontend Dev |
QA Engineer |
Дизайнер |
| 1. Затвердження макету екрану |
|
|
|
|
|
| 2. Написання коду (API та UI) |
|
|
|
|
|
| 3. Тестування функціоналу |
|
|
|
|
|
| 4. Завантаження коду на “Продакшн” |
|
|
|
|
|
Крок 3. Написання Status Report (Кризового звіту)
PM повинен регулярно писати Status Reports замовнику. Найважче — писати їх, коли все погано.
Сценарій: Сьогодні п’ятниця. У вівторок має бути реліз мобільного додатку для Замовника. Але вчора звільнився Frontend-розробник через сімейні обставини, не дописавши ключовий екран оплати. Реліз у вівторок фізично неможливий (запізнення мінімум на тиждень).
Напишіть короткий (на 3-4 абзаци максимум) офіційний лист/звіт Замовнику за правилом “Сендвіча з поганими новинами” (Позитив - Негатив - Рішення).
Структура вашого звіту:
- Summary (Короткий статус поточних справ): Що взагалі було зроблено добре за цей тиждень.
- Issue / Roadblock (Проблема): Чіткий і чесний опис проблеми (без емоцій і звинувачень), як це впливає на дедлайн у вівторок.
- Action Plan (План дій): Найважливіша частина! Замовнику не потрібні ваші вибачення, йому потрібне рішення. (Наприклад: “Ми беремо іншого розробника з сусіднього проєкту, він вникатиме 2 дні, тому пропонуємо випустити версію без оплати у вівторок, а оплату додати наступного понеділка…”).
Вставте текст цього листа у ваш звіт.
Контрольні запитання
- Опишіть етап “Performing” (Виконання) за моделлю Такмана. Чим він відрізняється від етапу “Norming”? Роль PM-а на цьому етапі зменшується чи збільшується?
- У матриці RACI для однієї задачі вийшло три літери “A” (Accountable). До якого ризику/проблеми на проєкті це гарантовано призведе?
- В який момент життєвого циклу проєкту (до початку розробки, під час, чи в кінці) найкраще створювати матрицю RACI? Чому?
- Чому при написанні Status Report з інформацією про зрив дедлайну категорично не рекомендується звинувачувати конкретного співробітника перед замовником (наприклад: “Василь не встиг написати код”)?
- Що таке політика “No Surprises” (Жодних сюрпризів) в комунікації зі Стейкхолдерами та як регулярні Status Reports допомагають її дотримуватися?
Вимоги до звіту
- У репозиторії курсу на GitHub додати файл
lab_14.md.
- В цей файл перенести результати виконання Кроків 1, 2 і 3 (Аналіз моделі Такмана, заповнену матрицю RACI та текст вашого кризового Status Report).
- У файлі
lab_14.md дати письмові відповіді на всі 5 контрольних запитань.
- Завантажити зміни на GitHub та надіслати посилання викладачу.