Как стать тимлидом и не взорваться

Что надо понять

Вам платят деньги не за то, что вы пишите код

Умение писать код и понимать его — по-прежнему важно для TL, он оценивает и продумывает архитектуру и т.д. Но у вас всего две руки, а у команды их явно больше

Ваша основная задача — создать такие условия, чтобы команда была наиболее эффективна. Программист должен писать код, а всё остальное — ваши заботы.

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

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

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

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

Вам нужно нанимать людей. Хорошо, если у вас есть отдел кадров, который умеет нанимать IT-специалистов. Если нет — у вас появились дополнительные обязанности. Учитесь составлять вакансии, отбирать специалистов, проводить собеседования, увольнять. И если у вас не стартап с космическими инвестициями, готовьтесь находить людей в бюджете ниже рынка. Возможно даже придётся самому обзванивать кандидатов.

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

Вы не можете выбирать технологии, какие хотите. Обычный разработчик может предлагать новые технологии, а задача TL — поддерживать баланс стека технологий проекта. Помните, стабильность проекта и процесса разработки — ваша обязанность. Что делать, если из команды уходит единственный хранитель какой-то особенной технологии? Кроме того, использование каждой технологии должно быть обосновано. Я периодически наблюдал как полтора земплекопа в крохотном проекте всё пилят на микросервисах. Они не догадывались, что компания не была готова к этому. Конечно, ни к чему хорошему такие эксперименты не приводили.

Вы палочка-выручалочка в любом аврале. В любых нештатных ситуациях вы не можете просто рявкнуть на команду: «Всё должно быть сделано!» и уйти. Сидеть до ночи должны именно вы. Нельзя бросать разработчиков с проблемой один на один. Это плохой пример для них, ответственность в таких случаях лежит именно на TL. Но и держать всю команду на аварийных работах тоже нет смысла. Я сам несколько раз возвращался домой в 5 утра, а на следующий день приезжал к 9 утра на совещание. Вообще, ваша работа в том, чтобы до такого не доводить.

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

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

Зачем нужны тимлиды

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

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

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

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

Про карантин

Сейчас времена не простые. Как выживаете в карантин?

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

На этот вопрос однозначно ответить нельзя. Многим людям стало комфортнее. Например, мой случай: на дорогу до офиса у меня уходит 1 час 20 минут, что в сумме почти три часа на дорогу туда-обратно. Сейчас я могу это время потратить либо на работу, либо на свои личные дела, что в итоге делает меня более продуктивным.

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

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

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

Конечно, есть и минусы — в моем случае, когда работа сильно завязана на личном общении, возможность взять и выцепить человека попить кофе и поговорить сильно деградировала. Я учусь ее компенсировать через обычные созвоны — мы стараемся даже неформальное общение переносить в онлайн — сидим с чашками кофе в zoom:) Кажется, что заметного падения качества работы не произошло.

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

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

Думаю, что это направление будет расти и мы будем более лояльнеев этом плане друг к другу. Полностью оставаться на удаленке, конечно, не будем — возможность собраться всем в переговорке очень ценна. Или просто развернуться в кресле и задать вопрос коллеге.

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

Идеальные вопросы для интервью — какие они?

Спойлер: идеальных вопросов нет. Не существует универсального списка, благодаря которому вы все узнаете о человеке и не промахнетесь. Я провожу групповые собеседования: рекрутер, несколько ребят из отдела разработки (чтобы поделились впечатлениями + смогли меня заменить, когда я буду, например, в отпуске) и я. Рекрутер оценивает софтскилы, а мы проводим техническое интервью — разбираем кейсы или спрашиваем, а что будет, если сделать вот так. Все проходит в формате непринужденной беседы, что позитивно влияет на кандидата: ему спокойнее и он меньше волнуется.

Совет: идите в ногу со временем и не задавайте вопросы типа «Кем вы видите себя через 5 лет» или «Собираетесь ли вы в декрет». Вряд ли вам ответят правду, зато такие вопросы негативно влияют на ваш HR-бренд. Спросите лучше о мотивации или о том, в каком направлении кандидат хочет развиваться. Это будет корректней и информативней для вас.

История из жизни
«Как мы проворонили хорошего кандидата»

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

Какие знания и навыки у него должны быть

