Семь советов начинающему тимлиду

«Я пришел в тимлиды из инженеров», – с этих слов почти каждый руководитель команды разработки начинает рассказывать о своем карьерном пути. Так сложилось, что тимлидами чаще всего становятся самые опытные инженеры. При этом многие из них, примерив новую роль, теряются и совершают довольно много ошибок. Руководить командой разработчиков – задача довольно сложная. Инженеры, как правило, ценят автономность и не любят, когда им говорят, что делать. 

 

Мы попросили нашего сегодняшнего героя – руководителя команды Java-разработчиков из EPAM Александра Бармина – поделиться своим опытом и дать несколько советов начинающим тимлидам.

 


 

Я пришел в тимлиды из инженеров. Два года назад я начал работать на проекте EPAM для одного крупного иностранного заказчика. Предполагалось, что наша команда из трех разработчиков будет заниматься поддержкой проекта. Но оказалось, что объем работы довольно большой, и проект перешел в активную разработку. Задач у нас становилось всё больше, команда росла – и в какой-то момент я её возглавил. Это произошло как-то само собой: я был самым опытным разработчиком на проекте и постепенно стал брать на себя больше ответственности. И ещё мне на пользу сыграло то, что на прошлой работе я руководил командой из четырех человек. 

 

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

 

тимлиду

 

Совет #1. Выясните, чего от вас ждут в новой роли 

 

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

 

Я подошел к своему менеджеру и спросил, чего от меня ждут, какая моя роль в этом проекте. Он ответил, что мне нужно выстроить процесс разработки, наладить общение с заказчиком и следить за качеством продукта. Когда я прояснил ожидания, стало немного легче. Однако понимание, что работа тимлида не менее ценна, чем работа разработчика, пришло не сразу. 

 

Когда я был инженером, мне казалось, что главные задачи тимлида – бегать, суетиться, подкидывать разработчиком побольше работы и постоянно её проверять. Думаю, что у ребят складывалось такое же мнение обо мне. Чтобы показать, что моя работа тоже важна, на статус-митингах я наравне с остальными членами команды начал рассказывать о том, чем конкретно занимался. Что я не просто весь день двигал тикеты в Jira и писал какие-то важные письма, но, например, сумел договориться о том, чтобы нам дали виртуальную машину в облаке, которая нам очень нужна. 

 

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

 

Совет #2. Выберите инструменты для работы с командой 

 

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

 

Со временем, когда качество кода начало падать, мы вместе с менеджером проекта собрали встречу, на которой проговорили  с командой несколько важных моментов. Обсудили, по каким правилам должно проходить код-ревью, синхронизировали наши представления о том, что такое Definition of Ready и Definition of Done, определились с KPI и с инструментом для проверки работы – им, кстати, стал обычный чек-лист из 10 пунктов. Код-ревью провел – галочку поставил, тесты написал – еще одна галочка. И тимлид или разработчик, который проверяет задачу, имеет право сказать: «Вася, у тебя тут галочки не хватает, иди доделывай». 

 

Прежде чем внедрять какой-то KPI или OKR, нужно объяснять сотрудникам, почему эти показатели важны для команды. Например, низкий KPI по покрытию кода тестами говорит о том, что команда может поставлять заказчику некачественный продукт, а значит, что нужно принимать меры. 

 

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

 

Совет #3. Делегируйте задачи вместе с ответственностью 

 

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

 

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

 

Я начал с того, что делегировал процесс код-ревью одному из разработчиков. Сказал: «Вася, проверь код у Пети и скажи, хорошо ли он написан». Этот подход не сработал, потому что Вася и Петя сидели рядом, дружили и после работы играли в Counter-Strike. Вася, естественно, не хотел подставлять Петю и говорил мне, что всё в его коде хорошо. 

 

Постепенно я пришёл к мысли, что делегировать нужно не просто задачу, но и ответственность за её выполнение. Я начал говорить: «Вася, ты делаешь код-ревью, и если после этого в системе что-то сломается, я спрошу с тебя». 

 

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

 

тимлиду

Александр с частью своей команды 

 

Совет #4. Автоматизируйте повторяющиеся  задачи

 

Есть ещё одна книга, которую я советую прочитать всем тимлидам, называется «Проект “Феникс“». Она о том, как построить DevOps на проекте. Там был клёвый персонаж по имени Берт. К нему всегда все бежали за помощью, потому что он мог решать внештатные ситуации и тушить пожары. Пока я эту книжку не прочитал, не осознавал, что нахожусь в такой же ситуации. 

 

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

 

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

 

Тогда я понял, что процесс передачи знаний – новичкам или сотрудникам, которые работают давно – можно автоматизировать. Для новичков я записал видео с демонстрацией экрана и закадровым голосом, где объяснил всё, что им нужно знать о проекте. Я также применил принцип делегирования и попросил нескольких сотрудников прописать, как решать самые частые проблемы на проекте. «Вася, ты почистил место на Jenkins, напиши, как ты это сделал. Это поможет ребятам справиться с такой же проблемой самостоятельно». 

 

Так у нас набралась целая база знаний по проекту, которая здорово помогаем всей команде экономить время и силы.

 

Совет #5. Убеждайтесь, что сотрудники понимают, что вы от них хотите

 

Мне всегда казалось, что я могу довольно четко сформулировать любую задачу. Но то, что кажется абсолютно понятным лично тебе, не всегда так же очевидно для других людей. Глеб Архангельский в своей книге «Тайм-драйв» даёт простой, но действенный совет: не просто сообщайте людям, что им нужно делать, а убедитесь, что они правильно вас поняли.

 

Я начал просить ребят своими словами объяснить, что им нужно делать – особенно, если задачи были действительно сложными.  Это до сих пор помогает нам избежать недопониманий, которые возникали на первых порах.  

 

Совет #6. Не переделывайте за сотрудниками их работу 

 

Вот ещё одна боль, с которой я столкнулся, когда начинал свой тимлидский путь. Я давал сотруднику задачу, а через два дня он возвращался не с тем результатом, который я ожидал. В такие моменты мне хотелось сесть и всё переделать. Это – неправильная тактика. Тимлиду не нужно чинить своими руками то, что сломалось. Ему необходимо сделать всё для того, чтобы сотрудник сам нашёл верное решение.

 

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

 

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

 

Совет #7. Фиксируйте договоренности после встреч один на один 

 

Большая часть работы тимлида – помогать членам команды развиваться и давать обратную связь на их работу. Когда я был инженером, мне очень помогали такие встречи, и я тоже начал регулярно проводить их с ребятами. Мы встречаемся, чтобы обсудить прогресс, решить проблемы, если они есть, прийти к каким-то договоренностям

 

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

 

И ещё раз о том, что почитать и посмотреть начинающим тимлидам:

 

 

Фотографии: личный архив Александра Бармина