Хабрахабр

Тимлид — это сержант в IT-подразделении

Иной раз чудится, что тимлид — это кто-то или что-то вроде Снарка из поэмы Льюиса Кэрролла: точно существует, разносторонне и противоречиво описан в своих бытовых и деловых проявлениях, но при всем при том что представляет собой — загадка. Разобраться с тем, насколько значима эта (тимлида, не Снарка) роль в инженерных командах, кого правильнее на нее ставить и какие подводные камни скрыты в «тимлидстве», обещает помочь Saint TeamLead Conf 2018, которая пройдет 24–25 сентября в Санкт-Петербурге.

В беседе: кто такие тимлиды, как их правильно готовить, кого и к чему должны готовить они, каким должен быть круг их обязанностей и многое другое. За месяц до мероприятия мы без лишних формальностей поговорили с техническим директором проекта Mos.ru Романом Ивлиевым, который возглавляет Программный комитет Saint TeamLead Conf 2018.

Справка

Роман Ивлиев родился в 1982 году. В 2005-м окончил факультет кибернетики МИФИ. Больше 15 лет в IT. Специализация: высокие нагрузки, менеджмент в технологических командах, обучение.

Последние места работы:
• В 2009–2013 годах — сначала старший инженер, затем руководитель проектов в «Лаборатории Касперского» (отвечал за поддержку и разработку корпоративных сайтов — как b2c, так и b2b).
• В 2014–2016 годах — директор по информационным технологиям Banki.ru
• Занял должность CTO в проекте Mos.ru в конце 2016 года.

Чем, по твоему опыту, работа техдиром в госструктуре отличается от деятельности на той же позиции в бизнесе? — Уже почти два года как ты CTO в проекте Mos.ru, а до того много лет трудился преимущественно в организациях коммерческих.

Система постановки задач мало чем отличается от тех, которые приняты в коммерческих конторах. — С точки зрения производственных процессов существенной разницы считай что нет. В его работу вовлечено множество людей, которые имеют право принимать и принимают решения. Разница в масштабе: обычно государственный проект — громадный механизм. В госорганизации IT-подразделению чуть сложнее в плане выстраивания внешних коммуникаций: бывает, по полдня пытаешься поймать нужного человека — просто потому, что штат широченный. Для сравнения: если в Banki.ru мы ваяли какой-нибудь внутренний проект впятером, то в Mos.ru к сопоставимому с ним может быть причастно человек двадцать. Но с теми, с кем необходимо взаимодействовать регулярно, в том числе по линии интеграции сервисов, мы на короткой ноге: со всеми перезнакомились.

Наш Mos.ru мало чем отличается от рыночных b2c-сервисов — разве что деньги мы не зарабатываем. В каждом уголке Департамента информационных технологий города Москвы (ДИТ) и других структур, с которыми нам приходится взаимодействовать, свои правила игры и свои проблемы, как и в любой огромной организации, да хоть бы в том же «Сбертехе».

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

— Что находится за фасадом Mos.ru?

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

Из свежего — делали такой для парка «Зарядье». Еще в зоне нашей ответственности digital-спецпроекты.

Кое-что берем со стороны, хотя редко. У нас, условно говоря, команда полного цикла. От пользователя мы их прячем, чтобы для него любой переход в пределах портала был бесшовным. Другие сервисы, которые живут в домене www.mos.ru, но разработаны не нами, а другими подразделениями ДИТ, доступны на площадке благодаря внутренним интеграциям. Сидя на Mos.ru, ты запросто можешь находиться в другой системе, однако, если не полезешь в код страницы, ничего и не заметишь.

Их сервисы, в свою очередь, замыкаются на отраслевые IT-системы: здравоохранительную, социальные и так далее. Теми же городскими «Госуслугами» (на них можно попасть через наш сайт) занимается отдельная команда.

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

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

Как делятся зоны ответственности? — Как у вас выстроена иерархия технического руководства?

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

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

Аналогичным образом работает эксплуатация. DevOps у нас тоже as a Service: задачи ставятся, приоритизируются и потоком прогоняются через девопсов, которые также не закреплены намертво за какими-то командами.

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

Обе эти команды взаимодействуют с «основной разработкой» по линиям DevOps, тестирования и эксплуатации.

В каждой обычно пятеро, максимум шестеро сотрудников — в зависимости от направления. Второй тип команд — те, которые создают и поддерживают отдельные модули Mos.ru, включая GUI. Бэкендеры у меня в большинстве своем full stack разработчики, но я не заставляю их крутиться на двух танцполах сразу. В таких мини-группах прослеживается четкое разделение на фронтенд и бэкенд: в нашем случае оно показало себя эффективным. У каждой такой команды есть тимлид.

И чем такой тимлид занимается? — Вот и прозвучало это слово.

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

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

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

