Все о должности тимлида: кто такие руководители команды разработки и как ими становятся

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Систематизируйте своё развитие

Выделите время для развития. Например, есть приём «No meeting hours, no meeting day». Это то время, которое вы выделяете себе на знакомство с новыми подходами и практиками. На первый взгляд может показаться, что это время стоит использовать для выполнения своих непосредственных обязанностей, однако если правильно им распорядиться в контексте саморазвития, то результативность только вырастет.
Заведите карточку на себя. Например, список навыков. Разумеется, навыки будут уже другие. Пройдитесь по списку ваших навыков фильтром доказуемого опыта, чтобы объективно определить свои слабые места. 
Спросите руководителя. Это быстрый и простой способ получить взгляд с ещё одного ракурса. Руководитель может дать очень ценные советы относительно того, над чем нужно поработать и как дальше расти. 
Пройдите курсы. Индустрия управления в IT развивается, можно найти программу по вкусу.
Добавьте новые каналы информации

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

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

Teamlead roadmap. Егор Толстой YourDestiny, Стас Цыганов @DevAlloy и комьюнити собрали и систематизировали разные аспекты деятельности тимлида, описав, что делать, зачем делать, как делать и т. д. Рекомендую!

Продукт и бизнес

• Medium: Business
• Medium: Marketing
• Harvard Business Review
• vc.ru
• TechCrunch

Управление

• YouTube: Management Channel
• Habr: Управление разработкой
• Habr: Управление проектами
• Telegram: TechLeadsGoodReads
• Late Night Teamlead Show

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

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

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

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

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

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

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

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

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

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

Варианты будущего роста

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

Чем занимается team leader

Отметим, что тимлид – это должность, а не отдельная профессия. Что входит в обязанности этого специалиста:

• Общение с заказчиком, организация разработки. Team lead помогает программистам решать поставленные перед ними задачи (с высоты своего опыта). Он одновременно и управляет, и сам занимается разработкой. Поэтому должен иметь иметь хороший базис в программировании и навыки менеджера. Он учитывает приоритеты и интересы конкретного заказчика, отслеживает эффективность членов команды в плане бизнес-процессов.
• Наем, обучение и адаптация всех сотрудников. Лидер взаимодействует с менеджерами и эйчарами для закрытия потребности в кадрах, принимает участие в собеседованиях. В маленьких организациях тимлидеры иногда сами занимаются наймом. В больших компаниях эйчары производят первичный отбор, а team lead задействуется для технических собеседований. Он знакомит новичков с принятыми в работе стандартами, самим проектом, инструментарием и кодом. Помогает джуниорам понять бизнес-процессы и роль каждого в них, планирует развитие других сотрудников, мониторит их рост. Благодаря тимлиду обеспечивается соответствие всей команды и отдельных кадровых единиц потребностям бизнеса.
• Помощь коллегам и координация команды. Лидер выполняет не только управленческие функции, он принимает участие в работе над кодом. Руководитель следит, чтобы продукт соответствовал целям, которые поставил заказчик. Осуществляется это путем контроля разработки и координации деятельности команды. Программисты обращаются за помощью к тимлиду, а во время индивидуальных бесед и общих собраний обсуждается ход грядущей работы.

Менеджерские полномочия тимлида:

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

Технические компетенции управленца:

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

Team leader должен четко осознавать, что сейчас происходит с проектом, текущий этап разработки, отклонять/одобрять различные идеи и предложения сотрудников. Он ответственен за микроклимат в коллективе, за то, чтобы все члены команды были работоспособны. Иными словами, он помощник, психолог и друг. Руководитель обеспечивает комфортные условия работы своим подчиненным.

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

Знания и навыки

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

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

Что касается знаний и навыков, то для работы тимлидом соискатель должен:

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

Повторюсь еще раз – тимлид это и программист, и психолог, и менеджер в одном лице.

Требования работодателя к кандидатам

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

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

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

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

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

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

Про ошибку найма и ответственность

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

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

Ошибки, негатив и минусы

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

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

Принятие решений. Бывает, что людей в команду спускают сверху. Вам необходимо сразу четко обозначить здесь правила: либо у вас есть право вето на абсолютно все решения по построению команды, либо необходимо объяснить руководству, почему будет работать именно так. В идеале и самое часто встречающееся на практике — когда team lead сам формирует себе команду. Повышается моральная ответственность так как решения принимал сам lead.

Личностные качества. В команде есть человек, который по каким-то причинам вас не устраивает

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

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

