«В группе разработчиков нужны конфликты. Результаты будут быстрее»

Как тимлиду строить команду?

Определить размер

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

Определить состав

Следует определить состав команды, требуемый уровень специалистов. Чтобы делать любой проект, нужен определённый набор компетенций. В продуктовом подходе есть инструмент — Звёздная карта — который позволяет сформировать матрицу компетенций, требующихся для реализации проекта. Смотря на эту карту, можно закрывать компетенции и впоследствии сформировать кроссфункциональную команду.

Быть готовым к потерям

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

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

ВАЖНО во избежание неконгруэнтности подбирать людей, близких команде по ценностям и взглядам на жизнь. Если есть потребность в создании команды для краткосрочного проекта и нет нужды в процессах её выстраивания, можно опереться только на компетенции членов. Но если команда нужна на долгосрочную перспективу, она должна быть синхронизирована по ценностям. Человек, который не вписывается в общую систему ценностей, в любом случае уйдёт. Рано или поздно.

Сделать акцент на коммуникациях

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

Какие навыки нужны тимлиду?

Soft skills

Руководитель группы разработки должен быть лидером и обладать соответствующими качествами: уметь не только управлять процессами, но и брать ответственность за их результат; гореть тем, что делает, заражая при этом других, наставлять сотрудников. Ко всему прочему руководитель должен обладать базовыми знаниями психологии. Без этого тяжело выстроить работу с людьми.

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

Hard skills

Хард скиллы важны, но не так принципиальны для тимлида. Как говорил Стив Джобс, «бессмысленно нанимать толковых людей и указывать им, что делать». Необходимо брать людей, чтобы они говорили, что делать. В идеале тимлид должен быть компетентным и обладать экспертными знаниями в процессах разработки. И понимать, как делается продукт. Вовсе необязательно знать все нюансы: это может быть верхнеуровневое понимание ситуации, но во всей её целостности, с учетом взаимосвязей и взаимовлияния отдельных элементов.
Если человек — эксперт, он достаточно быстро вникнет в ту или иную область в случае возникновения проблемы. Если лидер — не эксперт, ему понадобится кто-то, кто может давать экспертную оценку с минимальным набором софтовых скиллов. Менеджер может отлично работать в паре с технарём.

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

С какими задачами сталкивается тимлид и как их решать?

Научить команду самостоятельности

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

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

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

Сотрудничество со смежными командами

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

ВАЖНО в этом вопрос отталкиваться от оргструктуры организации. Согласно закону М.Конвея, она накладывает отпечаток на архитектуру программного решения. В зависимости от того, что является приоритетным для компании при разработке — оргструктура или архитектура — будут выстраиваться особые модели коммуникации. К примеру, у нас на проекте за определённые микросервисы отвечает конкретная команда, есть чёткие границы её ответственности при взаимодействии с другими командами. Это позволяет избегать дубляжа в функционале и полномочиях.

Определить внутренние правила игры

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

У нас две команды разработчиков. Обе работают по Scrum. Одна пишет сервис на C#, другая на Java. Сперва мы разбили зоны функциональности. А впоследствии фиксировали контракты, договаривались, как они будут выглядеть, расходились, и далее совместно фиксировали результат. Если говорить о внутрикомандной работе, то у нас преобладают горизонтальные взаимодействия. Коллеги приходят ко мне как к эксперту за советом, рекомендацией, но не за готовым решением.

Автор: Юрий Кербицков, руководитель группы разработки компании ICL Системные технологии

Публикация размещена на Tproger.