Как правило, эту роль брал на себя senior back-end developer. До недавнего времени что в Banki.ru, что в Mos.ru у меня выбивались в тимлиды исключительно «бэки». Но на текущий момент у меня уже два тимлида из фронтенда.

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

Мы поняли, что людям надо кооперироваться на горизонтальном уровне, сбиваться в неформальные объединения без прямого подчинения, но со статусами — наподобие званий в тайных обществах, что-то вроде «магистра ордена back-end». Дело вот в чем: фронтендеру в 2018 году тяжело уследить за тем, что творится в мире бэкенда, и наоборот. 2, развивать ли Angular или лучше сделать ставку на React. Носители таких «титулов» — люди, которые де-факто принимают управленческие решения прикладного характера: будем ли мы перебираться на PHP 7.

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

Да, системного архитектора у меня нет. В конечном счете архитектурная команда заменяет мне системного архитектора.

Он подчиняется напрямую CTO или есть управленцы промежуточного уровня? — Какое место тимлид занимает у тебя в команде?

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

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

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

Однажды мы уткнулись носом в факт до обидного простой: бригада из десяти разработчиков не способна ничего производить, а способна только бракоделить и ругаться. — В 2008 году я с коллегами писал хитрый софт на оборонном заводе. Тогда впервые в моей жизни возникло словосочетание «начальник группы» — эдакий прототип тимлида.

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

В точности как сейчас в Mos.ru. В Banki.ru структура технического отдела тоже была «ячеистая»: команды в ней управлялись тимлидами, и большую часть времени с ними — пятерыми — я и контактировал напрямую, за отсутствием начальника разработки.

Так я бы там рассудком повредился без тимлидов — руководителей групп, которые избавляли меня от мучений, связанных с выстраиванием технологической панорамы во всех деталях. До того в «Лаборатории Касперского», где я отвечал за работу корпоративных сайтов, под моим управлением действовало несколько команд — разнопрофильных, с разными технологическими стеками. А уж выстраивание правил игры — как выполнять code review, помогать ли младшим, журить ли старших и так далее — оставалось на их совести. Взаимодействовал я с ними на уровне идеологии и общей координации процессов.

В Штатах на них держится вся армия. И снова о том же: с кем еще тимлидов сравнивать, как не с сержантами? Вернее, могу, но с болью и через пень-колоду. Я без своих «сержантов» тоже не могу. Они первыми несут мои пожелания, предложения и поручения «в массы» и следят за тем, чтобы все это претворялось в жизнь. Они мои глаза, уши, руки.

— На твой взгляд, тимлид — это скорее профессия или ситуативная роль в организации, по аналогии со скрам-мастером?

Одно дело, когда у команды задачи в основном однотипные, а люди движутся в едином ритме. — У меня сейчас в коллективе есть и те и другие. Во втором случае у тимлида есть все шансы превратиться, пусть на время, в натурального администратора, который будет эти задачи «маршрутизировать». Другое — когда в команде параллельно решают n задач, где n может превышать число инженеров в команде. Как по мне, так это и роль и профессия.

Каждый придумывает конфигурацию, какая ему больше по душе. Вдобавок на рынке до сих пор спорят о том, кто за птица тимлид в принципе и каковы его базовые функции. Например, в Banki.ru я и подбор кадров делегировал своим тимлидам: те в достаточной степени «просветлились», чтобы задавать на собеседовании правильные вопросы, не только для определения квалификации кандидата, но и для того, чтобы прощупать его soft skills. Чаще даже исходят из того, какие задачи необходимо и уместно решать в конкретной команде. В Mos.ru мы постепенно пришли к той же системе. Мало-помалу ребята прокачивались и превращались из обычных технических руководителей начального ранга в юнитов следующих уровней. Я часто на этом этапе присутствую в качестве зрителя. Ребята сами изучают резюме, отсматривают кандидатов, проводят технические собеседования.

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

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

Когда в команду входят и руководитель продукта (product owner), и проджект-менеджер, и все-все-все, где зона ответственности тимлида? — Давай посетим твой идеальный мир. Тимлид тяготеет скорее к «проектности», чем «продуктовости»?

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

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

— Что тимлиду в итоге приходится контролировать?

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

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

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

Если команда что-то не успевает в срок, он, едва это обнаружив, шагает к своему начальнику, и без рассусоливания признается: «Не успеваем, потому что „недозаложились"», — и предлагает ему варианты решения. В-третьих, такой руководитель при возникновении сбоев любого толка, с которыми сам не силах справиться, сразу сигнализирует о них и выносит их на рассмотрение людей, способных решить вопрос.

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

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

— Какие еще обязанности могут — или должны — быть отданы на попечение тимлида?

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

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

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

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

