Один человек или команда? Как определить минимальный состав проекта по компетенциям, зависимостям и риску

Исследования не подтверждают простого правила вроде "маленькие команды всегда лучше" или "большие команды всегда делают больше".

Метаанализ 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-команд, управления проектами или исследований команд и разработки программного обеспечения. Материал использует каждый источник только в той части, которую он действительно поддерживает. Семишаговый способ определения минимального состава является редакционным обобщением этих принципов, а не формальным стандартом перечисленных организаций.