Сталкивались ли вы с потребностью в расширении команды? В жизни менеджера или тимлида часто возникает такая потребность, так как разрастается скоуп, сжимаются сроки, открывается новый проект или новое направление. Такие ситуации обычно сопровождаются страхом допустить ошибку: ведь если с самого начала что-то пойдет не так, ком проблем может "снести" проект в дальнейшем.

Мы взяли на себя задачу рассказать о самых распространенных ошибках ведь гораздо проще учиться на реальных (и чужих) ошибках, чем изучать идеальные (только в теории) кейсы. 

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

Исходные данные:

• кросс-функциональные команды;

• каждая команда закреплена за системой/конкретным функционалом, т.е. команды выполняют задачи параллельно;

• во главе каждой команды стоит тимлид/проектный менеджер/тимлид и проектный менеджер;

• разработка заказная/outstaff/in-house, если заказчики от бизнеса и команды достаточно изолированы друг от друга.

Важно отметить, что статья написана от лица ресурсного менеджера, который занимается ротациями и планированием состава команд, а не от лица тимлида какой-то конкретной команды – той, из которой забирают ресурсы, или той, в которую их добавляют. У сотрудника с ролью ресурсного менеджера есть полная картина того, что происходит в нескольких его командах: он понимает, в какой из них ресурсов не хватает, а в какой – избыток, а также какие сотрудники близки к выгоранию. 

Говоря про расширение, мы рассматриваем обобщенную новую команду, которая появляется, когда разрастается скоуп проекта, но не какой-то определенный тип расширения – когда новая команда полностью независима от предыдущей или новая команда образовалась из старой. Поэтому, когда вы будете примерять нашу статью на свои кейсы, имейте в виду, что некоторые случаи вам будут подходить, а некоторые – нет, и это нормально.

Расширять или не расширять?

1. Расширять команду при плавающей нагрузке
   Ошибкой будет расширить команду, потому что такая потребность есть в определенной точке, но вы не знаете, будет ли загрузка у настолько большой команды в будущем. Возможно, тяжело в конкретный момент времени, но есть риск, что новые сотрудники потом останутся без задач, заскучают и уволятся.

   Варианты помощи:

   • Временно подключить более свободную команду на помощь перегруженной;

   • Подключить дополнительных сотрудников, но после "горящего" проекта ротировать тех, кто в команде давно, в другие команды, где есть потребность.

2. Не расширять команду при стабильной перегрузке или открытии новых проектов Если вы работаете на стабильном проекте, но начали планировать задачи своей команды в интервалах 10-30 минут без рисков и без окон свободного времени, значит, ваша команда работает на износ и пора расширяться. Если в вашем направлении открылся новый проект, а старые не закрывались, то есть все сотрудники при деле – расширяйтесь, не бойтесь. При расширении обязательно упадет производительность, но зато ваши сотрудники не пойдут писать заявления.

Найм

1. Снижать требования к кандидатам из-за острой нехватки специалистов на проекте и поджимающих сроков
   Не снижайте требования к кандидатам и не переходите к стратегии "нужен уже хоть кто-нибудь". На горящие проекты нельзя брать кандидатов без нужных вам навыков, так как времени на их обучение не будет из-за поджимающих сроков. Это может плохо закончиться и для новичка, и для команды, и для проекта.

2. Не расставаться с неподходящими проекту новичками
   Если вы все-таки наняли сотрудника, который не подходит для проекта, не бойтесь вовремя признаться себе в том, несмотря на то, что потрачены огромные усилия на поиск, найм и онбординг. Это лучше, чем потратить ещё три месяца впустую и расстаться только в конце испытательного срока.

3. Ожидать, что при подключении нового человека производительность команды сразу вырастет, а не упадет
   В этом случае производительность команды обязательно сначала упадет, а не вырастет. Подробный разбор есть здесь. Даже специалист с релевантным опытом только через месяц самостоятельно начнет деливерить задачи, не отнимая процент загрузки у команды на разъяснения и консультации, но все равно еще не будет работать на полную мощность. Это нормальный процесс. Можно опираться на следующие сроки:

   • Полностью подходящий проекту и команде специалист сможет вникнуть через две-три недели курирования, а через месяц должен спокойно выполнять типовые проектные задачи;

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