А часто и вовсе разнится от человека к человеку. По большому счету, наполнение профессии тимлида — или роли, как ни назови, — функциональностью зависит от взглядов и целей руководства. Люди разные, команды разные. Я не настаиваю на том, чтобы обязанности тимлидов в Mos.ru были унифицированы. Вместе с тем существует команда, куда мы «подселяем» молодых ребят, и в ней воспитательная работа, наоборот, ведется очень активно: нужно встроить человека в нашу парадигму и процессы, что требует обстоятельности. Кому-то нет надобности развивать на своем участке бурную воспитательную деятельность, поэтому он сосредотачивается на делах инженерных и на синхронизации процессов. Там у руля стоят ребята чуть более опытные, и мы их наработки в дальнейшем тиражируем внутри подразделения: удачные техники и приемы нам нужны позарез, ведь мы собираемся еще больше работать с молодежью, в том числе через повышение квалификации новичков.

— Насколько глубоко тимлиду надо быть погруженным в актуальный технологический стек по сравнению со своими «подшефными», которые работают руками больше него?

Нужно, чтобы он отличал шелуху от передового решения. — Глубоко, по-настоящему глубоко. Ведь хорошего инженера хлебом не корми — дай попробовать новейшие технологии, и по барабану, что те только-только появились. Ему предстоит это делать часто. Ему надо будет решить, требует ли это вынесения на суд общественности (скажем, моей архитектурной команды). Тимлид, который общается с разработчиками в своей команде и проводит в ней code review, может увидеть какой-нибудь ранее не встречавшийся ему компонент, которого в системе не было. Вроде и не страшные вопросы, но в проектах с длинным циклом поддержки, лет пять-шесть, они становятся отнюдь не праздными и начинаю влиять и на бизнес. Допустим, будем ли мы внедрять Vue.js, хотим ли переходить на PostgreSQL 10 или «девятки» нам хватает за глаза.

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

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

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

Мы ведь вскользь коснулись того, что back-end и front-end разошлись далеко друг от друга и быть мегапрофи в обеих сферах очень трудно. — Как быть, если ты тимлид в кроссфункциональной команде?

Или, если ты заправский бэкендер и не рвешься нырнуть с головой во фронтенд, хорошо бы, чтобы за соседним столом сидел дружественный тебе «фронт», который будет поддерживать тебя с точки зрения экспертных знаний по части технологий. — Желательно все же быть подкованным с обеих сторон. Ну а ты продолжишь совершенствоваться как «бэк» и в то же время объединять коллег и вести их к победам, мотивируя их, повышая их профессиональный уровень, иногда даже развлекая.

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

Вдобавок смотря о какой компании мы говорим. — Больше зависит от человека, чем от его позиции или специализации. Архитекторы ведь тоже разные бывают. Где-то самые толковые тимлиды лучше всего вырастают из старших разработчиков, в каких-то — из архитекторов. Что уж там, IT — область зачастую нестандартизированная, даже на уровне протоколов. Одни программируют, другие только рисуют, третьи и программируют и рисуют, четвертые строят супернавороченные модели. Нет такого: раз ты архитектор, путь в лиды тебе заказан. О людях и говорить нечего.

Кто становится лучшим техдиром — тот, кто был тимлидом или архитектором? С карьерной траекторией до пункта CTO все то же самое. Сплошные вопросы. Считать ли, что «архитектор — тимлид — технический директор» — это развилка, на которую человек обязательно попадает, став старшим инженером, и вынужден выбирать?

— Как понять, имеет ли старший разработчик или системный архитектор, да кто угодно потенциал, чтобы стать классным тимлидом?

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

Слушают его на общих встречах или нет. Сам я ориентируюсь на поведение человека, на то, как к нему относятся в подразделении. Садится с краешку и тупит в планшет или живо слушает, размахивает руками, реагирует на реплики других. Выступает ли он на таких ивентах, занимает ли активную позицию: «Не хочу кодить на вашем дрянном PHP, дайте мне писать на Go, потому что он здесь будет хорош тем-то и тем-то».

Если я вижу, что человек «включенный», мне становится спокойнее: я понимаю, что он с меньшей вероятностью опустить руки при первых же трудностях, а остальные к нему в случае чего прислушаются.

Сначала нагружаю человека новыми обязанностями на две-три недели и смотрю, как у него идут дела. Дальше я устраиваю нечто вроде испытательного срока. Безусловно, я новоиспеченному тимлиду помогаю, отвечаю на его вопросы. Что-то вроде обучения по «бразильской системе».

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

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

Пробовать ли назначать такого сотрудника руководителем группы вопреки его возражениям и сомнениям в надежде на то, что за испытательный срок он войдет во вкус? А бывает, что прекрасный инженер с развитыми soft skills, которого, ко всему прочему, уважают в коллективе, наотрез отказывается становиться тимлидом. Ну а у меня однажды через три месяца после такого назначения уволился отличный разработчик: настолько ему не мила была его новая роль. Может, и войдет.

