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

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

Как вообще появилась Школа Тимлида на Хекслете

Школа тимлида родилась из нашего курса для наставников. У нас наставниками работают практикующие разработчики, и для них наставничество — далеко не основная деятельность. В то же время менторство требует определенного понимания того, как учатся другие люди, как устроена вся культура обучения, а также наличие определенного уровня эмпатии. Конечно, в большинстве случаев люди этими навыками изначально не владеют. 

Поэтому мы стали помогать нашим наставникам приобрести эти компетенции — учить, как взаимодействовать со студентами и выстраивать культуру взаимодействия. Мы стараемся максимально реалистично смоделировать те взаимодействия, с которыми столкнется будущий разработчик в команде. Это значит, что у них не будет любящего учителя, который ведет за ручку и все рассказывает. Студент в Хекслете достаточно автономен. В то же время есть постоянная коммуникация в комьюнити студентов: они задают вопросы и получают на них ответы. Этот процесс изначально выстроен точно так же, как общаются тимлид и джун в рабочих командах.

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

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

В интернете можно найти огромное количество роадмапов для тимлидов, некоторые из гигантские и противоречащие друг другу. При этом мы часто в Школе поднимаем вопрос: «А кто же такой тимлид, что для него действительно важно?». Особенно потому, что хардовая экспертность не всегда является строго обязательной для классного тимлида. Понятно, что тимлид должен быть как минимум компетентным в той области, где работает. Но есть много дискуссий, насколько глубоко его компетентность должна заходить. Школа тимлида на Хекслете охватывает не все навыки, которые можно найти в роадмапах, — но у нас и нет таких целей. Скорее, мы много работаем над теми вещами, которые характерны как для тимлидов, так и для наставников Хекслета — их удобнее всего имплементировать после обучения в Школе в наставничество у нас. 

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

В первую очередь, наша целевая аудитория — практикующие разработчики или тестировщики, которые потенциально могли бы стать наставниками Хекслета. В предыдущих наборах у нас было много ребят не только из разработки, но и из IT в самом широком смысле — проджекты, продакты, техлиды и техдиры, и даже действующие тимлиды. Сам процесс обучения устроен так, что мы не создаем закрытое пространство, где есть только ограниченный набор знаний. У нас много коммуникации между студентами Школы, во время которой студенты обмениваются опытом — это очень важно, потому что такие процессы повышают вовлеченность студентов-тимлидов в обучение.

Формат обучения — как мы учим и где делать домашку

Сейчас мы набираем третий набор в Школу тимлида, поэтому мы уже успели проработать формат обучения. Школа длится 3 недели, за это время у нас проходит 6 встреч в Zoom (2 раза в неделю) примерно по 2 часа каждая. 

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

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

Первые уроки: SMART, Цикл Деминга и канбан-доски

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

На следующей встрече мы обсуждаем, почему несмотря на работу с целеполаганием по SMART, может оказаться, что этого все равно недостаточно. Если команда у тимлида будет состоять хотя бы из нескольких человек, то эти цели и задачи нужно будет дробить, как-то отслеживать прогресс и анализировать проблемы. Тут мы знакомимся с инструментами для дальнейшей работы с целями — это PDCA, или цикл Деминга-Шухарта.

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

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

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

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

Середина программы: цикл Колба, шеринг знаний и работа с мотивацией

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

После того, как мы поговорили о таксономии, мы переходим к знакомству с поэтапным освоением нового знания на примере цикла Колба. Если кратко, то он состоит из нескольких основных этапов:

  1. Человек получает новый опыт и осознает проблему

  2. Переходим к обучению, практикуемся, чтобы решить проблему

  3. Применяем полученные знания в жизни и закрываем проблему. 

Это наиболее распространённая модель усвоения новых знаний взрослыми людьми.

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

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

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

На живых примерах мы разбираем, как выглядит каждая из этих базовых идей:

  • Ожидания. Как мы демонстрируем свои ожидания от наших коллег, студентов или сотрудников

  • Язык. Каким языком мы пользуемся для коммуникации, какие виды языка бывают и как они влияют на взаимодействие людей друг с другом

  • Взаимодействие. Как оно выглядит и какие типы взаимодействия существуют.

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

  • Ритуалы. Конечно, мы не будем обсуждать, как кого-то приносить в жертву богам. Скорее мы будем говорить про регулярно повторяющиеся действия — дейлики и другие похожие вещи.

Важная мысль, которую мы постараемся донести, связана с построением культуры внутри команды. Мы постараемся создать ситуацию, в которой люди, занимающие в традиционной системе коммуникации более пассивную роль (студенты, джуны), будут брать в свои руки основные решения. При этом мы не можем пойти к ним и сказать, что они теперь должны быть субъектами и принимать самостоятельно решения. Так работать не будет — они просто скажут: «Хорошо», — но больше ничего не изменится.

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

