Где найти и как выбрать тимлида

Интро: структура разработки и процесс обеспечения качества в Miro

Вся продуктовая разработка поделена на направления — стримы. Все стримы кросс-функциональные и кроме разработчиков в стримы входят и другие функции: аналитика, маркетинг, продакт, дизайн. Каждый стрим развивает часть продукта, объединённую общей идеей. Например, Growth стрим — это команды, которые работают над ростом продукта. Или Platform стрим — команды, которые разрабатывают публичную платформу и SDK. Есть стрим Stability and Scalability, команды в котором создают инструменты для доставки, инфраструктуры и обеспечения качества. Здесь разрабатываются системы для автотестирования. Все QA лиды и инженеры пользуются результатами работы этого стрима.

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

Например, практически с каждой Scrum командой работает выделенный QA инженер, который руководствуется ценностями Agile-тестирования:

«Testing throughout over testing at the end». Тестирование — это не дополнительный этап, а часть каждого этапа разработки.

«Preventing bugs over finding bugs». Процесс обеспечения качества в первую очередь направлен на предотвращение ошибок, а не на их эффективный поиск. Но это не значит, что процесс поиска ошибок нужно исключить.

«Testing understanding over checking functionality». Мы в первую очередь обеспечиваем качество продукта, а не только производим проверку на соответствие требованиям. 

«Building the best system over breaking the system». У нас нет цели найти все ошибки — мы фокусируемся на предотвращении и поиске важных. Ошибки, что встречаются крайне редко, можно пропустить, потому что их поиск будет очень дорогим.

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

Подробнее процесс обеспечения качества описан в статье.

Текущие конфликты

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

А вот иррациональные конфликты или полный штиль  –  повод присмотреться.

Как искать? Конструктивные искать обычное не нужно, участники сами готовы привлекать внимание к проблеме и погружать в нее. Скрытые –  встречами, вопросом «а что еще ты думаешь?», внезапно открывающим поток мыслей, которые человек не знал когда будет уместно выразить, поиском причин, по которым человек не может выразить свою мысль открыто 

Используйте рекрутинговое ПО

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

Контролировать сроки. Например, вы решили воспользоваться советами из этой статьи и прописали сроки и зоны ответственности. Кто будет это контролировать? В экосистеме компании Headhunter есть облачная CRM для рекрутинга Talantix, где можно прописать сроки для каждого из этапов воронки, например, «проверка резюме техническим специалистом» — до 4 дней. Если есть задержка, система сама о ней напомнит — это удобно и рекрутеру, и нанимающему руководителю.

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

Анализировать наём на достоверных данных, а не по наитию. Огромный плюс Talantix — аналитика: вы можете просмотреть статистику по каждому рекрутеру за разные периоды. При этом видно воронку: на каких этапах и почему «отваливаются» кандидаты.

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

С помощью CRM-системы тимлид видит подбор как на ладони в режиме 24/7, может зайти с компьютера, телефона или другого устройства. Всё это освобождает от горы документов в почте и сообщений в мессенджерах, а значит — ещё проще интегрировать наём в рабочий процесс.

Уйти (,) нельзя (,) остаться: трудный выбор коллектива

Вы доросли до того момента, когда приняли решение двигаться дальше, и устроились на новое место с повышением. Другая ситуация: руководство на текущем месте отметило ваши заслуги и решило вверить вам подразделение. В назначенный день вас представляют всем сотрудникам и торжественно произносят: «У вас новый руководитель, просим любить и жаловать». Страшно?

Тут возможны две кардинально противоположные ситуации:

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

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

Я не буду заострять внимание на этом варианте — он достоин отдельной истории. Кратко дам советы

Читайте литературу по психологии, управлению, менеджменту. Пробуйте, ошибайтесь и пытайтесь вновь. Главное — оставаться человеком в любой ситуации, это вернется. Это как учиться плавать: если на середину пруда выплыл — отлично, умеешь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обучающий стиль

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

