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

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

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

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

Появление отдела и мое погружение в менеджмент

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

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

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

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

К концу 2021 года количество проектов стремительно увеличилось и стало понятно, что потребуется найм новых девопс инженеров. Руководство приняло решение сформировать в компании DevOps отдел и назначить меня руководителем направления. Я расскажу как организовывал работу нового отдела, какие практики внедрил и какие материалы использовал для развития в менеджменте.

Обучение менеджменту

Я сразу понимал, что менеджмент это не просто дополнительная обязанность, а отдельная профессия, о которой я ничего не знаю и которой мне нужно учиться. Основным источником знаний для меня стали книги. С помощью них я сформировал базовые понимания по роли, а далее учился конкретным практикам: проведению встреч один на один (one-on-one), обратной связи, делегированию и т.д. Я не буду перечислять все прочитанные книги, а отмечу только те, которые были для меня самыми полезными:

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

• The Effective Manager,  Марк Хорстман. Книга от автора подкаста про менеджмент - Manager Tools. Тут фундаментально разбираются основные концепции менеджмента и даются конкретные инструкции по базовым практикам, от проведения One-on-One до коучинга.

• The Practice of System and Network Administration, 2nd Edition,Т. Лимончелли. В этой книге про практики и принципы системного администрирования есть глава про управление. В отличие от ранее указанных мною книг тут идет уклон на управление техническим отделом, содержатся полезные рекомендации по организации отдела, найму и управлению. Понятно, что это книга про классическое системное администрирование, но тем не менее большая часть информации будет актуальна для любого технического отдела.

• On Writing Well, Уильям Зинсер. Книга не про управление, но на тему важного для руководителя навыка - написание текста. Менеджеру необходимо часто писать тексты и делать это быстро и качественно: анонсы, регламенты и политики, различные документации, письма. Я изучал эту книгу, когда работал над первой статьей на Хабр и она оказала большое влияние на развитие навыка, который был на довольно слабом уровне. Отмечу, что это книга про написание нехудожественного текста, тут нет ничего про деловую переписку.

  

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

Формирование команды

Сейчас помимо меня в команде 4 человека. Двое работают на полной занятости и двое на частичной, совмещая с основной работой. Расскажу про сложившийся подход, который применяется сейчас в формировании команды. 

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

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

Во-первых найм джуна дает не только перспективу, но и реальную пользу с первых месяцев работы. Джун постепенно разгружает коллег с задач вроде разбора обращений и инцидентов, администрирования простых стендов, внутренней инфраструктуры, сопровождения релизов, документирования и прочего. Конечно, надо отталкиваться от сложности проектов и искать инженера с необходимым бэкграундом. Если говорить про технические навыки, то я нанимаю кандидатов с минимум годом опыта работы в сфере администрирования Linux-систем, умеющих автоматизировать свою работу (скрипты, Ansible) и знающих основы Docker.

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

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

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

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

Коммуникации с командой

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

С каждым сотрудником я провожу регулярные еженедельные встречи в формате One-on-One — еженедельные получасовые встречи между сотрудником и руководителем. Цель этих встреч состоит в выстраивании взаимоотношений с коллегами и улучшении рабочих процессов. По большей части я стараюсь придерживаться методик проведения O3, описанных в книге Хорстмана, которую я упоминал ранее: 10 минут сотруднику, 10 минут руководителю, 10 минут на обсуждение развития и роста.

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

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

Регулярные звонки отдела, где участвуют все сотрудники, проходят один раз в неделю и длятся один час. Цель звонков — наладить коммуникации между инженерами: позволить лучше познакомиться лично, обменяться опытом и обсудить новые идеи по работе. Изначально встречи проходили раз в две недели, но после сокращения времени One-on-One звонков они стали еженедельными.

