Одна людина чи команда? Як визначити мінімальний склад проєкту за компетенціями, залежностями та ризиком

Дослідження не підтверджують простого правила на кшталт "менші команди завжди кращі" або "більші команди завжди роблять більше".

Метааналіз 2023 року, що охопив 208 незалежних ефектів і 21 435 команд, виявив загалом практично нульовий зв'язок між розміром команди та виконанням завдання, але водночас значну відмінність залежно від контексту. Автори показують, що значення розміру команди змінюється, зокрема, разом зі складністю завдання та потребою в координації. [4]

Експеримент зі складним завданням кризового картографування також показав одночасно переваги й витрати більших команд: зі збільшенням команди зростала співпраця, але змінювалися моделі індивідуальних зусиль. У цьому конкретному експерименті найбільші команди перевершили еквівалентну кількість людей, що працювали незалежно. Це не універсальний рецепт для будь-якої роботи. [5]

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

Scrum Guide 2020 описує Scrum Team як невелику, багатофункціональну та самокеровану команду. Там також зазначено, що зазвичай вона складається з 10 або менше людей. [3]

Це корисний орієнтир у контексті Scrum, але не універсальний закон для всіх проєктів, послуг, галузей і моделей виконання.

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

Британський Service Standard вимагає, щоб команди цифрових послуг були багатодисциплінарними та мали доступ до належного набору компетенцій. Він також зазначає, що склад має залежати від того, чого команда повинна досягти на конкретному етапі. [1]

Окремі рекомендації GOV.UK вказують, що розмір команди та потрібні ролі змінюються на різних етапах створення послуги. [2]

Звідси випливає практичне правило:

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

Неможливо правильно визначити склад для нечітких меж.

Зафіксуйте щонайменше:

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

Проєкт "створити застосунок" і проєкт "спроєктувати, створити, захистити, розгорнути та підтримувати застосунок протягом року" потребують зовсім різного покриття робіт.

Замість того щоб одразу призначати посади, перелічіть види роботи, які справді потрібно виконати.

Для цифрової послуги це можуть бути:

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

Для іншого типу проєкту список буде іншим.

GOV.UK зазначає, що команда, яка створює та експлуатує цифрову послугу, потребує широкого набору компетенцій, серед яких потреби користувачів, проєктування, створення, тестування, безпека, розгортання та підтримка. [2]

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

Для кожної сфери визначте:

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

GOV.UK прямо допускає доступ команди до спеціалізованої експертизи без обов'язкової постійної присутності такого фахівця в команді. [1]

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

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

Перевірте:

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

GOV.UK відносить керування залежностями від інших команд до необхідних спроможностей під час створення цифрових послуг. [2]

Коли над послугою працює більше однієї команди, додатково потрібно координувати плани та прогрес між командами. [8]

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

Залежно від проєкту це можуть бути:

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

GOV.UK рекомендує забезпечувати доступ до спеціалізованої експертизи, коли вона потрібна, а склад команди має враховувати й найризикованіші припущення поточного етапу. [1]

Це не означає автоматично окрему повну ставку для кожного ризику. Але компетентна людина повинна мати чітку відповідальність і реальну можливість впливати на рішення.

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

Матеріали PMI про планування ресурсів підкреслюють важливість узгодження навичок, доступності, вартості та досвіду з потребами проєкту. [7]

Для кожної людини перевірте:

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

Покриття компетенцій без покриття часу не є повним покриттям проєкту.

Мінімальний склад має враховувати й безперервність.

Запитайте:

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

Не кожному малому проєкту потрібна повна взаємозамінність. У короткому низькоризиковому проєкті свідоме прийняття такого ризику може бути обґрунтованим.

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

Проєкту не потрібна окрема людина для кожної назви ролі.

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

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

Не об'єднуйте відповідальності лише тому, що "хтось має це зробити". Поєднання має сенс лише тоді, коли людина може виконати обидві відповідальності на потрібному рівні та має достатньо часу.

Одна людина може бути раціональним складом, якщо одночасно:

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

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

