Тимлид или Руководитель группы разработки?

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

В 2018-м году я пришел в компанию Авито на совершенно понятную всем нам в экосистеме 1С должность – руководитель группы разработки. Но, когда я приступил к работе, ко мне со всех сторон стали обращаться как «тимлид 1С». До этого я никогда такого и ни на одной из своих предыдущих работ не слышал такого обращения.

Я задумался: «А действительно, может ли быть в 1С должность тимлид?». У нас в отделах 1С обычно есть руководители группы разработки, архитекторы и прочие должности, но тимлид – это что-то новое.

Давайте разбираться. Я разделил доклад на три части:

• Тимлид – о чем это вообще, что под этим подразумевается, как в разных компаниях различаются роли на этой должности?

• Команда. Это краеугольное понятие, когда мы говорим о тимлиде.

• Что такое тимлид в 1С? Поговорим о возможностях тимлида в экосистеме 1С, Я расскажу о своих ошибках и успехах на пути тимлида в команде разработки 1С.

Кто такой тимлид: три столпа тимлида

Часто в интернете я вижу определение:

Тимлид – это разработчик, который руководит другими разработчиками.

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

Определение выше – понятное, потому что тимлиды, в большинстве своем, действительно бывшие разработчики. Так сложилось, что 90% людей, которые приходят в эту профессию, раньше занимались разработкой.

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

Какими качествами должен обладать человек, если он хочет исполнять роль тимлида и быть эффективным в этой роли?

Для меня это, прежде всего, три столпа – три базовые группы навыков, которые нужны тимлиду.

1. Управление людьми. Сюда мы относим все, что подразумевает взаимодействие с членами команды. Как команды в целом: мотивация, дизайн команды, управление компетенциями. Так и работа с людьми непосредственно: встреча one-to-one, найм, онбординг, развитие конкретных людей и обратная связь.

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

3. Личные навыки. Когда тимлид переходит из простого разработчика на новый уровень, у него появляется часть обязанностей, которые он раньше не делал. Например, он должен принимать решения – это очень важная компетенция, которая безусловно является личным навыком. Раньше тебе просто давали задачу, ты ее делал, и все было классно. Теперь же ты должен принимать решения – делать эту задачу или не делать.
   В личные навыки также можно отнести: коммуникацию, управление эмоциями – своими и чужими (эмоциональный интеллект), управление конфликтами – это тоже немаловажно в команде.

Если посмотреть на слайд, все столпы равны. Но в реальной жизни, когда мы смотрим на какого-то конкретного тимлида, какие-то столпы будут чуть ниже, а какие-то – чуть выше. Так происходит, потому что в зависимости от компании роль тимлида трансформируется:

• где-то важнее управление людьми;

• где-то более важен технологический стек;

• личные навыки почти всегда важны – и не только тимлидам, но тимлидам они важны особенно.

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

Как выглядит дорожная карта тимлида

Я перечислил достаточно много навыков, которые входят в базовые столпы, но мой коллега из Авито Егор Толстой – руководитель iOS-разработки в Авито – пошел еще дальше.

Он как-то встретился с друзьями-тимлидами, и они придумали собрать все возможные навыки тимлида в одном месте – так, чтобы на это можно было визуально посмотреть. Это не значит, что один человек должен знать все, что там указано. Но, как минимум, это некий путь развития.

Ребята собрались вместе и придумали Teamlead Roadmap – это дорожная карта тимлидов. Карта интерактивная, кликабельная – можно нажать на любую компетенцию, например, на «Собеседование» в ветке «Управление людьми – Найм».

При этом будет представлена информация:

• для чего роль нужна;

• что будет, если роль не выполнять;

• и приведен список литературы на каждую из этих тем.

Ребята сделали эту дорожную карту OpenSource-проектом – если вы хотите поделиться опытом о ролях, которые вы выполняете, и они не отображены на карте, вы можете зайти на GitHub и законтрибьютить им новую роль. Сделайте корректное описание, и они ваши правки примут. Т.е. это – открытый проект, развивающийся в сообществе.

Дорожную карту развития можно использовать для:

• Составления собственного плана развития. Вы заходите на эту карту, смотрите какие навыки могут быть полезны в работе, и чего вам, возможно, не хватает. Иногда нужна визуализация, чтобы понять, что вы хотите дальше развивать. Развивать все роли одновременно – невозможно;

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

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

• Найма тимлидов. Карта помогает составить план собеседования и понять, по каким темам мы хотим погонять тимлида.

Что почитать о тимлидах

В заключение первой части, где мы говорили просто про определение тимлида, и какие роли у него возможны, я подготовил список литературы:

• «Человеческий фактор. Успешные проекты и команды». Том ДеМарко, Тимоти Листер;

• «Как пасти котов. Наставление для программистов, руководящих другими программистами». Дж. Ханк Рейнвотер;

• «Как хорошему разработчику не стать плохим менеджером». Константин Борисов;

• https://tlroadmap.io/

