Выводы о том, какого тим-лида ценит и команда, и клиент. Баланс качества и сроков, прогноз рисков и список задач, который поможет вам не стать мелким тираном <3

Привет! Меня зовут Максим Мишанин (@Uncertainty), я тим-лид и Java-разработчик в Red Collar. Еще год назад был разработчиком в одной крупной международной компании, но решил сменить стабильность процессов на звездную команду и человека, у которого, знал, многому научусь. Тогда я был лишь разработчиком, а на новом месте мне предстояло возглавить продуктовую команду. 

Рассказ ниже может помочь начинающим тим-лидам не потерять доверие команды и не порушить настроенные процессы. Выводы, понятно, субъективны. Если поделитесь своим опытом в комментариях — буду рад.

Как представлял роль: 4 зоны ответственности и «красные флаги» тим-лида

Основная задача тим-лида — полное понимание, куда движется проект и кто за что отвечает. Для этого все дела можно поделить на четыре зоны ответственности: 

1. Ответственность за направление разработки на проекте. Распределять, кто чем будет заниматься по временной шкале: приоритезация задач, контроль качества.

2. Коммуникация в команде — решение проблем внутри команды. И по взаимодействию между командами разработки внутри, и даже членами одной команды. Задача здесь — настройка до уровня, когда все может функционировать и без тим-лида до 2-3х недель.

3. Коммуникация с заказчиком: тим-лид объясняет все задачи, умеет рассказывать все понятно и вежливо, даже если приходится повторять несколько раз. Доносить риски, слушать пожелания и вносить коррективы. Частично выполняет роль проджект-менеджера, но по техчасти.

4. Верхнеуровневое понимание проекта: зачем делается, куда идет, где сейчас находится. Смотреть на него с точки зрения не только разработки, но и бизнеса: вовремя замечать и превентивно решать проблемы, общаясь со всеми членами команды, работать с рисками.

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

• На любой вопрос ответ «Читай доку», даже если этого там нет.

• Главное, чтобы в текущем спринте мы сделали все запланированное, а что будет потом — неважно.

• Плохо построенный процесс разработки продукта, как следствие — продукт в будущем сложно поддерживать.

• Каждая проблема становится неожиданностью.

Мягкий вход = маленькая команда + пошаговое погружение

Попросите команду до 5 человек

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

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

Доказывайте свою ценность постепенно

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

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

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

1. Когда приходите в проект, не надо говорить: «Я тим-лид и я буду все решать», — такого все равно по факту не будет, потому что в хороших компаниях решает вся команда, сообща, а за вами может быть финальное решение, но тиранство тут точно не поможет.

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

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

4. Затем можно пробовать аккуратно хвалить людей. Скажите, «Вы такие молодцы, мне даже добавить нечего к сказанному». Покажите, что они сильная команда, а вы пришли не руководить, а лишь помогать работе делаться. Подсматривайте за процессами и лишь иногда порционно вливайте внимание, если необходимо скорректировать чью-то работу.

Показывайте команде, что она хороша и справляется без вас и не бойтесь стать ненужным: такого не будет. Большие проекты (от пяти человек и от полугода разработки) один продакт-менеджер никогда не вытянет. Кроме того, с технической точки зрения никто кроме вас не поможет общаться с заказчиком и следить за проектом.

Теперь расскажу подробнее о том, что кроется под верхним слоем «задач». Сложные точки проявления тим-лида, благодаря которым все начинает работать слаженно.

Задача 1. Балансируйте качество и сроки; или помните о том, что существуют QA

Дилемма и разработчика, и тим-лида: функциональность или качество. Думаю, всем знакома проблема, когда 2-3 спринта делается одна и та же задача «до идеала» или документация пишется долго и слишком детально, — и сроки срываются. С одной стороны это нормально, потому что значит, что ребята круто делают и глубоко погружаются. Но всегда есть сроки — ответственность перед продуктом, его запуском и заказчиком.

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

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

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

Задача 2. Защищайте команду перед клиентом и устраняйте слабые места в процессах

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

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

Как решить проблему, если человек не тянет:

1. Сначала просто созвониться и спросить, в чем сложность. Возможно, будет достаточно доступно объяснить принцип решения задачи и советами или примером — важно: не готовым кодом! — направить в нужное русло.

Если не помогло:

1. Под предлогом срочности и важности передать задачу более опытному/заинтересованному члену команды, либо взять на себя, так как проект всегда в приоритете;

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

3. В случае, если ни один из подходов не подошел, есть немалая вероятность, что этому человеку не по пути с вами и компанией в целом.

Задача 3. Прогнозируйте риски и не бойтесь отстаивать свою позицию

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

Из-за суммы факторов и неподготовленности не поймали нужный момент увеличения команды, например, подключения того же аналитика, QA и фронтов. Думали: так когда они здесь нужны, когда ставить? Не было уверенности сейчас или потом. А оказалось, что надо было еще раньше, чем мы начали об этом думать. Это привело к некоторым неудобствам в будущем: представьте, за две недели нам пришлось увеличить команду с 4 до 12 человек!

Вывод — мне стоило сильнее проявить опасения, обсудить их и тогда скорее всего мы бы поставили людей на проект вовремя.

Задача 4. Не ставьте задачи, а настраивайте работу так, чтобы задачи ставились командой сами

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

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

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

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

Хороший тим-лид — это не тиран, а консультант.

Итог

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

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

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