Как управлять командами в IT и не выгореть: от лодок к пароходам

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

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

1. Маленькая моторная лодка
2. Кросскомандные коммуникации
3. Выращивание лидеров
   
4. Личные уроки
   
5. Резюме
   

Маленькая моторная лодка

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

Потом я получил в управление ещё одну команду. В ней изначально было семь человек, но часть разработчиков её покинула, и численность сократилась до трёх. Я посмотрел на бэклог задач, мы кое-что оптимизировали, и сейчас этой команде просто не нужно столько людей, сколько в ней было раньше. С управленческой точки зрения у меня получилась ещё одна «моторная лодка». Теперь их стало две. Руководить ими удавалось, но по мере увеличения количества людей управление начинает занимать пропорционально большее количество времени. Две команды — в два раза больше времени на управление. 

Когда я перешёл на позицию CTO стрима, команд стало три, причём состояли они не только из разработчиков, но и людей с другими ролями — всего около сорока человек.

На старте я стал выстраивать с ними отношения как тимлид: то есть в каждой команде вникал во все процессы, общался со всеми участниками. Другими словами, стал строить ещё одну моторную лодку. Однако скоро стало ясно, что «лодочный» подход больше не работает. 

Во-первых, я погряз в микроменеджменте: мне регулярно приходилось вмешиваться в деятельность команд и «тушить пожары». Взяли в работу задачу, но не договорились о сроках; внешний подрядчик не успевает с задачей, а об этом становится известно лишь когда проходит дедлайн… и прочее, и прочее. «Микроменеджерить» мне приходилось и раньше, но одно дело — когда ты ведёшь одну или две небольшие команды, совсем другое — когда у тебя их много, и они большие.

Во-вторых, моего времени просто физически перестало хватать на ручное управление.  

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

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

Кросскомандные коммуникации

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

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

Мы выбрали второй путь: создали общие чаты, стали проводить очные встречи в офисе. Я не против режима удалённой работы, но всё же считаю, что для эффективной межличностной коммуникации команде стоит собираться в офисе хотя бы раз в неделю.

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

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

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

Но долго это продолжаться не могло, поэтому, наладив межкомандные коммуникации, мы стали растить новых техлидов, чтобы не приходилось и дальше тушить локальные «пожары». 

Выращивание лидеров

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

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

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

Развитие способности к чёткому целеполаганию — ещё один важный для взращивания хорошего лидера фактор. Человек должен сам понимать, куда растить команду, уметь брать на себя ответственность. Многие ребята думают, что позиция лида — это только «плюшки», раздача поручений и так далее. На самом деле на 80% — это ответственность. Да, у тебя развязаны руки в большей степени, чем у линейного разработчика, но ты отвечаешь за результат. Многие думают, что если они упустят сроки, то просто придут к руководству и скажут: «Ну, у нас не получилось». Люди сильно удивляются, когда ты им говоришь: вы придумали такой план, вы по нему в сроки не умещаетесь, вам надо сейчас сесть и придумать, как успеть. Они думают, что им добавят время, выделят дополнительные ресурсы, если у них не получится. Но в реальности всё выходит иначе.

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

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

У ситуации с рисками есть и обратная сторона, требующая управления. Если начинающие лиды могут чего-то не учесть, то опытные, как ни странно, напротив, иногда усложняют процесс, чтобы учесть даже те риски, вероятность возникновения которых ничтожна. Помня о некоторых случаях из прошлого, они как бы пытаются «подстелить соломку» даже там, где этого делать не нужно. И тут как раз задача управленца заключается в том, чтобы не допустить излишнего усложнения процессов, — потому что сложность обычно означает увеличенные сроки, а нам это не нужно. Не то чтобы тут надо было рисковать и ставить нереалистично короткие сроки, просто мы по опыту знаем, сколько времени нужно заложить на различные нештатные ситуации, когда подтверждаем обязательства по задачам. Например, когда на проекте наши результаты зависят от результатов внешних команд, на которые у нас нет прямых рычагов воздействия, мы «на берегу» закладываем 10–20% времени на случай, если внешние партнеры опоздают с дедлайнами. 

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

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

Личные уроки

Я рассказал о том, как изменил команды и взаимодействие между ними, чтобы работа делалась эффективней, а люди, которые её выполняют, росли профессионально и чувствовали себя более счастливыми на своих рабочих местах. Может показаться, что всё дело в списке мер, которые лидер должен применить к командам, но на самом деле, как бы банально это ни звучало, начинать изменения нужно с себя. 

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

Первая моя ошибка и, как я вижу по своим коллегам сейчас, ошибка многих других молодых лидеров заключается в стремлении брать на себя больше задач и обязательств, чем ты реально можешь сделать. Когда получаешь лидерскую позицию, амбиции зашкаливают. Ты думаешь, что раз раньше справлялся, то и сейчас как-нибудь справишься. Но масштаб и количество задач растут, а у тебя как было 24 часа в сутках, так и осталось. Хорошая аналогия тут: марафон и спринт. Участники марафонов не бегут всё время в полную силу, а грамотно рассчитывают ресурсы на всю дистанцию, тогда как как спринтеры выкладываются на полную в момент непродолжительного рывка. 

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

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

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

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

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

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

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

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

Резюме

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

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