Решение конфликтов, эмпатия и понимание цели: soft skills руководителя команды разработчиков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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