4. Нанимать людей с подозрением на выгорание
   Так не работает. Нужно, чтобы человек сначала восстановился, а потом подключился к проекту. Иначе будет много проблем: тимлиду придется постоянно его мотивировать, а он будет деморализовывать команду и уйдет в самый неподходящий момент.

5. Нанимать "друзей-неразлучников"
   Единовременный найм нескольких сотрудников из одной компании значительно повышает риски проекта. Обычно в таких ситуациях один сотрудник крайне зависим от другого и, если вы потеряете одного, за ним может уйти другой. 
   Однажды мы наняли сразу двух коллег-друзей: аналитика и тимлида. Один был более зависим от другого. По плану друзья должны были попасть в одну команду, но открытие проекта затягивалось и формирование команды отложили на неопределенный срок, а друзей в итоге распределили по разным командам. Аналитик настаивал на том, что был бы более эффективен, если бы работал вместе с другом-тимлидом. Потом по личным причинам уволился тимлид, а сразу же за ним уволился и аналитик. В итоге мы потеряли сразу двух сотрудников и две ключевые позиции. 
   Если вы хотите нанять "друзей-неразлучников", то распределите их по разным проектам как можно дальше друг от друга и договоритесь с ними об этом сразу, чтобы у друзей не сложилось ложных ожиданий о совместной работе.

Ротации

1. Забрать в новую команду всех лучших сотрудников, в том числе лидеров практик/отделов ANA, DEV, TST
   Когда открывается новый проект и собирается команда, первое желание менеджера – забрать туда всех лучших и перспективных. 
   Если проекты, с которых вы хотите забрать сотрудников, не собираются заканчиваться в самой ближайшей перспективе, то высока вероятность, что без лучших сотрудников они сразу же упадут. 
   При формировании команды соблюдайте баланс, ведь у вас не только должен взлететь новый проект, но также должны не упасть старые. Не переводите лидеров в новый проект, пока они не обеспечат себе стабильную замену. Если времени на подготовку замен у вас нет, то помогут следующие варианты:

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

   • Если целую команду единовременно перевести на проект невозможно, то собирайте новую по принципу "один опытный в практике". В этом варианте также нужен сильный, амбициозный и не выгоревший тимлид, который на первых этапах самостоятельно закроет часть проблем, за которые должны отвечать лиды практик. Не забывайте, что нужно готовить замены в команде, из которой вы планируете переводить ресурсы. Переведите из старой команды в новую лида той практики, которая оказалась самой слабой в новой команде, иначе тимлид быстро устанет, выгорит, а команда станет еще слабее и останется без тимлида.

2. Не соблюдать баланс между специалистами разных грейдов
   Если в команде будут одни seniors – каждый со своим мнением, опытом, уверенностью в правоте – вероятны конфликты и проблемы с мотивацией. Могут возникнуть проблемы с тем, что старшие специалисты не хотят выполнять простые задачи или хотят сменить практику. Подробнее про старших специалистов поговорим в следующем пункте.

   Если в команде одни middles, нет инициативы и ответственности, и каждый делает свой "кусок", не смотрит на задачу в объеме. Одни juniors в команде – тоже опасно. Вы просто не двинетесь дальше, так как будет царить хаос и некому будет поделиться экспертизой и проконтролировать их деятельность.
   Чтобы не допускать проблем, описанных выше, нужно стремиться к золотой середине и иметь в команде примерно одинаковое соотношение juniors, middles, seniors.

   Какие задачи выполняют специалисты разных грейдов:

   • Senior навигирует работу младших грейдом специалистов, задает рамки и ограничения, не дает менее опытным специалистам закопаться слишком глубоко или наоборот замечает, если специалист не докопал;

   • Middle работает довольно стабильно. Его задачи: как можно быстрее понять суть и цели проекта, контрольные точки, принимать участие в agile-мероприятиях и скорее начать деливерить задачи – писать документацию или код. Middle требует ревью;  

   • Junior очень активен и даже если не знает глубоко процессов, добивается результата. Часто именно такой junior лучше стабильного middle, так как младшему специалисту помогает моральный и эмоциональный запал, но со временем, взрослея и теряя его, junior становится стабильным middle специалистом. Junior требует контроля, ревью и помощи.