Конец Школы: коммуникация, обратная связь и выпускной

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

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

Последняя встреча — выпускной, она посвящена нескольким моментам. Во-первых, мы поговорим о тех темах, которые мы обсуждали до этого. Сопричастность — один из важных принципов, который позволяет поддерживать мотивацию на достаточно высоком уровне. Это ощущение: «Я не пассивный кусок неизвестной субстанции, который плывет по течению и не может на что-то влиять, я могу только плыть или утонуть». И как раз эта встреча показывает на практике, как это может работать.

Дело в том, что на протяжении всей Школы студенты выполняют домашние задания, где там часто фиксируются темы, которые им хотелось бы рассмотреть. И на последнем занятии мы обсуждаем то, что они предложили и что им действительно интересно — это и есть прием сопричастности, которая, делает пассивную роль (студентов) более активной. Это в дальнейшем могло бы повлиять и на культуру шаринга знаний. 

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

После выпуска

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

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

Оставить заявку на бесплатную Школу Тимлида от Хекслета можно здесь.

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


  1. XeL077
    00.00.0000 00:00
    +11

    Как стать - быть единственным разработчиком, которого можно назначить из команды.

    Что даст - много вызовов (проблем) и немного больше зарплаты.


    1. MiraclePtr
      00.00.0000 00:00
      +6

      Что даст - много вызовов (проблем) и немного больше зарплаты.

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

      Это я как синьор ставший лидом говорю.


      1. tommyangelo27
        00.00.0000 00:00
        +4

        Всё верно, я дальше вас пошёл и стал назад программистом.

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


  1. E_BEREZIN
    00.00.0000 00:00
    +17

    Как стать тимлидом, обучаясь на любых курсах? Отвечу кратким тезисом, который вы сформулировали в прошлом году:

    Никак


    1. klimkinMD
      00.00.0000 00:00

      Погодите, может "тимлид", это проще чем "мидл"


    1. S__vet Автор
      00.00.0000 00:00

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


  1. sheshanaag
    00.00.0000 00:00

    Тимлид не ведущий разработчик ни по смыслу, ни в переводе. Ведущий команды - да. Бедный тот ведущий разработчик, который ещё и тимлидом должен быть.


    1. stitrace
      00.00.0000 00:00
      +2

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


      1. Myz17
        00.00.0000 00:00

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


        1. JohnRambo
          00.00.0000 00:00

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


    1. XeL077
      00.00.0000 00:00

      Такова реальность


  1. iosuslov
    00.00.0000 00:00

    Работал на заводе "тимлидом" - постановка задач, планирование, решение проблем, межкомандное взаимодействие, обучение сотрудников, поощрения и наказания...знаете чего не было? - я не стоял у "станка". Я мог делать все, что делали мои "бойцы", но я этого не делал, моя задача была в построении и организации процессов.

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

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

    Второе условие - моя ЗП должна быть как минимум на 10% выше самой высокой ЗП в команде, потому что менеджер не имеет права получать меньше, чем его подчинённые. И потому что головняков у тимлида как минимум в два раза больше, чем у самого синьерного синьера.

    Вероятность выполнения таких условий в компаниях в РФ стремится к нулю - поэтому в тимлиды я скорее всего не пойду )))


    1. dimas062
      00.00.0000 00:00

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


    1. JohnRambo
      00.00.0000 00:00

      Вероятность выполнения таких условий в компаниях в РФ стремится к нулю

      Во-первых это не так. Даже я однажды работал в месте где техлид не писал совсем. А во вторых, допустим ты стал тимлидом, что тебе мешает доходчиво объяснить руководству почему делать надо так, а не иначе?! Думаю причина в том, что тот кто у вас там тимлид просто не может это сделать. А раз не имеет способности блестнуть лидерскими качествами и даром убеждения, ну пусть пишет код тогда. Так что становись тимлидом и меняй процессы.


  1. KuramoriReika
    00.00.0000 00:00

    В EvE Online годами управляя группами людей по 200-300, иногда по 600 человек я понял, что для меня это совсем не сложно, но запарно. Поэтому я быстро отказался от цели стать начальником отдела или тимлидером, ведь за небольшой бонус к зарплате я получаю необходимость работать с бумажками и сокращение личного времени. Плюс придётся быть пунктуальным и быть всегда на связи с начальством, ходить на корпоративы и устраивать совместный отдых. Это того не стоит, нервы дороже, а обратного пути не будет.