О тимлиде, его качествах и умениях
Чем больше команда, чем больше разных специалистов в нее входит, тем сложнее такой командой управлять. Тимлиду необходимо быть тактиком, стратегом и техническим консультантом одновременно. Он должен выполнять цели, поставленные компанией, и одновременно учитывать интересы и потребности своей команды.
Так, тимлиду нужно хорошо понимать суть бизнеса компании, ее ценности и структуру. А еще ему необходимо четко осознавать, чего компания хочет от разработчиков, каких целей должна достичь команда и в какой срок. Это понимание тимлиду нужно донести до всех членов команды, чтобы каждый из них знал, что нужно делать и для чего.
Кроме профессиональных навыков разработчика, тимлиду нужны:
- владение техникой фасилитации встреч;
- умение выстраивать коммуникации;
- умение распределять как задачи, так и ответственность;
- умение локализовать конфликтные ситуации в команде;
- эмпатия, коммуникативность и внимательность.
Основные задачи, с которыми тимлиду нужно будет работать каждый день:
- управление людьми и командами;
- управление проектами;
- знание технологий и их использование;
- управление бизнес-процессами.
О формировании команды и ее жизненных этапах
Для сбора команды необходимо понимать профиль кандидатов, их технические навыки и то, какие функции закроет каждый член команды. Оптимальный вариант — сначала продумать состав команды, а затем ее собирать.
Но чаще всего бывает не так. Сначала над проектом начинает работать пара человек, затем они понимают, что решить все задачи они не в состоянии, и нанимают ещё одного человека или несколько.
Если вам нужно усилить какое-то звено, добавить новые компетенции в команду и т.п., то в первую очередь определитесь с тем, какие цели и функции будут у каждой позиции и какими компетенциями должен обладать сотрудник.
Чтобы превратить толпу разработчиков в слаженно действующую команду, нужно донести до всех общую, понятную и измеримую цель, сформулировать принципы работы и взаимодействия.
Порой бывает так, что для достижения общей цели тимлид очень сильно давит на коллег, от чего они начинают его ненавидеть и выгорают. Как не настроить всех против себя? Ответ довольно прост:
- давайте возможность каждому сотруднику проявить себя;
- занимайтесь ростом каждого сотрудника;
- прислушивайтесь к мнению каждого;
- позаботьтесь, чтобы команда понимала общую цель;
- не устанавливайте правила, которые команда не понимает.
Что касается этапов становления команды, то их еще в 1965 году описал доктор Брюс Такман. Согласно его модели, жизненный цикл команды состоит из четырёх стадий:
- Формирование. На этом этапе у команды сильная зависимость от лидера, ей требуется руководство и указание направления развития.
- Бурление. Члены команды принимают некоторые решения самостоятельно, без лидера. Но люди иногда конфликтуют, поскольку пытаются утвердиться в отношении к коллегам и лидеру.
- Нормализация. Роли и обязанности становятся понятны всем членам команды, они принимают их.
- Производительность. Все ясно понимают стратегию, что и зачем делают. Команда способна долго работать без лидера.
Эти стадии цикличны, через них команда может проходить несколько раз, но с каждым циклом ее производительность увеличивается.
О коммуникациях в команде
Для эффективной коммуникации в команде очень важно сделать так, чтобы каждый участник понимал, чем занимаются его коллеги. Для этого необходимо очертить границы ответственности, чтобы все знали, где начинается и где заканчивается их персональная «территория». В этом очень хорошо помогает матрица RACI, позволяющая систематизировать все активности и события и наглядно показать команде, кто и что должен делать в том или ином случае.
Эта же матрица помогает выявить узкие места в коммуникациях и внести изменения. Скажем, проводят встречу на 10 человек, после которой составляют список задач без указания ответственных за каждую задачу. В этом нет ничего страшного, если записаны понятные задачи вроде разработки сайта или запуска рекламы. Тогда члены команды прекрасно понимают, кто и что должен делать. Но когда возникают задачи на стыке функций разных специалистов, то их обычно исполняются либо неэффективно, либо никак.
В чем здесь проблема? Участники команды не понимают, где заканчивается зона ответственности одного и начинается зона ответственности второго. Каждый считает, что какую-то задачу должен выполнять другой. Вместо того, чтобы идти к общей цели, люди занимаются формализмом и спорят о том, кто должен ставить задачу. Чтобы такого не случалось, нужно обязательно определять ответственного за решение каждой подобной задачи, иначе за дело никто не возьмется. Даже если задача на стыке функциональности, у нее должен быть один владелец, с которого будут спрашивать. И он должен решить ее во что бы то ни стало.
Другая частая ситуация: заказчик просит внести незначительные, но важные правки. Задача ставится в спринт, а ее выполнение согласовывается менеджером и тимлидом с непосредственным исполнителем. Менеджер и тимлид могут долго согласовывать и выбирать исполнителя, который вообще неизвестно когда получит задачу на руки. Так что для таких маленьких правок лучше всего создать специальную линию коммуникаций: напрямую связывать заказчика и разработчика, даже если это будет происходить только в строго отведенные часы.
Важную роль в коммуникациях играют регламент и правила. Но формализм часто вредит, так что навязывать их команде не стоит. Искусственные ограничения, как правило, не приживаются, а только создают проблемы. Лучше сосредоточиться на формировании и донесении командных принципов, которыми люди должны руководствоваться при принятии решений и при коммуникациях друг с другом. Это поможет сотрудникам принимать решения самостоятельно, не бояться ответственности и реализовывать решения.
В некоторых компаниях принципы разрабатывают при создании команды (причем разные команды делают это независимо друг от друга), утверждая отдельные положения на общей встрече.
Об удаленной работе
С эпидемией коронавируса внутренние организационные процессы очень сильно изменились. Это касается и управления командами. Самые очевидные отличия:
- Получение дополнительной информации. Когда мы работаем в офисе, то при обсуждении основной темы часто обговариваем и дополнительные. Это помогает лучше понять суть задачи и сформировать более полное представление о коллегах. Когда же общение ограничивается только созвонами на определенную тему, то обсуждения получаются не такими насыщенными, иногда возникает искаженное представление о людях.
- Получение помощи. В офисе людям проще попросить о помощи и получить ее. А с чатами и видео это не так удобно. Сложнее всего новичкам, которые вливаются и развиваются не так быстро.
- Контроль исполнения задач. Даже самые трудолюбивые сотрудники могут быть выбиты из колеи, когда вместо привычного офиса оказываются на удалёнке. А тимлиду становится гораздо сложнее отслеживать исполнение задач.
Руководителю команды нужно учитывать эти сложности. Например, приходится чаще устраивать неофициальные и неформальные созвоны, чтобы участники команды лучше узнавали друг друга. Рабочие встречи стоит начинать с того, чтобы люди немного поболтали на свободные темы и получили порцию позитива.
Также руководителю приходится устраивать обмен опытом в команде и внимательнее оценивать метрики эффективности сотрудника, чтобы вовремя заметить просадку и исправить проблему. В нашей команде после перехода на удаленный режим продуктивность некоторых сотрудников сильно снизилась. Сначала мы не могли понять, в чем дело, думали, что это выгорание, либо человек потерял интерес. Но когда вернули некоторых в офис, их продуктивность вернулась на доковидный уровень.
Эффективность распределенной команды зависит и от инструментов. По-прежнему важную роль играют база знаний, где собраны ответы на частые вопросы, и таск-трекер, в котором сотрудники могут просмотреть свои задачи и оценить их выполнение.
Возможные проблемы
В работе команды возникают разные проблемы. Расскажу о самых частых:
Разобщенность. Каждый член команды «тянет одеяло на себя», снижается эффективность. Тот случай, когда эффективность одного человека выше эффективности всей команды. В начале существования команды такие ситуации допустимы и даже полезны, поскольку участники понимают, кто чего стоит. Но если пустить разобщенность на самотёк, это приведет либо к быстрому выгоранию отдельных участников и сложностям в проекте, либо к его срыву.
Отсутствие общей цели. Пожалуй, это самая большая проблема, поскольку в таком случае команды нет — есть просто группа людей, эффективность которой ограничена возможностями бюрократического аппарата. То есть придется заставлять сотрудников бездумно выполнять работу, смысла которой они не понимают.
Эта проблема может выражаться по-разному: либо цель понимает только менеджер, либо вообще никто.
В первом случае не всё потеряно, управленцу нужно прикинуть, сколько он снимет с себя операционной работы, если добьется того, что все действия сотрудников будут направлены на достижение нужной цели. Во втором случае сложнее: управленцу необходимо сначала самостоятельно разобраться в сути работы и общей цели, а потом объяснить команде. Глядишь, и сам поймет.
В заключение
Роль тимлида в любой компании крайне важна. Он должен профессионально разбираться в технических нюансах, чувствовать людей и управлять развитием каждого участника и всей команды, добиваясь высокой эффективности работы. А иначе команда будет просто группой людей, собравшихся в одном месте и выполняющих схожие задачи. Тимлиду нужно постоянно совершенствовать свои хард и софт-скилы, включая самостоятельную работу и/или дополнительные источники, как онлайн-курсы, статьи, видео, советы коллег и т.п.