Если развить твою аналогию, человек надевает сержантские лычки, но офицерских училищ не кончал. — «Тимлидство» на карьерном пути напоминает ступеньку перед входом в категорию «менеджеров-менеджеров». Нет ли у него опасности скатиться в микроменеджмент и гиперконтроль? Каким рискам подвержен тимлид, который начинает свой путь в новой ипостаси?

И задача старшего товарища — технического директора или руководителя разработки — вытащить начинающего тимлида из болота избыточной детализации и чрезмерного старания. — Скатываются, только в путь. Особенно часто такое происходит, когда коллектив находит лида внутри. Случалось, команда не выдерживала и умоляла: «Уберите от нас этого деятеля». Не у всех получается безболезненно переключиться. Человек сидел себе и программировал, а теперь у него новый фронт работ — все новое. На нашу сентябрьскую Saint TeamLead Conf было подано несколько заявок на эти темы: как поймать человека на фазе микроменеджмента, как адаптировать его к «тимлидству», что делать с его «лычками».

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

Часто, впрочем, решить и не удается: мне известна масса случаев возврата с позиции руководителя группы в разработку под девизом: «Ну вас к лешему, лучше буду писать код и кайфовать, а управлять — это вы как-нибудь без меня».

Где у них обычно пробелы? — Каких компетенций чаще всего недостает тимлидам на российском рынке?

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

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

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

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

Каковы критерии качества его работы? — Как понять, справляется ли тимлид со своими задачами?

— Коротко: если все счастливы, то все хорошо.

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

— Судя по итогам предыдущей конференции, сложилось ли в российском IT общее понимание того, кто такой тимлид в принципе?

Вопрос так и остался висеть в воздухе. — Нет! Может, оно и правильно, что нет единого стандартного определения: значит, это «тимлидство» допускает гибкий подход. Оказалось, что широта и вариативность понятия «тимлид» соизмерима с размерами IT-отрасли.

Мы не в последнюю очередь для того и задумали TeamLead Conf, чтобы те, кто вошел в это «состояние», встретились с теми, кто только собирается, и чтобы вторые увидели, что это широченный мир и что эта деятельность разительно — и не в худшую сторону, вопреки распространенным опасениям, — отличается от чистой разработки.

В той, которую выстроил в Mos.ru на сегодняшний день я, продакт активно общается с тимлидом. Схем работы, в которые может быть вовлечен тимлид, множество. А в Banki.ru у меня, напротив, продакт брал на себя задачи аналитика, и чаще всего в разработку сгружали нечто, не требующее подробных разъяснений; разве только на процедурах вроде груминга бэклога иногда требовалось потрясти продакта и выведать у него кое-какие детали. Даже так: продакт несет свою продуктовую мысль тимлиду.

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

И наглядно показать, что если ты тимлид в компании А, это не значит, что, перейдя в компанию Б, ты получишь абсолютно такой же набор задач с таким же набором требований к тебе. Одна из целей, которые мы преследуем при подготовке Saint TeamLead Conf, — продемонстрировать коллегам эту бесконечность возможностей.

Как запросы аудитории будут отражены в программе следующей конференции? — Были ли в программе предыдущей, первой TeamLead Conf темы, которые оргкомитету хотелось, но не удалось копнуть глубоко?

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

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

Войдут ли они в повестку мероприятия? — Есть ли крутые практики у зарубежных IT компаний, которые разумно было бы «подглядеть» российским тимлидам?

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

Создать «отраслевой хаб», задать профессиональные стандарты, что-то другое? — Каковы долгосрочные цели конференции?

Более того, и звучат-то до предела пафосно: организовать, поддерживать и развивать площадку для того, чтобы на ней общались и обменивались опытом представители касты тимлидов, как из IT-отрасли, так и с околоайтишных рынков. — Не сказать чтобы они оригинальные. Как показывает практика других наших мероприятий, со временем будет и «отраслевой хаб», и все остальное.

Пришло «время середины»: мы дали старт общению, показали, что проблемы есть у всех и что проблемы эти имеют решения, предложили решениями делиться и сообща двигать отрасль вперед. Мы научились шевелить индустрию «снизу» — через HighLoad++, через серию прикладных конференций РИТ++, приноровились бодрить индустрию «сверху» — через Whale Rider и Aletheia Business.

Угадаете, о какой зарубежной компании шла речь? Доклады, которые Роман с коллегами отобрали для представления на Saint TeamLead Conf уже отмечены в Программе конференции.

Там же появятся и видео новой конференции, но через несколько месяцев. Материалы весенней TeamLead Conf в полном объеме выложены на нашем YouTube-канале. Подписывайтесь, если не хотите пропустить.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть