Иной раз чудится, что тимлид — это кто-то или что-то вроде Снарка из поэмы Льюиса Кэрролла: точно существует, разносторонне и противоречиво описан в своих бытовых и деловых проявлениях, но при всем при том что представляет собой — загадка. Разобраться с тем, насколько значима эта (тимлида, не Снарка) роль в инженерных командах, кого правильнее на нее ставить и какие подводные камни скрыты в «тимлидстве», обещает помочь 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, а до того много лет трудился преимущественно в организациях коммерческих. Чем, по твоему опыту, работа техдиром в госструктуре отличается от деятельности на той же позиции в бизнесе?
— С точки зрения производственных процессов существенной разницы считай что нет. Система постановки задач мало чем отличается от тех, которые приняты в коммерческих конторах. Разница в масштабе: обычно государственный проект — громадный механизм. В его работу вовлечено множество людей, которые имеют право принимать и принимают решения. Для сравнения: если в Banki.ru мы ваяли какой-нибудь внутренний проект впятером, то в Mos.ru к сопоставимому с ним может быть причастно человек двадцать. В госорганизации IT-подразделению чуть сложнее в плане выстраивания внешних коммуникаций: бывает, по полдня пытаешься поймать нужного человека — просто потому, что штат широченный. Но с теми, с кем необходимо взаимодействовать регулярно, в том числе по линии интеграции сервисов, мы на короткой ноге: со всеми перезнакомились.
В каждом уголке Департамента информационных технологий города Москвы (ДИТ) и других структур, с которыми нам приходится взаимодействовать, свои правила игры и свои проблемы, как и в любой огромной организации, да хоть бы в том же «Сбертехе». Наш 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, организация ретроспективы, воспитание новичков.
В переводе на воинские звания это кто-то вроде сержанта — командира отделения. Он наделен полномочиями и вправе принимать решения в рамках тех технологических решений и стандартов, которые мы сообща взяли на вооружение.
Плюс у меня тимлиды входят в архитектурную команду. Это не формализованная и не постоянно действующая структура: она возникает, когда назревает потребность придумать что-то новое по части технологий. Тогда на встречу со мной собираются все тимлиды, руководители отделов тестирования и эксплуатации и все прочие, кто кровно заинтересован в изменениях. Садятся кружком специалисты с разными компетенциями, с разными взглядами на технологический ландшафт, с разными должностями. Обсуждают спорные вопросы, фиксируют договоренности, придумывают архитектуру или решение — и расходятся.
До недавнего времени что в Banki.ru, что в Mos.ru у меня выбивались в тимлиды исключительно «бэки». Как правило, эту роль брал на себя senior back-end developer. Но на текущий момент у меня уже два тимлида из фронтенда.
Все меняется. Нам пришлось адаптироваться к нынешним технологическим реалиям, и в результате мы завели у себя то, что принято называть гильдиями.
Дело вот в чем: фронтендеру в 2018 году тяжело уследить за тем, что творится в мире бэкенда, и наоборот. Мы поняли, что людям надо кооперироваться на горизонтальном уровне, сбиваться в неформальные объединения без прямого подчинения, но со статусами — наподобие званий в тайных обществах, что-то вроде «магистра ордена back-end». Носители таких «титулов» — люди, которые де-факто принимают управленческие решения прикладного характера: будем ли мы перебираться на PHP 7.2, развивать ли Angular или лучше сделать ставку на React.
Гильдии регулярно собираются — отдельно фронтендеры, отдельно бэкендеры. Собираются и выясняют, кому что хорошо, кому что плохо, что нынче модно и круто. Спорят, действительно ли Webpack — унылая шляпа, которая собирает кучу всего ненужного, или просто с ним надо научиться обращаться. Только не переливают из пустого в порожнее, а приходят в итоге к практическому решению.
В конечном счете архитектурная команда заменяет мне системного архитектора. Да, системного архитектора у меня нет.
— Какое место тимлид занимает у тебя в команде? Он подчиняется напрямую CTO или есть управленцы промежуточного уровня?
— Промежуточного уровня у нас нет — так уж сложилось. По логике вещей между тимлидами и мной должен находиться руководитель разработки. Фактически же в отделах тестирования и эксплуатации начальники есть, а разработкой заведую лично я. Поэтому и тимлиды подотчетны мне напрямую.
Чуть похитрее схема подчинения у девопсов. Изначально я тоже собирался обособить их в отдельную группу со своим начальником, но мы с ребятами покумекали и решили, что это лишнее управленческое звено. Завели в DevOps вместо босса Kanban, чем и довольны в высшей степени.
— Когда ты впервые столкнулся в разработке с такой сущностью, как тимлид? Когда на личном опыте убедился в том, что эта функция полезна?
— В 2008 году я с коллегами писал хитрый софт на оборонном заводе. Однажды мы уткнулись носом в факт до обидного простой: бригада из десяти разработчиков не способна ничего производить, а способна только бракоделить и ругаться. Тогда впервые в моей жизни возникло словосочетание «начальник группы» — эдакий прототип тимлида.
Ватагу инженеров разделили надвое, назначив по ответственному на каждую из двух групп. Одним из них оказался я. Мы с начальником другой группы принялись выстраивать внутренние процессы разработки и отлаживать взаимодействие между половинками нашего мини-коллектива. Вдвоем мы коллектив «табунного типа» превратили в два эффективных боевых звена. Начали распределять между ними задачи и эти самые задачи приоритизировать, планировать на более долгие сроки, да и, в конце концов, синхронизировать работу команд во избежание простоев.
В Banki.ru структура технического отдела тоже была «ячеистая»: команды в ней управлялись тимлидами, и большую часть времени с ними — пятерыми — я и контактировал напрямую, за отсутствием начальника разработки. В точности как сейчас в Mos.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. Пришло «время середины»: мы дали старт общению, показали, что проблемы есть у всех и что проблемы эти имеют решения, предложили решениями делиться и сообща двигать отрасль вперед.
За месяц до мероприятия мы без лишних формальностей поговорили с техническим директором проекта 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, а до того много лет трудился преимущественно в организациях коммерческих. Чем, по твоему опыту, работа техдиром в госструктуре отличается от деятельности на той же позиции в бизнесе?
— С точки зрения производственных процессов существенной разницы считай что нет. Система постановки задач мало чем отличается от тех, которые приняты в коммерческих конторах. Разница в масштабе: обычно государственный проект — громадный механизм. В его работу вовлечено множество людей, которые имеют право принимать и принимают решения. Для сравнения: если в Banki.ru мы ваяли какой-нибудь внутренний проект впятером, то в Mos.ru к сопоставимому с ним может быть причастно человек двадцать. В госорганизации IT-подразделению чуть сложнее в плане выстраивания внешних коммуникаций: бывает, по полдня пытаешься поймать нужного человека — просто потому, что штат широченный. Но с теми, с кем необходимо взаимодействовать регулярно, в том числе по линии интеграции сервисов, мы на короткой ноге: со всеми перезнакомились.
В каждом уголке Департамента информационных технологий города Москвы (ДИТ) и других структур, с которыми нам приходится взаимодействовать, свои правила игры и свои проблемы, как и в любой огромной организации, да хоть бы в том же «Сбертехе». Наш 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, организация ретроспективы, воспитание новичков.
В переводе на воинские звания это кто-то вроде сержанта — командира отделения. Он наделен полномочиями и вправе принимать решения в рамках тех технологических решений и стандартов, которые мы сообща взяли на вооружение.
Плюс у меня тимлиды входят в архитектурную команду. Это не формализованная и не постоянно действующая структура: она возникает, когда назревает потребность придумать что-то новое по части технологий. Тогда на встречу со мной собираются все тимлиды, руководители отделов тестирования и эксплуатации и все прочие, кто кровно заинтересован в изменениях. Садятся кружком специалисты с разными компетенциями, с разными взглядами на технологический ландшафт, с разными должностями. Обсуждают спорные вопросы, фиксируют договоренности, придумывают архитектуру или решение — и расходятся.
До недавнего времени что в Banki.ru, что в Mos.ru у меня выбивались в тимлиды исключительно «бэки». Как правило, эту роль брал на себя senior back-end developer. Но на текущий момент у меня уже два тимлида из фронтенда.
Все меняется. Нам пришлось адаптироваться к нынешним технологическим реалиям, и в результате мы завели у себя то, что принято называть гильдиями.
Дело вот в чем: фронтендеру в 2018 году тяжело уследить за тем, что творится в мире бэкенда, и наоборот. Мы поняли, что людям надо кооперироваться на горизонтальном уровне, сбиваться в неформальные объединения без прямого подчинения, но со статусами — наподобие званий в тайных обществах, что-то вроде «магистра ордена back-end». Носители таких «титулов» — люди, которые де-факто принимают управленческие решения прикладного характера: будем ли мы перебираться на PHP 7.2, развивать ли Angular или лучше сделать ставку на React.
Гильдии регулярно собираются — отдельно фронтендеры, отдельно бэкендеры. Собираются и выясняют, кому что хорошо, кому что плохо, что нынче модно и круто. Спорят, действительно ли Webpack — унылая шляпа, которая собирает кучу всего ненужного, или просто с ним надо научиться обращаться. Только не переливают из пустого в порожнее, а приходят в итоге к практическому решению.
В конечном счете архитектурная команда заменяет мне системного архитектора. Да, системного архитектора у меня нет.
— Какое место тимлид занимает у тебя в команде? Он подчиняется напрямую CTO или есть управленцы промежуточного уровня?
— Промежуточного уровня у нас нет — так уж сложилось. По логике вещей между тимлидами и мной должен находиться руководитель разработки. Фактически же в отделах тестирования и эксплуатации начальники есть, а разработкой заведую лично я. Поэтому и тимлиды подотчетны мне напрямую.
Чуть похитрее схема подчинения у девопсов. Изначально я тоже собирался обособить их в отдельную группу со своим начальником, но мы с ребятами покумекали и решили, что это лишнее управленческое звено. Завели в DevOps вместо босса Kanban, чем и довольны в высшей степени.
— Когда ты впервые столкнулся в разработке с такой сущностью, как тимлид? Когда на личном опыте убедился в том, что эта функция полезна?
— В 2008 году я с коллегами писал хитрый софт на оборонном заводе. Однажды мы уткнулись носом в факт до обидного простой: бригада из десяти разработчиков не способна ничего производить, а способна только бракоделить и ругаться. Тогда впервые в моей жизни возникло словосочетание «начальник группы» — эдакий прототип тимлида.
Ватагу инженеров разделили надвое, назначив по ответственному на каждую из двух групп. Одним из них оказался я. Мы с начальником другой группы принялись выстраивать внутренние процессы разработки и отлаживать взаимодействие между половинками нашего мини-коллектива. Вдвоем мы коллектив «табунного типа» превратили в два эффективных боевых звена. Начали распределять между ними задачи и эти самые задачи приоритизировать, планировать на более долгие сроки, да и, в конце концов, синхронизировать работу команд во избежание простоев.
В Banki.ru структура технического отдела тоже была «ячеистая»: команды в ней управлялись тимлидами, и большую часть времени с ними — пятерыми — я и контактировал напрямую, за отсутствием начальника разработки. В точности как сейчас в Mos.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-канале. Там же появятся и видео новой конференции, но через несколько месяцев. Подписывайтесь, если не хотите пропустить.
Все наши новости вокруг управления и предпринимательства, мы собираем в тематическую рассылку. В нее входят: публикации статей и расшифровок, открытые видеозаписи, клёвые докладчики и другие полезности. Если интересно — подписывайтесь.