Какие личностные качества должен иметь тимлид? Список довольно обширный, но ведь и ответственность у руководителя большая:

• трудолюбие, целеустремленность;
• адаптивность, гибкость;
• инициативность, креативность;
• самостоятельность, ответственность, пунктуальность;
• коммуникабельность;
• стрессоустойчивость, терпеливость, дипломатичность.

Teamlead должен иметь минимум 5 лет опыта в IT области. Что потребуется ему для успешной работы:

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

И это список только наиболее важных требований. Работа требует навыков работы с Linux based дистрибутивами, знания Agile, PHP, Scrum, MySQL, JavaScript. Могут еще встречаться условия, имеющие отношение к конкретной сфере работы заказчика.

Какие требования чаще всего звучат в описании вакансии тимлида:

• высшее техническое образование (это точно будет преимуществом, но не всегда является обязательным требованием);
• достаточное количество знаний и навыков в своем стэке (их мы перечислили выше);
• умение проводить код-ревью и менторинг;
• опыт работы от 5 лет;
• управленческие навыки.

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

Шаг номер 0. Зачем?

Итак, вам предложили стать тимлидом или вы сами захотели им стать. Что надо сделать в первую очередь? Хорошенько подумать, а надо ли оно вам.

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

Я общался с многими состоявшимися специалистами в этой профессии и все они говорят примерно одно и то же: 

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

• Кто-то — потому что хочет больше влиять на процессы и результат. Лично я отношу себя к данному лагерю. В этом плане тоже всегда есть чем заняться. Хромающие процессы по всем фронтам. От начала формирования бизнес задач и требований, до уже конечных результатов разработки.

Ложные цели, на которые не надо вестись:

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

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

• Повышение уровня ЧСВ. Ничего особо крутого в этой должности нет. Это просто очередная должность чуть выше рядовой. Как ефрейтор или сержант в армии. Вроде лычка есть, но хвалиться особо нечем, и вокруг куча таких же.

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

Где-то нужен полуменеджер-полуразработчик, где-то техлид/архитектор, где-то пипл менеджер и т.д

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

Советую заранее узнать, что же именно от вас требуется. 

Спойлер: 80-90% вакансий на российском рынке — полуменеджер-полуразработчик. Формально говорится, что 60-70% времени надо писать код, а 30-40% менеджерить. При небольших размерах команды и порядочном работодателе это может неплохо работать. Лично у меня где-то сейчас 40 на 60 получается делить код с менеджементом. Хотя я чувствую, как при разрастании команды код отодвигается от меня всё дальше и дальше. 

Однако при недобросовестном или просто непонимающем работодателе, от вас будут ожидать примерно 100% менеджмента и 100% написания кода. Постарайтесь узнать об этом как можно раньше, чтобы СБЕЖАТЬ.

Чаты как способ выстраивать связи

Команда — это система, частями которой являются живые люди. И как любая другая система, её характеристики меняются от того, какие связи образовались между её элементами.

В удалённой работе нет другого способа формирования нужных связей, кроме как создавать чаты. Нередко можно услышать «у нас слишком много чатов». Порой, это действительно так. Но если каждый новый чат помогает решить проблему, то придётся мириться с их количеством. В целом, можно создать несколько постоянных чатов, а остальные формировать на время решения конкретной задачи. Часто замечал, что для решения какой-то рабочей проблемы достаточно создать чат, позвать в него людей, которые нужны для решения проблемы, описать проблему и подождать. Каждый участник начинает прикладывать усилия для решения проблемы. Т.е. моя задача была в том, чтобы определить необходимый состав группы для решения проблемы и начать формировать связи между людьми. В офисе для этого служат неформальные разговоры на рабочих местах или же официальные совещания, а в удалённой работе связи формируются в чатах.

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

Страх №1. Ты не востребован на рынке

Буду получать меньше, чем сейчас

• 144–294 тыс. рублей, если являетесь профессионалом, который, возможно, менторит пару человек, но едва ли исполняет весь набор функций тимлида.
• 175–357 тыс. рублей, если вы тимлид небольшой команды.
• 225–491 тыс. рублей, если вы тимлид большой команды в 10-30 человек или менеджер менеджеров.

Как победить страх, что ты не востребован на рынке

• Это повышает вашу уверенность в завтрашнем дне. Дает понять, что если что-то пойдет не так (компания обанкротится, вы выгорите, ваш руководитель сойдет с ума и т.д.), вы всегда сможете найти себе что-то еще.
• Позволяет оценить ваши навыки. Длительное время сидя на одном месте трудно понять, а как вы справляетесь. На собеседовании вы получите максимально честный и жесткий фидбэк.
• Дает понимание рынка: что и где требуется от тимлидов, какие полезные практики и процессы применяются и чем они могут быть полезны вам в текущей ситуации.

Ходить по собеседованиям не обязательно значит хотеть сменить работу. Это не страшно, за это не наказывают.
Teamlead Roadmap

Образцовый стиль

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

При образцовом стиле руководитель ставит высокие требования к себе самому и к своим подчиненным. Например, в Кошельке старший инженер не только решает сложные задачи, но и регулярно выступает на митапах, пишет статьи, обучает менее опытных коллег, думает над тем, как улучшить процессы код-ревью, проектирует фичи, затрагивающие все iOS-команды (у нас их на данный момент 5), отвечает за технические метрики (крэш-фри, время запуска приложения), а также участвует в формировании процессов найма. А от перечисления всех обязанностей лида платформы меня бросает в холодный пот. Всё это звучит очень сложно, но на практике, при достижении определённого уровня развития , это делается уже на автомате. А ещё мы всецело выступаем за дистрибутивную честность. 

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

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

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

Мы понимаем все негативные эффекты такого подхода, поэтому не ожидаем от каждого сотрудника, что он будет техлидом. Наша карта компетенций подразумевает очень широкое распределение по уровням: от тех, кто только стал мидлом, до уровней principal, techlead, platform lead.

Плюсы и минусы профессии

Теперь немного о достоинствах и недостатках профессии:

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

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

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

Как быть хорошим Team Lead-ом? Советы

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

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

Контролируйте свое эго.

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

Каждое, даже самое простое решение, может иметь далеко идущие последствия, поэтому очень важно обсуждать его со всеми заинтересованными сторонами,” — говорит Линда Брэнаган (Linda Branagan), в прошлом опытный тимлид из компании Construct Internet Design.

Обсуждайте детали и договаривайтесь обо всем заранее.
Поскольку коммуникации — это важная часть функциональности тимлида, старайтесь по-максимуму обсуждать все аспекты работы над проектом и договариваться обо всем заранее, советует Майк Скэнлин (Mike Scanlin), СЕО американской компании Born to Sell и бывший тимлид в целом ряде ИТ-компаний, среди которых T/Maker и General Magic.
“Нет ничего хуже, чем работать в течение года над проектом, и, продемонстрировав результаты своей работе на очередной спринте, услышать от членов команды что-то вроде “А как насчет этих функций?” или “Мы забыли, что нам нужно будет реализовать вот это.” Постарайтесь убедиться в том, что все известно и четко спланировано еще до начала работы над проектом,” — рекомендует он.

Не провоцируйте конфликты, но будьте готовы к ним.
Также важно помнить о том, что будучи на позиции тимлида, очень сложно угодить всем сторонам, а поэтому конфликты в той или иной форме практически неизбежны. “Работа на позиции тимлида означает, что на каком-то этапе вам придется принимать решения, касающиеся членов команды, и эти решения неизбежно будут вызывать конфронтацию. Этот аспект работы часто оказывается неожиданным для многих тимлидов, потому что далеко не все умеют и способны решать конфликты,” — сказал Стив Морс (Steve Morse), разработчик поддержки в компании Tealeaf Technology.

Про devrel

Я слышал, что у вас есть школа спикеров? Можешь рассказать про нее подробнее?

Да, Speakers Club. В 2016 году на devconf я слушал про IT-бренд — для меня это была совершенно новая область, т.к. в компаниях, где я работал, этого не было. На докладе рассказывалось что такое IT-бренд, какие есть способы его прокачки и как это делать.

Я вернулся с доклада и поднял вопрос о том, чтобы начать прокачивать IT-бренд в Lamoda. Именно в этот момент к нам пришла Женя Голева, наш действующий devrel.

Она с лета 2016 начала курс по публичным выступлениям, куда позвали тимлидов и техлидов — туда попал и я, так как интересовался темой.

По результатам года работы Speakers Club мы подготовились и выступили на HighLoad и на других конференциях.

Speakers Club существует 4 года и мы собираемся каждые 2 недели. Люди приходят туда за тренировкой — тема не имеет никакого значения. Можно прийти рассказывать хоть про морских рыбок:) Главное — нужноприходить без презентации и просто начинать выступать. Дальше уже ведется работа над подачей, работой с аудиторией, структурой повествования и так далее. Главная идея клуба — возможность получить обратную связь о своих навыках, и получить её в максимально безопасной атмосфере.

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

Например, на следующей неделе у нас будет мероприятие IT Gathering. На нем IT-руководство рассказывает о результатах работы за квартал: что мы сделали хорошо, что плохо, и какие у нас планы на следующий квартал. Также там выступает и devrel, рассказывает про состояние бренда, его стратегию и планы. Мы регулярно напоминаем сотрудникам о том, что можно выступать публично и почему это хорошо.

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

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

Это упражнение позволяет пробить стену с синдромом самозванца и ощущение, что “все, что я делаю скучно и неинтересно”. Когда ты слушаешь вопросы своих коллег и понимаешь, что если внутри компании есть люди, готовые задать интересный вопрос, то значит и снаружи, скорее всего, этот опыт можно интересно изложить. Дальше, при работе над докладом, можно рассчитывать на поддержку devrel либо других опытных спикеров.

То есть у вас нет проблем с трафиком людей желающих выступить?

Это постоянный фокус, над которым мы работаем. По щелчку пальцев кучу докладов создать не получается, но есть объем наработок, чтобы регулярно что-то писать на Хабр и делать стабильно по 20-30 докладов в год уже несколько лет. То есть проблемы нет, но работать над этим постоянно приходится — люди в основном думают о своих задачах, а не о том, чтобы выступать.

От автора курса

Тимлид — это лидер, от качества работы которого зависит эффективность работы команды. На его плечах лежат такие задачи как:

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

На опыте моих подчиненных я вижу, что начинающим тимлидам бывает сложно понять как правильно выполнять все эти новые обязанности и с чего начать свою работу. Какие приоритеты нужно расставить? Как правильно общаться со своими подчиненными? Как построить эффективную работу с бизнесом? Как выстроить общение со своим руководителем и новыми коллегами по команде? Как избежать ошибок, которые отрицательно скажутся на репутации и дальшей работе? Эти и многие другие вопросы могут быть препятствие для развития карьеры тимлида.
В моем курсе для тимлидов “Тимлид: основы” я разбираю базу того, что составляет работу хорошего тимлида. Рассказываю с чего нужно начинать работу с людьми, какие моменты нельзя упускать, разбираю конкретные ситуации, с которыми часто сталкивается тимлид. Мой курс для тимлидов — это отличное руководство, дающее необходимую опору на начальном этапе работы и хороший бэкграунд для продолжения карьеры тимлида. Не упустите шанс получить все необходимое для старта успешной карьеры руководителя!

Лайфхаки

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

Вот несколько наших секретов:

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

Шаг номер 2. Общий план первоначальных действий

От теории переносимся к практике.

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

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

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

Очень важно это всё понимать и учитывать. Иными словами, тимлиду приходится быть не просто хорошим трудягой, но еще и опытным политиком

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

Какие назначить первые встречи, чтобы во всё это погрузиться?

Первым делом встретьтесь 1 на 1 с руководителем и, используя роадмап тимлида https://tlroadmap.io/, обговорите конкретные ожидания от вашей позиции. Главное помнить, что в роадмапе указано не «всё, что должен знать и делать тимлид», а «всё, что могут требовать от тимлида в разных компаниях», т.е. это объединение подмножеств хотелок из разных компаний. Так что, когда вам начальник скажет: «Ну, вроде выглядит норм, давай-ка всем занимайся,» — вашей задачей будет ему объяснить, что всем заниматься невозможно физически и нужно проанализировать конкретную ситуацию, проект, команду, выделить наиболее важные области, которые вы и возьмете на себя.

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

• взглянуть на текущую ситуацию с разных сторон;

• узнать какую-то историю, которая творилась еще до вас;

• проанализировать самих людей;

• понять ожидания этих людей от вас.

Обязанности тимлида

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

В перечень основных обязанностей тимлида входит:

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