Мы верим в то, что сможем достигать крутых результатов, если будем развивать индивидуальные навыки своих сотрудников. Для этого каждые полгода мы проводим performance review. Оно включает в себя отзывы от коллег, self-review и 1-1 с руководителем для рефлексии. После этого мы составляем план на полгода таким образом, чтобы сотрудник знал, что ему делать для улучшения своих навыков. Каждый пункт этого плана является целью и ставится по фреймворку SMART. Например, если одной из целей является крупный рефакторинг, то мы определяем definition of done этого рефакторинга. Так он станет конкретным и измеримым. Планируем объём работ: реально ли закончить этот рефакторинг за 3-6 месяцев? И думаем о том, какую пользу он принесет компании.

Девиз обучающего стиля

Дополнительные материалы

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

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

  • Матрица доверие-прозрачность https://t.me/general_it_talks/78

  • Ситуационное лидерство https://t.me/general_it_talks/59

  • Чайка-менеджмент, микроменеджмент https://t.me/general_it_talks/28

  • Обучение, приоритеты и иллюзию компетентности в этом деле https://t.me/general_it_talks/60 https://t.me/general_it_talks/41 https://t.me/general_it_talks/116

  • Овертаймы и подбор темпа работы https://t.me/general_it_talks/42 https://t.me/general_it_talks/61

  • Теория разбитых окон https://t.me/general_it_talks/48

Кому не подходит должность

Считаете, что вы способны возглавить команду? Будьте осторожны со своими амбициями, так как не каждый разработчик с организаторскими способностями может стать успешным тимлидом. Тщательно взвесьте свои возможности, чтобы не навредить проекту и не испортить отношения с сотрудниками.

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

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

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

Описание должности

Кто такой тимлид и чем он занимается? Само название имеет английское происхождение (team leader – «лидер команды»). Этот человек – координатор команды разработчиков. Он определяет сферы ответственности своим подчиненным и контролирует их работу, организовывает обучение и обеспечивает возможности профессионального роста для специалистов, а также ведет переговоры с заказчиком.

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

Кроме непосредственно профессиональных, на тимлида возложены функции менеджера:

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

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

Team leader – не только менеджер и продюсер, но и один из лучших программистов. Его деятельность, кроме управленческих задач, предполагает участие непосредственно в разработке проекта. Ему надо постоянно держать руку на пульсе: знать, на какой стадии находится работа в данный момент, рассматривать все предложения членов команды, аргументированно принимать их или же отвергать.

Технические задачи тимлида:

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

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

Общее в инструментах

Удивительно, насколько схожи инструменты работы тимлида и психолога тоже схожи. Вот они. 

Эмпатия

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

И психологу, и тимлиду нужно быть эмпатичным и применять эмпатию в работе

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

Заметили, что я сказала «в работе»? Конечно, не только в работе эмпатия пригодится, но не надо проявлять эмпатию к каждому встречному-поперечному. Если к вам бабушка в метро подсела и начала жаловаться на жизнь, вы не обязаны включать эмпатию. А если поедете специально в дом престарелых, чтобы навестить одиноких стариков, туда свою эмпатию везите обязательно.

Искренность

Искренность в том, что и для чего я делаю. 

У меня был такой кейс: меня пригласил руководитель поработать с темой выгорания, work-life баланса, говоря, что его команда постоянно перерабатывает. Оказалось, что руководитель сам постоянно перерабатывает, по ночам пишет письма сотрудникам, не ходит в отпуск – такой многозадачный человек. При этом своей команде он говорит: «Вы должны следить за балансом, должны не перерабатывать, саморефлексией заниматься». И в этом есть неискренность: он ставит такие условия, которые сам не соблюдает. 

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

Уверенность

Важно не путать с самоуверенностью. Уверенность в том, что я делаю, в том, какие задачи я ставлю, как я их ставлю. Это очень сопряжено с вопросом личной ответственности. 

Это очень сопряжено с вопросом личной ответственности. 

Личная ответственность в работе руководителя и в работе психолога – это базис самоощущения себя в профессии. Например, многим тимлидам свойственно устранятся от неудобных увольнений. А когда руководитель боится взять на себя ответственность за увольнение сотрудника, происходит внутренний дисбаланс, внутренний конфликт. И если начинают задавать вопросы, тимлид порой встаёт в позицию самозащиты и говорит: «Ну слушайте, мне пришлось его уволить, меня заставили, техдир сказал, что если не уволю, то буду плохим руководителем». 

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

