Содержание
Поделитесь, что вы сделали, когда клиент попросил протестировать новую функцию «вчера», а у вас горели сроки по другим задачам. Специализируюсь на финансовых обзорах, банковских темах (кредитование, ипотека, вклады, инвестирование, дебетовые и кредитные карты и многое другое). Большой опыт работы в банке, знаю специфику работы “от и до”.
Обычно эту должность занимает наиболее опытный разработчик. Однако не всегда это оправдано, поскольку он может не уметь управлять. Специалист должен одновременно развивать навыки менеджмента и коммуникации.
Если на предприятии каждый будет заниматься только своим делом, не обращая внимания на синхронность с другими специалистами, получатся только отдельные компоненты, а не цельный продукт. Но нас больше интересует Inversion of Control — это важный принцип, упрощающий расширение возможностей системы, при котором поток управления программы контролируется фреймворком. Этот подход с точки зрения менеджмента отлично работает и позволяет отличать микроменеджмент от менеджмента здорового человека. Эти принципы позволяют эффективно проектировать технические системы, которые будет легко поддерживать и расширять в течение долгого времени. Эти принципы также можно применять к проектированию команд и ролей внутри них.
Речь не только про разработчиков — сейчас в партнёрстве шесть человек, и двое из них — из TSEKH’а, нашего дизайнерского подразделения. Главный критерий здесь в том, чтобы человек действительно мог и хотел революционно менять ход развития нашей компании. Безусловно, в каждой IT-компании у работы тимлида будут разные акценты. Но в целом теперь вы понимаете, с чем вам предстоит столкнуться, если вы собираетесь специализироваться в этой отрасли.
Сильный сотрудник не тот, у кого нет проблем, а тот, кто умеет их выявлять, находит в себе силы признать, решить и сделать выводы на будущее. Множество проблем в начале моего пути усугублялись нежеланием показывать слабости. Были ситуации, когда я брал на себя задачи, которые очевидно не мог бы выполнить в рамках рабочих часов. Я программировал, занимался командой и ее развитием, пересматривал процессы, старался улучшить всё, до чего только мог дотянуться.
В этом случае тимлид должен давать каждому наиболее подходящую ему задачу, которую специалист сможет выполнить. Чтобы получить эту должность необходимо повышать скиллы, начать разбираться в тех продуктах, над которыми ведется работа, научиться коммуницировать с коллегами, погружаться в бизнес- процессы. У тимлида есть пути развития до менеджера уровнем повыше. Можно, например, выбрать карьеру в технической сфере (системный архитектор) или сфере менеджмента (проект-менеджер). Тимлид (от англ. “team leader”— лидер команды) — это продвинутый разработчик, который отвечает за управление командой и участвует в разработке проекта. Нередко можно услышать мнение, что тимлид – ведущий разработчик, который использует свои лидерские качества для управления командой, но не ограничивается управлением.
Часто разработчики думают, что быть тимлидом — это долго работать над архитектурой кода, передавать свои знания мидлам и джунам. Но вместо этого тимлидам приходится много общаться с командой и клиентами, погружаться в бизнес-задачи. Самый лучший вариант — выбрать тимлида из разработчиков внутри компании. Он уже знает процессы и легко сможет управлять командой. Но не все сеньоры готовы становится тимлидами — в этом основная сложность. При этом тимлид не берет задачи всего проекта на себя, а именно организовывает работу команды и контролирует ее этапы.
Для наглядности показываем, в чем разница между teamlead и techlead, в таблице. Курс предназначен для тех, кто уже руководит группами разработчиков, или тех, кто только готовится стать руководителем в IT. Возможно, это Senior разработчики, которые растут в менеджеры, или же те, у кого количество подчинённых выросло от одного до нескольких сразу. Узнаете, как определить эффективность совместной работы, и познакомитесь с типами команд. Научитесь управлять разными сотрудниками, находить контакт с ними, оценивать компетенции и распределять роли в команде. Осознаете свои сильные и слабые стороны, научитесь расставлять приоритеты в задачах, разовьёте управленческие навыки и сможете избежать выгорания.
Опишите на собеседовании ситуацию из вашего опыта, когда у разработчиков возникли разногласия. Расскажите, что случилось, в чем была сложность и что сделали, чтобы решить проблему. Изучайте требования бизнеса к проекту, в котором участвуете. Например, узнайте, почему решили использовать новую библиотеку или изменили верстку.
Эту проблему можно решить достаточно просто, если устранить неоднозначность термина “архитектор”. Разработчики обычно вырастают не просто в абстрактных архитекторов, а в software архитекторов, которые умеют проектировать системы и отлично писать код. А вот аналитики обычно дорастают до solution architect, которые отлично умеют собирать требования и проектировать системы, которые удовлетворяют этим требованиям. Давайте теперь посмотрим как эти принципы можно применить к самой команде. Все заканчивается релизом приложения и дальнейшей эксплуатацией, что приносит определенный поток монеток.
Поймёте, как оценить задачу, для которой сложно спрогнозировать срок выполнения. Поймёте, как сформировать расписание проекта в четыре шага и работать в рамках бюджета. Научитесь отслеживать прогресс и качество проекта, работать с рисками, вовлекать заинтересованные стороны, проводить тимбилдинг и организовывать коммуникации. Изучите три обязательных шага для закрытия проекта. Познакомитесь с принципами эффективного общения, поймёте, как поощрять команду к обсуждению и когда нужно вмешаться в ход встречи. Научитесь выявлять ключевые моменты обсуждения, использовать визуализации и сможете развить свои навыки фасилитатора.
Отличным вариантом будет дописать какой-то «костыль» — быстрое временное решение, снижающее критичность вопроса — и успеть выпустить обновление. А к полноценному решению проблемы вернуться в следующем апдейте. Обязательно следите за рабочим временем и состоянием команды, регулярно обсуждайте нагрузку и планы. Стремясь казаться https://deveducation.com/ лучше, многие могут взять на себя больше, чем стоило бы. Ответственность и желание держать слово мешают сотруднику вовремя признаться, что ему тяжело и объем задач или сроки нужно пересмотреть. Когда в команде есть сильная конкуренция, со временем специалисты перестают делиться полезной информацией друг с другом.
Если вашего уровня недостаточно, чтобы принять какое-то сложное техническое решение, всегда можно обратиться к техлиду, архитектору или специалисту в конкретной области. Этот человек понимает, что такое ответственность и работа в команде. Он опытный программист и лидер, способный управлять человеческими ресурсами внутри собранной им команды. Тимлид занимается конкретным проектом, может собрать всех участников вместе и подтолкнуть их идти к единой цели.
Создание приятной психологической обстановки, умение разрядить обстановку или мобилизовать силы команды. Умение мягко обратить внимание человека на его сильные и слабые стороны, успехи и ошибки, помочь сделать выводы. Тимлид — это управленец, и работать «руками» ему приходится меньше, чем другим программистам. Чтобы не терять навык, нужно по несколько часов в день писать код и одновременно учиться, знакомиться с новыми технологиями. Иначе будет сложно вовремя заметить ошибки, сделать качественный code review, да и в целом заслужить доверие команды.
Если придётся решить вопрос с увольнением или неожиданным отпуском, вы сможете принять решение с опорой на Трудовой кодекс. В мессенджере Telegram есть интересные чаты и каналы для руководителей команды разработки, и от их лица. Общий онлайн-курс, который подойдет всем, кто хочет работать на управляющей должности. Образовательная программа длится месяц и состоит из трех видеолекций в неделю, а также из вебинаров.
Но на практике путь до тимлида может быть куда сложнее или куда проще. Многое зависит от того, где трудится разработчик и от уровня профессионализма программистов, которые его окружают. Но в жизни бывает, что тимлидами становятся и с «мидла» и даже с «джуна». Если в команде всего 2 разработчика, значит один из них должен быть лидером и неважно кто он — «мидл» или «джун».
Онлайн-курс “Управление командами digital-специалистов” от Skillbox. Учитывая все вышеописанное, на деле вакансий по должности тимлида значительно меньше. Но даже если уменьшить количество объявлений по должности до , это все равно показатель высокой востребованности. Определение компетентности разработчиков, формирование команды и совмещение специалистов между собой. BrainUP – агрегатор онлайн-курсов с удобной системой сравнения по цене, продолжительности, отзывам и другим критериям. Выбирайте и сравнивайте обучающие курсы по digital и IT.
Важно сразу убедиться, что все тщательно спланировано и известно. IT-сфера активно развивается, поэтому растет и востребованность в управленцах. Их труд хорошо оплачивается и по российским, и по зарубежным как руководить командой меркам. Работа требует навыков работы с Linux based дистрибутивами, знания Agile, PHP, Scrum, MySQL, JavaScript. Могут еще встречаться условия, имеющие отношение к конкретной сфере работы заказчика.
Как мы уже говорили, отличия между техлидом и тимлидом можно объяснить через разницу между hard skills и soft skills, так как специалисты по-разному используют эти навыки. В частности, hard skills для технического специалиста – must have, так как он должен быть авторитетом для коллег. Прокачать «мягкие» навыки можно на специальных онлайн-курсах. Далее – подробнее о качествах, которыми должны обладать технические и командные лидеры. В 99% случаев руководителем команды разработки становится опытный разработчик, который проявил соответствующее рвение и не просто готов нести большую ответственность, но и любит это.
А вообще ситуация, когда тимлид и техлид – один человек, – плохая идея, так как их требования и зона ответственности часто вступают в противоречие друг с другом. Например, техлид четко следит за выполнением технического задания, но часто это происходит в ущерб свободному времени. Другие задачи (в частности, помощь новичкам) игнорируются, в результате чего сотрудники испытывают стресс. На старте работы в маленьком коллективе достаточно одного человека, которым может самостоятельно решать технические задачи и контролировать двух-трех своих опытных коллег.
Ну и еще один совет — постоянно прокачивать необходимые скиллы, как самостоятельно, так и при помощи коллег или онлайн-курсов. Подмечайте удачные управленческие решения коллег и руководства. Берите их на заметку и старайтесь использовать при необходимости. Принимать решения в условиях недостаточной информированности и брать на себя за это ответственность.