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

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

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

Рустам Мухамедьянов, руководитель WINFOX

Как было устроено тимлидство раньше

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

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

Александр Хрущев, технический директор WINFOX

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

• — Набор функций тимлидов в разных командах отличался. Кто сколько задач на себя взвалил, тот настолько и тимлид. 
• — Самые-самые тимлиды, набирая себе тимлидских задач, надолго вываливались из написания кода. Срабатывало правило «Кто не кодит — тот и тимлид». 
• — Новые сотрудники не сразу понимали и принимали такой эволюционный подход к тимлидству. Они считали, что тимлидов у нас и вовсе нет.
• — Новые направления и команды оставались без лидов. Все потому, что процесс становления тимлида занимает время.

Почему мы решили поменять подход к тимлидству

Однажды CEO, CTO, руководитель проектного офиса и менеджеры проектов собирались на очередной митинг, посвященный проблемам исполнения производственного плана. В ходе подготовки мы заговорили про тимлидство. 

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

Как видит тимлидство CEO:

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

Как видит тимлидство CTO:

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

Как видит тимлидство руководитель проектного офиса:

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

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

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

Александр Хрущев, технический директор WINFOX

Вот к каким интересным результатам мы пришли в процессе этого штурма. 

Лиды считают, что тимлид — это золотая середина между распределением задач и менеджментом. Вот что делает тимлид по их мнению:

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

Мидлы уверены, что тимлид — это человек, который выслушивает всех участников проекта и принимает взвешенное решение. Вот что еще делает тимлид по мнению мидлов:

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

По версии джунов все обстоит примерно так:

• — «О, а у нас есть тимлид?!»;
• — тимлид консультирует других разработчиков и помогает им искать решения;
• — тимлид получает большую ЗП;
• — тимлид занимается шерингом экспертизы внутри команды;
• — тимлид просто кайфует)

Внимательный читатель подумает: «Так… Лиды, мидлы, джуны высказались, а где сеньоры-то?».

Дело в том, что с давних пор у нас работает немного доработанный принцип известного профессора бухгалтерского учета школы бизнеса Джеймса МакКинси «Up or Out» в формате «Up or Outstaff». Если разработчик, ставший сеньором, не растет в сторону тимлида или управленца, мы обычно переводим его на работу по модели аутстафа.

Александр Хрущев, технический директор WINFOX

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

А если серьезно, именно в этот момент в компании наметилась тотальная нехватка тимлидов. И это стало прекрасным поводом для перезапуска института тимлидства.

Как у других: опыт коллег из IT-сферы

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

Роль тимлида

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

Лучшие практики в разных IT-компаниях

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

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

В e-legion нет четкой вертикальной иерархии, когда есть тимлид, все с ним соглашаются и всегда на «вы». Тимлид — не большой начальник, которого надо бояться, а такой же разработчик, как и остальные: с ним можно общаться о работе, на отвлеченные темы. 

В отделе iOS-разработки e-legion все строится на том, что каждый — полноценная рабочая единицы со своими обязанностями и ответственностью. Благодаря этому создается комфортная среда для работы. При такой открытости тимлид может гораздо более оперативно заметить, что конкретного сотрудника что-то идет не так. Ребята открыты: если что-то не нравятся, они говорят. И тмилид может влиять на это, исправлять ситуации и помогать им возвращаться в комфортное состояние.

В ICL Services матричная структура, и есть два типа тимлидов: линейный и проектный. Линейный — как тренер. Готовит к забегу, следит за тем, чтобы все использовали единую и принятую методику бега, делится лучшими практики бега, снабжает формой, отслеживает календарь марафонов. Проектный — это как раз тот самый pacemaker, который помогает команде хорошо бежать. Двухъярусная система работает за счет того, что одни тимлиды не заняты в операционной деятельности и могут создавать организационные условия для развития сотрудников, а вторые, наоборот в проекте — работают на заказчика, но не нянчат новичков до требуемого уровня, а просто получают готовых «бегунов» от линейных. 

Чувство плеча и командообразование — основной в фокус в работе линейного тимлида в компании. Можно выделить четыре отличительных черты в ICL Services: тимбилдинги, нетоксичная организационная культура, этика правды и прозрачность. 

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

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

В DD Planet все построено на атмосфере открытости и доверия. Мы радуемся общим и персональным успехам и делимся неудачами, чтобы поддержать друг друга и не наступать на эти «грабли» в будущем. Мы регулярно проводим время вместе и вне работы, например отмечаем дни рождения, после напряженной недели ходим в бар или друг к другу в гости — играть в настольные игры. А пару раз я даже помогал коллегам в переезде – такой тимбилдинг неплохо сплачивает и позволяет понять, кто как работает в команде.

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

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

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

Так же, как и в других компаниях, в ICEROCK DEVELOPMENT тимлиды организуют команду, строят рабочие процессы и знают, какие технологии лучше использовать. Но есть важное отличие. Поскольку во многих проектах там используем Kotlin Multiplatform Mobile, тимлидам нужно меньше усилий на синхронизацию Android- и iOS-разработчиков. Для обеих платформ вначале продумывается одна бизнес-логика, и таким образом команды автоматически синхронизируются.

Как устроено тимлидство сейчас

Мы серьезно пересмотрели подход к тимлидству и сделали три главные вещи:

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

Рассказываем подробнее про каждый шаг.

Урезали минимально необходимый набор тимлидских функций

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

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

Убрав эти пункты и оставив только самые необходимые, мы получили следующий джентльменский набор необходимых качеств тимлида у нас в компании. Вот эти качества:

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

Начали официально закреплять статус тимлидов в командах

Мы поняли, что необходим некоторый официоз. 

Молодые сотрудники путают тимлидство с наставничеством, воспринимая тимлида исключительно как своего наставника. А сами тимлиды на вопрос «А кто у нас тимлид?» не всегда могут уверенно сказать «Я». Плюс прочие проблемы с донесением информации в распределенных командах.  

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

Заставили всю эту штуку работать

Это оказалось самым сложным. 

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

Подробнее про KPI читайте во второй статье. 

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

• — кому доверили тимлидство;
• — как мотивируем тимлидов;
• — что нам дал перезапуск тимлидства.