Что такое быть team leader

Плюсы и минусы профессии

Теперь немного о достоинствах и недостатках профессии:

Возможность реализовать свои лидерские качества

Высокий доход

Востребованность на рынке труда

Общение с разными заказчиками и расширение круга общения

Хорошая площадка для развития карьеры

Отсутствие большой конкуренции,так как хороших тимлидов на рынке недостаточно

Ненормированный рабочий день

Ответственность за команду, а не только за себя

Необходимость постоянно совершенствовать свои профессиональные знания

Нужно постоянно быть в курсе всех вопросов, касающихся проекта

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

Где искать

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

Хабр

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

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

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

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

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

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

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

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

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

Настройте коммуникации

1. Уменьшать входящий трафик, делегируя и автоматизируя. Кстати, про это был классный доклад Алексея Катаева deusdeorum на TeamLead Conf 2019. 
2. Правильно работать с оставшимся трафиком.

Настраиваем почту

«Inbox Zero»1

Удалил совсем неважное.Пример: флуд-рассылка.2. Настроил раздел для неважного сейчас. Пример: Deploy status autoupdate3

Разделил важное на блоки. Пример: «Проблема на продакшене».Пример: «У нас есть классная идея. Давайте обсудим. Что думаете?».

Настраиваем мессенджер

1. Первый и главный — включить уведомления только о личных сообщениях и упоминаниях. 
2. Следить за актуальностью списка комнат/каналов. Лучше оставаться только в тех, где либо вам что-то интересно, либо вы кому-то нужны. Из всех остальных можно смело выходить. 
3. Настроить пуш-уведомления. Если соблюдать первый и второй пункты, то уведомления будут приходить в основном в тех случаях, когда информация каким-то образом вас касается. 
4. Не пренебрегать статусами. Когда необходимо сосредоточиться, очень помогает, например, статус «Не беспокоить». 

Знания и умения

Для успешной работы тимлиду необходимы профессиональные знания и навыки. Ведь он не только руководит командой, но и сам является разработчиком, причем одним из лучших в коллективе. Соответственно, ему надо отлично разбираться в таких IT-«премудростях»:

• MySQL, PHP, JS и различные серверные технологии;
• масштабируемость web-проектов;
• Ubuntu и другие дистрибутивы операционной системы Linux;
• методологии разработки (Agile, Scrum и прочие).

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

Обучение

Уточните планы и ресурсы для обучения в компании. Наблюдайте за тем, как разработчики делится идеями и новостями индустрии. Ваше восприятие обучения зависит от роли и опыта.

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

Популярность этого вопроса дает ощущение осведомленности, но на деле важно синхронизировать понимание между участниками

На что смотреть? На штиль, рябь или волны идей внутри команды. На планы развития.

Какие знания и навыки у него должны быть

Какие личностные качества должен иметь тимлид? Список довольно обширный, но ведь и ответственность у руководителя большая:

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

Teamlead должен иметь минимум 5 лет опыта в IT области. Что потребуется ему для успешной работы:

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

И это список только наиболее важных требований. Работа требует навыков работы с Linux based дистрибутивами, знания Agile, PHP, Scrum, MySQL, JavaScript. Могут еще встречаться условия, имеющие отношение к конкретной сфере работы заказчика.

Какие требования чаще всего звучат в описании вакансии тимлида:

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

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

Самостоятельность

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

Что измерять?

Еще одна интерпретация «рычага власти»

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

Обязанности тимлида

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

В перечень основных обязанностей тимлида входит:

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

Пора программировать

Мы настроили время, коммуникацию, справились с отвлекающими факторами, налили чаёк… И мы парализованы.

У нас антипаттерн – аналитики-паралитики.

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

Как вы думаете, о чём будет думать архитектор нефтекомплекса, когда ему надо чинить трубу? «Пройдет ли этот биметалл эконормы? А как на давление повлияет в сжигателе?» В данном случае архитектор просто не сможет починить эту трубу, потому что не справится с такой когнитивной нагрузкой.

У нас то же самое. Разработка ПО – это комплексная задача. Бизнес-контекст, архитектура, код и прочее. От нас как от тимлидов требуют думать глобально. 

Чтобы решить задачу, я использую подход вокализации действия. У меня над рабочим столом висят карточки, где написаны разные роли – архитектор, аналитик, программист. И я себе говорю, например: «Сейчас я аналитик, мой фокус внимания – не код, а бизнес-контекст» или «Сейчас я программист, я не думаю, как перекрутить требования». Упрощаем себе жизнь, переключаем фокусы внимания. 

Этап развития команды

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

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

Идеальная сферическая команда в вакууме

Скорее вот такой:

Реальная команда в атмосфере компании

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

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

Что с этим делать? В первую очередь это инструмент рефлексии. Не столь важен ответ, сколько попытка построить кривую и попутно понять, что происходило с вами в последние месяцы.

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

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

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

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

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

Демократический стиль

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

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

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

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

Частый ответ на вопрос о странном legacy решении в проекте

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

Подготовка к переносу наработок на предпрод для проверки

