Привет, Хабровчане! Меня зовут Виктор Чижеков, я техлид команды разработки внутренних продуктов CDEK. В этой статье хочу поделиться своим опытом, как я стал техлидом, но продолжал быть разработчиком. Как переосмыслил свою роль и обязанности, как изменилось видение команды и как я начал на неё влиять.
Статья будет полезна всем, кто работает с командами — тимлидам, техлидам и тем, кто хочет ими стать. В ней описан личный опыт, не претендующий на публикацию в учебниках и пособиях.
Содержание
Немного о себе
Я работаю в компании уже более 8 лет и за это время успел попробовать себя в разных командах. В каждой из них всегда был менеджер, и управление командой находилось в его зоне ответственности. Я в основном занимался техническими задачами, но всегда задумывался о том, чтобы попробовать себя в роли тимлида.
Когда меня пригласили на текущую должность, предложили управление командой из 7 человек. Что это такое я до конца не понимал, ведь полноценного опыта управления командой у меня не было. О том, как управлять командой, я знал лишь из книг и разных конференций. Стоит отметить, что искал я именно такое развитие карьеры, поэтому предложение воспринял как шаг вперёд. Это стало для меня своего рода вызовом.
Итак, я в новой продуктовой команде в составе: владелец продукта, 3 бэкенд‑разработчика, 2 фронта, 1 тестировщик, UX‑дизайнер. И продуктов немножко — корпоративный мессенджер, карьерный портал, база знаний, внутренний новостной портал компании и новый корпоративный портал, который был только на начальном этапе. С руководителем‑продактом определили зоны ответственности следующим образом: мне выделили техническое оснащение продуктов (архитектура, стабильность, сопровождение, оптимизация работы сервисов) и развитие технических скиллов команды. Продакт отвечал за поставку и описание фич, за развитие софтов команды. Зоны определили, поехали.
Я стал техлидом — ожидание и реальность
Сначала я мыслил следующим образом: «Я техлид — значит все должны приходить ко мне, задавать вопросы и консультироваться». «А как это будем делать?», «Что с этим делаем?» и тому подобное. Всё оказалось по‑другому — разработчики в команде уже не джуны, а вполне зрелые специалисты. Я примерно знал их уровень, но полноценно с ними не работал. Для меня стало шоком, что решения они принимают в большинстве случаев самостоятельно.
Стал погружаться во все задачи и пытаться их дописать, понять и начать управлять ими… Так я допустил свою первую и банальную ошибку — погрузился в микроменеджмент. Не сразу распознал это в своих действиях, но когда понял, начал задавать вопросы: «А зачем я это делаю, для чего?». Ведь если ребята и так справляются с этими задачами, зачем мне их контролировать и тратить на это своё время. Я могу заняться более полезными вещами для команды и компании.
Это было нелегко осознать, ведь по сути, я дал ребятам полностью самим вести задачи и выполнять их без моего ведома. Меня периодически подключали только на ревью, и когда я смотрел эти задачи, то убеждался: моё участие там было не нужно. Так я начал доверять команде и делегировать разного рода задачи.
Как во мне самозванец процветал
Статья была бы скучной, если бы в ней не появился многим известный мем антигерой — самозванец.
Во многих компаниях и командах есть проблемы с планированием, в нашей команде на тот момент этот процесс тоже требовал доработки. Для решения этой проблемы предложил использовать планинг покер, где бы мы оценивали задачи в стори поинтах и начали работать с этим. Мы попробовали так поработать, но всё равно оценка задач для команды оставалась непонятной и не очень прозрачной штукой. В результате несколько спринтов прошли, мягко говоря, не так, как планировали...
После небольшого самоанализа факапов сроков, пришёл к следующему выводу. Так получалось из‑за того, что я принимал участие в оценке, хотя мне не стоило этого делать: задачу возьмёт кто‑то другой, а у него нет моего опыта. Я оценивал задачу в 7 стори поинтов, а команда — в 21 стори поинт. При обсуждениях оценки я убеждал коллег, что задачка небольшая и легко решается, и они соглашались со мной (авторитет всё‑таки). По факту ребятам нужно было время, чтобы вникнуть в задачу и понять, как её реализовать, а потом уже разрабатывать. Таким образом моё занижение оценок приводило к «заниженной оценке» задач. После неудачных спринтов корил себя, мол, вовремя не заметил, что мы не успеваем сделать задачи в срок, я неправильно руковожу командой. В это время появлялся «второй Я», который шептал на ухо: «Ты точно туда пришёл? Ты ведь их топишь, ты не справляешься, иди отсюда, это не твоё».
Большое спасибо моему руководителю, который на очередном 1:1 вернул меня в работу, сказав простую фразу: «Разве это не вызов — выстроить процесс и сделать так, чтобы команда была самостоятельной и взаимозаменяемой. Разве не для этого ты сюда приходил? Разве это не интересный кейс, которым можно будет гордиться?». И действительно, после этих слов я почувствовал, как всё изменилось. Самозванец исчез, а вместо раздражения и негодования я получил заряд энергии и сил для генерации идей, как мы с этим можем бороться и какие шаги можем сделать для успешного планирования задач.
К сожалению, самозванец исчез ненадолго…
Следующая неудача, которая вновь вернула его — кейс, когда мы долго не могли масштабировать внутренний сервис видеозвонков. Не могли выявить причины его падения и улучшить стабильность.
После 2 месяцев исследования и тестов не получили никакого внятного ответа. Единственное, что удалось выяснить: текущее ограничение по участникам онлайн встречи — 60 человек. Такой результат сильно расстраивал и демотивировал. Потратить 2 месяца работы команды, чтобы понять только наш потолок и не найти вариантов его повысить. Тут, конечно же, вернулся «друг‑самозванец» со своей любимой фразой: «Чувак, а то ли место ты занимаешь? Ты ведь не справляешься! Какую‑то простенькую задачку не можешь решить!». Я место себе найти не мог, было стыдно руководителю в глаза смотреть после таких результатов. Даже начал искать работу не спеша.
Вдруг руководитель снова вызвал меня на встречу 1:1. Естественно, я готовился к худшему, потому что самозванец во мне бушевал и царил. Но на встрече опять прозвучали очень важные слова: «Ты ведь не эксперт в видеозвонках, да и команда первый раз ими занимается, поэтому не греби всё на себя. Давай лучше подумаем, как поднять экспертизу и какие выводы можем сделать из сложившейся ситуации. Подумаем, что можем с этим сделать.»
В итоге мы нашли решение и наш сервис выдерживал звонки со 150 пользователями, чего для большинства онлайн встреч компании на тот момент было достаточно. А я намного реже стал встречаться со своим «другом».
Следующая история о том, как я осознал, что все люди разные и к каждому нужен свой подход.
Люди не роботы: понять и простить
На одном из ретро мы обсудили, что многих разработчиков отвлекает переключение контекста со своей задачи на чужую для проведения code review. Пришли к выводу, что если задачи не очень срочные, можно ревьюить их утром или вечером, чтобы днём не отвлекаться.
Поясню: у нас распределённая команда, работаем в разных часовых поясах. Чтобы не тормозить процесс, те кто находится в новосибирском часовом поясе (+4 часа к мск) могут провести ревью утром, а коллегам из московском часового пояса хорошо бы посмотреть задачу вечером. Чтобы утром для остальной команды ревью уже было проведено и был понятен статус — доработать задачу или передавать дальше по процессу. Обсудили на ретро решение и начали работать.
Через некоторое время наблюдаю, что это не работает и снова ребята днём отвлекаются на код‑ревью. На митинге уточнил у команды, что случилось — почему не выполняем договорённости? Выяснили, что кто‑то делал по привычке: получал ревью и тут же бросался его смотреть. Кто‑то просто забыл о договорённости.
Так я понял, что люди не роботы и могут забывать об изменениях в процессах, поэтому необходимо напоминать и фиксировать все договорённости в каком‑нибудь документе. У нас им стал раздел команды в конфлюенсе, где описываем регламенты работ. Также в корп. мессенджере все важные договоренности закрепляем в чате команды, чтобы можно было к ним быстро вернуться.
Периодически, примерно 1 раз в неделю, напоминаем о какой‑либо нашей договоренности и процессе.
Смена фокуса или как я стал приносить больше пользы
В какой‑то момент начал замечать, что мне становится неловко на митингах. Все ребята рассказывают, как они классно что‑то реализовали, а я, вроде, чем‑то занимался, но результата, который можно пощупать и которым можно было бы гордиться — нет. День прошёл в созвонах, обсуждениях и сказать на дейли особо нечего. Это выбивало из колеи. А ещё было стыдно, когда брал задачу, обещал сделать её за 2 дня, а отвлечения на разные встречи и обсуждения приводили к тому, что делал 4 дня. Всё это демотивировало, мешало работать продуктивно и получать удовольствие от работы.
Случайно на Хабре нашёл статью «Почему я чуть не запорол свою карьеру тимлида. 4 совета начинающим», внимательно прочитал её и переосмыслил своё поведение и статус в команде. Я теперь не разработчик — больше времени тратится на коммуникации и помощь коллегам. Поэтому перестал фокусироваться на своих задачах, а начал фокусироваться на задачах коллег и старался помочь им решить их. На митингах начал отслеживать зависшие задачи и уточнять — нужна ли помощь.
Опять же — все разные: кто‑то сам приходил с просьбой о помощи, а кто‑то стеснялся и на митинге говорил, что помощь не нужна. Тогда через несколько часов я снова запрашивал информацию по задаче, и если результата не было — предлагал помощь, и коллеги соглашались. Кейсы бывали разные: например, некоторые боролись с проблемами, которые мы уже решали на других проектах. Тут просьба о помощи сократила бы решение с 1 дня до 1 часа, но ребята не знали этого. Теперь мы не боимся просить помощи, в том числе и я. 🙂
Позже встретил ещё одну статью — «Самый плохой программист, которого я знаю». Она придала мне дополнительной мотивации для выстраивания процесса по передаче своих знаний и опыта команде.
Первый конфликт
В первый же месяц работы у меня произошёл конфликт — я не смог договориться с фронтенд‑разработчиком о приоритете задач. Разработчик говорил, что у него всё готово и нужно подключать бэкенд‑разработчиков делать API, чтобы он смог показать демо своей работы. Я настаивал на том, что у бэкенд‑разработчиков сейчас другие приоритеты, им нужно закончить свои задачи. В итоге мы не договорились и перешли на повышенные тона, разработчик был мною очень недоволен и вышел из встречи.
Позже разработчик покинул компанию, и выяснилось, что у него были сложности во взаимодействии внутри команды в целом. Это меня немного успокоило, но всё равно было не по себе.
Для меня это был первый яркий конфликт за 7 лет в компании, когда мы прямо поругались из‑за того, что не смогли услышать друг друга. Очень переживал тогда, думал: «Только пришёл в команду и сразу устроил конфликт на ровном месте, ведь можно было что‑то придумать и договориться».
Сейчас понимаю, что тот конфликт был неконструктивным, и мне не удалось его привести к конструктивному состоянию. Потому что в конструктивных конфликтах всегда вскрывается какой‑то факт, который раньше не замечали или не учитывали, а он может кардинально изменить отношение к ситуации.
Теперь, спустя некоторое время, осознаю, что нужно было в момент недопонимания сделать 3 вещи:
выяснить мотивацию сотрудника: для чего ему нужно, чтобы было именно так, как он хочет;
проговорить все варианты развития событий;
прийти к компромиссу, чтобы все были win‑win.
Сегодня я не боюсь конфликтов, главное чтобы они были конструктивными.
Как развиваем команду
Вместе с руководителем мы развиваем софт‑скиллы ребят, обсуждаем что западает и какими инструментами можем это прокачать. В результате таких обсуждений провели несколько экспериментов, о которых вкратце расскажу ниже.
Пять пороков команды
На одном из ретро мы проработали пороки нашей команды и выяснили, что нужно улучшить. Решили запустить марафон «Битва с пороками». Марафон длился 2 месяца. За это время мы узнали о потрясающих инструментах, которые оказались невероятно полезными!
В рамках марафона разбирали каждый порок и выполняли различные упражнения для борьбы с ним в нерабочее время и даже в выходные дни.
Если кому‑то интересна суть марафона — можем вынести в отдельную статью (пишите в комментариях).
Каждый день был наполнен новыми знаниями и интересными заданиями, и это действительно изменило отношение внутри команды. Многие восприняли марафон как квест и были вовлечены в процесс: вовремя выполняли задания сами и напоминали о них другим. К заданиям относились осознанно и старались выполнить качественно. Конечно, были и те, кто сказал, что это «лишь отнимает время».
Профит: команда становится сплочённее, увереннее в своих решениях и эффективнее.
Эксперимент с фича-лидами
Вместе с продактом пришли к выводу, что хорошо, если ребята будут брать какую‑то фичу и полностью прорабатывать её. В обязанности фича‑лида входили: декомпозиция, выпуск на прод, проработка сложных моментов, заведение задач на других участников и на другие команды, если это необходимо. Также контролирование сроков и своевременная просьба о помощи.
Обсудили с командой все эти процессы и запустили эксперимент. Поработали в таком режиме пару месяцев. Сначала всем понравилось, но позже начались разногласия типа: «Ну, это же фронтенд, как я могу фронтенд пинговать, чтобы они делали мою задачу — у них ведь свои есть». И задача зависала на неопределенный срок.
Снова вспоминаем, что все люди разные: кто‑то готов к новой роли, а кто‑то — нет. Решили оставить роль по желанию. Хочешь — бери фича‑лидерство, не хочешь — не бери.
Профит: ребята незаметно для себя становятся фича-лидами (мини-руководителями) и доводят задачи до прода. Прокачивает ответственность, организованность, ориентацию на результат и командность.
Эксперимент с «добрым утром»
В рамках одно из ретро подсветили, что есть проблема с фокусировкой на приоритетных задачах. В результате иногда переключаемся на задачи, которые легче или быстрее сделать. Придумали простое правило: по утрам писать в чат команды «Доброе утро» команде и напоминать про фокусные задачи. Конечно, если это будет делать один и тот же человек — будет скучно, поэтому решили всем по очереди предоставить такую возможность.
После первого круга обсудили, что кто‑то тратит на активность много времени, кто‑то делает с удовольствием, а кому‑то — в тягость. В итоге — оставили по желанию: кому интересно и готов — участвует в этой эстафете.
Профит: перестроилась работа с приоритетом задач и уменьшилась расфокусировка. Прокачивает фокусировку, осознанность и ответственность.
Эксперимент с ответственными за модуль
Чтобы немного разгрузить меня от вовлечения во все проекты, мы назначили ответственного за каждый модуль разработчика. Нужно было следить за стабильностью модуля и его метриками, оперативно реагировать на алерты, работать с техническим долгом и передачей информации в тех. поддержку. Изначально, когда запустили эксперимент, особого эффекта не заметил — метрики подсвечивал в основном я, на алерты реагировал тоже только я, документацию на поддержку готовил тестировщик, а не ответственный за модуль.
Через какое‑то время мы обсудили ещё раз: кто такие эти ответственные за модули и что они должны делать, актуализировали список модулей и зоны ответственности.
Спустя примерно полгода начал замечать, как ребята стали заводить техдолги на модули, начали реагировать на алерты. И прямо сердце радовалось, когда такое происходило — значит, работа была проделана не зря.
Профит: у ребят прокачивается ответственность и осознанность, ведь они отвечают за сервис, а значит нужно следить за ним качественней и смотреть в будущее.
По итогу этих экспериментов мы замечаем, как команда развивается. Видя результаты, уже можно гордиться проделанной работой, а это позволяет прогонять возникающего периодически «друга‑самозванца». Но точно ещё есть куда расти и что прокачивать, а это придаёт драйв в работе.
Вместо вывода
Когда работаешь над задачами как исполнитель и общаешься с командой, но не отвечаешь за сроки и выполнение планов, не всегда замечаешь, как проявляются софты коллег. Однако, когда ты начинаешь руководить командой и анализировать поведение её членов, больше внимания обращаешь на их «мягкие навыки» и профессиональный рост команды. Если есть опытный коллега, с которым можно обсудить эти моменты, ты словно снимаешь розовые очки и начинаешь видеть ситуацию более реалистично и под другим углом.
Вливаться в новую роль всегда непросто, и мой путь был таков. В качестве краткого резюме хочу дать такие советы:
1. Банально, но правда — все люди разные и нужно изучить свою команду и особенности каждого, найти подход.
2. Каждая команда — совокупность индивидуумов, и только через эксперименты можно найти свой путь. Нет серебряной пули, которая решит ваши проблемы здесь и сейчас.
3. Оценивать «мягкие навыки» очень сложно, если раньше об этом даже не задумывался. Для этого нужно начать смотреть на всё под другим углом.
4. Софты не прокачиваются после прочтения инструкции или книги. Это постоянная работа над собой. Иногда результат виден спустя месяцы или даже годы.
5. Не стоит делать из факапов трагедию: рассматривайте их как точки роста.
6. Появление «самозванца» и сомнений при переходе на новую роль — это нормально. Не дайте им взять верх и продолжайте развиваться.
Эта история не претендует на инструкцию к действию, она, скорее, рассказывает, как тяжело из технаря перестроиться в менеджера, что этот путь тернист и сложен. Иногда люди сдаются и возвращаются обратно в разработчиков, а иногда смотрят на эти сложности как на новый вызов и начинают с ним работать. Я выбрал второй вариант — меня это вдохновляет и придаёт сил! Надеюсь, было интересно!
Поделитесь в комментариях своими кейсами после перехода на роль техлида или тимлида. Если вас заинтересовал материал и вы можете порекомендовать книгу, статью или любую другую полезную информацию — также делитесь в комментариях, мне будет очень полезно.
