Роль qa lead в продуктовой компании: особенности и зоны ответственности

Где научиться специальности?

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

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

1. Курс «TeamLead» от SkillBox

SkillBox – онлайн-университет современных профессий в области маркетинга, дизайна, программирования и менеджмента. Участник проекта Skolkovo, обладатель премии Рунета за 2018 и 2019 годы.

• Чему научитесь: освоите навыки управления командой разработчиков, принципы подбора персонала; изучите методологии Agile, Scrum и Kanban; сможете эффективно решать бизнес-задачи; узнаете системы мотивации работников.
• Формат обучения: практические видеоуроки, самостоятельные домашние задания с проверкой преподавателем и исправлением ошибок, защита дипломного проекта; всего 82 урока, сгруппированные в 28 тематических модулей.
• Преимущества: доступ к материалам курса навсегда с учетом всех обновлений; преподаватели-практики; разбор реальных кейсов; диплом о прохождении подготовки; отсрочка платежа до 12 месяцев.
• Длительность курса: 6 месяцев.
• Кому подойдет: начинающим специалистам, middle и senior-программистам.
• Стоимость: около 39 000 рублей, возможна рассрочка по 6 900 рублей в месяц.

2. «Руководитель команды разработки» от GeekBrains

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

• В программе обучения: автоматизация разработки, управление командой исполнителей и сложными системами. Вы научитесь подбирать специалистов, внедрять мотивационные программы, понимать продукт, разработкой которого будет заниматься команда. Узнаете как обеспечить качество работы и автоматизировать процессы.
• Продолжительность обучения: 6 месяцев.
• Формат: лекции два раза в неделю, вебинары и занятия в группе. Разбор всех тем будет проходить на основе ваших реальных кейсов. В конце занятий – защита итогового проекта и диплом о профессиональной подготовке государственного образца.
• Подойдет: начинающим управленцам и опытным разработчикам.
• Стоимость обучения: 3 113 рублей в месяц при беспроцентной рассрочке на 36 месяцев. Полная цена курса около 115 000 рублей.

3. «Team lead 2.0» от Otus

Образовательный онлайн-портал OTUS предлагает более 80 авторских курсов в области IT для разного уровня подготовки. На рынке с 2015 года. Обладатель премии Рунета за 2018 год и резидент государственной программы Skolkovo.

• В программе курса: Вы освоите современные техники и инструменты руководства. Научитесь подбирать специалистов не как отдельную единицу для выполнения рабочих процессов, а как часть сплоченной команды, которая выполняет общую задачу.  Вы не просто изучите персональные навыки управленца, но и научитесь работать с командой.
• Длительность обучения: 5 месяцев, по 4 часа в неделю в формате вебинаров (вторник и пятница в вечернее время), плюс домашние задания с проверкой преподавателем. В программе всего 7 тематических модулей, в том числе проектный (подготовка и защита диплома). По окончании курса получите сертификат о профессиональной подготовке.
• Подойдет: практикующим специалистам в области разработки не ниже уровня Middle/Senior.
• Стоимость курса: 110 000 рублей.

Про devrel

Я слышал, что у вас есть школа спикеров? Можешь рассказать про нее подробнее?

Да, Speakers Club. В 2016 году на devconf я слушал про IT-бренд — для меня это была совершенно новая область, т.к. в компаниях, где я работал, этого не было. На докладе рассказывалось что такое IT-бренд, какие есть способы его прокачки и как это делать.

Я вернулся с доклада и поднял вопрос о том, чтобы начать прокачивать IT-бренд в Lamoda. Именно в этот момент к нам пришла Женя Голева, наш действующий devrel.

Она с лета 2016 начала курс по публичным выступлениям, куда позвали тимлидов и техлидов — туда попал и я, так как интересовался темой.

По результатам года работы Speakers Club мы подготовились и выступили на HighLoad и на других конференциях.

Speakers Club существует 4 года и мы собираемся каждые 2 недели. Люди приходят туда за тренировкой — тема не имеет никакого значения. Можно прийти рассказывать хоть про морских рыбок:) Главное — нужноприходить без презентации и просто начинать выступать. Дальше уже ведется работа над подачей, работой с аудиторией, структурой повествования и так далее. Главная идея клуба — возможность получить обратную связь о своих навыках, и получить её в максимально безопасной атмосфере.

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

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

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

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

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

То есть у вас нет проблем с трафиком людей желающих выступить?

Это постоянный фокус, над которым мы работаем. По щелчку пальцев кучу докладов создать не получается, но есть объем наработок, чтобы регулярно что-то писать на Хабр и делать стабильно по 20-30 докладов в год уже несколько лет. То есть проблемы нет, но работать над этим постоянно приходится — люди в основном думают о своих задачах, а не о том, чтобы выступать.

Избегайте вопросов-клише на собеседовании

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

В каком направлении вы хотите развиваться?

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

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

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

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

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

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

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

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

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

Карьера

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

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

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

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

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

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

Кто такой Тимлид?

Описание профессии тимлид начну, пожалуй, с уточнения: это не специальность, а должность, или административная единица по другому, исключительно в сфере IT.

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

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

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

Резюмируя вышеперечисленное, можно сказать, что тимлид это три в одном – программист высокого класса + менеджер-управленец + психолог.

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

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

Заявка на подбор и текст вакансии — это не одно и то же

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

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

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

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

Обычно я указываю не только обязательный технический минимум

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