3. Брать несколько лидеров на смежные позиции или "две хозяйки на одной кухне"
   Например, если взять двух сильных аналитиков с лидерскими качествами на роль архитектора и лида аналитики, в скором времени они могут начать конфликтовать, так как их взгляды на архитектуру и разработку наверняка будут отличаться. В итоге оба будут демотивированы конфликтами, а для компании будет высок риск увольнений и потери этих сотрудников. Если все-таки в одной команде оказалось двое лидеров на близких по смыслу задачах, распределите между ними разные роли и зоны ответственности так, чтобы они работали, не пересекаясь друг с другом в задачах.

4. Не иметь "команду-бенч", то есть бойцов запаса
   Часто у компаний нет такой команды для экстренных замен. Когда кто-то уволился, нужно экстренное включение нового сотрудника. Проблему может решить "команда-бенч", которая будет заниматься внутренним/неприоритетным проектом. Через эту команду могут проходить сначала сотрудники с рынка, либо "отдыхать" выгоревшие специалисты. Это позволяет компании иметь резервный ресурс и сокращать время на поиск и найм сотрудников. Специалисты из этой команды гораздо быстрее адаптируются, ведь им проще, чем новичкам с рынка, так как они уже знают вашу компанию изнутри и останется только разобраться в проекте. Особенностью "команды-бенча" будет высокая текучка: сотрудники могут задерживаться там от двух месяцев до года, но несколько позиций должны быть закреплены, например, тимлид и аналитик. 

5. Не ротировать сотрудников, работающих на одной и той же позиции один-два года 
   Звучит идеально, но нужно хотя бы стремиться к налаживанию процесса контролируемых ротаций у вас в команде. Дело в том, что каждый сотрудник сталкивается с выгоранием, если работает один-два года на одной позиции и не видит перспектив роста, задачи становятся обыденными и не мотивирующими. Чтобы не доводить до увольнения и не ждать, когда человек придет с запросом на перевод сам, менеджерам стоит планировать контролируемые ротации заранее.

   Чтобы "планировать ротации", нужно регулярно получать информацию о состоянии сотрудников: тимлиду собирать её напрямую с сотрудников. Таким образом, тимлид сигнализирует о том, что человек заскучал, а руководитель тимлида принимает решение, в какую команду возможен перевод. При этом необходима обратная связь от сотрудника о том, какой функционал и проекты ему интересны.

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

Онбординг

1. Не запрашивать доступы ко всем необходимым системам заранее
   Перед тем, как сотрудник реально сможет выполнять проектные задачи, ему нужно получить доступы во всевозможные системы. Запросите все доступы заранее. Обычно для этого достаточно подписанного NDA. Попросите HR получить подписанный новым сотрудником NDA сразу после того, как он принял оффер. Это сократит вам две недели ожидания доступов/токенов. Если сотрудник переходит из команды в команду, также не пренебрегайте этим советом. Наверняка у него есть не все доступы, и вы можете запросить их заранее. Так ваш новый член команды сразу после перехода сможет выполнять реальные задачи, а не скучать несколько дней в ожидании доступов.

2. Не назначать кураторов при адаптации новых сотрудников
   Новым сотрудникам недостаточно передать дела. Для глубокого и осознанного погружения новичкам нужна помощь кураторов. Куратором может быть любой член команды в аналогичной новичку роли. Его задача – контролировать прохождение сотрудником программы обучения, консультировать, ревьюить и помогать. Кураторство не должно заканчиваться испытательным сроком: новичку еще до полугода нужны будут консультации и поддержка куратора, не бросайте его. Ошибочно думать, что если сотрудник senior или middle, то он сам во всем разберется, ко всем придет и спросит то, что ему непонятно. Новое место работы – стресс для любого человека, и именно куратор поможет сделать период онбординга для новичка комфортным.

