11 друзей менеджера: как собрать и не растерять команду для высокорискового проекта

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

Я Александр Юдин, занимаюсь развитием и эксплуатацией IТ-инфраструктур и информационных систем более 20 лет. А сейчас руковожу проектами по развитию и эксплуатации платформы Cloud.ru Evolution. В статье поделюсь своим подходом к  формированию команд для высокорисковых проектов, неудача в которых может негативно повлиять на карьеру.

С чего все началось, или как я понял, что будущий проект — та еще авантюра

В январе-феврале 2022 года позвонил хороший знакомый и предложил мне курировать один проект. Нам предстояло построить новую облачную платформу на базе собственных разработок. Конкурентами были VMware, Amazon Web Services и Microsoft Azure. MVP продукта мы должны были представить в декабре того же года, а уже в 2023 — начать разворачивать продакшн в трех дата-центрах!

Проект заинтересовал меня — он обещал быть амбициозным и в чем-то даже уникальным. Уже на старте на базе моего опыта у меня появилось несколько идей, как его можно реализовать.

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

За это время я осознал: мои идеи не сработают. Опыт не особо релевантен, а направлений работы куда больше, чем я мог представить… Построить систему, которую кто-то уже написал, выпустил мануалы и спеки было бы намного проще. Тут же предстояло создавать проект с нуля.

Что было на старте: цель — есть, команды — нет. Путь не определен, код не дописан, ресурсы не подвезли, дедлайн по запуску MVP — меньше чем через год. Проект намечался высокорискованным, где каждый шаг превращается в research — поиск нужного и изучение неизвестного.

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

Проект высокорисковый, данных почти нет. Что делать?

Перед началом запуска проекта я был один. У меня не было того, кто, к примеру, мог бы продумать архитектуру, сети, развернуть софт. Мне предстояло набрать в команду нужных людей, объяснить, зачем им все это надо, да еще и так, чтобы эта команда подготовила MVP в довольно сжатые сроки — до конца года.

На основе минимальных данных о проекте, которые я собрал сам и через беседы с коллегами, мне удалось сформировать портрет и состав потенциальных членов команды. Нужных специалистов в начале 2022 года по понятным причинам было найти непросто, поэтому оставался один вариант — хантить кадры внутри компании.

Шаг 1. Определиться с кругом потенциальных членов «банды»

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

Я действовал из следующего соображения: всегда найдутся те, кого не устраивает положение дел в текущей команде. Это можно косвенно понять из разговоров, а еще по настроению внутри компании. Только я был аккуратным и действовал мягко, чтобы не нажить врагов внутри компании. Все-таки мне тут еще работать 🤭.

Коллеги, которые хотели бы что-то изменить в своей работе, мне и были интересны — вербую! 

Был у меня забавный случай, когда искал в команду ГИПа. В смежной команде был ГИП, с которым я неплохо общался. Однажды я предложил ему перейти ко мне. Об этом прознал лид смежной команды и сотрудника мне не отдал. Тот в итоге отказался со словами: «Нет, со мной поговорили, сказали, что есть другие важные задачи».

Потом каждый раз в течение полугода, когда я просто заходил поприветствовать коллег, лид, завидев меня через пол опенспейса, кричал, чтобы никто из команды не поддавался моему влиянию. «Так, парни, его не слушать, игнорируйте его, пожалуйста!».

Шаг 2. Понять желания каждого «завербованного» и склад его ума 

Далее — самое интересное: заинтересовать нужных людей и привлечь их в команду. Я запланировал набрать для проекта не более десяти человек, чтобы эффективно руководить ими без посредников. Если бы людей оказалось больше, в команде могло бы нарушится единство, а я был бы не в состоянии контролировать всех, уделять время каждому.

Есть исследования, которые подтверждают, что примерно до десяти человек — оптимальный размер команды. Например, Джефф Сазерленд, один из авторов Scrum и Agile, утверждает, что лучшие результаты дают команды до 7 человек.

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

1. Общался тет-а-тет в неформальной обстановке. Как пример — предлагал ему или ей сходить в ближайший кафетерий, пообедать вместе.

2. Рассказывал о проекте.

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

4. Писал для себя саммари после встречи. Я фиксировал основные моменты, чтобы не упустить ничего важного.

Для меня смысл первой встречи — понять, насколько специалист впишется в команду. Тут речь не столько про компетенции, а про mindset (склад ума). Поясню, что я имею в виду.

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

Шаг 3. Найти, в каких точках соприкасаются желания специалиста и цели проекта 

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