Книга «Человеческий фактор. Успешные проекты и команды» – моя рекомендация к прочтению. Она очень сильно повлияла на меня в самом начале пути. Эта книга 70-80-х годов, но в ней офигенно написано о построении команды.

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

Команда – ключевое отличие тимлида от руководителя

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

В команде кроется принципиальное отличие тимлида от руководителя.

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

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

Представить тимлида без команды сложно. Вряд ли его кто-то называет тимлидом.

Какие бывают иллюзии в создании эффективной команды

Расскажу кратко про нашу команду разработки 1С в Авито, и про то, какие иллюзии мне пришлось преодолеть, чтобы стать ее тимлидом.

Когда я пришел в Авито, я начитался книг, изучил Agile, освоил фреймворк Scrum, и решил, что сейчас сделаю офигенную команду.

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

• Не все, что написано в книгах – работает. Очевидный вывод, но я до него дошел не сразу. Когда мы берем книжку, там написано: «сделайте то-то и то-то, и ваша команда будет на 300% эффективнее». Это не всегда работает.
  Иногда достаточно больно, когда ты пытаешься внедрять что-то ценное, но команда это не принимает. У этого могут быть абсолютно разные причины: другой состав команды или другой тип людей в команде, или вообще бизнес не подходит под штуки, описанные в книгах. Поэтому далеко не все, что написано в книгах – работает. Но экспериментировать обязательно нужно – без этого вы команду не построите.

• Обязательно экспериментируйте. Но важно, чтобы эксперименты были управляемыми. Вы должны четко понимать, что вы хотите внедрить, и какой результат получить. Желательно еще добавить к этому метрики – когда вы хотите поэкспериментировать, вам нужно точно понимать, какого результата вы ожидаете.

• Не бойтесь сделать ошибку. Мы все люди – все ошибаемся, и члены вашей команды тоже. Поэтому не бойтесь делать ошибку и честно признать ее. Нужно честно сказать команде: «Ребят, я хотел это внедрить, но что-то не взлетает. Давайте накинем, как это можно сделать?».

• Всегда интересуйтесь мнением своей команды. Это очень важно. Когда вы как классический руководитель, приходите и говорите: «Сейчас у нас будет Scrum», Scrum'а у вас точно не будет. У людей всегда есть свое мнение. Даже у тех, кто годами мог молчать. Если вы спросите у него напрямую, мнение у него точно есть, и, возможно, вы удивитесь, насколько оно будет полезно.

Команда разработки 1С в ИТ-компании

Что касается команды разработки 1С в Авито:

• С одной стороны нам проще – в Авито с самого начала было много айтишных команд, которые занимаются не 1С, а разработкой в других, совершенно разных средах. Вокруг нас всегда была айтишная движуха, всегда был какой-то Scrum – нам было, на кого равняться.

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

• Сюда мы относим инструменты. Например, в Авито есть Git, циклы сборки, TeamCity, автотесты. Все это прилетает к нам из теха.

С одной стороны, строить команду в Авито очень интересно, потому что всегда есть где посмотреть, как это применяется. С другой стороны, это суперсложно, потому что далеко не все практики применяются в 1С – иногда просто негде почитать про практики в 1С, так как другие команды этим не занимаются.

Что же такое тимлид в 1С

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

Тимлид – человек, который должен сделать работающую команду, поэтому мне это название импонирует больше, чем «Руководитель разработки».

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

Какие активности я применяю в Авито

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

1. One-to-one. Это встреча «один на один» со своими разработчиками. Эти встречи должны быть регулярными – раз в неделю или раз в две недели, например. Вы назначаете время и человек рассказывает про свои боли, а вы даете обратную связь, как эти боли разрешить.
   Это очень важно, но в начале это не принимается никем. Сначала люди молчат и не понимают, что нужно делать. Они говорят: «Зачем я тебе как руководителю должен говорить, что мне не нравится?»
   В этом плане нужно быть настойчивым, давать нормальную обратную связь, давать понять людям, что это не желание узнать какие-то сокровенные вещи, а это – желание им помочь.
   Сотрудник должен понять, что встречи один на один – это канал для связи с руководителем по поводу вопросов, которые не всегда можно решить на общих встречах или в неформальной обстановке.

2. Stand-up meeting. У нас в отделе проводится два стендапа, у каждого из которых совершенно разная судьба.
   Первый stand-up meeting проводится на уровне всего подразделения BPA (business process automation), которое занимается самой разной разработкой, и, в том числе, содержит нашу группу разработки 1С.
   Этот stand-up meeting у нас называется «daily meeting», и его ввели по распоряжению руководства. Когда началась пандемия, все ушли на удаленку домой, и нам сказали: «Теперь в 10 утра мы с вами будем встречаться в Зуме». И это, конечно, боль, потому что люди этот митинг не принимают: на него абсолютно не ходят, несмотря на то, что их ругают. Там большая часть людей молчит – все прямо совсем плохо. Пока мы работаем над тем, чтобы этот stand-up meeting переформатировать.
   Другой stand-up meeting, который мы сделали у себя в группе разработки, – короткая утренняя встреча два-три раза в неделю, где нет никакой повестки. Мы просто встречаемся, чтобы начать день. Каждый может рассказать, что захочет – например, поделиться, какую задачу вчера делал, или как классно покатался на велосипеде. Я абсолютно не ограничиваю темы на митинге.
   Это просто встреча, чтобы продуктивно начать день. Сейчас, на удаленке, это суперважно, потому что, сидя за компом, у тебя будто больше нет команды. Поэтому классно, что мы можем встретиться и что-то обсудить, как раньше где-то на кухне в столовой в Авито, и начать работать. Мне нравится такой формат.

