Все вакансии закрыли сильными кандидатами, каждого хвалили на собеседовании, а через квартал проект буксует, и никто не понимает почему. Шесть человек с отличными резюме тратят по восемь часов в неделю на согласования, а два ключевых решения третью неделю ждут, пока кто-нибудь возьмёт их на себя. Резюме были хорошие. Команды из них не сложилось.
Сумма сильных резюме ещё не делает команду
Идею можно поменять, стратегию скорректировать, рынок переосмыслить. А слабую команду не обойти: на ней ломается всё остальное. Собрать людей под проект можно осознанно, не надеясь на удачу.
Всё начинается с ошибки: искать «лучших специалистов» в надежде, что сильные индивидуалы сами сложатся в сильную команду. Так выходит редко. Команда держится на ролях, договорённостях, ответственности и общем понимании цели. Без этого даже опытные профессионалы работают разрозненно и тянут проект в разные стороны.
У этого провала три частые причины. Первая: подмена цели. Руководитель собирает людей «в целом», без конкретной задачи, и команда не понимает, ради чего работает и по каким критериям её оценивают. Вторая: иллюзия универсальности. От одного человека ждут, что он будет сразу стратегом, исполнителем, коммуникатором и кризис-менеджером. В стартапах это особенно заметно и быстро приводит к выгоранию. Третья: скорость изменений. Продукт развивается быстрее, чем перестраивается команда, и состав, который не меняется вместе со стадией, начинает тормозить рост.
Выгорание тут не случайность. Кристина Маслач и Майкл Лейтер, авторы самой известной модели профессионального выгорания, называют шесть сфер, где расхождение между человеком и работой ведёт к выгоранию. Три из них, нагрузка, контроль над своей работой и ценности, напрямую зависят от того, как собрана команда: сколько ролей взвалили на одного человека, кто за кого решает и разделяют ли люди цель.
Команда начинается с цели и границы
Хорошая команда раз за разом достигает целей и при этом не выгорает и продолжает расти. Цена результата важна так же, как он сам. Постоянные конфликты, перегрузки и текучесть говорят о неэффективности, даже если формально цели выполняются.
Командой можно назвать только группу с общей целью, распределённой ответственностью и регулярным взаимодействием. Если люди работают параллельно и почти не влияют друг на друга, перед вами набор исполнителей. Поэтому у команды всегда есть граница и размер. Попытка включить в неё всех подряд размывает ответственность и убивает фокус.
Цель должна быть конкретным результатом с критерием успеха и сроком. «Сделать лучший продукт для малого бизнеса» целью не является. «За шесть месяцев довести двадцать пилотных клиентов до платной подписки» является: из неё понятно, какие роли нужны сейчас, а какие подождут. Рядом с целью стоит контекст: стадия проекта, ограничения, допустимый уровень неопределённости. Команде в поиске продукта нужны другие люди и другие договорённости, чем команде на масштабировании.
Цена ошибки в составе тоже зависит от типа команды. Для стартапа на ранней стадии от сборки зависит выживание: ошибка в роли или конфликт ценностей могут остановить проект ещё до выхода на рынок. В продуктовой команде внутри компании вопрос обостряется при росте: то, что работало на трёх-пяти людях, ломается на десяти-пятнадцати. Проектной команде осознанная сборка нужна из-за сроков: если не выровнять ожидания заранее, большая часть времени уходит на согласования.
Роль означает ответственность за результат
Ни должность, ни список задач роль не описывают: роль задаёт, за какой результат человек отвечает. «Ничейных» зон в рабочей команде быть не должно, и перекрытие ролей без явной договорённости вредит так же. Когда за одну область отвечают двое, решения буксуют. Когда резерва нет совсем, отпуск одного человека останавливает работу.
Проверить это можно за час. Выпишите все решения, которые команда принимает регулярно: приоритеты на неделю, архитектурные изменения, релиз, ответ ключевому клиенту, найм. Напротив каждого поставьте одно имя того, кто решает, и имена тех, с кем он советуется. Если у решения два владельца или ни одного, вы нашли источник задержек. В команде из шести человек такая таблица обычно выявляет два-три спорных решения, и почти всегда именно они стоят в очереди дольше всего.
Как это выглядит на практике. «Что берём в спринт» решает продакт-менеджер, советуясь с техлидом. «Как устроить новый сервис» решает техлид, советуясь с двумя разработчиками. «Выпускаем ли релиз в пятницу» решает тот, кто отвечает за поставку, и это имя должно быть одно, даже если обычно соглашаются все. Спорные строки чаще всего выглядят так: «приоритеты на неделю: продакт и директор» или «ответ ключевому клиенту: кто первым увидел письмо». Каждая такая строка превращается в лишнюю встречу.
Есть и предел, о котором вспоминают поздно: команда должна быть способна удерживать в голове всю систему, за которую отвечает. Если зон ответственности больше, чем помещается в головах, роли формально расписаны, но работают на износ. Связь действует и в обратную сторону. Продукт со временем повторяет то, как разговаривают между собой люди, которые его строят: где команды почти не общаются, там в продукте появляются швы. Поэтому границы команды стоит проводить там, где хотите видеть границы продукта.
Даже при точно расставленных ролях команда не заработает без налаженного взаимодействия: способов принимать решения, обмениваться информацией и разрешать конфликты. Сами по себе они возникают редко. Доверие строится на предсказуемости. Люди выполняют договорённости и открыто говорят о проблемах, и доверие растёт. Перестают выполнять, и команда уходит в защиту и прячет ошибки.
Инструментов для этого немного. Короткий документ с ролями и зонами ответственности, понятный всем. Регулярные встречи, где все узнают, что происходит, и проговаривают проблемы. Договорённости о том, как принимаются решения, как даётся обратная связь и как обсуждаются ошибки. Их редко формализуют, хотя качество работы определяют именно они.
У команды, где этого не хватает, узнаваемые симптомы. Первый: много встреч, обсуждений и инициатив, мало результатов. Проверка простая: посчитайте, сколько из десяти последних встреч закончились записанным решением с владельцем. Если меньше половины, команда занята процессом.
Второй: команда звёзд, где каждый тянет одеяло на себя. Решения принимаются медленно, конфликты переходят на личности, на ретроспективах обсуждают людей вместо работы. Третий: размазанная ответственность. В случае успеха непонятно, кто его обеспечил, а в случае провала виноватых нет. Его выдаёт таблица решений, о которой шла речь выше, где у важных строк по два имени.
Три новых человека дают на 140% больше связей
Рабочие команды обычно небольшие, от пяти до девяти человек. Механика простая: число парных связей в группе растёт примерно как квадрат её размера и считается по формуле n × (n-1) / 2. В команде из пяти человек таких связей десять, из десяти уже сорок пять, и каждая может обернуться недопониманием или лишним согласованием.
Возьмём команду из шести человек: пятнадцать связей. Руководитель добавляет троих, чтобы ускориться. Людей стало на 50% больше, связей теперь тридцать шесть, на 140% больше. Если каждая связь в среднем требует двадцати минут координации в неделю, координация выросла с пяти часов до двенадцати.
Добавьте онбординг: новичку нужно несколько недель, чтобы восстановить контекст, и всё это время кто-то из старых участников тратит на него часть дня. Первые два-три месяца после расширения команда часто работает медленнее, чем до него. Допустим, каждый новичок первые шесть недель забирает у наставника по полтора часа в день. Три новичка за шесть недель обходятся примерно в 135 часов времени старых участников, почти месяц работы одного человека, и это сверх роста координации.
Отсюда правило. Если работы стало больше, делите её на несколько автономных команд с чёткими границами и раздувать одну не спешите. Сигнал к разделению: в команде больше девяти человек или общие согласования стабильно занимают больше часа в день на каждого.
Проблемы состава часто маскируются под стратегические ошибки. Решения принимаются медленно, задачи пересобираются, обсуждения идут по кругу. Если одни и те же ошибки повторяются, диагностику стоит начинать с ролей, ответственности и принятия решений. Стратегия подождёт.
Нехватка роли и устаревшие роли: две истории
Компаний за этими историями нет, обе сложены из типичных ситуаций, и цифры в них примерные.
В стартапе на стадии идеи собрались четыре человека с сильным техническим опытом. Все умели программировать и считали, что этого достаточно. Продукт развивался медленно, решения принимались хаотично. Никто не отвечал за понимание рынка и клиентов: команда сосредоточилась на технической реализации и игнорировала обратную связь. После разбора один из участников взял на себя рынок, гипотезы и приоритеты. Решения стали приниматься быстрее, фокус сместился на ценность для клиента.
За следующие четыре месяца команда провела около тридцати разговоров с клиентами против трёх за предыдущие полгода и вышла на первые платящие пилоты. Новых людей не нанимали. Навыков не прибавилось, изменилось только их распределение.
Во второй истории проблема обратная: роли есть, но масштабу они уже не соответствуют. Продуктовая компания на стадии активного роста за год выросла с восьми до восемнадцати человек в одной команде. Скорость разработки упала, напряжение выросло. Формально все нужные роли были на месте, но решения принимались долго, приоритеты постоянно менялись, а люди работали как на ранней стадии, когда всё решалось на ходу.
Первым шагом команду разделили на две по девять человек с отдельными зонами продукта и зафиксировали, кто отвечает за продуктовые решения, кто за архитектуру, кто за поставку. Вторым настроили общие встречи, где ищут препятствия и риски, а отчёты оставили в письменном виде. Ввели ретроспективы, где разбирали и работу, и взаимодействие. Через несколько месяцев скорость выросла, а текучесть снизилась. Людей никто не менял, команду подогнали под новый этап.
Когда сильные одиночки всё же правы
У подхода «нанять лучших и не мешать» есть убеждённые сторонники, и доводы у них серьёзные. Хорошие специалисты сами договорятся о ролях, а формализация их только раздражает. Таблицы ответственности, синхронизации и ретроспективы съедают время, которое опытные люди потратили бы на работу. Подбор по навыкам к тому же давно отработан: структурированное интервью с одинаковыми вопросами и заранее описанной шкалой оценок неплохо предсказывает, как человек справится с работой. Зачем усложнять?
В маленьких командах из трёх-четырёх очень опытных людей они правы, особенно если люди уже работали вместе и разделяют цель. Им действительно хватает устных договорённостей, и формальные роли можно описать одной страницей.
Подход перестаёт работать в трёх случаях: когда команда больше пяти-шести человек, когда люди работают вместе впервые и когда стадия проекта меняется. Структурированное интервью хорошо предсказывает, как человек справится со своей работой. Как шесть таких людей поделят ответственность, оно не предсказывает. Это приходится проектировать отдельно.
Есть и самая тяжёлая проверка: сильный специалист с токсичным поведением. Вред от подорванного доверия бывает больше пользы от его навыков. Начинать стоит с открытого разговора и ясных ожиданий. Если поведение не меняется, приходится принимать жёсткое решение. Тот же критерий работает шире: расставаться с человеком необходимо, когда он системно не выполняет договорённости или разрушает взаимодействие. Долгое терпение демотивирует остальных сильнее, чем сам уход.
Как пересобирать команду на каждой стадии
Сборка не заканчивается на старте. Для стартапа порядок действий обычно такой:
- Прояснить цель и контекст: на какой стадии идея, какой уровень неопределённости допустим, какие задачи критичны для выживания.
- Честно оценить компетенции основателя. Команда должна дополнять его: сильному в продукте и слабому в продажах основателю первых людей стоит искать в продажах.
- Собрать людей под критичные роли, не гонясь за идеальным составом. На раннем этапе он почти наверняка будет меняться.
- Через три месяца пересмотреть таблицу решений. Если какая-то роль всё это время пустовала, а работа шла, роль была не нужна. Если какую-то зону закрывали по очереди все, ей пора дать владельца.
На росте работает другая логика: роли, работавшие на старте, устаревают, и адаптация требует, помимо найма, изменения процессов, коммуникаций и ожиданий. Лидер задаёт направление, темп и культуру и отвечает за условия работы. Сильнейшим специалистом ему быть не нужно: его сила в способности принимать решения и удерживать фокус. Процессы должны соответствовать стадии. Избыточная формализация на раннем этапе тормозит, нехватка процессов на росте оборачивается хаосом.
Разнообразие взглядов команде полезно, но держится оно на общих базовых ценностях: отношении к ответственности, качеству и честности. При общих ценностях конфликты обсуждаются на уровне задач и процессов и заканчиваются договорённостью. Когда расходятся именно ценности, конфликты становятся персональными, и даже сильные профессионалы не сработаются. Отличить один случай от другого помогает формулировка спора. «Давайте выпустим в пятницу, а не в среду» звучит как спор о задаче, и его можно решить данными. «Тебе вообще всё равно, что мы выпускаем» звучит как спор о ценностях, и данные его не решат. Если второго типа фраз становится больше, разговор пора вести с лидером команды один на один.
О здоровье команды больше всего говорит срок, за который ключевой вопрос находит владельца и решение. Смотреть его стоит вместе с числом людей, ушедших по своему желанию за квартал: ускорить решения ценой текучести несложно. Если вопросы закрываются быстрее, а люди остаются, состав работает.
Пересборка обычно нужна, когда в команду приходят сразу несколько новых людей или проект переходит на следующую стадию. Первой обнаруживается зона ответственности без владельца. Закрыть её новым наймом кажется естественным, но обычно это лишь добавляет связей и согласований. Подходящий владелец нередко уже сидит в команде, и найти его помогает та же таблица регулярных решений с одним именем напротив каждого. Пустая строка в ней обходится дешевле новой вакансии.