К минусам можно также отнести то, что со временем ваши технические навыки будут падать. Это и миф, и правда одновременно. Роль лида позволяет более широко взглянуть на некоторые технические аспекты, на мета-принципы программирования. А то, что вы не будете знать как запрограммировать в iOS 10 новый фреймворк CallKit и какие интерфейсные методы в нём есть — это пережить будет тяжело, но в целом можно.

С чего всё началось

У нас было три небольших группы разработки. Каждая жила по своим правилам, у каждой был свой список задач, свои цели и свой лид, одним из которых был я. В какой-то момент все три группы объединили в одну команду, а меня назначили тимлидом этой новой команды. Команда — распределённая, разброс по часовым поясам — от Москвы до Новосибирска, из 11 человек только двое сидели рядом в офисе, 5 человек, включая меня, работали удалённо. В таких условиях была опасность превратиться в группу программистов, каждый из которых получает задачу и выдаёт кусок кода. А мне хотелось построить команду, в которой люди будут участвовать в жизни продукта, который мы делаем.

Когда рекрутер «пинает» тимлида и команду разработки — это нормально

Воронка подбора — это зеркало найма, то, как он проходит у вас в компании. Поэтому воронка бывает разной: у кого-то шесть-семь этапов, а у кого-то — все двадцать. В разработке hh.ru воронка выглядит так:

заявка на подбор → скрининг резюме рекрутером → согласование кандидатов техническими специалистами → интервью с командой → тестовое задание (опционально) → повторное интервью → оффер.

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

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

В результате сели за круглый стол: я, команда, рекрутер. И нарисовали схему:

• Как идет процесс
• Кто за что отвечает
• Какие максимальные сроки у нас заложены под каждый этап

Решили, что если накапливается определенное количество нерассмотренных кандидатов, то рекрутер пишет в общий чат и не стесняется нас «пинать»

Если кандидат нереально хорош, то эйчар может отправить сразу ссылку на вакансию — «кандидат горящий, важно не потерять!»

Когда мы это сделали — все зависания исчезли. Главное принять, что рекрутер тут — «пинатель», это его работа и не стоит на него за это злиться.

А еще от зависаний нас спасает сервис из экосистемы hh.ru —

Кандидаты у нас долго не залеживаются, поэтому приложил скриншот из соседнего отдела:

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

Шаг номер 1. Знание — сила!

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

Про тимлидство существуют сотни статей, видео, книг, курсов и т.д. Фильтровать нужно тщательно.

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

• М. Уоткинс «Первые 90 дней». Хорошая и вдумчивая книга о том, как успешно адаптироваться к переходу на новую должность. Чем заняться в первые 90 дней. И о том, что эта адаптация, как системный процесс, нужна не просто конкретному индивиду, а всей компании в целом.

• Дж. Ханк Рейнвотер «Как пасти котов». Книга для начинающих или будущих управленцев вполне хороша и толкова (пусть и немного стара). Однако для людей с опытом, наверное, будет немного кэпской.

• Ф. Брукс «Мифический человеко-месяц». Расскажет об управлении проектами: как надо, как не надо, и почему 9 женщин за 1 месяц не смогут родить ребенка. Есть мнение, что книга несколько устарела, тем не менее, если вы в этом не очень разбираетесь, то она обогатит вас полезными идеями.

• Э. Голдратт. «Цель. Процесс непрерывного совершенствования». Классический художественный роман, объясняющий на разных примерах теорию ограничения систем. Чтиво интересное и полезное. 

• Д. Ким, К. Бер, Д. Спаффорд. «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему». Очень интересная и поучительная книга, которая в художественном формате рассказывает о том, как в ИТ подразделении улучшают процессы работы, приходят к DevOps идеологии и спасают бизнес.

• Т. ДеМарко «Deadline. Роман об управлении проектами». Еще одна книга в художественном формате. Легкое и интересное чтение об управлении ИТ проектами.

• Т. ДеМарко, Т. Листер «Вальсируя с Медведями». Порекомендовал бы эту книгу для средних и крупных проектов. Излечивает от наивности, открывает глаза на происходящее. Показывает, что случиться может много чего и рассказывает, как с этим жить и работать.

• М. Дорофеев «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо». Книга не про программирование, но программистам, тимлидам, менеджерам точно пойдёт на пользу. Очень толковая книга по личной эффективности, организации задач и т.п. Всем настойчиво рекомендую.

• М. Ильяхов, Л. Сарычева «Новые правила деловой переписки». Замечательная книга. Смело её рекомендовал бы и разработчикам, и менеджерам, и вообще примерно всем. О том как в переписке быть толковым, уважительным, приятным и эффективным. Очень многим этого не хватает.