3. Не выделять % времени на проведение обучения кураторам
   Имейте в виду, что задача онбординга сотрудников требует времени как со стороны новичка, так и со стороны куратора, передающего знания и экспертизу. Не ждите, что кураторством эксперт будет заниматься в свободное время. Выделяйте ему процент времени на эту активность: сначала 50%, затем снижайте процент по мере погружения новичка.

4. Не иметь карту онбординга
   Каждый раз, когда в команду приходит новичок, куратор устно объясняет ему все формальные и неформальные правила компании и команды, придумывает вводные задания и ищет ссылки на материалы, которыми пользуется команда. Берегите время кураторов – составьте карту онбординга, где будут зафиксированы все организационные вопросы, а также программы обучения для каждой практики (ANA, DEV, TST, TL). Так онбординг станет структурированным и новичку будет гораздо проще и понятнее погружаться в проект.

5. Не контролировать новичков: заряженных juniors/ interns
   Если к вам пришел очень мотивированный и боевой junior/ intern, который показывает хорошие результаты, ни в коем случае не отпускайте контроль. Когда вы дадите ему серьезную задачу, есть риск, что сотрудник все-таки «поплывет» и поставит под угрозу проект. Даже если сотрудник уверяет вас, что он справляется, посмотрите результат его работы, обсудите выполнение поставленной задачи. Не забывайте управлять ожиданиями старших сотрудников и заказчика/ бизнеса от новичка – даже если последний проявил себя с лучшей стороны на первых задачах, это не значит, что он может не завалить следующие.
   В среднем, когда младший специалист справится с двумя боевыми задачами успешно, контроль можно уменьшать.

6. Не назначать кураторов сотрудникам, меняющим роль
   Даже если сотрудник давно у вас работает и сильно замотивирован, при переходе на другую роль не стоит оставлять его одного. При изменении деятельности даже экспертам нужна помощь и контроль хотя бы на первых порах. Не забывайте и таким сотрудникам назначать кураторов.

   Например, тестировщик-senior хочет стать веб-разработчиком. В соседней команде для него освобождается место, но разработчик был в команде один и при переходе тестировщика на эту роль курировать его будет некому. Сроки окончания этапа веб-разработки достаточно лояльные, команда поддерживающая, тестировщик замотивирован. В итоге оказалось, что возможности тестировщика в разработке переоценили, но, так как куратора не было, узнали об этом поздно. Также из-за отсутствия куратора экс-тестировщик быстро впал в нервозное состояние, потому что никто не разделил с ним груз ответственности. В итоге сотрудник не справлялся и уволился. Компания потеряла и senior-тестировщика, и начинающего веб-разработчика в одном лице. Вывод: если планируете перевести сотрудника на другую роль, вне зависимости от грейда ему нужен куратор в принимающей команде – тот, кто будет вести, растить и подстраховывать.

В заключении первой части статьи напомним про соблюдение баланса. С одной стороны, постоянно перемещать сотрудника с проекта на проект и превращать команды в общий пул ресурсов – плохо. С другой – не расширять команду на стабильном проекте, когда текущая перегружена, тоже не приведет ни к чему хорошему. Избегайте крайностей. Имейте запасной план. Прежде чем принимать решение о расширении, подумайте и проанализируйте ситуацию в долгосрочной перспективе. Не бойтесь ротировать сотрудников: с контролируемыми и заранее планируемыми ротациями вы приобретете значительно больше, чем потеряете. Держите руку на пульсе и регулярно общайтесь со своими сотрудниками, выявляйте их потребности и риск выгорания. 

Источники

1. Расширение команды не всегда ведет к росту производительности