Усе одно вирішальними є конкретні межі. Назва "малий проєкт" сама по собі нічого не визначає.

Команда стає більш обґрунтованою, якщо є кілька таких умов:

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

За таких умов важливіше додати відсутні компетенції, ніж просто збільшити кількість людей.

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

Дослідження програмних проєктів у Journal of Systems and Software показало, що зв'язки між розміром команди, продуктивністю, зусиллями та часом складні й не завжди відповідають інтуїтивним очікуванням. [6]

Метааналіз розміру команд також показує, що результат залежить від контексту завдання й витрат командних процесів. [4]

Тому питання не "скільки людей ми можемо додати?", а "чи усуває наступна людина реальне обмеження проєкту більше, ніж збільшує витрати на координацію?"

Не кожна важлива компетенція повинна бути присутня щодня.

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

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

Є одна умова: доступність має бути реальною, а не формальною. Має бути зрозуміло:

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

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

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

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

Варіант B: публічна послуга з обліковими записами, платежами та інтеграціями
З'являється більше спеціалізації, тестування, ризиків, залежностей і паралельних робіт. Команда з кількох людей стає значно більш обґрунтованою.

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

Це той самий загальний тип продукту, але різні межі, ризики та модель експлуатації створюють різні потреби в команді.

1. Ви починаєте з готового переліку посад, а не з роботи, яку треба виконати.

2. Ви вважаєте, що кожна роль потребує окремої людини.

3. Ви дивитеся лише на компетенції та ігноруєте доступний час.

4. Ви додаєте людей, не усуваючи залежності та вузькі місця.

5. Ви ігноруєте компетенції, що випливають із ризику, бо вони не створюють видимої функції.

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

7. Ви вважаєте початковий склад незмінним до кінця проєкту.

GOV.UK прямо зазначає, що розмір і ролі команди змінюються на різних фазах розвитку послуги. [2]

Це розумний принцип і поза державними послугами:

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

Мінімальний склад залежить від фази та меж, а не є числом, раз і назавжди закріпленим за проєктом.

Для кожної важливої сфери запишіть п'ять речей:

Сфера роботи - що має бути виконано?
Компетенція - які знання й уміння потрібні?
Відповідальність - хто ухвалює рішення та відповідає за результат?
Доступність - компетенція постійна, періодична чи зовнішня?
Ризик відсутності - що станеться, якщо компетенції не буде або людина стане недоступною?

Лише після цього призначайте конкретних людей.

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

1. Чи кожна обов'язкова сфера роботи має відповідального?
2. Чи кожна критична відповідальність покрита людиною з потрібною компетенцією?
3. Чи хтось поєднує кілька ролей і реально має на них достатньо часу?
4. Чи проєкт потребує паралельної роботи, якої поточний склад не витримає?
5. Чи знаємо основні залежності від інших людей, команд і постачальників?
6. Чи важливі ризики мають доступ до правильної спеціалізованої експертизи?
7. Чи може одна відсутність зупинити весь проєкт?
8. Чи достатній склад не лише для створення, а й для запуску та підтримки, якщо це входить у межі?
9. Чи знаємо, які компетенції можуть бути періодичними замість постійних?
10. Чи визначили моменти, коли склад буде повторно оцінено після зміни меж або фази?

Проєктування команди не повинно починатися з питання:

"скільки людей зазвичай потрібно для такого проєкту?"

Краща послідовність:

результат -> робота -> компетенції -> залежності -> ризик -> спроможність -> люди.

Якщо після цієї перевірки одна людина справді покриває все, одна людина може бути правильним вибором.

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

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

[1] GOV.UK Service Standard - Have a multidisciplinary team
Відкрити джерело

[2] GOV.UK Service Manual - Set up a service team at each phase
Відкрити джерело

[3] The Scrum Guide, 2020 - Scrum Team
Відкрити джерело

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
Відкрити джерело

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Відкрити джерело

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Відкрити джерело

[7] Project Management Institute - Solving The Resource Puzzle
Відкрити джерело

[8] GOV.UK Service Manual - Running more than one service team
Відкрити джерело

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