И это моя ответственность перед клиентом, у меня должна быть уверенность в том, что я делаю

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

Готовность получить обратную связь

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

Место работы

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

Обучение

Получить образование, чтобы потом работать тимлидом, можно в различных российских вузах по таким специальностям:

  • Бизнес-информатика
  • Информатика и вычислительная техника
  • Математика
  • Цифровая экономика
  • Прикладная информатика в области обработки данных.
  • Автоматизированные системы обработки информации и управления
  • Электронный бизнес
  • Технологии программирования
  • Разработка программно-информационных систем
  • Информационные ресурсы и сервисы
  • Управление разработкой программных проектов.
  • Информационные системы и базы данных
  • Программная инженерия
  • Открытые информационные системы
  • Программное обеспечение мобильных систем и приложений
  • Фундаментальная информатика и информационные технологии.
  • Корпоративные информационные системы управления.
  • Когнитивные технологии
  • Информационное обеспечение автоматизированных систем.

Заведите личные карточки

План развития.

  • что должен уметь сотрудник к определённому моменту времени;
  • с какими задачами он должен справляться и на каком уровне;
  • какие области ответственности должен закрывать.
  1. Первый аргумент против карточек высказывал я сам: до определённого момента я думал, что буду держать всё в голове, потому что я же тимлид, я могу! Но количество навыков, планов развития и областей ответственности росло вместе с размером команды. Уровень ответственности слишком высок, чтобы полагаться только на свои память и интуицию. Поэтому я завёл карточки. 
  2. «Это слишком сложно!». Ответ на это очень простой: не надо усложнять! Не стоит перечислять 100500 навыков и расписывать план развития каждого сотрудника на 25 страниц. Оставьте только те сведения, которые реально необходимы. 
  3. «Ведение карточек занимает слишком много времени». Я решил проверить этот тезис на себе. Разумеется, с секундомером не сидел, но у меня получилось что-то около часа в месяц на всю команду из пяти человек.
  4. «Невозможно формализовать рост людей». Да, невозможно формально описать развитие человека — это многогранный и очень непростой процесс. И карточки — это как раз то, что помогает мне подходить к нему чуть более осознанно. Ещё раз: именно помогает, а не заменяет собой всю работу. 

Как понять, какой из стилей предпочтителен для вас

Это самый трудный вопрос, ответ на который вам придется найти самостоятельно. Отведите себе время на рефлексию после прочтения статьи.

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

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

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

Перспективы должности

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

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

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

Как проходит рабочий день руководителя группы разработки

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

10:00 — Вы встречаетесь с менеджером проекта или непосредственно заказчиком, обсуждаете рабочие моменты, вносите правки в уже существующие наработки и договариваетесь о дедлайне для сдачи следующего черновика проекта. 

12:00 — К вам в компанию пришли устраиваться новые программисты, поэтому вы принимаете участие в их собеседовании и делитесь своими впечатлениями с  HR отделом. Ваша команда пополнилась двумя джунами. Начинают работать уже сегодня! Вы проводите им экскурсию по отделу, знакомите их с коллегами и показываете рабочие места. Затем даете новичкам несложные задания и смотрите, как они справляются с ними в течение дня.

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

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

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

Где искать

С должностью тимлида ситуация как и с другими ИТ-вакансиями: спрос намного превышает предложение.

Хабр

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

Есть два основных варианта: 

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

ИТ-конференции 

Самое удачное место для деловых знакомств. HR может представить команду, рассказать о компании и найти ценных кандидатов.

Кадровое ИТ-агентство

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

Оставляйте заявку на нашем сайте (ссылка на главную) — мы поможем найти классного специалиста.

Остались вопросы?

Как становятся Team Leader

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

Хобби

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

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

Есть какие-нибудь pet-проекты по разработке?

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

На этом закончилось наше интервью с руководителем направления разработки в Lamoda Александром Афеновым.

Приведите в порядок встречи один на один

Пример формата записи результатов и договорённостей по итогам встречи

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector