Александр Шакун, тимлид в Osome (облачный бэк–офис для предпринимателей):
«Свою задачу вижу в том, чтобы стать максимально ненужным. Буду считать свою миссию выполненной, когда все члены команды будут достаточно прокачаны, чтобы:
- сделать любую задачу в предсказуемый срок;
- провести и эффективно участвовать в любом ивенте (ретро, демо, дейли, whatever);
- эффективно ответить на любой вопрос о продукте со стороны других команд;
- придерживаться общих ценностей.
Конечно, для тимлида к этому добавляется некоторое количество административных обязанностей, таких как найм и мотивация, эти вещи остаются на мне».
Дмитрий Матвеев, тимлид Evrone (команда экспертов в разработке сайтов и приложений на Ruby on Rails, создают проекты для финтеха):
«Для того, чтобы стать тимлидом, разработчику нужно развить в себе менеджерскую оставляющую. Научиться часто переключаться с одной задачи на другую. Научиться распределять и планировать свое время. Уметь просто «на пальцах» объяснить, как работает та или иная функциональность.
Сейчас существует большое количество тренингов. По people–менеджменту, тайм–менеджменту, стресс–менеджменту, конфликт–менеджменту и прочие. Разработчику нужно прикинуть свои сильные и слабые стороны и посетить какой–либо тренинг. Как правило, это занимает не так много времени: в среднем от одного до нескольких дней. В некоторых компаниях, особенно в крупных, есть обучение и развитие сотрудников. Рекомендую им воспользоваться.
Могут помочь не только тренинги, но и профильные конференции. Нужно посмотреть несколько топовых докладов с конференции TeamLeadConf, чтобы иметь представление, с чем придётся столкнуться на позиции тимлида».
Ксения, тимлид в отделе технической экспертизы IBS про 3 качества хорошего тимлида:
«Гибкость. Работы много, и не всегда тимлид видит оптимальное решение. Ему нужно уметь объективно обсуждать с коллегами реализацию задачи, то, как ее лучше сделать. Если он с чем–то не согласен, не должен давить. Объяснить всем, что это за собой повлечет, какие могут быть минусы, какие плюсы у возможных решений.
Еще нужно обладать твердостью в определенном смысле. Потому что, как я говорю, разработчики — люди творческие. Бывает, делают что–то долго, на что–то не соглашаются, могут по–разному вести себя в рамках реализации задачи. Если это влияет на работу команды, на остальных участников, на сроки, то тимлид должен жестко выстроить свою позицию, чтобы проект не пострадал.
Ну и, конечно, обязательно нужно иметь разноплановый бэкграунд, чтобы оценивать результат работы команды. То есть тимлид в идеале вырастает либо из аналитика, либо из разработчика и, соответственно, свои ошибки и успехи в предыдущих проектах он должен помнить и применять на практике».