После того, как я беседовал с человеком, я давал ему неделю-две на обдумывание. А после — назначал новую встречу, где мы более подробно проговаривали детали. На эту встречу я шел с пониманием масштабов проекта, амбиций человека, которому я предлагаю со мной работать, и выгод, которые была возможность достать: материальное вознаграждение, рекомендацию перед тимлидом, масштабность и уникальность будущей работы.

Так вот — я затронул мотивацию, стыковку целей проекта и сотрудника. Как это сделать? Что говорить, чтобы человек захотел прийти в команду? 

Начну с того, что всех сотрудников я условно делю на «материальщиков» и «идейных», но оговорюсь — в разговоре с любым из них стоит коснуться и денег, и самореализации. 

«Материальщиков» больше интересуют деньги и все, что с ними связано: карьера, премии, бонусы. Я позаботился о бенефитах для них заранее: переговорил с линейными руководителями и обсудил возможность индексации, премии и так далее. «Идейным» важнее самореализация и чувство принадлежности к чему-то большему. С ними может быть немного сложнее, потому что есть шанс ошибиться в предположениях о том, в каком направлении человек хочет расти.

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

Был коллега, которого я хотел схантить к себе в команду. Из первого разговора с ним я знал, что финансовый вопрос у него закрыт, деньги его не сильно волновали. Ему была важна самореализация, ощущение причастности к чему-то большому — и в разговоре с ним я показал, какой по амбициям и масштабу проект он может создать. 

— Представь, что мы вместе с тобой строим IaaS-платформу, выпускаем ее в продакшн, приходят довольные клиенты. Эта платформа стала для компании ключевой. Ты идешь в центре оживленного мегаполиса, и вот видишь на башне Москвы-сити билборд «Cloud.ru Evolution» — это платформа, которую ты сделал! Звучит круто, правда?

Шаг 4. Поддерживать мотивацию каждого члена команды

Итак, «банда» в сборе. Признаюсь, на старте мне удалось собрать не всех, кто был нужен. Пришлось идти на компромиссы: отсылать кого-то из своей команды в смежную, чтобы «выведать» информацию по нужной теме, много искать в интернете, брать консультации коллег — с условием, что никого у них не буду хантить. Что-то даже пришлось делать самому, например: рисовать фасады стоек, считать количество коммутаторов, портовую емкость, определять кабели подключения.

Несмотря на это, на первых порах мы были полны драйва и энергии. Сносили все препятствия, даже их не замечая. Но со временем мотивация команды потихоньку стала слабеть. Что в таком случае делать?

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

О мотивации можно сказать многое. Я выделю, по моему мнению, ключевые действия, которые помогают ее поддерживать:

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

2. Не стеснять команду лишними рамками. Например, частыми созвонами, пометкой каждого шага в таск-менеджере. Лучше, когда есть свобода для креатива и генерации идей. При этом контроль остается, но он становится ситуативным. Ребята знают, что в любой момент их могут спросить, как дела с задачей, и они должны будут что-то ответить. 

3. Налаживать горизонтальные связи внутри команды. Такие связи — это взаимодействие на равных, а не как «руководитель-подчиненный». Можно устраивать неформальные встречи, болтать в кофе-поинтах. 

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

Как выстраиваю хорошие отношения в команде

Я сторонник атмосферы доверия и неформального общения. Когда я сформировал команду, я был заинтересован в том, чтобы ребята общались, взаимодействовали вне работы. Это поможет им стать не просто коллегами, но и приятелями. Я считаю, что при таком раскладе людям гораздо проще проявлять себя, в том числе и в работе.

Хороший способ сплотиться — устраивать встречи команды за пределами офиса: сходить на обед в кафе вместо столовой, посидеть где-то после работы.

Если у кого-то из команды есть общие интересы, можно поучаствовать в обсуждении. Делиться своими хобби и увлечениями — только приветствуется. 

Один из главных моих принципов — не вмешиваться, не модерировать естественное общение команды, если нет конфликта. Если руководитель вклинивается в общение, команда может менее уверенно проявлять себя и в работе. А задача у меня была противоположная: убрать ненужные рамки.

Как провожу one-to-one встречи

Один из моих любимых методов — личные встречи с членами команды. Если просто по-человечески поинтересоваться, как у человека обстоят дела, можно выявить проблемы в самом начале.

Какие могут быть проблемы? Да самые разные: выгорел, и поэтому едут сроки, не нравится кто-то из команды, с чем-то не согласен или вообще что-то приключилось в жизни, и нужен дэй-офф или даже отпуск.

Как по мне, оптимальная периодичность встреч — 1-2 раза в неделю. Если проводить реже, можно упустить что-то важное: например, две недели назад человеку оффер сделали, а вы узнаете сильно позже, потому что «ван ту ваны» по календарю — раз в месяц.

Как удерживаю членов команды

