Роль тимлида: что остается менеджерам?

    image

    Привет, Хабр!

    В последнее время в области IT и digital все чаще слышится слово «тимлид». Но при детальном рассмотрении видно, что все по-своему понимают эту профессию.

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

    В этой статье мы попробуем разобраться, кто же такой этот загадочный «тимлид» и так ли нужны менеджеры?



    Кто такой тимлид?

    TeamLead, как следует из самого слова – это лидер команды разработчиков. Это человек, который отвечает за все, что касается разработки в проекте. У него очень богатый функционал – это снятие запроса клиента, оценка объема и сроков работы с учетом рисков и особенностей своей команды, распределение задач внутри команды с максимальной эффективностью, планирование и выпуск релизов, и даже мотивация команды на работу и участие в презентациях ключевых релизов заказчику.

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

    Пишет ли тимлид код? Безусловно, ведь он вдохновляет свою команду в том числе и личным примером. Но на написание кода он тратит не более 20-30% рабочего времени, так как в приоритете у него управление командой.

    Профессиональный портрет

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

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

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

    Как уже было сказано выше, тимлид сам пишет код, поэтому, вне всяких сомнений, он должен обладать солидным опытом разработки – от 5 лет и более.

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

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

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

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

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

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

    И, наконец, самое главное качество для любой профессии – честность. Умение быть честным в первую очередь перед самим собой, способность не закрывать глаза на моменты, когда что-то идет не так. Честность перед членами команды, менеджерами проекта и заказчиком. Только подумайте, сколько неудачных проектов было бы спасено, если бы кто-нибудь вовремя встал и сказал: «У нас проблема».

    Роль менеджера

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

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

    Резюме

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

    Остается вопрос, как же разработчики становятся тимлидами? Об этом и о карьере в ИТ в целом мы поговорим в наших следующих статьях.
    Бизнес-школа РИК
    28,00
    Компания
    Поделиться публикацией

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

      +7
      Правильный тимлид в разработке — это как сержант в армии США. А сержантский корпус — становой хребет армии США.
        0
        Тимлид в разработке — как Team Leader в морской пехоте США )))
        –1
        Пишет ли тимлид код? Безусловно

        хм… Почему? («потому что вдохновляет команду»? что за бред?)
          –1
          Владимир, простите за прямолинейность, так-то я редко высказываюсь, но вы реально написали какую-то хрень. Мне вот сразу видно, что знания у вас чисто теоретические, и на практике вы никогда не строили команду разработки и понятия не имеете, кто там за что отвечает. Если увижу в резюме кандидатов название вашей школы — ну точно не возьму такого на работу.
            +4
            Всегда доставляли такие комментарии. Появился из неоткуда сказал, что материал «хрень» без всяческих оснований, получил лайки. Я бы не отказался прочитать ответную статью, чтобы подкрепить сказанное. В противном случае, ценности от коммента ноль.
              0
              Евгений, это, безусловно, ваше право и я не претендую на соответствие конкретно вашим ожиданиям — я поделился своим мнением, хотя меня всегда настораживали люди, способные делать поверхностные выводы на основании недостатка данных. Надеюсь, это помогает вам в работе.
              +2
              снятие запроса клиента
              и
              планирование и выпуск релизов

              Это вот уж точно не зона ответственности тимлида. Преобразовывать требования клиента в понятный список требований — это, как правило, задача либо бизнес-аналитика, либо менеджера проекта. А планирование релизов это вообще стратегическая задача. Тимлид отвечает чаще всего за тактику: разбить список требований на итерации, выделить задачи, проводить ревью кода, и держать в тонусе команду не давая ей прокрастинировать и еще не мало всяких вещей. Однако нужно понимать, что основная область работы тимлида — это его команда, он отвечает за общую эффективность.
              А то, что вы поместили в обязанности некоего менеджера. То это административные задачи в широком смысле, которые зачастую вообще имеют мало отношения к разработке проекта. И занимаются ими менеджеры по другим вопросам.
                –1
                Кирилл, я могу согласиться с тем, что бизнес-аналитик может снять задачу и преобразовать ее в требования, но это предельный фэн-шуй мечты ;)) я работал на проектах с крупными интеграторами уровня Люксофта и там тимлид ездил собирать задачу. Проекты шли вполне успешно.
                  0
                  Т.е. мой комментарий не в пику вам, а о том, что в большинстве случаев идеально все сделать не получается ;)
                    +2
                    Бизнес-аналитик это не предельный фен-шуй мечты. Просто он не всегда нужен, например если компания небольшая. То его роль выполнять все же лучше менеджеру проекта, а не тимлиду.
                    Так то понятно, что из-за недостатка специалистов в большинстве случаев один человек занят в 2-3 направлениях.
                      0
                      Исходя из моей практики, менеджеру, как правило, не до аналитики. Просто, деятельность менеджера и аналитика, на мой взгляд, принципиально разная. У менеджера много мелких задач и постоянное жонглирование приоритетами. А у аналитика — основательные длинные задачи, которые опасно делать урывками. Сам много раз видел эпические фэйлы, когда менеджеров заставляли писать ТЗ и при этом у них была пара клиентов с плотными коммуникациями — ничего хорошего не выходило :))
                +1
                А как реализовать постановку задач?

                менеджер->тимлид->программисты

                Тут через мозг тимлида будет солидный говнопровод

                или

                менеджер->программисты<-тимлид

                Тут тимлид может фокус внимания с задач перевести на кот
                  +1
                  У меня на практике подход был такой (речь, в основном, про интеграционные проекты, хотя, в интернете почти каждый проект такой):

                  — Когда начинается новый блок работ (спринт или новый отдельный кусок проекта), мы звали тимлида на встречу с клиентом и его айтишниками (если они есть). Это критически необходимо, потому что менеджер просто не знает, что надо спросить у клиента. Я на своей практике видел менеджеров, которые могли действительно качественно снять задачу с клиента, раза 2-3. Причем, тесно работал и с крупнейшими интеграторами, и со стартапами.

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

                  И ничего страшного не произошло — общение тимлида с клиентом было строго пакетировано по времени :)
                  –1
                  В этой статье мы попробуем разобраться


                  Но затея не удалась, за попытку — спасибо (с) Юнона и Авось
                    0
                    «Наконец, менеджер может быть настоящим продюсером проекта, управляя продуктом сразу с нескольких сторон: дизайн, разработка, маркетинг и т.д. Однако, это очень непростая роль и до нее менеджеру необходимо дорасти и в профессиональном и в личностном смысле.»

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

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

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

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