Вот ты и тимлид, сынок! Добро пожаловать в наши ряды. Имя спрашивать не буду, все равно через полгода выгоришь и уволишься.
Предисловие
Сегодня ты стал лидером команды. На тебя свалилось огромное количество обязанностей и встреч, от разработки ты потихоньку уходишь. Начало всегда воодушевляет. Утопая в задачах, встречах, обязательствах ты находишь романтику, ты делаешь свою работу хорошо (тебе так кажется).
Но нет, не так хорошо ты выполняешь свою работу. Спринты не закрываются, таски льются рекой, два seniora объявили друг другу войну из PR, а менеджеры решили пойти войной на тебя, объявив тебя виновником всего этого беспорядка. И вот очередное утро, дейли, и после чашки кофе ты задаешь себе вопрос: "А эффективен ли я и моя команда?"
Эта статья о двух вещах:
Эффективности и развитии команды
Эффективности и развитии TL
Почему именно эти темы? Потому что человек, который будет все это развивать один и роль в команде у него TL.
Эффективность и развитие команды: понятия, которые идут рядом
Именно команда приносит настоящий инкремент в продукт. И чтобы она это делала, TL должен очень много поработать над исправлением множества проблем, конфликтов, которые обычно существуют почти сразу после набора команды или вашего прихода в сформировавшуюся команду. Все люди разные - отсюда сложности. В одной из книг, которую я когда-то вычитал, была следующая фраза
Люди сложнее технологий.
По моим личным наблюдениям, да и по некоторым исследованиям (например, Хоторнский эффект) на эффективность влияют многие факторы:
Знание разработчиком продукта, который он создает и его смысл
Климат и взаимодействия внутри команды
Климат вне команды и межкомандные отношения
Обратная связь для каждого сотрудника и развитие его навыков
Перечислять можно много и много других факторов, но лично для меня - эти самые значимые, потому что в разный момент времени некоторые члены команды уходили в другие команды из-за отсутствия одного или нескольких пунктов выше.
Знание и смысл продукта
А зачем разработчику знать как работает весь продукт и его смысл? Лучший продукт получается тогда, когда в одной комнате собираются единомышленники. Да, методы и пути к их цели могут отличаться у каждого, но цель - все равно одна. Мы тут собрались, чтобы сделать что-то очень классное, поэтому мы ждем, что каждый будет вкладываться максимально в то, что делает. Если разработчик понимает, что его труд имеет смысл, ему нравится продукт, то его мотивация работать будет всегда высокой.
Задача TL в этом пункте донести до команды идею продукта и дать каждому разработчику понять, что то, что сотрудник делает, действительно важно.
Климат в команде
Хороший климат располагает к высокоэффективной работе. В команде каждый сотрудник должен чувствовать себя "легко".
Есть замечательная книга - "5 пороков команды" Патрика Ленсиони.
В книге рассказывается о пяти пороках, которые могут уничтожить изнутри любую команду в очень короткие сроки. Ниже будут эти самые пороки:
Недоверие
Боязнь конфликта
Безответственность
Нетребовательность
Безразличие к результатам
Патрик Ленсиони подробно приводит этапы решения этих самых проблем в своей книге. Не буду прикреплять картинки и спойлерить, но сразу скажу - все это проецируется не только на большие корпорации (в книге происходит разбор всех этих пороков на примере компании), но и на небольшие команды.
Задача TL быть человеком, который исправит эти пороки. Кто, если не он?
Климат вне команды и межкомандные отношения
На ретро часто можно услышать фразы аля "Мы не сделали, потому что эти глупые ${group_name} нам ${action_name}". Такие вещи объединяют команду, так как есть общий враг, который всем мешает. Только, постойте... другая команда тоже работает на благо общей цели. И они тоже заинтересованы в выпуске продукта. Я к чему - не нужно искать врагов. Не нужно делать так, чтобы другие команды, становились врагами.
Задача TL не допускать появления таких вот "врагов". Объяснять команде, что мы все в компании - команда.
Обратная связь и развитие навыков
Когда сотрудник работает на протяжении долгого времени и с ним не общаются, он начинает задавать вопросы аля "А нужен ли я?". Просто я сам попадал в такую ситуацию. Оказалось, что не нужен, но это уже совсем другая история.
Быть нужным - очень приятно. Поэтому любому разработчику будет очень комфортно работать с TL, который интересуется его делами на работе. Но тут мало интересоваться - необходимо также давать обратную связь об эффективности сотрудника. И повышать эту эффективность на основе обратной связи. Как?
Матрица компетенций не панацея, но может очень сильно помочь в этом. Командные мероприятия, которые направлены на кругозор сотрудников, 1:1 мероприятия для развитие навыков отдельных сотрудников. Перечислять способы и методы можно бесконечно, но найти бы время...
А если серьезно, то задача TL дать каждому сотруднику знания или направление для получений знаний. Помочь ему в развитии в том числе с помощью постановки каких-либо задач и правильной подачи обратной связи.
Развитие TeamLead
Поговорили о команде. Теперь нужно подумать о себе.
Спустя полгода работы TeamLead навыки в разработке постепенно теряются. Вот ты уже забываешь какие-то финты, которыми мог похвастаться на собеседованиях и перед командой, чаще спрашиваешь у команды какие-то вещи не потому что "не знаешь", а потому что действительно чуточку подзабыл. И в этом нет ничего страшного.
Действительно, нагрузка TL во многих компаниях скорее связана с управлением и процессами, поэтому направление вашего роста немного меняется - книги и статьи по управлению начинают заменять книги по разработке. Тут наступает ключевой момент, ведь в любой сфере есть так называемая "точка невозврата" - после нее вернуться в ряды разработчиков будет достаточно трудно. Что же делать?
Если от разработки уходить не хочется (как и мне), то есть несколько методов, которые мне несколько помогли.
Делите день на две части - Решение проблем разработчиков и управление и решение задач на разработку. Первое время будет трудно, но после вы откроете для себя силу и мощь календаря. Конечно, возможно, несколько дней в неделю у вас могут быть забиты планированием и общением с бизнесом, но рано или поздно день будет делиться на "до" и "после".
Больше внимания на code review - разработчик растет не только тогда, когда сам пишет код, но и когда смотрит и читает чужой код. Насмотренность наше все!
Больше общайтесь и советуйтесь с разработчиками по задачам. У вас в команде настоящие профи, которые точно помогут вам в разработке - учитесь у них. Будьте ближе к команде и не стройте из себя "Всезнающего"
Не забывайте про книги и статьи про разработку
Небольшой совет от друга PM
"Не забывай о том, что ты должен быть не только специалистом в компании, но и специалистом в сфере."
Но и тут необходимо сохранять баланс! Видите ли, специфика работы совсем другая. Не стоит уходить только в код, только в архитектуру и паттерны. Помните о том, что результат, который вы приносите продукту, на самом деле, приносит команда. И в этой команде есть наверняка специалисты, которые знают лучше вас. Ваша задача сделать эффективность команды максимальной. В этом, на самом деле, и заключается профессиональный рост TL.
Заключение
Конечно, невозможно в одной статье рассказать про все факторы, которые увеличивают эффективность работы. Как и невозможно перечислить все практики и методики. Но тут на помощь приходят книги, которые более подробно расскажут о многих аспектах эффективности
"Джедайские техники" Дорофеев Максим. Личная эффективность и все что связано с прокрастинацией.
"5 пороков команды" Патрик Ленсиони. Эффективность команд и разбор основных проблем в командах, которые мешают показать настоящий результат.
"Как пасти котов" Дж. Ханк Рейнвотер. Самая распиаренная книга. Кратко о важном в управлении.
"Человеческий фактор. Успешные проекты и команды" Том ДеМарко, Тимоти Листер. Подробная книга о проблемах в командах.
