x

Добро пожаловать в IT Leader Assistant.
Please Войти!

Создать аккаунт

Идеальный размер Agile-команды и проблемы разрастания команды

Максим Шаламов
08-27-2021 11:30
Идеальный размер Agile-команды и проблемы разрастания команды
Сегодня поговорим о размере команды для эффективной работы. Отталкиваться будем в основном от Agile-подобных структур, но все тезисы и проблемы будут актуальны для всех типов IT проектов и команд. Итак, Agile рекомендует не превышать размер команды в 15 человек, давайте обсудим какие проблемы вообще может нести большая команда.

Управление командой тимлидом

Начну со своего любимого пункта управление командой. Поскольку я считаю, что в команде должен быть тимлид, в голове которого должны быть и приоритеты, и основной скоуп задач, и проблемы своих людей (как работать с проблемами подчиненных можно узнать из курсов ”Тимлид: основы” и “Как работать с выгоранием”) и многое другое, то, чтобы качественно выполнять свою работу, у него должен быть осязаемый для одного человека набор задач. Моем мнение, что имея 10+ человек тимлид почти выпадает из процесса закрытия задач (написания кода, создания пайпланойв и т.д.). Однако, это заменяется общим пониманием всех задач проекта, встречами с заказчиком, аналитиками и соседними отделами, сбором обратной связи от команды и решением проблем. Во многих командах тимлид еще и техлид (разницы мы обсуждали в нашем видео), что оставляет на его плечах еще и архитектуру проекта. По опыту у лидов после получения в прямое подчинение больше десяти человек, начинаются проблемы с тем, чтобы все успеть. Тут цифра в 15 человек может стать излишней, не говоря про больше.

Удержание контекста и понимая архитектуры участниками команды

Следующий важный для команды момент, команда должна работать над связанным функционалом так чтобы члены команды понимали чем занимается их команда в целом и чем занимаются их коллеги. Чем больше людей, тем больше задач в команде. Чем больше задач, тем меньше общий уровень понимания каждого о целостной картине в проекте, тем меньше вовлеченность и выше вероятность появления людей, которые не смогут переключаться между задачами команды при необходимости. Так же с падением общего уровня понимания людей о проекте, вы увидите, что ваша команда разделиться на группы почти не пересекающиеся по задачам, потому что люди имеют ограниченные возможности по удержанию контекста (в данном случае об общей структуре части проекта, о подводных камнях и общих бизнес задачах). В итоге все равно команды из 15+ человек, разобьются на более маленькие группы.

Долгие общие встречи и коммуникация

Большой проблемой станут общие встречи. Обсуждение общих целей, распределение и разбор задач, ретроспективы (или аналогичные по цели, но отличные по названию встречи) превратится в затяжной марафон. В итоге, либо часть людей будет молчать (что лишает смысла такие встречи), либо выскажутся все, но большинство будет выпадет из контекста встречи сразу после своего слова (что тоже обесценивает такие встречи). В итоге это приведет либо к бесконечным встречам, либо вы снова увидите, как встречи будут организовываться между устоявшимися группами людей. Опять же люди будут поделены по связным кускам функционала, которым они занимаются.
В больших командах проявится проблема коммуникаций, люди которые мало пересекаются или вообще не пересекаются по задачам, не будут считать малознакомых коллег частью своей команды. И снова мы получим кучкование по принципу совместной работы (это не мешает определенным людям дружить и общаться, но это так работает и с людьми вне вашей команды и компании).

Как решить проблему разростающейся команды

В итоге, как бы вы не подходили к структуре отделов и формату работы с проектами. Большие команды, будут разбиваться естественным путем на более мелкие формирования. Только это будет порождать путаницу, уменьшать вовлеченность и создавать конфликты при перекидывании людей между кусками проекта. Гораздо эффективнее поделить проект (если он реально велик) на понятные функциональные куски. Закрепить за ними команды и назначить ответственного, или ответственных, за архитектуру проекта в целом (больше говорил об этом тут). Если вам приходится работать в рамках организованной большой команды (и достучаться до бизнеса или руководства вы не можете), то просто распределите ответственности между мини-командами. Главное обсудите, как вы будете строить согласованную архитектуру проекта и все получится.
Если у вас есть какие-то вопросы или пожелания вы можете воспользоваться формой для связи с нами:

Комментарии

Чтобы оставить комментарий, пожалуйста, авторизуйтесь

Подписывайтесь на обновления

Последние статьи из нашего блога