3. 1С tech days. Эта активность хорошо зашла и мне, и ребятам. Суть заключается в следующем – я выделяю каждому разработчику определенный день и прошу его подготовить доклад на 30 минут на произвольную тему. Темы не ограничены 1С и разработкой.
   У нас были темы докладов про эмоциональное выгорание, социальные факторы и прочее.
   Это лучше, чем когда ты насаживаешь какие-то знания сверху в свою группу разработки. В нашем случае ребята доносят тебе какие-то интересные вещи.
   Среди докладов была тема про брокеры сообщений, после чего мы их решили попробовать, и даже использовали RabbitMQ в некоторых моментах.
   Там были доклады про Docker – ты совершенно не ожидаешь, что человек, который писал последние два года на 1С, принесет тебе доклад про Docker-контейнеры. Это очень круто, и я с удовольствием смотрю эти доклады.

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

5. Planning poker. Это единственная активность, которая осталась от Scrum. Изначально это был кусок Scrum, мы оценивали задачи по стори-поинтам, чтобы потом их закидывать в спринты.
   Там все, что связано со Scrum, уже отвалилось, как нерабочая для нас практика. А Planning poker остался, потому что это оказался интересный формат, где мы можем увидеть задачи друг друга.
   В 1С есть проблема – задачи у разработчиков очень изолированы друг от друга. Один разработчик, грубо говоря, делает что-то в ЗУПе, другой делает в «Управлении холдингом», и их задачи очень редко пересекаются.
   Встреча в рамках Planning poker'а позволяет посмотреть, что делают другие разработчики. Например, один разработчик не знает, как делать задачу, и на встрече другие разработчики могут подсказать. «Вот же, мы три дня назад запилили фичу, которая позволяет сделать это быстро». Такие встречи проходят раз в неделю по 30-40 минут, но они очень помогают в работе.

Советы тимлидам: хорошие привычки

Несколько советов тимлидам, которые только начинают путь и недавно управляют командой. Сначала хорошие привычки:

• Делегирование. Все знают боль о делегировании задач. Всегда хочется сделать задачу самому, но делегировать обязательно нужно.

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

• Работа с людьми, а не сотрудниками. Это больше посыл: когда вы начинаете относиться к подчиненным, как к людям, это очень помогает двигаться вперед. Нужно понимать особенности разработчиков, понимать их мотивацию и понимать, что их драйвит в работе, а что заставляет прокрастинировать.
  Во-первых, когда я знаю особенности каждого разработчика, то могу подбирать задачи с учетом особенностей.
  Во-вторых, люди знают, что я не отношусь к ним, как к винтикам в механизме и каждый из них – это отдельный человек;

• Обучение и развитие. Когда вы становитесь тимлидом, то встаете на путь обучения и развития. По-другому – никак. Либо вы постоянно учитесь, развиваетесь, применяете новые знания, применяете новые практики, либо ничего не выйдет.

Советы тимлидам: плохие привычки

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

• Брать в работу решение сложных, критических или блокирующих задач. Большая ошибка тимлида – когда он как самый крутой программист говорит: «у нас срочная задача, бизнес кричит, сейчас я все сделаю». После этого его зовут на одну встречу, на вторую, третью. И в итоге вечером задача не сделана. Он ее может сделать, но не сделает, так как есть другие задачи. Поэтому тимлидам никогда не нужно брать подобные задачи и решать самому. Можно поучаствовать в решении, дать подсказки разработчику, но не делать самому;

• Перестать писать код совсем. Как я говорил раньше, одна из основных ролей тимлида – технический лид. Перестать писать код – это значит совсем уйти в менеджерскую стезю и в управление людьми. Столп управления растет, но технический столп падает;

• Делать все самому. Эта привычка перекликается с первым пунктом. Желание делать все самому возникает часто, особенно если команда маленькая. Вы начинаете хвататься за все, и пытаетесь сделать так, как никто не сделает. Особенно характерно для крутых разработчиков, которые пришли в тимлиды;

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

• Scrum. Это в качестве шутки, потому что Scrum у нас не взлетел. Сейчас мы Канбан распиливаем.

И все-таки – тимлид или руководитель группы разработки?

Для меня однозначно – тимлид.

Руководитель группы разработки – это что-то менеджерское, закостенелое. Мне это совсем не нравится.

Тимлид в 1С однозначно есть – эта роль применима, так как в 1С есть команда разработчиков.

Развивайте себя и свои команды!

*************

Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.