Тимлидер: плюсы и минусы профессии
Содержание:
- Настройте коммуникации
- Алгоритм подбора подходящего руководителя
- Что делать, если стали лидом
- Твои рекомендации/лайфхаки, которые могут сильно упростить работу тим лида?
- Обучение
- Психологическая роль
- Пора программировать
- Подбор: скоринг
- Обязанности тимлида
- Заработная плата
- В целом я считаю, что совмещение ролей управленца и инженера зависит от трех вещей:
- Приведите в порядок встречи один на один
- Как стать тимлидом
- Страх №1. Ты не востребован на рынке
- Кто такой Тимлид?
- Шаг номер 1. Знание — сила!
Настройте коммуникации
- Уменьшать входящий трафик, делегируя и автоматизируя. Кстати, про это был классный доклад Алексея Катаева deusdeorum на TeamLead Conf 2019.
- Правильно работать с оставшимся трафиком.
Настраиваем почту
«Inbox Zero»1
Удалил совсем неважное.Пример: флуд-рассылка.2. Настроил раздел для неважного сейчас. Пример: Deploy status autoupdate3
Разделил важное на блоки. Пример: «Проблема на продакшене».Пример: «У нас есть классная идея. Давайте обсудим. Что думаете?».
Настраиваем мессенджер
- Первый и главный — включить уведомления только о личных сообщениях и упоминаниях.
- Следить за актуальностью списка комнат/каналов. Лучше оставаться только в тех, где либо вам что-то интересно, либо вы кому-то нужны. Из всех остальных можно смело выходить.
- Настроить пуш-уведомления. Если соблюдать первый и второй пункты, то уведомления будут приходить в основном в тех случаях, когда информация каким-то образом вас касается.
- Не пренебрегать статусами. Когда необходимо сосредоточиться, очень помогает, например, статус «Не беспокоить».
Алгоритм подбора подходящего руководителя
Я не зря сменил способ выражения. Надеюсь, что к этому моменту вы уже поняли, что не бывает руководителей с плохим или хорошим стилем. Стили бывают только подходящими или нет. Равно как нанимающих менеджеров учат на собеседовании подбирать подходящих, а не идеальных кандидатов, так и я буду говорить о том, как найти подходящего, а не идеального руководителя. А для того, чтобы определиться, какой руководитель вам подходит в конкретной ситуации, нужно ответить на вопросы:
-
Какие из стилей предпочитаете лично вы, как сотрудник?
-
Какой стиль подходит команде, которую вы рассматриваете в данный момент?
-
Какой стиль будет подходить команде через год, два, пять (зависит от того как на долго вы собираетесь с ней остаться)?
-
Какой стиль использует руководитель?
-
Способен ли он менять свой стиль?
О том, как ответить на эти вопросы мы поговорим ниже, а пока разберемся, как интерпретировать ответы:
-
Запишите ответ на первый вопрос, скорее всего у вас выйдет несколько предпочтительных стилей.
-
Стили из вопросов 2-4 должны быть из списка ваших предпочтительных.
-
Ответы на вопросы 2 и 4 должны совпадать.
-
Единственная ситуация, когда на этот вопрос можно ответить отрицательно — если все предыдущие ответы совпали и руководитель должен использовать, использует и будет использовать подходящий для вас стиль руководства.
Что делать, если стали лидом
Роль team lead, как и роль менеджера, имеет ряд специфических особенностей, зависящих от внешних и внутренних факторов бизнеса, времени, технологий и видения самой компании. Если стали лидом, первым делом:
- Настройте процессы работы в отделе. При этом максимально их задокументируйте.
- Продумайте систему обучения сотрудников.
- Настройте правильную систему делегирования различного рода заданий и лишь направляйте и контролируйте их выполнение.
- Вступайте в диалог в любой непонятной ситуации. В споре рождается истина. Лишь так вы поймете людей и получите подтверждение, что они понимают вас.
Что сработало в моем случае может сработать и в вашем. Главная же доктрина заключается в том, что всё приходит с опытом. Если вы работаете в этом направлении, конечно. Проблемы со временем не исчезнут, вы просто научитесь их решать.
Помните, что учиться можно не только на своём опыте, но и на чужих ошибках. Teamleadство — это круто.
Твои рекомендации/лайфхаки, которые могут сильно упростить работу тим лида?
Я использую планнер, куда записываю все дела, которые не успел завершить, если нужно было переключиться на другую задачу – это сильно упрощает жизнь. Ещё настроил интеграции в calendar/mail/slack приложениях, что тоже немного упрощает жизнь. Когда у тебя митинг по календарю, то slack будет автоматически мьютить любые нотификации, и ты не будешь отвлекаться на какие-то сообщения от коллег. Mail позволяет настроить несколько почтовых ящиков, и ты не паришься о том, что можешь случайно забыть проверить какую-то одну из своих почт. А calendar агрегирует все твои звонки/митинги в одно место, что тоже очень удобно и позволяет легче планировать свой рабочий день.
Не знаю, является ли это «лайфхаками», но мне в работе сильно помогает.
Обучение
Уточните планы и ресурсы для обучения в компании. Наблюдайте за тем, как разработчики делится идеями и новостями индустрии. Ваше восприятие обучения зависит от роли и опыта.
Старший разработчик увидит еще одну точку зрения на вопрос, а младший – руководство к действию. С вашей точки зрения можно пропустить эти процессы. Проясняйте это.Так же важен вопрос подкованности в soft-skills
Популярность этого вопроса дает ощущение осведомленности, но на деле важно синхронизировать понимание между участниками
На что смотреть? На штиль, рябь или волны идей внутри команды. На планы развития.
Психологическая роль
Бытует мнение, что большинство разработчиков являются интровертами. В действительности, это очень близко к истине. Благодаря этому знанию появляется несколько методик, которые можно применять в работе.
Организуйте ежемесячные встречи с разработчиками. Сценарий таких встреч каждый месяц повторяется. Поначалу разработчик говорит, что всё ок, всё хорошо, проблем нет. Но основная сила психолога в вопросах. В беседе узнается, что и систему оценки на проекте в прошлом месяце можно улучшить, и взаимоотношения между отделами подтянуть, а ещё было придумано оригинальное решение, которое можно вынести как базовое и написать по нему гайд. Ведь на другом проекте возникли такие же проблемы и решали их дольше, чем нужно. Беседу обязательно надо конспектировать, потому что в ней могут быть отличные мысли. Их можно и нужно претворять в жизнь. После таких бесед часть проблем нивелируется. Так как процесс итеративный, он помогает устранять проблемы и не занимает много времени. Такие встречи не нужно превращать в совещания отделов. Это должны быть именно тет-а-тет беседы в спокойной обстановке. Так вы сможете решить даже сложные личностные проблемы.
Станьте «большим братом». Lead несет ответственность за работу своего подразделения. Он должен быть в курсе задач, сроков исполнения и качества функциональности на выходе для каждого разработчика. Однако, в процессе работы не стоит впадать в крайности. Пословица «Всё хорошо в меру» работает здесь отлично. Старайтесь не вмешиваться, если всё идёт хорошо. При этом всегда держите руку на пульсе и предотвращайте кризисные ситуации. Сотрудник комфортнее всего работает, когда на него не давят сверху, но при этом он чувствует влияние невидимого «большого брата», который является не контроллером, а советчиком.
Внедряйте «безликий код». Самый долгий и трудный процесс — привести код вашего отдела к «безликому коду», когда нельзя по стилю определить, кто его написал. Это направление правильное и трудное. Если возможна вариативность решения, вы встретите несколько лагерей. Чтобы в случае кризисной ситуации в ваш адрес не посыпалось «вот решили тогда так, а это оказалось плохо, и сейчас все минусы всплыли», необходимо дипломатично решать каждый вопрос. Помните, что с базовыми решениями, которые вы разрабатываете и согласовываете, будут работать другие люди. Делайте удобно для них.
Пора программировать
Мы настроили время, коммуникацию, справились с отвлекающими факторами, налили чаёк… И мы парализованы.
У нас антипаттерн – аналитики-паралитики.
Представим ситуацию: мы архитекторы нефтекомплекса. Мы в голове держим весь этот нефтекомплекс: как он работает, почему он все еще не взорвался. Допустим, все рабочие ушли в отпуск и надо починить трубу. Мы единственные, кто может это сделать.
Как вы думаете, о чём будет думать архитектор нефтекомплекса, когда ему надо чинить трубу? «Пройдет ли этот биметалл эконормы? А как на давление повлияет в сжигателе?» В данном случае архитектор просто не сможет починить эту трубу, потому что не справится с такой когнитивной нагрузкой.
У нас то же самое. Разработка ПО – это комплексная задача. Бизнес-контекст, архитектура, код и прочее. От нас как от тимлидов требуют думать глобально.
Чтобы решить задачу, я использую подход вокализации действия. У меня над рабочим столом висят карточки, где написаны разные роли – архитектор, аналитик, программист. И я себе говорю, например: «Сейчас я аналитик, мой фокус внимания – не код, а бизнес-контекст» или «Сейчас я программист, я не думаю, как перекрутить требования». Упрощаем себе жизнь, переключаем фокусы внимания.
Подбор: скоринг
- Бизнес-ориентированность — насколько человек прагматичен, когда целью является результат для бизнеса, а не, скажем, уровень удовлетворённости красотой и изящностью кода. Тимлид должен в первую очередь руководствоваться принципами управления, а не личного комфорта. Простой пример: если бизнесу нужно провалидировать в рамках A/B-теста какую-то концепцию, вероятно, нет смысла делать покрытие кода тестовой группы юнит-тестами, даже если принято покрывать тестами всё, и разработчику нравится писать тесты.
- Коммуникации. В культуре Badoo на коммуникациях построено очень многое, и умение эффективно общаться со всеми — серверниками, тестировщиками, топами, дизайнерами — просто необходимо.
- Уровень мотивации. На мой взгляд, тимлид должен обладать сильной внутренней мотивацией, ведь превращение из разработчика в тимлида — это не переход со ступеньки на ступеньку карьерной лестницы, а перепрыгивание на другую лестницу, стоящую особняком, — лестницу управления. Без сильной мотивации любое развитие — а развитие всегда есть выход из зоны комфорта — будет очень тяжёлым.
- История удачных/неудачных проектов. Сюда же относятся причины провалов проектов (чтобы потом проверять следующие проекты на наличие тех же паттернов провалов).
- Уровень неформального лидерства. Руководитель должен уметь вести за собой сотрудников, мотивировать их на достижение целей. Кроме того, неформального лидера команда легче примет в качестве тимлида.
Обязанности тимлида
В некоторой мере обязанности тимлида пересекаются с областью деятельности менеджера проектов. Но у team leader есть и свои особые задачи, характерные для веб-разработки.
В перечень основных обязанностей тимлида входит:
- разбор бизнес-задачи и последующая ее обработка в техническое задание для разработчиков;
- оптимизация работы;
- оценка работы всех участников команды по отдельности и в целом, рекомендации по улучшению или исправлению;
- при желании и возможности написание части кода для сохранения навыков;
- дипломатическая работа, решение конфликтов и споров;
- заключение договоров;
- распределение бюджета;
- разработка архитектуры;
- проведение переговоров с клиентом, выяснение его требований и пожеланий;
- расстановка приоритетов, планирование всех этапов разработки;
- написание ревью кода;
- соблюдение сроков и своевременный выпуск продукта;
- налаживание контактов с группой и заказчиком;
- умение мотивировать и вдохновлять сотрудников на своем примере;
- полная ответственность за себя, работу команды и проект в целом;
- ведение отчетов и другой документации, их предоставление руководству и заказчику;
- нахождение ошибок в проекте и их устранение;
- участие в формировании команды, подбор и собеседование с претендентами на вакансию;
- подбор наиболее эффективных методов работы;
- при необходимости разъяснение технического задания лично каждому;
- определение для всех задач и ролей в команде;
- выгрузка изменений на сервер;
- организация обмена знаниями и навыками среди сотрудников;
- проведение совещаний, обсуждений и мозговых штурмов внутри команды;
- тестирование полученного продукта;
- контролирование процесса разработки проекта;
- выслушивание идей и предложений от участников команды, их оценка, дальнейшее принятие либо отклонение.
Заработная плата
Активное развитие IT-сферы повысило востребованность должности тимлида. Опытный профессионал ценится, и его работа, соответственно, достойно оплачивается.
Сколько получает такой специалист? Уровень заработной платы в основном зависит от региона и масштабов компании, где он работает. Разумеется, заработок на крупном предприятии в Санкт-Петербурге или Москве будет выше, чем в небольшой организации на периферии. Сегодня тимлид в среднем может зарабатывать от 160 до 340 тысяч рублей в месяц. По информации, изложенной на сайтах с вакансиями, минимальная зарплата для претендента на эту должность составляет почти 26 000 рублей, а максимальная – немного больше 672 тысяч рублей.
В целом я считаю, что совмещение ролей управленца и инженера зависит от трех вещей:
1) Стадии развития вашей команды
Если посмотреть на стадии развития группы по Такмену, все команды проходят несколько этапов: сначала идет этап формирования команды, в процессе люди начинают конфликтовать и начинается так называемый этап шторминга, конфликтная стадия – наиболее критичный этап.
Потом, когда люди поняли, кто есть кто, они начинают притираться друг к другу и наступает длительный этап норминга, на котором производительность медленно растет, доходит до пика на этапе перформинга и потихоньку падает.
Если вы тимлид в команде, которая только формируется или проходит конфликтную стадию, помните, что эти этапы нужно проскочить как можно быстрее, и вместо разработки стоит потратить время на то, что вы будете отслеживать конфликтные ситуации заранее и, если что, мирить сотрудников, много коммуницировать.
Как только вы перейдете в режим норминга и перформинга, у вас освободится гораздо больше времени на программирование.
2) Уровня квалификации и мотивации ваших сотрудников
Если у нас команда высоко мотивирована, но не очень квалифицирована, как будто там много активных джунов, то ваше время гораздо эффективнее вкладывать в менторинг команды, чтобы они быстро доросли до того уровня задач, которые им нужно выполнять.
Обратная ситуация – у вас в команде толпа «выгоревших синьоров». Тогда время и энергию стоит вложить в поддержку ребят, чтобы они выскочили из ямы демотивации.
Если у вас команда немотивированных и неквалифицированных сотрудников, то, наверное, вы всё время будете заняты микроменеджментом и больше ничем.
Есть классическая табличка на эту тему:
Единственный возможный вариант освободить себе время на разработку – делегировать задачи достаточно мотивированной и квалифицированной команде.
3) Уровня коммуникации на проекте
Возможности тратить времени на разработку не будет, если есть проблемы в коммуникации на проекте.
Например, mushroom management (управление по принципу «меньше знаешь – крепче спишь), когда вы являетесь единой точкой коммуникации и никто больше не знает, что происходит.
Очевидно, что в таком случае у вас не будет времени на инженерную деятельность.
Приведите в порядок встречи один на один
Пример формата записи результатов и договорённостей по итогам встречи
записывайте фидбэк, который хотите дать сотруднику, если это терпит до встречи;
освежайте в памяти информацию перед встречей (я не раз вспоминал про какую-то часть фидбэка только потому, что делал записи);
предоставляйте первое слово сотруднику (в этом диалоге вы находитесь в сильной позиции — вам понятно, что вы хотите сказать, как его вести и т
д., так что, начав с себя, вы можете сбить человека, и он либо забудет сказать о чём-то важном для него, либо не захочет этого сделать);
больше обсуждайте то, что важно сотруднику, помните о том, что встреча один на один — это в первую очередь площадка для подчинённого. Это то гарантированное (хоть и не единственное) место и время, где он может обсудить что-то наедине с руководителем;
фиксируйте результаты (это может быть значимая реакция на какую-то обратную связь или какие-то договорённости);
настройте периодичность встреч (разным людям требуется разное количество подобных встреч, нелишним будет поинтересоваться у сотрудника, не слишком ли редки или часты для него такие беседы);
не усложняйте (как и в случае с карточками, записывать всё подряд не нужно, иначе инструмент превратится из полезного во вредный).
Как стать тимлидом
С нуля стать тимлидом не просто сложно, а невозможно. Эта должность требует наличия множества навыков и знаний, а также опыта работы. Надо понимать, что такое программирование и менеджмент, знать, как работать и управлять человеческими ресурсами.
Для старта можно выбрать такие направления в вузах, как информатика и вычислительная техника, информационные системы и базы данных, а также другие направления, связанные с информатикой и программированием.
После работы веб-разработчиком можно уже думать о том, как дорасти до руководящих постов. Для этого надо постоянно учиться, быть инициативным и проявлять лидерские качества.
В большинстве случаев тимлидом становятся после приобретения профессионального статуса senior, т. е. став экспертом в своем деле, способным оценить весь проект в целом.
Но не все senior могут стать лидерами. Его, возможно, будут воспринимать всерьез и выполнять поручения, но эти задания могут быть неэффективны, так как новоиспеченному тимлиду не хватает управленческих навыков. Даже если поступит предложение стать тимлидом, для начала надо обдумать свои возможности, чтобы никого не подвести и не стать обузой для своих же подчиненных.
Чтобы эффективно управлять командой веб-разработчиков, надо изучать психологию, менеджмент, планирование, все время обновлять знания по программированию.
Сейчас доступна различная литература, лекции и семинары для желающих стать тимлидом, а также различные онлайн-курсы от проверенных обучающих платформ.
Самостоятельное обучение
Тем, кто уже имеет опыт в программировании, необходимо подтянуть навыки лидера и управленца. В этом может помочь самообразование с помощью специальной литературы:
- Том ДеМарко “Deadline. Роман об управлении проектами”
- Джефф Сазерленд “Scrum. Революционный метод управления проектами”
- Патрик Ленсиони “Пять пороков команды”
- Роман Матвеев “Наставничество. Метод Петра Кузнецова”
- Патрик Ленсиони “Смерть от совещаний”
- Роберт Кийосаки “Богатый папа, бедный папа”
- Джон Медина “Правила мозга”
Со списком книг о профессии тимлид можно ознакомиться на блоге.
Онлайн-курсы
Курсы станут отличным вариантом для тех, у кого не хватает времени на самообразование. Онлайн-обучение имеет несомненные достоинства:
- Удобный формат. Когда, где и как быстро проходить курсы – индивидуальный выбор ученика.
- Структурированная и собранная в одном месте информация.
- Готовое портфолио по окончании курса.
Популярные платформы Skillbox, Нетология, SkillFactory, Otus, City Business School и Академия АйТи предлагают свои курсы для будущих тимлидов:
- Практический онлайн-курс “TeamLead”
- Онлайн-интенсив “Бизнес и управление”
- Интенсив “Тимлид разработки”
На блоге iklife.ru можно найти обзор лучших курсов по Team Lead и выбрать подходящий для себя.
Страх №1. Ты не востребован на рынке
Буду получать меньше, чем сейчас
- 144–294 тыс. рублей, если являетесь профессионалом, который, возможно, менторит пару человек, но едва ли исполняет весь набор функций тимлида.
- 175–357 тыс. рублей, если вы тимлид небольшой команды.
- 225–491 тыс. рублей, если вы тимлид большой команды в 10-30 человек или менеджер менеджеров.
Как победить страх, что ты не востребован на рынке
- Это повышает вашу уверенность в завтрашнем дне. Дает понять, что если что-то пойдет не так (компания обанкротится, вы выгорите, ваш руководитель сойдет с ума и т.д.), вы всегда сможете найти себе что-то еще.
- Позволяет оценить ваши навыки. Длительное время сидя на одном месте трудно понять, а как вы справляетесь. На собеседовании вы получите максимально честный и жесткий фидбэк.
- Дает понимание рынка: что и где требуется от тимлидов, какие полезные практики и процессы применяются и чем они могут быть полезны вам в текущей ситуации.
Ходить по собеседованиям не обязательно значит хотеть сменить работу. Это не страшно, за это не наказывают.
Teamlead Roadmap
Кто такой Тимлид?
Описание профессии тимлид начну, пожалуй, с уточнения: это не специальность, а должность, или административная единица по другому, исключительно в сфере IT.
В дословном переводе с английского «Team Lead» означает «лидер команды». Это руководитель-управленец, который возглавляет коллектив веб-разработчиков. Он является ключевым связующим звеном между заказчиком и исполнителями. Тимлид проводит переговоры, принимает заказы на разработку, которые потом преобразовывает в технические задания для специалистов.
Как руководитель группы, он управляет работой по проекту, координирует действия, распределяет задания, разруливает спорные и конфликтные ситуации, мотивирует свою команду. Он контролирует все этапы процесса разработки, от начала и до конца. А для этого ему необходимо знать программирование на уровне не ниже senior.
Не секрет, что в любом коллективе работают люди, которые не только выполняют различные функции, но еще и являются разными по типу личности. Поэтому тимлид должен учитывать все эти факторы и уметь найти подход к каждому человеку в отдельности, а также объединить их в группу единомышленников. А это уже из области психологии. Только тогда общая работа над проектом может быть результативной.
Резюмируя вышеперечисленное, можно сказать, что тимлид это три в одном – программист высокого класса + менеджер-управленец + психолог.
Зная все технические тонкости разработки веб-проектов, тимлид все-таки не осуществляет непосредственно сам исполнительскую работу. Он планирует, организует, оптимизирует процессы, распределяет обязанности с учетом возможностей каждого сотрудника. Часто Team Lead сам набирает себе команду. Ответственность за весь проект лежит на нем, даже если ошибки совершают исполнители.
Стать тимлидом может только опытный разработчик-программист, который имеет богатый опыт работы в сфере IT, а еще у него должны быть хорошие навыки лидера, который не только формально возглавит команду, но и будет являться авторитетом для своих подчиненных.
Шаг номер 1. Знание — сила!
Если вы всё же согласились на данную позицию, то следующее (а в идеале и заранее), что надо сделать — ознакомиться с полезной информацией на эту тему.
Про тимлидство существуют сотни статей, видео, книг, курсов и т.д. Фильтровать нужно тщательно.
Прилагаю список того, что мог бы порекомендовать я из более-менее основательного. Статьи и какие-то выступления с конференций вы можете найти и отобрать самостоятельно.
-
М. Уоткинс «Первые 90 дней». Хорошая и вдумчивая книга о том, как успешно адаптироваться к переходу на новую должность. Чем заняться в первые 90 дней. И о том, что эта адаптация, как системный процесс, нужна не просто конкретному индивиду, а всей компании в целом.
-
Дж. Ханк Рейнвотер «Как пасти котов». Книга для начинающих или будущих управленцев вполне хороша и толкова (пусть и немного стара). Однако для людей с опытом, наверное, будет немного кэпской.
-
Ф. Брукс «Мифический человеко-месяц». Расскажет об управлении проектами: как надо, как не надо, и почему 9 женщин за 1 месяц не смогут родить ребенка. Есть мнение, что книга несколько устарела, тем не менее, если вы в этом не очень разбираетесь, то она обогатит вас полезными идеями.
-
Э. Голдратт. «Цель. Процесс непрерывного совершенствования». Классический художественный роман, объясняющий на разных примерах теорию ограничения систем. Чтиво интересное и полезное.
-
Д. Ким, К. Бер, Д. Спаффорд. «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему». Очень интересная и поучительная книга, которая в художественном формате рассказывает о том, как в ИТ подразделении улучшают процессы работы, приходят к DevOps идеологии и спасают бизнес.
-
Т. ДеМарко «Deadline. Роман об управлении проектами». Еще одна книга в художественном формате. Легкое и интересное чтение об управлении ИТ проектами.
-
Т. ДеМарко, Т. Листер «Вальсируя с Медведями». Порекомендовал бы эту книгу для средних и крупных проектов. Излечивает от наивности, открывает глаза на происходящее. Показывает, что случиться может много чего и рассказывает, как с этим жить и работать.
-
М. Дорофеев «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо». Книга не про программирование, но программистам, тимлидам, менеджерам точно пойдёт на пользу. Очень толковая книга по личной эффективности, организации задач и т.п. Всем настойчиво рекомендую.
-
М. Ильяхов, Л. Сарычева «Новые правила деловой переписки». Замечательная книга. Смело её рекомендовал бы и разработчикам, и менеджерам, и вообще примерно всем. О том как в переписке быть толковым, уважительным, приятным и эффективным. Очень многим этого не хватает.
-
А. Орлов «Джедайские техники конструктивного общения». Коротко, по делу, с примерами. Однозначно рекомендую. И в работе пригодится, и в быту.
-
М. Гоулстон «Как разговаривать с мудаками». Книга придаёт понимание того, что не все проблемные отношения и коммуникации можно разрешить рациональными доводами, и что делать в таких случаях. Ну и о себе можно задуматься тоже:)
-
Роадмап тимлида https://tlroadmap.io/ Очень полезный инструмент, который поможет разобраться, какие бывают требования к тимлидам, понять, что с ними делать и как подтягивать свои знания. Также подойдет как хороший инструмент для того, чтобы обговорить со своим руководителем на начальном этапе работы, что же конкретно от вас ожидается.
-
Курсерный курс https://www.coursera.org/specializations/product-management Долгий и основательный курс, который покрывает всё про управление проектами. Выявление требований, план рисков, декомпозиция и распределение задач, аджайл техники и прочее. Вы справедливо можете заметить, что этот курс нужен менеджерам проектов, а не тимлидам. Теоритечески — да, а на практике возможно, что если у вас менеджер проекта и есть, то в каких-то деталях он может не очень разбираться. Тогда понадобится ваше участие.
-
Регулярные двухнедельные тимлидские конференции от ребят из подкаста Podlodka https://podlodka.io/tlcrew Там много хороших докладов и душевное отзывчивое комьюнити, с которым можно порой пообсуждать в деталях то, за что обычно деньги берут на платных индивидуальных консультациях.