company_banner

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



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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

    В заключение


    Роль тимлида в любой компании крайне важна. Он должен профессионально разбираться в технических нюансах, чувствовать людей и управлять развитием каждого участника и всей команды, добиваясь высокой эффективности работы. А иначе команда будет просто группой людей, собравшихся в одном месте и выполняющих схожие задачи. Тимлиду нужно постоянно совершенствовать свои хард и софт-скилы, включая самостоятельную работу и/или дополнительные источники, как онлайн-курсы, статьи, видео, советы коллег и т.п.
    Mail.ru Group
    Строим Интернет

    Комментарии 2

      0
      Почему тогда в скраме тимлидов нет?
        0
        Тимлид часто принимает на себя роль скрам мастера.

        Иногда тимлид может быть вдалельцем беклога вместо product owner. Это не лучшая схема, но так бывает.

        В остальном, в скраме пропагандируется получение инкремента улучшения продукта за итерацию. Если инкремент не получен, то итерация прошла неудачно.

        Для реализации этого могут использоваться целеполагание, планирование, грумминг, ретроспектива и другие скрам активности.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое