Урок 3 з 4
Команда
Підбір
Людей у команду обирають за такими критеріями:
- доступність — чи може людина працювати в потрібний час;
- вартість — чи вписується її оплата в бюджет;
- досвід, знання й навички — чи робила вона схожі ігри;
- часові пояси — чи вийде працювати разом, якщо людина в іншій країні.
Розмір команди
Що більша команда, то більше каналів комунікації між людьми (модуль 5): у команді з 5 людей їх 10, а з 12 людей уже 66. До того ж ще в 1913 році французький інженер Максиміліан Рінгельман помітив: що більше людей тягнуть канат разом, то менше зусиль докладає кожен. Це називають ефектом Рінгельмана. Тому гнучкі методи радять невеликі команди. Scrum Guide 2020, наприклад, рекомендує 10 людей або менше. Великий проєкт ділять на кілька таких команд.
Поруч чи віддалено
Дослідження не дають однозначної відповіді:
- Дослідники Microsoft проаналізували роботу понад 60 тисяч співробітників на початку пандемії (журнал Nature Human Behaviour, 2021). Повністю віддалена робота зробила спілкування між командами рідшим, а нові зв'язки почали виникати рідше.
- Нік Блум зі Стенфорда провів експеримент на 1600 працівниках китайської IT-компанії (журнал Nature, 2024). Гібридний формат, тобто два дні вдома на тиждень, не погіршив продуктивності, а звільнень стало на третину менше.
Хто за що відповідає: RACI
Щоб жодна робота не лишилася «нічиєю», будують матрицю відповідальності. Найпоширеніша — RACI:
- R (Responsible, виконавець) — робить роботу;
- A (Accountable, відповідальний) — приймає результат і відповідає за нього. На кожну роботу лише один A;
- C (Consulted, консультант) — з ним радяться під час роботи;
- I (Informed, поінформований) — його повідомляють про результат.
По рядках ставлять роботи з WBS, по стовпцях — ролі, а не імена: люди змінюються, ролі лишаються.
Матрицю перевіряють:
- по рядку: немає R — роботу ніхто не зробить; немає A або їх два — ніхто не відповідає;
- по стовпцю: забагато R чи A в однієї людини — вона перевантажена і ризикує вигоріти.
Правила команди
На старті команда домовляється про правила роботи (team charter): коли зустрічаємось, де пишемо, як ухвалюємо рішення, що робимо при конфлікті, що означає «готово». Записані правила знімають половину суперечок.
RACI-матриця гри
Хто робить, хто відповідає, з ким радяться і кого інформують.
| Робота | PM | Прог. | Диз. | Тест. | Марк. | Засн. |
|---|---|---|---|---|---|---|
| Концепція | R | C | C | I | C | A |
| Дизайн | A | C | R | C | I | |
| Механіка | A | R | C | C | ||
| Сервер | A | R | I | |||
| Рівні | A | C | R | C | ||
| Маркетинг | I | C | R | A | ||
| Тестування | A | C | C | R | ||
| Реліз | A | R | C | I |
Ролі: PM — керівник проєкту; Прог. — програміст; Диз. — дизайнер; Тест. — тестувальник; Марк. — маркетолог; Засн. — засновники.
Етапи розвитку команди
Нова команда не стає злагодженою в перший день. Психолог Брюс Такман у 1965 році помітив, що групи проходять схожий шлях, і поділив його на етапи. Пізніше, у 1977-му, він додав п'ятий.
- Формування (forming). Люди обережні й ввічливі, суперечок майже немає. За цим ховається невпевненість: кожен з'ясовує, як тут заведено, хто має останнє слово і чи можна сперечатися. Керівник на цьому етапі пояснює мету, ролі й правила, щоб зняти тривогу.
- Шторм (storming). Коли люди освоїлися, вилазять розбіжності: у підходах, амбіціях, уявленнях про якість. Команда з'ясовує, чия думка важить більше. Це нормальний етап, а не ознака поганої команди. Керівник не гасить суперечки силою, а допомагає перевести їх у рішення.
- Нормалізація (norming). Постійні суперечки виснажують, і команда домовляється: хто ухвалює рішення, як проводимо зустрічі, що вважаємо «готовим». Правила стають звичкою. З'являється довіра: людина може не погодитися й не боятися за своє місце.
- Продуктивна робота (performing). Команда витрачає енергію на задачу, а не на з'ясування стосунків. Люди підхоплюють роботу одне одного без нагадувань. Керівник тут менше керує і більше прибирає перешкоди.
- Розформування (adjourning). Проєкт завершено, команда підбиває підсумки і розходиться в нові проєкти.
Етапи не йдуть строго по прямій. Новий програміст посеред проєкту чи жорсткий дедлайн можуть повернути команду в шторм. Тому заміна людини коштує більше, ніж здається: команді знову треба розподілити ролі і вплив.
Етапи розвитку команди
Ефективність команди падає на шторм і росте, коли з'являються правила.
- 1. пояснити мету, ролі й правила
- 2. переводити суперечки в рішення
- 3. закріпити домовленості
- 4. прибирати перешкоди
- 5. підбити підсумки