1. После выполнения наработок необходимо сделать git pull в текущую ветку из ветки stage (в некоторых случаях master) удаленного основного репозитория и тем самым предотвратить появление конфликтов в удаленном репозитории. Затем пушить ветку с наработками git push в свою же ветку удаленного репозитория 

В принципе — ничего нового в этом пункте нет, стандартное предупреждение и разрешение конфликтов в Git-е. Но тимлиду имеет смысл разъяснить этот пункт, особенно если исполнитель удаленный и еще не привык к общим требованиям. За время, что он работал над задачей — в ветке stage могли появиться изменения от других разработчиков, и безопаснее разрешить конфликты в локальной ветке до того, как очередная порция изменений будет запушена в удаленный репозиторий. 

1. В удаленном репозитории нужно создать мерж реквест в stage на тимлида или старшего на проекте, если он отвечает за сливания. 

Если на текущем проекте есть отдельный чек-лист —  разработчик должен заполнить его, если нет — отметить в комментарии к задаче ссылку на merge request (в некоторых случаях коммит) с наработкой и описанием. Отписать тимлиду или старшему на проекте, если он отвечает за сливания, чтобы проверил работу и принял merge request, либо отправил на доработку. 

1. После того, как все замечания устранены и мерж реквест принят, смотрим работу на основной (тестовой) площадке. 

Про ветки и коммиты

Правила именования веток 

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

ih(os)/номерЗадачи/краткоеОписаниеЗадачи

Ih — значит inhouse, штатный сотрудник 

os — outstaff-подрядчик 

54361 — обязательно указываем номер задачи 

краткоеОписаниеЗадачи — это 2 — 4 слова. 

Пример правильно названной ветки: 

ih/54361/fixCatalogStyles 

В случае, если работа по какой-то причине не привязана к конкретной задаче, именование следующее: 

ih(os)/годмесяц/краткоеОписаниеЗадачи 

Пример альтернативно названной ветки если нет задачи под неё: 

ih/2107/checkoutRefactoring 

Правила именования коммитов

Именование коммита должно отражать суть проделанной работы. В наименовании коммита должен присутствовать номер задачи и номер пункта данной задачи.

Пример: 

«54361-1 import elements to offers iblock»

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

Правила форматирования кода перед выполнения задачи

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

Для того, чтобы избежать этой проблемы, надо: 

• Отформатировать этот файл перед выполнением работ, согласно регламенту написания кода (в PHPStorm можно комбинацией клавиш + + L) и закоммитить, при этом в настройках PHPStorm должны стоять верные настройки PSR и версия PHP. 

• Указать в коммите, что это форматирование 

• Начать выполнять работу только после коммита с форматированием

Правила работы с версткой и стилями 

В нашей компании бэкендеры не правят стили и верстку прямо в back-end минуя исходник верстки. Для работы с версткой используется отдельный репозиторий. Сперва фронтенд-разработчик правит верстку именно в файлах верстки, только потом backend-разработчик ее натягивает. Таким образом исходник верстки всегда актуален.

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

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

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

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

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

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

Перед началом работы

Исторически сложилось, что все свои проекты мы ведем на GitLab и «переезжать» куда-то со своими репозиториями не планируем —  во-первых, это сложно осуществить в рабочих проектах, где много команд, во-вторых нам просто нравится Гитлаб. Если у вас другая система — это не критично, общие требования идентичны. 

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

• Штатные сотрудники компании получают доступ ко всем репозиториям. Подрядчикам мы выдаем доступ к конкретным репозиториям, только на срок реализации проекта. Здесь тимлиду нужно не забыть выставить сроки предоставления доступа, т.к. 101% после сдачи проекта забудем удалить доступ подряда. 

Напоследок хотелось бы поговорить про выбор «программерской роли», когда вы тимлид

Давайте рассмотрим основные роли:

Ключевой разработчик, который делает основную бизнес-логику, разрабатывает ядро продукта.

Если ваша большая команда, времени на это может не быть. Стоит вовремя отдать эту роль, когда команда растет, иначе вы можете превратиться в прототипщика (человек, который пилит прототипы, а доведение проекта до ума оставляет на откуп команде).

«Затыкатель дыр» – человек, который приходит, когда нам чего-то не хватает для полного счастья.

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

Важно не только «затыкать дыры», но и заполнять пробелы новыми сотрудниками

«Еще одни руки» – еще один программист, который просто еще что-то делает – фиксит баги, например.

Этот подход работает, потому что тимлид с такой ролью хорошо знает систему

Тут важно не стать кодерским балластом

И мое любимое – кодерский балласт. Человек, которого лучше бы не было. 

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

Важно признать свою низкую квалификацию и не быть кодерским балластом

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

Для работодателя важна эффективность и качество выполняемой работы. Ему нужен надежный человек, который может самостоятельно решать мелкие проблемы, которому можно было бы доверить проект.

Для этого специалист должен обладать такими личностными качествами, как:

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

До того как специалиста назначат на должность тимлида, он должен проработать в IT-сфере не менее 5 лет, а также иметь следующие навыки и умения:

