Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Выводы о том, какого тим-лида ценит и команда, и клиент. Баланс качества и сроков, прогноз рисков и список задач, который поможет вам не стать мелким тираном <3
Привет! Меня зовут Максим Мишанин (@Uncertainty), я тим-лид и Java-разработчик в Red Collar. Еще год назад был разработчиком в одной крупной международной компании, но решил сменить стабильность процессов на звездную команду и человека, у которого, знал, многому научусь. Тогда я был лишь разработчиком, а на новом месте мне предстояло возглавить продуктовую команду.
Рассказ ниже может помочь начинающим тим-лидам не потерять доверие команды и не порушить настроенные процессы. Выводы, понятно, субъективны. Если поделитесь своим опытом в комментариях — буду рад.
Как представлял роль: 4 зоны ответственности и «красные флаги» тим-лида
Основная задача тим-лида — полное понимание, куда движется проект и кто за что отвечает. Для этого все дела можно поделить на четыре зоны ответственности:
Ответственность за направление разработки на проекте. Распределять, кто чем будет заниматься по временной шкале: приоритезация задач, контроль качества.
Коммуникация в команде — решение проблем внутри команды. И по взаимодействию между командами разработки внутри, и даже членами одной команды. Задача здесь — настройка до уровня, когда все может функционировать и без тим-лида до 2-3х недель.
Коммуникация с заказчиком: тим-лид объясняет все задачи, умеет рассказывать все понятно и вежливо, даже если приходится повторять несколько раз. Доносить риски, слушать пожелания и вносить коррективы. Частично выполняет роль проджект-менеджера, но по техчасти.
Верхнеуровневое понимание проекта: зачем делается, куда идет, где сейчас находится. Смотреть на него с точки зрения не только разработки, но и бизнеса: вовремя замечать и превентивно решать проблемы, общаясь со всеми членами команды, работать с рисками.
Также размышлял о том, что же такое плохой тим-лид. Вспомнил то, что не нравилось мне самому, когда у меня были тим-лиды:
На любой вопрос ответ «Читай доку», даже если этого там нет.
Главное, чтобы в текущем спринте мы сделали все запланированное, а что будет потом — неважно.
Плохо построенный процесс разработки продукта, как следствие — продукт в будущем сложно поддерживать.
Каждая проблема становится неожиданностью.
Мягкий вход = маленькая команда + пошаговое погружение
Попросите команду до 5 человек
Большие, устоявшиеся команды могут хуже принимать нового тим-лида, так как чужак приходит со своим подходом и порядками, у всех возникает больший стресс от притирок. В большие команды лучше входить опытным тим-лидам.
Когда команда небольшая и растет медленно — это хорошо для новичка. Он больше времени уделяет самому продукту, погружается в него, чтобы помогать ему расти с четким пониманием процессов. Упор моего погружения был в понимании где мы есть в плане бэка, формировании задач и выбора направления, куда двигаемся дальше.
Доказывайте свою ценность постепенно
Через месяц после моего вступления в должность ушел в отпуск технический директор. В этот момент я остро почувствовал, что команда не понимает, зачем им нужен тим-лид. А я, еще до конца не погрузившись в процессы компании и проектов, тоже плавал в понимании задач.
Такое положение вещей может подорвать и самооценку, и свою позицию относительно команды: если ты долго не проявляешь себя и не показываешь свою ценность, все могут привыкнуть считать, что ты лишний в своей роли.
Но и без стрессовых ситуаций может быть сложно правильно занять место в команде. Несколько советов, как легко и аккуратно войти в роль:
Когда приходите в проект, не надо говорить: «Я тим-лид и я буду все решать», — такого все равно по факту не будет, потому что в хороших компаниях решает вся команда, сообща, а за вами может быть финальное решение, но тиранство тут точно не поможет.
Первым делом разберитесь в бизнес-направлении и погрузитесь в проект: зачем пишете, куда пишете, для кого продукт. Изучите текущие документы, ходите с вопросами к людям с проекта и уточняйте все, что непонятно. Иначе вы будете знать меньше, чем разработчики, а это не прибавит вам авторитета.
После — постепенно погружайтесь в процессы через дела. Например, когда начнутся обсуждения и аналитик скажет: «Я делаю то и то», вы можете сделать замечание со знанием дела: «Ребята, вот тут может быть проблема, давайте создадим задачу, чтобы не забыть это сделать». То есть аккуратно показывайте, как вы вовлекаетесь в проект на равных с командой.
Затем можно пробовать аккуратно хвалить людей. Скажите, «Вы такие молодцы, мне даже добавить нечего к сказанному». Покажите, что они сильная команда, а вы пришли не руководить, а лишь помогать работе делаться. Подсматривайте за процессами и лишь иногда порционно вливайте внимание, если необходимо скорректировать чью-то работу.
Показывайте команде, что она хороша и справляется без вас и не бойтесь стать ненужным: такого не будет. Большие проекты (от пяти человек и от полугода разработки) один продакт-менеджер никогда не вытянет. Кроме того, с технической точки зрения никто кроме вас не поможет общаться с заказчиком и следить за проектом.
Теперь расскажу подробнее о том, что кроется под верхним слоем «задач». Сложные точки проявления тим-лида, благодаря которым все начинает работать слаженно.
Задача 1. Балансируйте качество и сроки; или помните о том, что существуют QA
Дилемма и разработчика, и тим-лида: функциональность или качество. Думаю, всем знакома проблема, когда 2-3 спринта делается одна и та же задача «до идеала» или документация пишется долго и слишком детально, — и сроки срываются. С одной стороны это нормально, потому что значит, что ребята круто делают и глубоко погружаются. Но всегда есть сроки — ответственность перед продуктом, его запуском и заказчиком.
Самое важное — скорость разработки. Порой лучше недоделать функциональность и пропустить малозначительные элементы, которые не влияют на положительные кейсы, но соблюсти сроки, чтобы этой функцией уже можно было пользоваться при прохождение какого-либо крупного флоу.
Не бойтесь, что где-то будет ошибка: помните, что есть тестировщики. Если долго копаться в деталях, мы можем потратить 3 спринта на 1 функцию, — а с ними сделать 3 функции за 3 спринта и параллельно все будет тестироваться и улучшаться. Так продукт разрабатывается быстрее, плюс заказчик приходит, смотрит и радуется и отношения с ним улучшаются.
Если же будете топить за функциональность — заслужите недоверие клиента. Представьте, что вам за полтора месяца не показывают ничего нового, а все обещают на словах — вы тоже на его месте подумали бы «что за х***я», и что стоит проверить работу команды. Начинаются многочасовые обсуждения задач, что жрет много-много времени и нервов у всех, а продукту никак не помогает.
Задача 2. Защищайте команду перед клиентом и устраняйте слабые места в процессах
Команда на созвоне является лицом компании и нельзя ее опускать в грязь. Тим-лид должен отстаивать позицию команды, даже если там что-то не так и кто-то сорвал сроки или сделал некачественно. Но каждое такое вмешательство нужно аргументировать реальными вещами.
Вместе с тем нельзя быть слишком мягким и разрешать человеку регулярно срывать сроки или пропускать серьезные ошибки — может закончиться потерей репутации перед клиентом, и клиент уходит, а это недопустимо. Надо учиться балансировать между возможностями людей и потребностями компании, и четко аргументировать важность решения задач.
Как решить проблему, если человек не тянет:
Сначала просто созвониться и спросить, в чем сложность. Возможно, будет достаточно доступно объяснить принцип решения задачи и советами или примером — важно: не готовым кодом! — направить в нужное русло.
Если не помогло:
Под предлогом срочности и важности передать задачу более опытному/заинтересованному члену команды, либо взять на себя, так как проект всегда в приоритете;
Провести 1-на-1 с этим человеком и выяснить его цели и стремления. Возможно, ему следует а) сменить проект, б) предложить отпуск: вдруг он просто сильно устал, в) мотивировать его: например, четче спланировать путь роста повышения грейда до следующей ступени и соответственно ЗП.
В случае, если ни один из подходов не подошел, есть немалая вероятность, что этому человеку не по пути с вами и компанией в целом.
Задача 3. Прогнозируйте риски и не бойтесь отстаивать свою позицию
Если бы в начале у меня было больше опыта, я бы не допустил эту ошибку. Как я уже рассказывал, почти сразу, как пришел, пришлось две недели жить без поддержки опытного коллеги, технического директора. Заказчик тоже только познакомился со мной и ждал решений. Уже надо было выбирать технологии проекта на основе исследований и приоритезировать задачи, но без плановых стратегий.
Из-за суммы факторов и неподготовленности не поймали нужный момент увеличения команды, например, подключения того же аналитика, QA и фронтов. Думали: так когда они здесь нужны, когда ставить? Не было уверенности сейчас или потом. А оказалось, что надо было еще раньше, чем мы начали об этом думать. Это привело к некоторым неудобствам в будущем: представьте, за две недели нам пришлось увеличить команду с 4 до 12 человек!
Вывод — мне стоило сильнее проявить опасения, обсудить их и тогда скорее всего мы бы поставили людей на проект вовремя.
Задача 4. Не ставьте задачи, а настраивайте работу так, чтобы задачи ставились командой сами
Я встречал тим-лидов-тиранов, и это ужасно: когда кто-то говорит, как надо, и все без понимания это делают. Люди должны прислушиваться и доверять вам, как тим-лиду, соглашаться, но и не бояться спорить аргументированно. Не быть марионетками.
Один человек на крупном проекте в любом случае не в состоянии все просмотреть и проверить, физически. Плох тот тим-лид, который настраивает команды с ожиданием проверки, что он должен все просмотреть.
Когда команда становится больше десятка, основная задача тим-лида — поддерживать сплоченность команды, чтобы уже и сами ребята не боялись друг к другу подходить с глупыми и не глупыми вопросами.
Ваша цель — выстроить все так, чтобы не вы создавали задачи. Команде должно быть интересно делать проект, должно хотеться сделать качественно. Приходит разработчик, говорит, что увидел тут пробел, давайте обсудим. И тим-лид выступает консультантом. Знайте, что это не лентяйство, а крутой уровень делегирования: чтобы каждый умел создавать себе задачи и делать их, вести по онбордингу, а вам остается только корректировать и консультировать. И если я заболею или уйду в отпуск, команда сможет жить без меня и проект не пострадает. Так вместо одной верхнеуровневый пары глаз, получается двенадцать пар глаз.
Хороший тим-лид — это не тиран, а консультант.
Итог
Мне нравится быть тим-лидом, но всегда очень многое зависит от команды. С ней мне повезло: это талантливые самостоятельные специалисты, порой из всех задач у меня остается лишь участие в кросс-ревью и я даже не пишу код. А то, что в команде сразу были сильные люди — помогло мне заниматься проектом, а не закрывать собой дыры. Поэтому помните о балансе джунов, миддлов и сеньоров.
Рано или поздно большинство разработчиков задумываются о роли тим-лида, это естественный рост специалиста. Чтобы вы были готовы к этому — или еще быстрее выросли в них — еще будучи стронг джунами не бойтесь проявлять инициативу и наращивайте опыт общения с людьми: участвуйте в ревью, в выступлениях, берите больше ответственности, чем от вас ожидают и копайте вглубь задач.
Если материал был для вас полезен, кидайте лайки, поделюсь еще одним инструментом тим-лида — кросс-ревью. Помогает обмениваться опытом, взаимно проверять задачи и растить хороших специалистов.
