Я хочу рассказать о том, кто такие тимлиды и какой перед ними стоит пул задач. Материал для тех, кто планирует развиваться в этом направлении, но не до конца понимает, что его ждет.
Я Миша Шпаков — тимлид команды разработчиков в Timeweb. Точнее одного из продуктов компании — VDS. Компания известна предоставлением хостинговых услуг, но время идет, все обновляется, и сейчас она выходит на новый уровень — этого же требует и от сотрудников.
Мою работу в двух словах можно описать как «профессиональное делегирование». Timeweb – это большая компания, по большей части состоящая из разработчиков. При этом каждый участник команды выполняет определенную задачу. Я распределяю задачи между разработчиками, налаживаю рабочий процесс и помогаю решать проблемы по мере их возникновения.
Тут надо отметить, что в разных компаниях должность тимлида включает в себя разный набор обязанностей. За свою карьеру я встречал несколько тимлидов, которые 99% времени писали код, и им в нагрузку давали какие-то менеджерские задачи. А в некоторых компаниях тимлид, наоборот, выполняет больше задач проджект-менеджера, меньше времени уделяя коду.
К примеру, в мою зону ответственности, помимо распределения задач и контроля сроков их выполнения, входит мотивация сотрудников и решение кросс-командных задач. Также в Timeweb я отвечаю за архитектуру VDS с точки зрения написания кода.
Тимлид работает с людьми, поэтому в первую очередь важны софт-скиллы. Нужно уметь коммуницировать и находить подход к коллегам, балансировать между бизнесом и разработкой, искать компромиссы.
В целом, нужно уметь объективно воспринимать информацию извне, анализировать ее и использовать в угоду эффективности всей команды.
Также в обязанности тимлида входит декомпозиция крупных задач на более мелкие для их дальнейшего распределения между разработчиками. Качество выполнения мелких и четко поставленных задач легче адекватно оценивать.
От тимлида во многом зависит успех всей команды, так как я выбираю техническое решение, которое будет выгодно бизнесу в перспективе, я назначаю сроки выполнения задач для разработчиков, я же отвечаю за качество итогового продукта.
Тимлидом я стал еще на предыдущем месте работы. Я дошел до определенного уровня развития и пришел к начальству, чтобы наметить дальнейшие пути роста. Мне предложили попробовать заняться менеджментом, и мне это понравилось.
Многие отмечают, что работа тимлида подразумевает гору ответственности и невозможность самостоятельно внести изменения в код. Приходится часто полагаться на других людей.
Да, моя текущая деятельность не похожа на работу программиста, но в ней тоже есть свой интерес. Ты видишь продукт более цельно. Не занимаешься отладкой конкретных кусков кода, а видишь готовое масштабное решение со всех сторон.
Круто видеть, как продукт постепенно превращается во что-то полноценное и выходит на рынок.
При этом я продолжаю заниматься разработкой параллельно. На это уходит примерно четверть всего рабочего времени, но при необходимости это соотношение всегда можно пересмотреть. Так что проблем с точки зрения отставания в развитии как специалиста я не наблюдаю, потому что выбрал путь развития вширь, постепенно увеличивая охват своей зоны компетенции, если можно это так назвать.
Я сознательно пришел к этой должности.
Идеальная команда для тимлида — это группа опытных программистов, которые компетентны в своей области и которым можно задавать вопросы, касающиеся технических аспектов. Поэтому, как мне кажется, тимлид необязательно является самым скилловым разработчиком в команде.
В любом случае найдется кто-то более умный, более опытный, более продвинутый и так далее. И синдрому самозванца нельзя позволять себя как-то дезориентировать. Нужно его принять и продолжать работать.
Многие видят всю нашу сферу деятельности как вечное противостояние бизнеса и разработки, где каждый активно лоббирует свои интересы, игнорируя чужие.
И тут важно правильно соблюсти баланс в зависимости от предметной области и от того, на каком этапе развития находится бизнес. Приходится приспосабливаться, уделяя больше внимания тому или иному аспекту. Приходится плыть где-то посередине, регулярно отыскивая компромиссные решения.
Ведь разработчики не существуют сами по себе, зачастую они выступают поддержкой для бизнеса, поэтому следование его интересам нередко остается в приоритете. На этом моменте должность тимлида превращается в должность некоего медиатора, пытающегося донести до обеих сторон их интересы и «урегулировать вопросы» между бизнесом и командой разработчиков. Грубо говоря, объяснить, почему сейчас важно «реализовать функцию на костылях и быстро», а не «пилить еще месяц, чтобы сделать красиво и на века». Или же объяснить бизнесу, почему нужно переосмыслить задачу или перенести сроки ее выполнения.
Собрал список того, что нужно почитать
Конкретные сайты и книги по деятельности тимлида я бы советовать не стал, потому что в разных компаниях меняется отношение к этой должности. Как я уже и говорил, везде свой набор обязанностей и разное соотношение работы с кодом и руководством. Да и литература как таковая не особо поспевает за тенденциями. Лучше читать статьи в интернете. Они более релевантны.
Почитать советую:
Тимлид — это не единственный этап развития для программиста. Уходить в руководство вовсе не обязательно, есть и другие пути. Но конкретно этот сильно расширяет кругозор, вынуждает более открыто смотреть на мир и дает возможность совсем иначе взглянуть на то, как устроена разработка для бизнеса.
Посмотреть полную версию разговора с Мишей можете здесь:
Слушайте в аудио: it.mave.digital/ep-2
Timeweb, в котором мы общаемся с представителями айтишных профессий и разбираемся, чем они занимаются, какие навыки для этого нужны и что им доставляет удовольствие в работе больше всего.
Давайте знакомиться
Я Миша Шпаков — тимлид команды разработчиков в Timeweb. Точнее одного из продуктов компании — VDS. Компания известна предоставлением хостинговых услуг, но время идет, все обновляется, и сейчас она выходит на новый уровень — этого же требует и от сотрудников.
Чем я занимаюсь
Мою работу в двух словах можно описать как «профессиональное делегирование». Timeweb – это большая компания, по большей части состоящая из разработчиков. При этом каждый участник команды выполняет определенную задачу. Я распределяю задачи между разработчиками, налаживаю рабочий процесс и помогаю решать проблемы по мере их возникновения.
В чем разница между тимлидом и проджект-менеджером
Тут надо отметить, что в разных компаниях должность тимлида включает в себя разный набор обязанностей. За свою карьеру я встречал несколько тимлидов, которые 99% времени писали код, и им в нагрузку давали какие-то менеджерские задачи. А в некоторых компаниях тимлид, наоборот, выполняет больше задач проджект-менеджера, меньше времени уделяя коду.
К примеру, в мою зону ответственности, помимо распределения задач и контроля сроков их выполнения, входит мотивация сотрудников и решение кросс-командных задач. Также в Timeweb я отвечаю за архитектуру VDS с точки зрения написания кода.
Какие навыки мне нужны
Тимлид работает с людьми, поэтому в первую очередь важны софт-скиллы. Нужно уметь коммуницировать и находить подход к коллегам, балансировать между бизнесом и разработкой, искать компромиссы.
В целом, нужно уметь объективно воспринимать информацию извне, анализировать ее и использовать в угоду эффективности всей команды.
Также в обязанности тимлида входит декомпозиция крупных задач на более мелкие для их дальнейшего распределения между разработчиками. Качество выполнения мелких и четко поставленных задач легче адекватно оценивать.
От тимлида во многом зависит успех всей команды, так как я выбираю техническое решение, которое будет выгодно бизнесу в перспективе, я назначаю сроки выполнения задач для разработчиков, я же отвечаю за качество итогового продукта.
Почему я стал тимлидом
Тимлидом я стал еще на предыдущем месте работы. Я дошел до определенного уровня развития и пришел к начальству, чтобы наметить дальнейшие пути роста. Мне предложили попробовать заняться менеджментом, и мне это понравилось.
Многие отмечают, что работа тимлида подразумевает гору ответственности и невозможность самостоятельно внести изменения в код. Приходится часто полагаться на других людей.
Да, моя текущая деятельность не похожа на работу программиста, но в ней тоже есть свой интерес. Ты видишь продукт более цельно. Не занимаешься отладкой конкретных кусков кода, а видишь готовое масштабное решение со всех сторон.
Круто видеть, как продукт постепенно превращается во что-то полноценное и выходит на рынок.
При этом я продолжаю заниматься разработкой параллельно. На это уходит примерно четверть всего рабочего времени, но при необходимости это соотношение всегда можно пересмотреть. Так что проблем с точки зрения отставания в развитии как специалиста я не наблюдаю, потому что выбрал путь развития вширь, постепенно увеличивая охват своей зоны компетенции, если можно это так назвать.
Я сознательно пришел к этой должности.
Работа тимлидом в команде
Идеальная команда для тимлида — это группа опытных программистов, которые компетентны в своей области и которым можно задавать вопросы, касающиеся технических аспектов. Поэтому, как мне кажется, тимлид необязательно является самым скилловым разработчиком в команде.
В любом случае найдется кто-то более умный, более опытный, более продвинутый и так далее. И синдрому самозванца нельзя позволять себя как-то дезориентировать. Нужно его принять и продолжать работать.
Как совместить бизнес и разработку
Многие видят всю нашу сферу деятельности как вечное противостояние бизнеса и разработки, где каждый активно лоббирует свои интересы, игнорируя чужие.
И тут важно правильно соблюсти баланс в зависимости от предметной области и от того, на каком этапе развития находится бизнес. Приходится приспосабливаться, уделяя больше внимания тому или иному аспекту. Приходится плыть где-то посередине, регулярно отыскивая компромиссные решения.
Ведь разработчики не существуют сами по себе, зачастую они выступают поддержкой для бизнеса, поэтому следование его интересам нередко остается в приоритете. На этом моменте должность тимлида превращается в должность некоего медиатора, пытающегося донести до обеих сторон их интересы и «урегулировать вопросы» между бизнесом и командой разработчиков. Грубо говоря, объяснить, почему сейчас важно «реализовать функцию на костылях и быстро», а не «пилить еще месяц, чтобы сделать красиво и на века». Или же объяснить бизнесу, почему нужно переосмыслить задачу или перенести сроки ее выполнения.
Собрал список того, что нужно почитать
Конкретные сайты и книги по деятельности тимлида я бы советовать не стал, потому что в разных компаниях меняется отношение к этой должности. Как я уже и говорил, везде свой набор обязанностей и разное соотношение работы с кодом и руководством. Да и литература как таковая не особо поспевает за тенденциями. Лучше читать статьи в интернете. Они более релевантны.
Почитать советую:
- Хабр, это по стандарту.
- Timeweb Community.
- Tproger — хороший ресурс.
- Из зарубежных отмечу Medium.
- Профильные Telegram-каналы в духе «Типичный тимлид».
Заключение
Тимлид — это не единственный этап развития для программиста. Уходить в руководство вовсе не обязательно, есть и другие пути. Но конкретно этот сильно расширяет кругозор, вынуждает более открыто смотреть на мир и дает возможность совсем иначе взглянуть на то, как устроена разработка для бизнеса.
Посмотреть полную версию разговора с Мишей можете здесь:
Слушайте в аудио: it.mave.digital/ep-2
Timeweb, в котором мы общаемся с представителями айтишных профессий и разбираемся, чем они занимаются, какие навыки для этого нужны и что им доставляет удовольствие в работе больше всего.
