Привет Хабр!
Меня зовут Саша Шутай, я тимлид в компании AGIMA. Конечно, прежде чем стать руководителем команды, я был разработчиком и работал под руководством нескольких тимлидов, поэтому знаком с разными подходами к управлению. В этой статье я поделюсь своим опытом тимлидерства и дам полезные советы, которые упростят жизнь новоиспеченного тимлида. В общем, расскажу, что ждёт разработчика, решившего стать руководителем.
Начнем по порядку. Определим термины.
- Тимлид — это руководитель группы разработчиков. Сразу обозначу, что тимлид это не старший разработчик.
У нас в компании более 30-ти команд во главе с тимлидами и опыт работы на совершенно разных проектах: от небольших до highload. Мы сами взрастили многих тимлидов в компании и накопили большой опыт, поэтому решили записать 6-ти месячный курс: «Как стать руководителем команды разработки». А в статье разберем основные моменты.
- Техлид — это технический руководитель продукта. В этой статье мы писали, кто такой техлид и какие навыки должны быть у него.
Продолжим. Чаще всего тимлидом становится опытный разработчик, который решает уйти в менеджеры с фокусом в техническую часть. По мере развития управленческих навыков и роста команды, тимлид всё меньше занимается непосредственной разработкой и всё больше people management. В моем случае примерно 60% времени уходит на управление, а 40% на ревью и ресерчи. В этом и кроется причина разочарований людей, которые хотят стать тимлидами, не до конца понимая, кто это.
Почему разработчики становятся управленцами
Есть свой особенный кайф работать чисто с технологиями, по которым есть документация или исходный код, а не с людьми (по которым, к сожалению, порой и того, и другого не хватает), всегда иметь только один тикет в to do, а при возникновении конфликтов приоритетов переводить все вопросы на тимлида или менеджера. В общем, полностью абстрагироваться от внешних процессов. Но не всем нравится такое положение дел, часто приходится о чём-то договариваться и отстаивать свою точку зрения. При возникновении сложной задачи, требующей дополнительных обсуждений, разработчик выходит из своей зоны комфорта. Он начинает развивать свои коммуникативные и менеджерские навыки. Потому что часто у разработчиков это в крови: чинить то, что сломано, будь это код или, как в случае с тимлидом, выстраивание правильных процессов.
Например, что-то работало неправильно — процесс или механизм, ты сам взял и во всём разобрался, починил или усовершенствовал процесс, повысил производительность, и проект стал лучше. И главное, это эмоциональный заряд, который ты получил от самостоятельной реализации инициативы, схожий с удовольствием от решения программистской задачи. Как ни крути, это приятно. Двигаемся дальше. При дальнейшем развитии управленческой ветки, программист начинает брать на себя функции тимлида:
- Делегировать рутинную работу младшему сотруднику;
- Формализовывать и давать установки по реализации задач;
- Налаживать механизм контроля сроков и требовать их соблюдения;
- Вести техническое ревью.
Вся эта работа не специфична для линейного разработчика, поэтому такое погружение в рутину менеджера заставляет задуматься о должности тимлида. Но все еще много вопросов:
- Так ли всё хорошо в работе руководителя?
- Стоит ли рассматривать рост в тимлида как обязательный этап в развитии карьеры программиста, или это совсем другая профессия?
- Налаживать механизм контроля сроков и требовать их соблюдения;
- Как от кода перейти к управлению людьми?
Когда я становился тимлидом, то не до конца осознавал весь объем работы (ответственность, сроки, бюджеты, команда, технологии), который нужно взять на себя. Это было сложно, но сейчас я понимаю, что оно того стоило. Итак, что ждет новоиспеченного тимлида на следующий день после назначения в должность?
Новая ответственность
Хорошо быть разработчиком, иметь ограниченный круг общения, сформированную зону комфорта, да и тимлид за тебя решает все возникающие вопросы. Разработчик несет ответственность перед техническим руководителем за созданный программный код, за выполнение согласованных сроков и действует по плану, полученному от тимлида. Если в способе реализации имеется ошибка, то ответственность за плохую реализацию вследствие плохого плана лежит уже на тимлиде, а не на разработчике. От того, как тимлид проработает задачу и будет вести контроль процесса разработки, зависит успешность проекта и развитие бизнеса:
- Срок реализации влияет на момент появления технического продукта на рынке;
- Правильное ресурсное планирование не позволит выйти из бюджета;
- Регулярные коммуникации со стейкхолдерами сопоставляют ожидания с реальностью;
- Качество продукта завоевывает признание пользователей.
Разберем подробнее, какую ответственность придётся взять на себя тимлиду:
1. Сроки и бюджеты
Первое, с чем сталкиваются тимлиды — сроки, бюджеты и распределение ресурсов. Мы работаем в сфере заказной разработки и нам очень важно, чтобы все наши разработчики были рентабельными. Поэтому в этом случае вам придется контролировать поток бюджета, входящего в вашу команду, ФОТ ваших разработчиков и их рентабельность. Особенно хорошо, если вы изучите виды трудовых договор, как считаются налоги и будете вести финансовое планирование поступающих в вашу команду средств и их распределение. Вы будете знать, как сможете нанимать людей, управлять распределением бюджета, считать рентабельность и понимать, когда и кому из своей команды можете увеличить оклад. Бизнес будет к вам приходить с задачами и вопросами о сроках реализации, поэтому вы должны соотнести требования с возможностями команды, декомпозировать постановку задач, составить оценку и следить за её соблюдением. Вашим помощником при планировании, контроле и коммуникациях с бизнесом может быть проектный менеджер. Используйте разные практики для синхронизации работы команды: daily meeting, retro.
2. Общение с бизнес-заказчиком
Для бизнеса тимлид — единственный представитель технической части проекта. Вместе с PM вам нужно выяснять все потребности бизнес-заказчика. В вашем расписании появится десяток еженедельных встреч, где вы будете согласовывать постановки, варианты реализации, приходить к консенсусу с ответственными лицами. Развивая навыки дипломатии и умение отстаивать свою позицию, вы сможете контролировать поток задач и планировать реализацию идей заказчика на комфортных для вашей команды условиях.
3. Kачество
Одно дело — запрограммировать код, другое — сделать конечный продукт удобным для пользователя. Интегрируйтесь с отделом качества на всех технических этапах проекта. Вам придётся найти специалистов, которые настроят автотесты, чтобы исключить риск аварий после релизов.
4. Кризисное управление и Disaster plan
Тимлид ответственен за жизнеспособность проекта. У всех случаются аварии — из-за сети, сервера или неудачного релиза. Никому не хочется в 3 часа ночи подключаться к production и решать проблемы костылём (что нормально только для временного решения). Проработать комплекс мер для предупреждения различных видов аварий или их исключения — лучше тимлида это никто не сделает. Если на проекте имеется нестабильный участок, необходимо завести тикет для работы с рисками или вообще решить причину нестабильности, выделив опасный код в отдельный сервис (чтобы не клал всю систему), и переработать архитектуру. А пока это происходит, добавить новых автотестов, чтобы не страдать при релизах.
Как со всем этим справиться?
Кажется, что ответственность — это естественно и просто, но на самом деле не все так просто. Ответственность за принятие решений, постоянные вопросы менеджеров и разработчиков, решение конфликтов, умение требовать выполнения поручений — это эмоциональная нагрузка и стресс. Когда ты разработчик — твой источник задач это трекер, а когда ты тимлид, то твой источник задач — это гораздо больше факторов (телефон, мессенджеры, почта, личное общение), и это еще один источник стресса. Если вы не научитесь справляться с таким видом нагрузки, то вы не проработаете в такой атмосфере больше полугода.
Частая ошибка (да и со мной так было): все силы бросать на решение незапланированной работы, которая будет на вас сваливаться каждый день. Растрачивая свой ресурс на внеплановую деятельность, вы откладываете выполнение основных задач. Разбейте рабочий день на интервалы по разным типам активности: ревью, консультации, встречи, исследования, и старайтесь их придерживаться. Никто вас не заставляет моментально отвечать на все сообщения в чатах (кроме аварийных), берите паузу на ответ, если вы заняты сейчас решением других дел.
Здесь можно позавидовать проектным менеджерам, для них это уже «детские болячки», т.к. они в этом варятся с самого начала и увеличивают свою нагрузку по мере роста. Тут важно отметить, что тимлид — это вчерашний разработчик, который находился долгое время в зоне комфорта и не занимался управлением.
Тимлид — это про управление командой
Тимлид — это в первую очередь работа с людьми и управление жизнью технической команды проекта. Потребуется заниматься ресурсным планированием и маппить потребности бизнеса с необходимым набором компетенций в команде. Если текущая команда не справляется с объёмом работы, это значит, скорее всего ей не хватает навыков. Тогда вам потребуется управлять кадровыми ресурсами, нанимать новых сотрудников, планировать развитие и повышения, мотивировать людей, решать вопросы увольнения. Рассмотрим подробнее эту сторону работы тимлида.
Найм
Вы будете драйвить процесс найма новых сотрудников, составлять профиль кандидата для HR и проводить собеседования. Не всегда удаётся быстро и просто найти идеального кандидата. Возможно, стоит доработать вакансию, добавить вкусных технологий (то, что может зацепить кандидата) или поднять уровень предлагаемого оклада, проанализировав текущую ситуацию на кадровом рынке. Составьте вопросы для быстрого скоринга по необходимым вам техническим скилам и попросите HR проводить по ним опрос. Так до очного собеседования будут доходить только релевантные кандидаты. Если ваш рабочий график не позволяет проводить много собеседований, делегируйте этап технического опроса своему либо техлиду. Сами же проводите только повторные встречи.
Увольнение
Неприятная для тимлида-новичка часть работы с командой — увольнения. Могут быть разные причины: некачественное выполнение работы разработчиком, проблемы внутри команды, либо желание самого сотрудника. Иногда оно может быть обоюдным—- вы тратите много сил на решение проблем с подчиненным, а сам разработчик устал от ваших постоянных нравоучений.
В слаженной команде не часто дело доходит до увольнения. Если раньше всё было хорошо, а сейчас сотрудник стал плохо работать, то стоит разобраться в причинах. Придётся провести сложный разговор, на котором вы расскажете сотруднику о том, что вас не устраивает в качестве его работы, при этом выделите его сильные и слабые стороны, так что он сможет сделать выводы.
Если вы избегаете такого разговора, то вы уходите от своей ответственности руководителя, а это ведет к плачевным последствиям. Уволить — самое быстрое и простое решение из существующих, но далеко не самое оправданное. Намного сложнее разбираться в сложившейся ситуации, искать другие способы выхода из нее: работать с человеком, предлагать другие условия, команду, задачи. Важно вовремя понять, не избегаете ли вы этого сложного варианта решения и не пытаетесь ли пустить всё на самотёк. Искать нового человека тоже затратно, сложно и долго. К тому же нет никакой гарантии, что новый человек не принесет новых проблем или не повторит старые.
Если разговор сложится, сотрудник признает свои ошибки и будет готов изменить своё отношение к работе, то зафиксируйте конкретный срок для исправление сложившейся ситуации, сформируйте метрики и требования, которые помогут оценить, решены ли все вопросы и проблемы. Назначьте промежуточные контрольные точки, чтобы иметь возможность скорректировать план работы сотрудника.
Если продолжать совместную работу дальше не вариант, и увольнение происходит по вашей инициативе, то в ваших интересах расстаться по-хорошему. Будьте честны, расскажите причины такого решения, так как это, возможно, поможет сотруднику самостоятельно отработать свои недостатки и добиться лучших результатов на новом месте. Дайте объективные аргументы в защиту принятого решения, чтобы исключить обиду на компанию. Сохраните хорошие отношения с разработчиком, ведь в впоследствии ваши карьерные пути могут ещё пересечься.
Если сотрудник сам проявил желание уволиться, в этом может крыться ваша недоработка как руководителя, особенно, если это произошло неожиданно для вас. Скорее всего, вы мало проводили self-review и one to one, не знали о проблемах и пожеланиях подчинённого и упустили возможность всё исправить.
Когда я был старшим разработчиком в одной из команд в другой компании, то частенько от меня требовали грепать логи боевого приложения и закисать на скучных задачах, отсутствовала возможности участвовать в R&D. Это всё не давало никакого интереса к работе и к профессиональным вызовам, что послужило причиной моего ухода. Также частая причина — невозможность договориться об изменении условий (оклада или задач), хотя вы на самом деле вполне могли бы это скорректировать, если бы знали о такой потребности сотрудника.
Здесь вам, как руководителю, важно найти баланс между желаниями сотрудника и реальными возможностями компании. Руководитель группы разработчиков это не добрый дядя с неиссякаемым бюджетом и стеком задач на новомодных технологиях, вы не сможете соответствовать всем требованиям работников, т.к. вас ограничивает бизнес, рынок и здравый смысл.
Мотивация сотрудников
Тимлид поддерживает в подчиненных интерес к работе, развитию и сотрудничеству. Как лидер он заряжает команду на сплоченную работу над проектом. Сильный руководитель может сделать из слабой команды нормальную, а хорошую вывести на уровень звёзд разработки. К сожалению, это работает и в обратную сторону: плохой руководитель может развалить отличный коллектив. Если не знаете, с чего начать, то мой совет — вникайте во все рабочие и нерабочие процессы, инициируйте встречи, обсуждения. Но каким бы классным лидером вы ни были, пока ваши подчиненные не будут чувствовать себя комфортно, ни о какой мотивации в работе не может идти и речи. Перед тем, как заниматься вопросами мотивации, создайте все условия для работы:
- Уровень заработной платы должен быть адекватным рынку, чтобы бонусы и премии были только приятным дополнением за качественную работу, а не обязательно частью, без которой невозможно прожить;
- Удобное рабочее место и производительная техника всегда в исправном состоянии;
- Налаженные взаимоотношения в коллективе. Никто не хочет работать в атмосфере негатива. Тимлид должен сформировать дружественную атмосферу в команде и пресекать на корню развитие конфликтов;
- Возможность расти, развиваться и уверенность в том, что тебе всегда помогут, напрямую влияет на заинтересованность разработчика браться за сложные задачи. Вы должны давать возможности для раскрытия человека как профессионала;
- Поощряйте инициативы, создайте культуру, располагающую сотрудников к шерингу опытом — успешного и не очень.
Закрыв базовые потребности сотрудника, начинайте формировать личные мотивационные факторы. Назначьте личные встречи. Выясните цели сотрудника, узнайте, как компания может помочь их достичь. Можно совместно разработать KPI, выполнение которого даст желаемые результаты (повышение, премия, рост зп). Зачем это нужно? Это поможет развитию сотрудника в соответствии с его желаниями и потребностями команды. Если все попытки мотивировать сотрудника не приносят успеха, качество работы продолжает ухудшаться, а работник не хочет идти на контакт, попытайтесь разобраться в причине такого отношения. Возможно, имеет место демотивация. В таком случае составьте карту мотивационных факторов человека и сопоставьте с ресурсами, которые предоставляет компания. Такое сравнение ожиданий с реальностью поможет понять, как построить дальнейшую работу. Если же окажется, что причина в нежелании работать, то смотрите пункт про увольнение, может быть, вам ещё получится исправить сложившуюся ситуацию.
Ты стал тимлидом, что дальше?
Я постарался рассказать, кто такой тимлдид, в чем его функции, затронул тему работы с людьми и привёл примеры, почему тимлидом быть не так просто, но интересно. Здесь я ещё хочу дополнить, что не стоит воспринимать эту должность как венец карьеры разработчика и уж точно не стоит идти в руководители только ради денег, так как сильные программисты могут зарабатывать больше, и это тоже классный вектор для развития. Если вы хотите попробовать, но уверенности, что справитесь, нет — возьмите для начала на текущей позиции на себя чуть больше ответственности. Разработайте, предложите и реализуйте план по рефакторингу (о котором вас никто не просил), предложите провести собеседования новых кандидатов, попробуйте провести код-ревью вместо своего руководителя, проанализируйте неэффективный процесс в команде и предложите его изменения. Заберите часть коммуникаций тимлида на себя. Если не получится — ничего не потеряете, но зато точно поймёте, как вам строить карьеру дальше!
Комментарии и обсуждения статьи в нашем блоге на Хабр.