• А. Орлов «Джедайские техники конструктивного общения». Коротко, по делу, с примерами. Однозначно рекомендую. И в работе пригодится, и в быту.

• М. Гоулстон «Как разговаривать с мудаками». Книга придаёт понимание того, что не все проблемные отношения и коммуникации можно разрешить рациональными доводами, и что делать в таких случаях. Ну и о себе можно задуматься тоже:)

• Роадмап тимлида https://tlroadmap.io/ Очень полезный инструмент, который поможет разобраться, какие бывают требования к тимлидам, понять, что с ними делать и как подтягивать свои знания. Также подойдет как хороший инструмент для того, чтобы обговорить со своим руководителем на начальном этапе работы, что же конкретно от вас ожидается.

• Курсерный курс https://www.coursera.org/specializations/product-management Долгий и основательный курс, который покрывает всё про управление проектами. Выявление требований, план рисков, декомпозиция и распределение задач, аджайл техники и прочее. Вы справедливо можете заметить, что этот курс нужен менеджерам проектов, а не тимлидам. Теоритечески — да, а на практике возможно, что если у вас менеджер проекта и есть, то в каких-то деталях он может не очень разбираться. Тогда понадобится ваше участие.

• Регулярные двухнедельные тимлидские конференции от ребят из подкаста Podlodka https://podlodka.io/tlcrew Там много хороших докладов и душевное отзывчивое комьюнити, с которым можно порой пообсуждать в деталях то, за что обычно деньги берут на платных индивидуальных консультациях.

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

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

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

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

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

Подбор: заместитель

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

1. Насколько легко он адаптируется к совершенно незнакомому типу нагрузки (а гибкость и скорость адаптации — одни из ключевых навыков менеджера, как мне кажется), как организуется его личная работа, успевает ли он всё сделать, если не успевает, рассказывает ли руководителю о проблемах (есть ли прозрачность).
2. Насколько тщательно он выполняет рутинную работу: достаточно ли у него въедливости и внимательности для этого, или придётся вкладывать ресурсы в коучинг и в этой области. Работа руководителя всегда подразумевает в том числе и рутинные действия. Но некоторым людям они даются очень трудно, приходится буквально себя заставлять. Если человек не может справляться с рутинными действиями даже в течение недолгого периода времени, возможно, это тоже негативный фактор, который стоит учитывать.
3. Уровень неформального лидерства в команде: отличается ли то, как работает человек в роли заместителя, от того, как он работал на проектной работе. Видно, как воспринимают его другие сотрудники.

Обязанности

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

• Заключение договора с клиентом, обсуждение всех деталей, поиск компромисса.
• Работа с договорами, различной документацией.
• Производить оценку обьемов и масштаба работ, бюджета, сроков выполнения работ.
• Расставление приоритетов, планирование больших и маленьких задач.
• Делегирование полномочий внутри коллектива таким образом, чтобы получить максимальную эффективность.
• Планирование релизов и своевременный их выпуск.
• Функции продюсера в управлении проектом, дизайнерские работы, грамотный маркетинг, разработка.
• Общительность, и налаживание контактов с каждым сотрудником, мотивирование персонала, обеспечение профессионального роста каждого.
• Мотивация, нужно показывать все на своем примере, быть образцом для своих сотрудников.
• Умение переделать бизнес-идею руководства в техническое задание для разработчиков.
• Ответственность за качество проекта, технологию его реализации.
• Написание ревью кода.
• Тестирование, проверка проекта, разработка его дизайна.
• Уметь понять и разобраться в поломке, при надобности – усовершенствовать проект.
• Написание технической документации.
• Участие в процессе формирования команды.
• Программирование архитектуры.
• Выбор наиболее подходящей и эффективной технологии для рабочего задания.
• Обьяснение общих идей каждому сотруднику команды.
• Выбор исполнителя из команды, подходящего для определенной задачи.
• Выгружать изменения на сервер.
• Обмен опытом между членами команды, с целью повышения эффективности, понимания и навыков.
• Оптимизация работы, проведение внутрикомандных совещаний.
• Ведение отчетов перед заказчиками в течении всего этапа проведения работа.
• Контролировать проект на предмет его соответствия заданным техническим параметрам.
• Оценка и поддержка предложений от других участников проекта.

Личностные качества:

• Аналитический состав ума
• Ответственность
• Пунктуальность
• Трудолюбие
• Дипломатичность
• Инициативность
• Нахождение простых способов решения сложных заданий
• Техническая грамотность (владение серверными технологиями и дистрибутивами)
• Нацеленность на результат
• Быстрое принятие решений в сложных ситуациях.