Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Тимлид - одна из ключевых для новичков фигур в команде. Этот специалист участвует в найме, организует онбординг - включает джунов в работу, следит за работой нового специалиста на испытательном сроке. То есть тимлид - один из тех, от кого зависит успешное трудоустройство новичка и его интеграция в команду. Подробнее об этом поговорили с<a>Дмитрием Матвеевым</a>, тимлидом компании<a>Evrone</a>.

2 Дмитрий Дементий: Расскажите, пожалуйста, о себе. Кто вы и чем занимаетесь?

3 Дмитрий Матвеев: В разработке с 2008 года. Преподавал в университете прикладную информатику, программирование на C++ и C#. Потом ушел в коммерческую веб-разработку. Начал с PHP, а в 2008 году перешел на Ruby On Rails.

4 С 2012 года работаю тимлидом. Делал проекты на аутсорсе. Собрал команду, в которой есть как опытные разработчики, так и джуниоры. В том числе есть опыт привлечения в проект студентов.

5 С 2015 года сотрудничаю с Evrone. Летом преподаю в IT Лаборатории (<a>проект пензенского IT сообщества</a>).

6 Д.Д.: Какой стек технологий использует в работе ваша команда?

7 Д.М.: Разрабатываем на Ruby on Rails.

8 <h2>Содержание</h2>

9 <ul><li><a>Кто такой тимлид и как он работает</a></li>

10 <li><a>Какую роль играет тимлид в найме и адаптации сотрудников</a></li>

11 <li><a>Что тимлид хочет от кандидатов на позицию джуниора</a></li>

12 <li><a>Заключение: об идеальной системе обучения и профессиональном росте</a></li>

13 </ul><h2>Кто такой тимлид и как он работает</h2>

14 Д.Д.: Вопрос, ответ на который нужен начинающим специалистам: кто такой тимлид, чем он занимается?

15 Д.М.: В команде может быть тимлид и проектный менеджер (проджект-менеджер). Роль этих специалистов варьируется в зависимости от организации процессов в конкретной компании.

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

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

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

19 Д.М.: Попробую описать процесс на примере рабочего дня. С моей точки зрения, краеугольный камень эффективности тимлида и команды в целом - daily meeting или ежедневный созвон. Во время митинга тимлид и участники команды синхронизируются. Это элемент организации процессов.

20 Следующий важный этап работы тимлида в течение дня - анализ задач. Он общается по каждой задаче с business owner. Это может быть заказчик или представитель заказчика. на этом этапе тимлиду нужно проработать путь решения задачи с учётом интересов бизнеса.

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

22 В течение дня тимлид помогает разработчикам решать их текущие задачи. Речь идёт о рабочих вопросах по коду. Условно говоря, когда джуниор не может что-то сделать, в игру вступает лидер команды. Он помогает новичку сделать так, чтобы<a>тесты позеленели</a>(и чтобы тесты в принципе появились :). Можно сказать, что тимлид играет роль той самой уточки, после общения с которой разработчик находит способы решения задачи.

23 Если обобщить, лидер планирует работу команды на несколько шагов вперёд, отвечает на вопросы "почему сделать" и "как сделать".

24 <h2>Какую роль играет тимлид в найме и адаптации сотрудников</h2>

25 Д.Д.: Какова роль тимлида в найме сотрудников? Чем он занимается: рекрутинг, собеседования, онбординг новичков? Если в компании есть HR, как тимлид с ним взаимодействует?

26 Д.М.: Роль в найме зависит от конкретной компании. В идеале тимлид активно участвует в поиске, отборе и адаптации новичков. Более того, он планирует усиление команды, даёт заказ на поиск новых специалистов, когда понимает, что новички нужны для решения задач.

27 Если в компании есть HR, он проводит первичную фильтрацию кандидатов. Если эйчара нет, первичный отбор берёт на себя тимлид. Кандидат встречается с тимлидом на втором или даже на первом собеседовании.

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

29 Д.Д.: Как тимлид планирует работу команды? Планирование происходит сверху (вы говорите, что Джон на этой неделе делает то и это, а Джек это и то) или снизу (Джон и Джек предлагают план, а вы контролируете)?

30 Д.М.: Иногда тимлид распределяет роли и задачи, хоть это и противоречит scrum. Это происходит, когда такое распределение очевидно и не вызывает значимых конфликтов в коллективе. Но в основном участники команды, включая начинающих разработчиков, сами определяют приоритетные задачи и распределяют роли.

31 Д.Д.: О контроле: как тимлид контролирует рядовых разработчиков? Выполненные задачи, качество кода, другие аспекты.

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

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

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

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

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

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

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

39 Д.Д.: Должен ли тимлид заботиться о росте сотрудников? Например, есть в команде джуниоры. Они должны учиться и прогрессировать. Этот процесс должен идти снизу (от джунов) или сверху (от тимлида)?

40 Д.М.: Если сотрудник не прогрессирует, виноват тимлид. Это аксиома. Развитие разработчиков - зона прямой ответственности лидера команды. Важно понимать, что необходимо обоюдной желание развиваться. Если у сотрудника такого желания нет, тимлид не поможет.

41 <h2>Что тимлид хочет от кандидатов на позицию джуниора</h2>

42 Д.Д.: Вернёмся к найму. Вам нужны разработчики. Какие требования вы предъявляете к кандидатам? Понятно, что это сильно зависит от проекта, но можно попробовать обобщить.

