7 заблуждений начинающего тимлида
Привет! Я Игорь Степанов, Senior Team Lead в Plarium. Сейчас я руковожу командой тим- и техлидов и отвечаю за техническое состояние клиентской части проекта Raid: Shadow Legends. Когда три года назад я стал тимлидом команды разработки, у меня было размытое представление о том, какие сложности могут поджидать на новой позиции.
В этой статье я поделюсь личным опытом перехода из разработчика в тимлида и приведу примеры семи заблуждений, с которыми пришлось столкнуться в начале этого пути.
Материал будет полезен как опытным разработчикам, которые размышляют над стратегией карьерного роста, так и начинающим тимлидам, которым хотелось бы обойти известные «грабли».
Заблуждение № 1: тимлид обязан быть технически сильнее всех участников команды
Тимлид должен понимать принципы работы каждой области на проекте и иметь возможность оценить качество выполнения задач. Коллеги из команды могут быть технически сильнее тимлида в различных областях.
Как только я вступил в должность, меня настиг страх по поводу опыта. Среди моих подчиненных и других коллег было много специалистов (а точнее — большинство) с бóльшим опытом, чем у меня. В департаменте был тимлид, тринадцать разработчиков и два архитектора. Я не представлял, с чего начинать строить авторитет и взаимодействие с командой.
Но несмотря на то, что тогда я еще не очень хорошо ориентировался в проекте, моего уровня было достаточно, чтобы построить направление для развития команды. Много технических проблем лежали на поверхности и требовали только грамотной организации.
За счет внимания к деталям и организованности вы можете построить процессы, учитывая интересы каждого разработчика и проекта в целом. Если вашего уровня недостаточно, чтобы принять какое-то сложное техническое решение, всегда можно обратиться к техлиду, архитектору или специалисту в конкретной области.
Тем не менее не стоит останавливаться на достигнутом. Помните, что обучение — постоянный процесс, а с развитием вашего технического уровня уважение команды к вашим решениям будет только расти. И если на старте некоторые пробелы в знаниях вам могут простить, то в долгосрочной перспективе остановка в развитии технических навыков ни к чему хорошему не приведет.
Показатель работы тимлида — не только успехи отдельных сотрудников, а функционирование команды как единого целого. Осознание сильных и слабых сторон каждого специалиста позволяет не вдаваться в некоторые области детально, а доверять и ориентироваться, кто из коллег может быстрее и качественнее решить вопрос.
Заблуждение № 2: соперничество идет команде на пользу
Задача тимлида — не создавать соперничество в команде и не подавать коллегам такой пример поведения как приемлемый. Конкуренция в рабочей среде — обычное дело, но, когда она превращается в открытое соперничество, ничего хорошего из этого не выйдет. Участники такого противостояния будут находиться в стрессе, у них снизится мотивация и производительность. В дальнейшем такая ситуация может привести к разобщенности в отделе и конфликтам между сотрудниками и даже командами, если конкурируют тимлиды.
Когда в команде есть сильная конкуренция, со временем специалисты перестают делиться полезной информацией друг с другом. Узнав что-то интересное, сотрудник, вместо того чтобы скорее рассказать об этом, будет искать способ вначале применить знание лично, заработав очки на фоне других.
Чтобы не провоцировать соперничество внутри команды, тимлиду важно помнить, что каждый сотрудник уникален и делает вклад в проект в соответствии со своими знаниями и возможностями. Старайтесь одинаково хвалить специалистов за схожие достижения. Сравнивайте результат работы сотрудника только с его же прошлым результатом, а не с результатами коллег.
Более критичным может быть соперничество на уровне команд. Например, у одного из тимлидов возникла идея изменить формат код-ревью. Вместо того чтобы обсудить ее с коллегой-тимлидом и вместе придумать лучший вариант реализации, он, скорее всего, поделится ею со своей командой и после презентует руководителю отдела. Тем временем оставшаяся часть команды под руководством другого тимлида не будет чувствовать причастность к принятому решению или еще хуже — саботирует внедрение чужой идеи. Участники команд будут видеть соперничество тимлидов и также вовлекутся в это противостояние.
Когда в нашем отделе одновременно назначили нескольких тимлидов, начало зарождаться соперничество между командами. Выходом из такой ситуации стало четкое разделение зон ответственности тимлидов и их команд. Специалисты начали наращивать свою уникальную экспертизу, отвечать за ее развитие в рамках всего проекта и дополнять друг друга в отделе.
Если в команде руководитель относится ко всем одинаково справедливо, сотрудникам проще перестать сравнивать себя с другими. Формируйте единую цель и, давая возможность каждому сконцентрироваться на собственном вкладе, стройте общее дело. При таком подходе сотрудники будут охотнее делиться новыми знаниями с другими. Экспертность команды будет расти вместе с развитием отдельного участника, а не замыкаться на одном человеке.
Заблуждение № 3: тимлид может тратить столько же времени на программирование, как и прежде
В роли тимлида у вас больше не будет возможности выделять на программирование столько же времени, сколько на позиции девелопера. Новые обязанности могут «не пустить» вас программировать день, два, а иногда и целую неделю.
На первых порах мне это казалось неприемлемым. С целью не терять технические навыки и на своем примере показать, какой работы ожидаю от окружающих, я начал (или, скорее, продолжил) много программировать. Помимо этого, постоянно внедрял новые правила, стандарты, идеи, добавлял процессы и оптимизировал существующие.
Это привело к тому, что весь день я занимался координированием работы команды, а вечером садился программировать. Когда уже совсем не было сил, смотрел пул- реквесты в надежде предложить оптимальные решения для всех областей. Попытка угнаться за двумя зайцами окончилась неудачей. Я понял, что такой объем работы просто невозможно выполнять на постоянной основе.
Набор обязанностей тимлида диктует ситуация на конкретном проекте. Любой вертикальный рост предполагает получение дополнительных административных обязанностей: в меньшей степени — у техлида, в большей — у тимлида. Если вы не хотите этого на данном этапе своей карьеры, вероятно, вам лучше подойдут стратегии горизонтального роста.
Но не всё так страшно, как кажется. Руководящая позиция позволяет реализовать больше идей, чем можно осуществить в одиночку. По сути, вы получаете возможность производить больше кода, который соответствует вашим стандартам качества.
Заблуждение № 4: переработки эффективны
Переработки могут решить проблемы в краткосрочной перспективе. При этом они не являются эффективным инструментом, если вы хотите долго и с удовольствием работать без вреда для здоровья. Овертаймы говорят о том, что вы промахнулись с планированием и стоит сделать шаг назад, оценить ситуацию и разобраться с причинами. А если обстоятельства позволяют — перепланировать работу заново.
Сначала я этого не понимал и пытался программировать в том же объеме, что и раньше, искренне веря, что неуязвим и моих сил хватит на много лет вперед. Я даже старался моментально реагировать на каждое сообщение в чатах. Но уже через пару недель такого режима почувствовал, что необходимо продумать систему, приоритизировать чаты и составить график. Например, проверять новые сообщения раз в полчаса. Поверьте, вы точно не успеете всё сразу, расставляйте приоритеты!
Обязательно следите за рабочим временем и состоянием команды, регулярно обсуждайте нагрузку и планы. Стремясь казаться лучше, многие могут взять на себя больше, чем стоило бы. Ответственность и желание держать слово мешают сотруднику вовремя признаться, что ему тяжело и объем задач или сроки нужно пересмотреть.
Помимо прочего, когда вы работаете на износ, сознательно или подсознательно, вы начинаете требовать такой же отдачи от других. Любая ошибка начинает восприниматься сквозь призму недобросовестности: «Почему я должен править эти мелочи до двенадцати ночи, если Олегу было лень задержаться на 5 минут и внести правки в свою же работу?».
Продуктивность и грамотно принятые решения напрямую зависят от вашего состояния, которое без здорового отдыха будет стремительно ухудшаться. Делайте перерывы, занимайтесь спортом или творчеством — и вы не будете терять интерес к работе. Иногда стоит поднажать, чтобы получить результаты вовремя, но нельзя жить в постоянном стрессе.
Заблуждение № 5: никто не сделает так же качественно, как я сам
Отношения тимлида с командой во многом строятся на взаимоуважении. Важно учиться доверять людям, обучать и при этом позволять им допускать ошибки.
На первых порах я полагал, что некоторые задачи лучше выполнить самому, нежели тратить свое и чужое время на разъяснения и последующие проверки. Мне было сложно грамотно распределять нагрузку между собой и командой. Это было связано с тем, что я продолжал мыслить как разработчик.
Делегирование — один из критически важных процессов, который вам предстоит освоить на любой руководящей позиции. Не стоит путать с обычным распределением задач. Делегирование — это передача сотруднику своей задачи с соответствующими полномочиями или их частью. Ответственный подход к этому процессу поможет разгрузить ваше время и полноценно сконцентрироваться на приоритетных задачах, а также предоставит подчиненным возможности для развития. Такая передача ответственности за результат способна вывести сотрудника из зоны комфорта и в то же время положительно повлиять на его рост.
Можно долго рассказывать, как и что должно работать, но лучше запоминаются собственные «шишки». Если вы позволите сотруднику сделать ошибку, а потом вместе с ним ее исправите, шансы, что он больше ее не допустит, будут в разы выше, чем когда вы будете говорить, что и как делать. Главное — не бросать человека в центр океана, ожидая, что он сам научится плавать. Учитывайте возможности и желания сотрудника, контролируя выполнение задачи в соответствии с его уровнем. Начните с бассейна :)
Идеальный вариант — разбавление задач умеренной сложности, выполняя которые человек чувствует себя комфортно, с задачами-вызовами, позволяющими сотруднику обучиться чему-то новому. Разумеется, такая возможность есть не всегда, но именно подобный темп помогает планомерно расти и развиваться.
Мысли о том, что никто не сделает так же качественно, как вы, могут быть верными. Но, если вы дадите другим возможность и пространство для работы над собой, в итоге кто-то сделает эту работу даже лучше, чем вы.
Заблуждение № 6: «костыли» — это всегда плохо
Стоит помнить о тройственной ограниченности любого решения: цена, время, качество. И мы выбираем, каким из этих пунктов целесообразнее пренебречь. Важно не угодить богам программирования, а выполнить задачу. И выполнить в соответствии с потребностями бизнеса и учетом доступных ресурсов.
Поначалу мне казалось, что «костыли» — это недопустимо. И это заблуждение присуще не только мне. Мозг разработчика любит систематизировать, упорядочивать, приводить к общему виду. Поэтому, как только какое-то решение не вкладывается в изначальный план, его пренебрежительно именуют «костылем».
Например, есть техническая проблема, которую надо решить в кратчайшие сроки. Если делать это в полном объеме, то не хватит времени для выпуска нового контента. Отличным вариантом будет дописать какой-то «костыль» — быстрое временное решение, снижающее критичность вопроса — и успеть выпустить обновление. А к полноценному решению проблемы вернуться в следующем апдейте.
Прежде чем вкладывать все свои творческие и технические силы на создание изящного решения проблемы, оцените ситуацию: насколько срочно нужно решение, как долго придется с ним жить и как часто взаимодействовать. Не стоит несколько дней «вылизывать» решение, которое побудет на продакшене пару часов как временный результат.
Главное, когда решаете написать откровенный «костыль», делайте это с полной ответственностью и осознанием, как это повлияет на проект в краткосрочной и долгосрочной перспективе. Технические долги имеют свойство накапливаться и достигать критической массы в самый неподходящий момент, да еще и все сразу. Поэтому их важно отдавать планомерно. Позволили себе или команде сделать что-то некачественно — сразу же заведите задачу на рефакторинг и запланируйте эти исправления в ближайшую итерацию разработки.
Если сроки не горят, но с последствиями решения придется регулярно сталкиваться и это критично для бизнеса, обязательно донесите важность вопроса до руководства. Необходимо выделить дополнительное время на качественный анализ проблемы и с полной ответственностью подойти к проработке задачи. Как донести эту важность? Оперируйте основными KPI и текущим или потенциальным влиянием технической проблемы на них. Цифры — лучшие помощники в оценке и аргументации важности любой задачи.
Не стоит писать код ради кода. Помните, что успешный проект — это нечто большее, чем набор правильно решенных технических задач.
Заблуждение № 7: хороший тимлид должен сам со всем справляться
Проблемы и сложности испытывают все. Нет людей, которым всё дается без усилий. И не бывает такого, чтобы всё получалось идеально с первого раза.
Множество проблем в начале моего пути усугублялись нежеланием показывать слабости. Были ситуации, когда я брал на себя задачи, которые очевидно не мог бы выполнить в рамках рабочих часов. Я программировал, занимался командой и ее развитием, пересматривал процессы, старался улучшить всё, до чего только мог дотянуться.
Я был менее опытен, чем другие, и считал, что нужно всем своим видом и каждым действием доказывать, что я достоин этой позиции. Однако ничем хорошим такой подход не заканчивается. По этой причине я не мог обсуждать проблемы и внутренние переживания с коллегами. Просто чтобы не показывать слабости и не дать повода усомниться, что мне это по плечу.
Стоили ли мои усилия полученного результата? Я думаю, они были полезны проекту. Но я мог бы получить 90 % выгоды, затратив раза в два меньше нервов и жизненных сил, если бы учел все вышеописанные заблуждения, особенно № 4 и № 5 :)
Вас, как и всех, будут ждать проблемы и сложности. Не нужно их стесняться и ни в коем случае не стоит игнорировать или замалчивать. Если проблемы чего и боятся — так это огласки. Потому что в таком случае всегда оказывается, что у них есть решение и вы далеко не первый, кто с этим сталкивается.
Обязательно делитесь переживаниями и трудностями со своим руководителем, другими тимлидами, HR BP вашей команды. Сильный сотрудник не тот, у кого нет проблем, а тот, кто умеет их выявлять, находит в себе силы признать, решить и сделать выводы на будущее.
Вывод
За три года на позиции тимлида я осознал главную идею: победитель — тот, кто поднялся на один раз больше, чем упал. Не стесняйтесь и не бойтесь своих падений. Чем богаче у вас опыт, тем проще найти способ подняться в очередной раз.
Конечно, сколько теории не читай, пока не испробуешь на себе — полностью не разберешься. Но всё же некоторых заблуждений удастся избежать.
Вооружайтесь моими советами и пишите свои мысли по этому поводу в комментариях. Буду рад пообщаться.
Всем хорошего тимлидства!
Найкращі коментарі пропустити