Soft skills руководителя команды разработчиков

Сегодня поговорим о том, какие soft-скиллы должны быть у руководителя, как, где и почему их необходимо применять. Эта тема затрагивается не так часто, поэтому сегодня мы при помощи Андрея Рыжкина, ИТ-директора Agima, решили расставить все точки над i.

Менеджер или технический специалист?

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

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

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

Оптимальный вариант — назначить руководителем команды разработчиков человека с хорошей технической базой, опытом и заметными лидерскими/административными качествами.

С чем придется столкнуться руководителю? От компании к компании этот список может варьироваться, но вот список стандартных обязанностей руководителя команды разработчиков:

1. Работа с командой: найм, онбординг, развитие, увольнение сотрудников, one2one, обратная связь, распределение задач, лидерство, фасилитация, управление конфликтами.
2. Работа с продуктом: понимание бизнес-ценности, целей, понимание потребностей клиента и потребителей; совместное с PO управление беклогом.
3. Обеспечение функционального качества проекта: процесс тестирования и управление инцидентами.
4. Обеспечение технического качества: оптимизированный и поддерживаемый код, работа с техдолгом, архитектура проекта, техническая документация, работа над отказоустойчивостью и производительностью проекта.
5. Автоматизация цикла разработки: настройка CI/CD, понимание и внедрение лучших практик.
6. Административные обязанности: схемы ведения проекта, улучшение процесса, метрики производства.
7. Выстраивание отношений с людьми внутри и вовне команды: эмпатия, умение договариваться, находить компромиссы и отстаивать интересы.

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

Примеры из практики? А пожалуйста

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

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

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

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

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

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

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

В целом, хороший руководитель должен:

1. Понимать необходимость принять то либо иное техническое решение и нести за него ответственность.
2. Уметь управлять людьми и постоянно прокачивать этот скилл.
3. Быть готовым к таким вызовам:
4. Распределять задачи, а не самостоятельно все решать, замыкая на себе процессы.
5. Общаться с людьми, а не отписываться в тикете.
6. Принимать решения в условиях недостаточной информированности и брать на себя за это ответственность.
7. Принимать очень непростые решения: увольнение, повышение в должности сотрудника или отказ в повышении, перевод сотрудника на другой проект.
8. Уметь видеть, закладывать и минимизировать риски.

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

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

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

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

Софт-скиллы руководителя команды разработчиков

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

1. Эмпатия, поскольку придется много работать с людьми: пытаться им помочь, ободрять, развивать, давать обратную связь, договариваться в случае возникновения конфликтных ситуаций.
2. Решительность, т.к. руководитель должен оперативно решать возникающие проблемы, даже в том случае, если информации недостаточно.
3. Тайм-менеджмент. Задач будет всегда больше, чем руководитель может решить самостоятельно. Поэтому нужно четко понимать, что реально решить, а что нет, плюс адекватно оценивать время, которое потребуется для каждой из новых задач.
4. Умение делегировать и принимать задачи. Этот скилл тесно связан с тайм-менеджментом. Плюс ко всему, следует научиться говорить «нет».
5. Стрессоустойчивость. Этот скилл очень нужен для того, чтобы долго и успешно работать в режиме многозадачности. Руководителя часто дергают — приходят обсудить важные вопросы, звонят по телефону, пишут в мессенджерах и на e-mail, прилетают новые задачи в трекере.
6. Системное мышление — необходимо уметь строить реальную объективную картину происходящего в отделе, чтобы находить проблемы и улучшать процессы.
7. Умение строить стратегические и тактические планы.
8. Самостоятельность. Решения нужно принимать самостоятельно, не надеясь на чудо, когда проблема или конфликт разрешатся сами собой.

И напоследок — несколько советов тем читателям, кто хочет стать хорошим руководителем команды разработчиков:

1. Не бойтесь ошибиться. Принять неправильное решение лучше, чем вообще ничего не решать, ожидая у моря погоды. В этом случае ситуация будет пущена на самотек, и это один из худших вариантов развития событий, т.к. вы ей не управляете.
2. Не стесняйтесь говорить своим коллегам, подчиненным и/или руководству, что вы чего-то не понимаете или не знаете как поступить в определенной ситуации, не стесняйтесь попросить о помощи. Если ситуация сложная — можно взять таймаут и посоветоваться с коллегами, руководством. В большинстве случаев это поможет решить задачу — совет со стороны часто помогает открыть новые аспекты.
3. Будьте готовы и открыты к критике, советам и предложениям.
4. Подмечайте удачные управленческие решения коллег и руководства. Берите их на заметку и старайтесь использовать при необходимости.

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

Автор -- Андрей Рыжкин, директор департамента разработки.

Больше полезных материалов смотрите на сайте Agima.ru.