43 Д.М.: Сначала отвлекусь, чтобы объяснить свою позицию. Я считаю, что реализованные проекты делают человека разработчиком уровня middle. У миддлов есть баланс качеств. С одной стороны, это самостоятельные разработчики. Они могут решать задачи сами. Разработчик уровня junior пока не стал самостоятельной рабочей единицей.

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

45 И о разработчиках уровня senior. Я их определяю так: если человек умнее меня, он senior :)

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

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

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

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

50 <ul><li>беседы на технические темы;</li>

51 <li>тестового задания;</li>

52 <li>совместного написание кода (live coding).</li>

53 </ul>Несколько лет назад я проводил собеседование и потом просил выполнить тестовое задание. Если у кандидата есть коммиты в open source проект, код из которого он может показать - это облегчает задачу с обеих сторон, и тогда в тестовом задании нет необходимости. Если человек нужен срочно, и на длительный формальный процесс найма нет времени, тогда я просто беседую и пытаюсь понять, какие задачи решал и может решить человек. Как пример золотой середины могу привести пример, как это сделано у нас в Evrone: на собеседовании дают небольшое и интересное задание, которое можно сделать за 15 минут, а уже по нему удобно смотреть, как человек мыслит и как привык писать код.

54 Д.Д.: Какие хард-скиллы должны быть у специалиста, чтобы он мог всерьёз претендовать на позицию джуниора? Что нужно уметь?

55 Д.М.: Нужны базовые знания языка и фреймворка, понимание общих принципов DRY и SOLID. Хотя сейчас и принято ругать ООП, но такой подход я считаю несколько инфантильным. На практике знание ООП очень важно. А если добавить к нему понимание функционального программирования, то, наверное, мы говорим уже не о джуниоре, а о состоявшемся и крутом специалисте.

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

57 Д.Д.: Аналогичный вопрос по софт-скиллз. Какие нужны софт-скиллы и как их оцениваете?

58 Д.М.: Человек должен быть адекватным в целом, иметь здравый смысл, не делать фигню. Предполагается, что успешный джун должен понимать и оценивать задачи. Важно, чтобы человек умел задавать вопросы, выбирать приоритеты.

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

60 <blockquote>Полезно читать книги, в том числе художественную литературу.

61 </blockquote>Важный софт-скилл - умение слушать. Ещё человек должен уметь адекватно конфликтовать и договариваться. Под способностью адекватно конфликтовать подразумевается умение отстаивать свою позицию, аргументированно доказывать что-то другим разработчикам и руководителю.

62 Д.Д.: Важные вопросы: пол и возраст. Я слышал, что на Западе есть мода не указывать пол и возраст, чтобы не было дискриминации по этим параметрам. И работодатели, и кандидаты к этому пришли. Как у нас обстоит дело? Есть ли шанс у кандидата 30, 35, 45 лет попасть на позицию джуниора? Есть ли красная черта возрастная? Например, в 34 берём человека, а в 34 и 6 месяцев не берём?

63 Д.М.: Барьеров по полу и возрасту нет. По полу ответ короткий - здесь никаких проблем нет. О возрасте можно порассуждать.

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

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

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

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

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

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

70 Д.Д.: Практикуете ли вы испытательный срок? Если да, на что обращаете внимание во время испытательного срока новичка?

71 Д.М.: Испытательный срок - очень важный инструмент. Это как вопрос гигиены, без него нельзя. Во время испытательного периода обычно выявляются нюансы, которые невозможно отследить и понять ни на одном собеседовании. Бывает так, что люди просто не могут работать вместе в одной команде.

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

73 Д.Д.: Что должен сделать джун, чтобы наверняка не пройти испытательный срок? Здесь не о крайностях типа прогулов или пьяных дебошей на работе, а о рабочих ситуациях. Как вы понимаете, что этот человек не подходит, хоть и старается? И как это понять человеку?

74 Д.М.: Человек не проходит испытательный срок, если регулярно не выполняет поставленные задачи. Если такая ситуация происходит один раз, это нормально. В крайнем случае передаю задачу другому специалисту. Но если ситуация систематически повторяется, то такой боец пока не готов к длительному сотрудничеству с нами.

75 <h2>Заключение: об идеальной системе обучения и профессиональном росте</h2>

76 Д.Д.: По вашему мнению, как выглядит идеальная система обучения программиста? Как и что надо изучать, чтобы стать хорошим специалистом?

77 Д.М.: Идеальной системы обучения нет. В работе и в обучении важна самостоятельность. Специалист должен понимать, что его код будет поддерживать он сам или другие разработчики. Важно читать книги, например, Фаулера. Не бояться код-ревью, учиться читать чужой код.

78 Д.Д.: Что нужно делать новичку, чтобы профессионально расти и продвигаться по карьерной лестнице? Стать тимлидом, например? Что учить, как и где работать?

79 Д.М.: Важно понимать, зачем нужен рост. Позиция тимлида подходит не всем. Если обобщить, разработчик может идти по пути развития хард-скиллз. Тогда он растёт в сторону senior и "архитектора". Второе направление - развитие софт-скиллз. Это развитие в сторону тимлида, менеджера.

80 Тимлид жертвует программированием в пользу общения. Это экстраверт или интроверт, желающий стать экстравертом. Тимлид отвечает за себя и за того парня. Учитывайте это, когда планируете своё развитие.

81 Д.Д.: Дмитрий, спасибо за интересную беседу!

82 Д.М.: Читателям всего хорошего!