Все описанные мной предыдущие шаги — способы, которые мотивируют человека работать в команде. Поддерживать атмосферу, где можно открыто делиться тем, что волнует и не нравится, проводить регулярные, но не слишком частые one-to-one, давать свободу идеям — вот, что я использую.

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

Проблемы и настроения сотрудников важно отслеживать, но, конечно, не выпытывать, не стоять над душой. Для того и выстраивается доверительная атмосфера, чтобы коллега мог сам прийти и обо всем мне рассказать.

У меня был случай, когда из-за личных обстоятельств продуктивность разработчика упала, и он не мог уделять проекту столько же времени, как в начале. Раньше он днями и ночами писал код, на выходных что-то делал, а сейчас это изменилось. Я начал думать — что с ним? Как потом выяснилось, по личным причинам человеку стало не до задач.

Я не носился в панике с мыслями: «Он нас бросил!» Да нет же, не бросил. Проект долгосрочный, и я был не готов запускать новый цикл формирования команды. Решил дать этому разработчику разобраться с тем, что происходит у него в жизни. И он потом, воодушевленный и одухотворенный, вернулся к проекту.

Как отношусь к контролю в высокорисковых проектах

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

Такие формальности я как руководитель беру на себя — все же без Ганта сегодня никуда. Но когда проект нелинейный, указывать точные сроки тяжело.

Поэтому при планировании этапов высокорискового проекта я искал баланс — держал фокус на том, что мы в состоянии делать здесь и сейчас, и прописывал время выполнения именно для этих задач. Это позволяло четче планировать сроки, пусть и на более коротком отрезке. Компромисс — наше все!

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

Кульминация 

Нас с командой ждал успех — мы с нуля построили облачную платформу Cloud.ru Evolution и уложились в сроки, которые закладывали изначально 🎉. Сейчас платформа — первое, что мы предлагаем на сайте, она стала стратегическим продуктом компании.

Резюмирую, что помогло команде добиться таких результатов:

1. Вербовка людей с помощью финансовых и профессиональных рычагов. Это наиболее универсальный метод. На старте не так важно, что именно сыграет, главное — набрать команду. Я считаю, что всегда можно найти нужного человека, которому можно предложить то, чего нет в других командах или компаниях.

2. Культура, в которой «банда» хочет творить и придумывать новое. Главный принцип — не встревать, а просто не мешать ребятам делать их работу. Инструментарий: неформальные встречи, упоминание побед, мягкое напоминание о целях — без стояния над душой и бесконечных тасков. Для идеального микса добавлю сюда атмосферу открытости и доверия.

3. Регулярные one-to-one. Я выделяю это отдельно, потому что считаю, что такие встречи — мощный инструмент, с которым можно быстро понять, когда кому-то из команды плохо либо он задумывается переходе. Еще считаю важным выстраивать диалог в первую очередь с человеком, а не со специалистом — начинать беседу не со статусов задач, а с того, как у коллеги дела.

Что стало с командой после проекта?

По окончании проекта я обошел линейных руководителей своих ребят и еще раз подсветил: «Парни и девчонки сделали то-то и то-то. Учти это, пожалуйста, при оценке их работы и расчете премий». Так я хотел достичь нескольких целей:

1. Показать руководству ценность их работников.

2. Дополнительно поощрить ребят. Обещать повышение или надбавку я не могу, поскольку не распоряжаюсь бюджетом подразделения, но косвенно повлиять на это — в моих силах.

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

Все получили премии, зарплаты проиндексировали. Кто-то перешел на новую должность: стал тимлидом или техлидом. Про всех ребят могу сказать, что профессионального веса и авторитета в компании они себе точно прибавили. В общем, в обиде никого не оставили.

Один коллега — тот, которого я мотивировал билбордом на башне Москвы-сити — ушел из компании. Как он мне объяснил при личной беседе, он не нашел в компании такого же по размахам проекта. Коллеги сразу же кинулись меня расспрашивать, а повышалась ли у него зарплата — и да, ее поднимали ранее. Но не ради денег человек трудился в выходные и по ночам. Для него была важна идея, амбициозная цель и самореализация.

Что касается меня, я перешел из одной команды в другую: раньше строил платформу в Change, сейчас эксплуатирую ее в команде Run. Не так давно завершился проект по приемке в эксплуатацию третьей зоны доступности, две уже построили и ввели в продакшн. Обкатали страшные сценарии в рамках Disaster Recovery Plan. Мне официально позволили сломать то, что я когда-то построил — и потом, естественно, восстановить. Потому что все-таки Disaster Recovery Plan.

Как вам такой подход к работе с командой? Может, у вас есть какие-то иные решения, которые тоже круто сработали? Делитесь в комментариях.