Также важно, чтобы правильно был прописан текст вакансии — он должен быть простым, четким, информативным. Помните: это визитная карточка, то, на что «клюет» кандидат

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

Слышал истории о том, что тексты вакансий составляются по схеме: нашли что-то похожее на hh.ru, немного подправили, дописали побольше технологий, опубликовали. При этом список требований у джуниора как для мидла со стажем. Не делайте так! Обязательно возле некритичных требований указывайте в скобках «будет плюсом», иначе вам придется очень долго искать человека, и от этого будет нехорошо не только рекрутеру, но и самому отделу.

История из жизни
«Как мы искали мидл-разработчика»

Как-то искали iOS-мидла в команду. Откликов мало, и вообще не те люди. Сели за круглый стол, все обсудили и поняли: то, что мы готовы предложить, нерелевантно требуемому опыту. Поменяли всего одну цифру (указали 3 года), и процесс пошел. Мой совет: будьте внимательны к каждой строке вакансии — одна цифра или фраза может в несколько раз сузить воронку.

Также полезно анализировать воронку на продвинутом уровне. Я регулярно смотрю в Talantix, все ли у нас хорошо. Сразу видно, на каких этапах срезаются кандидаты. Например, выясняется, что входящих откликов много, а техническое интервью проходят единицы. Что тут может быть? Например, плохо прописали заявку с рекрутером, и он не тех ищет или не те откликаются. Тогда нужно вместе пересмотреть требования и переписать текст вакансии.

Чаты как способ выстраивать связи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Где научиться специальности?

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

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

Курс «TeamLead» от SkillBox

SkillBox – онлайн-университет современных профессий в области маркетинга, дизайна, программирования и менеджмента. Участник проекта Skolkovo, обладатель премии Рунета за 2018 и 2021 годы.

• Чему научитесь: освоите навыки управления командой разработчиков, принципы подбора персонала; изучите методологии Agile, Scrum и Kanban; сможете эффективно решать бизнес-задачи; узнаете системы мотивации работников.
• Формат обучения: практические видеоуроки, самостоятельные домашние задания с проверкой преподавателем и исправлением ошибок, защита дипломного проекта; всего 82 урока, сгруппированные в 28 тематических модулей.
• Преимущества: доступ к материалам курса навсегда с учетом всех обновлений; преподаватели-практики; разбор реальных кейсов; диплом о прохождении подготовки; отсрочка платежа до 12 месяцев.
• Длительность курса: 6 месяцев.
• Кому подойдет: начинающим специалистам, middle и senior-программистам.
• Стоимость: около 39 000 рублей, возможна рассрочка по 6 900 рублей в месяц.

Посмотреть курс

Интенсив «Тимлид разработки» от SkillFactory

SkillFactory – онлайн-школа по работе с данными, лидер в сегменте Data Scientist, участник проекта Skolkovo. На рынке онлайн-образования с 2021 года.

• Чему научитесь: прокачивать навыки эффективного управления командой разработчиков; настраивать командные процессы; грамотно разрешать конфликтные ситуации; превращать бизнес-задачи в технические задания; планировать архитектуру будущего проекта.
• Формат обучения: вебинары, Q&A сессии, индивидуальные и групповые практикумы.
• Преимущества: формирование команды в процессе обучения; ментор на протяжении всего цикла обучения; работа в компактных группах.
• Длительность курса: 4 месяца.
• Кому подойдет: middle и senior-разработчикам.
• Стоимость: около 95 000 рублей за весь курс, или в рассрочку по 7 91 рублей на 12 месяцев без процентов.

Посмотреть курс

3. Онлайн-интенсив «Бизнес и управление» от Нетологии

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

• Чему научитесь: финансовому моделированию; проверять гипотезы и определять направление развития проекта; управлять конфликтами; собирать команду; использовать подход бережливого производства; приоритизировать задачи и контролировать их исполнение.
• Формат обучения: 14 тематических мини-интенсивов, каждый из которых состоит из 8 видео по 10-20 минут, 2-х промежуточных и одного итогового теста.
• Преимущества: практика и тренировка; помощь в подборе мини-интенсива.
• Длительность курса: в свободном графике, в зависимости от выбора интенсива.
• Кому подойдет: начинающим специалистам.
• Стоимость: каждый модуль стоит около 15 000 рублей.

Посмотреть курс

Как им стать

Как пра­ви­ло, тим­ли­ды — это быв­шие сеньоры.

Джу­ни­ор или мидл не смо­гут стать насто­я­щи­ми тим­ли­да­ми, пото­му что у них не хва­тит ква­ли­фи­ка­ции оце­нить про­ект в целом и сеньо­ры не будут вос­при­ни­мать их все­рьёз. Ино­гда тим­ли­да­ми назна­ча­ют про­стых мене­дже­ров, что­бы они рабо­та­ли с кли­ен­том, но это тоже ошиб­ка — такой мене­джер не смо­жет пра­виль­но оце­нить объ­ём работ и гра­мот­но рас­пре­де­лить зада­чи в коман­де. Что­бы стать тим­ли­дом, нужен боль­шой опыт в раз­ра­бот­ке и реше­нии архи­тек­тур­ных задач — а этим как раз и зани­ма­ют­ся сеньоры.

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

Кро­ме сво­ей обла­сти про­грам­ми­ро­ва­ния тим­лид дол­жен знать и уметь:

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

Коро­че, тим­лид — это мене­джер, кото­рый в совер­шен­стве зна­ет стек про­грам­ми­ро­ва­ния сво­ей команды.

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

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

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

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

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

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

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