Большая часть рабочих коммуникаций у нас происходит текстом, для этого мы используем Slack. Но иногда бывает гораздо проще и правильней остановить переписку и обсудить что-то голосом. Я стараюсь не брезговать быстрыми звонками, в Slack для этого есть удобная фича - Huddle. Еще при необходимости я стараюсь чаще делать демонстрацию экрана или просить коллег об этом. В условиях удаленки у нас нет возможности заглянуть друг другу в монитор и поделиться советами и мудростью. Ведь посмотрев как работает коллега можно самому приметить что-то полезное для себя, или же дать рекомендацию по тому как делать что-то оптимальнее и удобнее.

Обработка обращений и планирование задач

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

В первую очередь мне хотелось разобраться с обращениями от коллег и систематизировать их. Сложившееся у нас тотальное использование личных сообщений и тредов не позволяло эффективно планировать и организовывать работу над задачами и обращениями. В итоге мы перешли на более активное использование Jira для работы с запросами, а оперативные коммуникации перевели в специальный Slack канал #infrastructure или каналы проектов. Распределением задач занимаюсь я, либо проектные менеджеры сразу назначают их на ответственного за проект инженера. Использование kanban-доски помогает с визуализацией и планированием задач. 

Что касается ресурсного планирования, то здесь у компании появилась общая регулярная практика. По понедельникам у нас проходят совещания, где участвуют все проектные менеджеры и руководители отделов, и происходит планирование работ с распределением людей по проектам. Для планирования мы используем сервис Runn, а время затраченное на работу трекается сотрудниками через Hubstaff. Так осуществляется анализ реальных затрат времени на проекты и разницы с планированием. Сама практика ресурсного планирования помогает распределять людей и расставлять приоритеты для соблюдения сроков и бюджета проектов. Она позволяет заранее увидеть возможную нехватку кадров на проект, перегруз сотрудника и учитывать отпуска людей при планировании, которые также визуализируются в Runn.

Политики работы отдела

“Your team needs a wiki. On it you can document all your policies (what should be done) and procedures (how it is done)”  (с) OpsReportCard.

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

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

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

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

План развития сотрудника и система грейдов

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

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

У нас есть система грейдов, демонстрирующая какие конкретные навыки и опыт необходимы инженеру для роста в должности. План развития, разумеется, составляется с учетом системы грейдов. На текущий момент у нас следующие грейды инженеров DevOps: junior, pre-middle, middle, senior.

На middle грейде у нас появляется сертификация. Сейчас в список на выбор входят экзамены по AWS и Kubernetes (CKA). Конкретное направление обсуждается с сотрудником, и зависит от того к какому проекту мы готовим инженера или какую экспертизу хотим нарастить в команде. Сертификация — отличный способ развить и подтвердить навыки по необходимому направлению. Компания берет на себя оплату экзамена и материалов для подготовки. Для самой компании, помимо развития навыков сотрудников, наличие сертификатов может сыграть пользу на этапе пресейла новых проектов. 

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

Вывод

На момент написания статьи я уже полтора года работаю тимлидом, а количество людей в моей команде выросло с 1 до 4. В статье я описал свой опыт и пройденный путь. Каковы мои впечатления от работы в данной роли? 

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

Есть нюансы, к которым нужно быть готовым. Во-первых, у тимлида замедляется собственное техническое развитие, нужно балансировать между менеджментом и выполнением задач на проектах. Я стараюсь выделять себе 1-2 дня в неделю без встреч для возможности сфокусироваться на технических задачах. Во-вторых, переход на эту роль означает новую ответственность, сложности и вызовы. Если раньше я переживал только за свою работу, развитие и результат, то теперь отвечаю за всю команду. Нужно пропускать через себя проблемы, которые возникают у отдела в целом или у конкретного сотрудника и заниматься их решением.

Итак, я рассказал свою историю перехода на роль тимлида, поделился опытом обучения новой профессии, формирования команды и внедрения различных процессов в новом отделе. Я планирую и дальше развивать свои навыки. В качестве источника информации буду использовать подкаст Manager Tools от авторов книги The Effective Manager, которую я упоминал ранее. Я уже начал знакомство с Basic серии подкастов, которые позволяют закрепить и чуть углубить информацию из книги, а далее перейду к основному подкасту.