1. Аналитические способности.
2. Знания серверных технологий.
3. Готовность к самообучению.
4. Умение учитывать мнение команды.
5. Знания масштабируемости веб-проектов.
6. Способность принимать быстрые и простые решения в стрессовых ситуациях.
7. Умение распределять обязанности внутри коллектива.
8. Навыки и умения в программировании на уровне senior.
9. Оценка и планирование бюджета.
10. Умение рассматривать проблему с разных ракурсов.
11. Навыки наставничества.
12. Умение нести ответственность за работу других людей.
13. Знания языков программирования.
14. Способность учитывать риски.
15. Умение заметить и исправить ошибку.
16. Знания планирования задач.
17. Умение планировать, ставить сроки и укладываться в них.
18. Способность сформировать команду, обучать и мотивировать новых сотрудников.
19. Умение переработки требований заказчика в техническое задание.
20. Знания в области психологии, социологии, менеджмента и кадровой политики.
21. Навыки решения конфликтов и поддержания рабочей мирной атмосферы.
22. Умение распределять нагрузку между членами группы.
23. Знания ведения переговоров.
24. Умение проводить тестирование готового продукта.
25. Навыки контроля всех этапов работы.
26. Умение вести документацию.

В этом состоят только основные требования. Остальные могут быть связаны со сферой деятельности заказчика.

Чем занимается тимлид

Тимлид руководит командой разработчиков. Обычно он не пишет код (хотя может). Обычно он не думает об архитектуре (хотя может). 

Тимлид:

• Общается с клиентами или бизнес-подразделениями компании.

• Оценивает задачи, сроки каждого этапа, разбивает их на спринты.

• Распределяет нагрузку между разработчиками.

• Следит за тем, чтобы таски закрывались в срок.

• Оценивает решения разработчиков, дает рекомендации. 

• Согласует с заказчиком готовую работу.

Тимлид несет ответственность за проект. Сроки сорваны – виноват тимлид. Хотите добавить еще фичи – разговаривайте с тимлидом (он скажет, что этот спринт уже заблокирован, но, возможно, в следующем возьмутся за вашу фичу – если сможете ее «продать»).

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

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

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

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

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

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

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

Есть много позиций/уровней, которые близки к тим лиду. Можешь ли пояснить, чем тимлид отличается от сеньора, техлида, продакт менеджера?

В моём понимании:

• Сеньор – это разработчик, которому можно дать задачу и быть уверенным, что он с ней справится без посторонней помощи, даже если задача тяжёлая или нужно «задизайнить» что-то по мелочи.
• Тех лид – тот человек, который понимает каждый аспект работы приложения, делает дизайн приложения, помогает интегрировать различный функционал, пишет техническую документацию по проекту и так далее. Как правило, он имеет глубокие знания в своей технической области (бэкенд/фронтенд/мобильная разработка).
• Продакт менеджер занимается развитием продукта в целом. Он отвечает за анализ рынка, формирование требований к продукту, определение назначения продукта, последующее продвижение и т. д. То есть это вообще другая зона ответственности. Как правило, продакт менеджер работает совместно с тим лидом, для того, чтобы понять возможность реализации той или другой фичи, составлением роудмапа и т. д. 
• Тим лид – это такое связующее звено между всеми 🙂 Он помогает выстраивать процессы в команде, общается с продукт менеджером, понимает потребности бизнеса, и направляет целую команду в правильное русло.

Сколько получают Тимлиды и как найти работу?

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

Так, по Москве уровень зарплаты может достигать 400 тысяч рублей и более, при этом минимальная планка тоже высокая – около 100 тысяч рублей. В других регионах зарплаты гораздо ниже, примерно от 50 до 300 тысяч рублей.

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

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

Давайте теперь подумаем, как бороться с отвлечением и управлять вниманием

В чем проблема борьбы с отвлечением для тимлидов? В том, что классические подходы к тайм-менеджменту – focus time, помидорка, скалирование времени и другие – не работают, если сотрудники не уважают ваше время.

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

Крайне важно не забывать ответить

Я предпочитаю способ переноса времени: если вам написали, а вы программируете, то вы отвечаете через пятнадцать минут

Крайне важно не забывать ответить

Для тимлидов отметим важный момент: пишем «через 15 минут» правильно.

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

Рассмотрим еще одну проблему – возврат в контекст.

Вы программируете, у вас в голове: «Задача-метод-класс». Вас отвлекли, контекст пропал. Вы ответили сотруднику, нужно вернуться в контекст.

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

Мультитаскинг – большая проблема тимлида, и здесь могут помочь виртуальные рабочие столы.

На виртуальном рабочем столе программирования у вас может быть открыт IDE, браузер, требования.

На виртуальном столе, где у вас релиз в продакшен, Jenkins/TeamCity, Splunk/Kibana, чат с DevOps. То же самое с обсуждением требований: Skype/Teams, Jira, Confluence.

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

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

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

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

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

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

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

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

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

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

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

Образцовый стиль

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

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

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

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

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

Мы понимаем все негативные эффекты такого подхода, поэтому не ожидаем от каждого сотрудника, что он будет техлидом. Наша карта компетенций подразумевает очень широкое распределение по уровням: от тех, кто только стал мидлом, до уровней principal, techlead, platform lead.