Почему без тимлида не обойтись: нюансы формирования комплексной команды разработчиков и работа на удаленке

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.


От тимлида зависит многое — эффективность команды, достижение поставленных целей, профессиональный рост сотрудников. И чтобы разобраться в нюансах работы тимлида, мы поговорили с Иваном Михеевым, Deputy CTO в компании AGIMA. У Ивана многолетний опыт управления большими командами, включая отдел разработки с общей выработкой от 10 000 до 15 000 часов в месяц: PHP, Python, Mobile, Front-End, DevOps, QA.

О тимлиде, его качествах и умениях


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

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

Кроме профессиональных навыков разработчика, тимлиду нужны:

  • владение техникой фасилитации встреч;
  • умение выстраивать коммуникации;
  • умение распределять как задачи, так и ответственность;
  • умение локализовать конфликтные ситуации в команде;
  • эмпатия, коммуникативность и внимательность.

Основные задачи, с которыми тимлиду нужно будет работать каждый день:

  • управление людьми и командами;
  • управление проектами;
  • знание технологий и их использование;
  • управление бизнес-процессами.

О формировании команды и ее жизненных этапах


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

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

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

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

Порой бывает так, что для достижения общей цели тимлид очень сильно давит на коллег, от чего они начинают его ненавидеть и выгорают. Как не настроить всех против себя? Ответ довольно прост:

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

Что касается этапов становления команды, то их еще в 1965 году описал доктор Брюс Такман. Согласно его модели, жизненный цикл команды состоит из четырёх стадий:

  • Формирование. На этом этапе у команды сильная зависимость от лидера, ей требуется руководство и указание направления развития.
  • Бурление. Члены команды принимают некоторые решения самостоятельно, без лидера. Но люди иногда конфликтуют, поскольку пытаются утвердиться в отношении к коллегам и лидеру.
  • Нормализация. Роли и обязанности становятся понятны всем членам команды, они принимают их.
  • Производительность. Все ясно понимают стратегию, что и зачем делают. Команда способна долго работать без лидера.

Эти стадии цикличны, через них команда может проходить несколько раз, но с каждым циклом ее производительность увеличивается.

О коммуникациях в команде


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

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

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

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

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

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

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

Об удаленной работе


С эпидемией коронавируса внутренние организационные процессы очень сильно изменились. Это касается и управления командами. Самые очевидные отличия:

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

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

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

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

Возможные проблемы


В работе команды возникают разные проблемы. Расскажу о самых частых:

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

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

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

Эта проблема может выражаться по-разному: либо цель понимает только менеджер, либо вообще никто.

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

В заключение


Роль тимлида в любой компании крайне важна. Он должен профессионально разбираться в технических нюансах, чувствовать людей и управлять развитием каждого участника и всей команды, добиваясь высокой эффективности работы. А иначе команда будет просто группой людей, собравшихся в одном месте и выполняющих схожие задачи. Тимлиду нужно постоянно совершенствовать свои хард и софт-скилы, включая самостоятельную работу и/или дополнительные источники, как онлайн-курсы, статьи, видео, советы коллег и т.п.
Источник: https://habr.com/ru/company/mailru/blog/524752/


Интересные статьи

Интересные статьи

— Ян, сколько можно сбивать проекторы?! Когда вы уже закончите свой танк крутить?! Ну вот, опять сетка на сшивке сбилась, опять переделывать! — Дмитрий, выключите, наконец, болга...
Мои размышления о неудаче брутфорса авторского права вызвали бурную реакцию и массу вопросов. Вопросы продолжают поступать. В процессе обсуждения возникает множество однотипных дискуссий, что отн...
Доброго времени суток, друзья! Представляю Вашему вниманию перевод статьи Martin Heinz «Implementing 2D Physics in JavaScript». Давайте немного развлечемся, создавая двухмерные симуляции и ...
Пока Google готовил глобальное обновление для русскоязычного Ассистента – с новыми голосами, блэкджеком и встроенными оплатами, мы решили создать для него собственную игру. Мы экспериментировали ...
Привет, Хабр. В последние годы на территории России, Украины и Белоруссии обсуждалось введение цифрового радио стандарта DAB+. И если в России процесс пока не продвинулся, то в Украине и Белор...