Знаете, что самое странное в кросс-функциональных командах? Чем больше в них специалистов, тем медленнее иногда идет работа. Вроде логика простая: добавили в спринт еще двух разработчиков и дизайнера, значит, задачи должны закрываться быстрее. А на практике получается наоборот. Velocity падает, ретроспективы превращаются в разбор полетов, а Product Owner начинает нервно смотреть в бэклог.
Это не баг и не проблема конкретных людей. Это эффект Рингельмана, и он работает даже в самых мотивированных командах.
В 1913 году французский инженер Макс Рингельман проводил эксперименты с канатом. Он просил людей тянуть его по одиночке и группами. Результат оказался неожиданным: когда человек тянул один, он выкладывался на все сто. Когда в группе было восемь человек, каждый прикладывал усилий вдвое меньше.
Перенесите это на вашу Agile-команду. Три человека работают слаженно, каждый знает свою зону ответственности, все видят результат своих действий. Расширили команду до девяти, добавили еще пару ролей, и вдруг кто-то начинает думать: "Ну, кто-нибудь же проверит код за меня", "Тестировщик разберется", "У нас же есть тимлид, он и примет решение".
Agile построен на прозрачности и личной ответственности. Но вот парадокс: чем больше людей в команде, тем легче спрятаться за спины коллег. На стендапе говорят общие фразы, в Jira задачи висят в статусе "In Progress" неделями, а реальный прогресс измерить сложно.
В кросс-функциональных командах это усугубляется еще сильнее. Разработчик думает, что дизайнер подхватит задачу с UX. Дизайнер надеется, что аналитик уточнит требования. Аналитик ждет, когда тестировщик найдет несостыковки. А тестировщик вообще не в курсе, что задача уже должна быть готова к проверке.
Все заняты, все при деле, но продукт не движется вперед.
Дело не в лени в привычном смысле. Люди не злоупотребляют ситуацией осознанно. Просто срабатывает психологический механизм: когда ответственность размывается, мозг автоматически снижает усилия. Это не сознательное решение "пойду полентяйствую", а бессознательная реакция на условия работы.
В маленькой команде ты видишь, как твой код напрямую влияет на релиз. В большой команде это влияние становится менее очевидным. Ты один из десяти, и если ты сделаешь чуть меньше, это вроде как не критично. Другие компенсируют. Проблема в том, что так думают все.
Стендапы превращаются в формальность. Люди рассказывают, что они делали, но не берут на себя конкретные обязательства. Фразы вроде "продолжаю работу над фичей" ни к чему не обязывают. А если половина команды так отвечает, то кто за что отвечает?
В итоге получается, что все что-то делают, но непонятно, кто конкретно доведет задачу до конца. Задача переходит из рук в руки, обрастает комментариями в Confluence, но не закрывается.
Большие команды легко путают активность с продуктивностью. Созвоны, планирования, синки, воркшопы... Календарь забит встречами, все при деле, но спринт закрывается с половиной незавершенных задач.
Это тоже часть проблемы. Когда людей много, нужно больше времени на координацию. А координация создает ощущение работы. Ты весь день на встречах, обсуждаешь архитектуру, согласовываешь подходы, и к вечеру устал как собака. Но код не написан, дизайн не готов, тесты не прогнаны.
В Agile команды должны быть самоорганизующимися. Но когда команда большая, самоорганизация превращается в "не мое дело". Задача провисает, потому что непонятно, кто должен взять инициативу. Все ждут, что кто-то другой скажет "окей, я беру это на себя".
А в маленькой команде из трех-четырех человек это невозможно. Если задача висит, сразу видно, кто за нее отвечает. Некуда спрятаться, некого винить.
Разбивать. Вместо одной команды из двенадцати человек лучше сделать две по шесть. Да, придется дублировать роли, зато каждый будет видеть свой вклад. Каждый спринт будет прозрачным, каждая задача будет иметь конкретного владельца.
Можно использовать подход "two pizza teams" от Amazon: команда должна быть такой, чтобы ее можно было накормить двумя пиццами. Звучит забавно, но это работает. Обычно это 5-7 человек максимум.
Еще важно делать ответственность персональной. Не "команда делает фичу", а "Саша отвечает за бэкенд этой фичи, Маша за фронтенд, Петя за тестирование". Каждый знает, что если что-то не сделано, это видно конкретно по нему.
Velocity может расти, а производительность падать. Поэтому важно смотреть не только на story points, но и на cycle time, lead time, количество задач в статусе "In Progress" одновременно. Если у команды из десяти человек в работе постоянно двадцать задач, это красный флаг. Значит, никто ничего не доводит до конца.
Еще полезно отслеживать, сколько задач проваливается через спринт. Если регулярно переносится больше 30% бэклога, команда берет на себя больше, чем может сделать. И это тоже признак того, что люди не чувствуют личной ответственности за коммитменты.
Нельзя просто сказать "ребята, давайте работать лучше" и ждать изменений. Нужно менять структуру работы. Меньше людей на задачу, четкое распределение ролей, прозрачность вклада каждого.
И да, это противоречит идее "коллективного владения кодом" и "команда отвечает за все". Но на практике коллективная ответственность часто превращается в коллективную безответственность.
Лучше работает модель, где есть основной владелец задачи и помощники. Владелец отвечает за результат, помощники подключаются по необходимости. Так понятно, кто за что отвечает, но при этом сохраняется взаимопомощь и обмен знаниями.
Эффект Рингельмана работает не потому, что люди плохие или ленивые. Он работает, потому что так устроена психология. Когда усилия незаметны, когда результат не привязан к конкретному человеку, мозг автоматически снижает вовлеченность.
В Agile-командах это особенно опасно, потому что там изначально ставка на мотивацию и самоорганизацию. И если команда слишком большая, эти принципы размываются.
Так что если в вашей команде есть ощущение, что все работают, а результата нет, возможно, дело не в людях. Дело в количестве этих людей.
