Хотел бы поделиться опытом и своими взглядами на особенности управления процессами в IT-компаниях. А именно рассказать подробнее о том, чем отличаются роли Team Lead и Tech Lead и какие функции и задачи могут быть с ними связаны. Прежде всего это будет интересно team lead vs tech lead тем, кто работает в растущих командах или задумывается о карьерном росте на позиции разработчика. А также тем, кого волнуют вопросы эффективного управления в продуктовых компаниях. Достоинства должности в основном связывают с приобретением административных навыков.
LeadGen Expert: Эффективная лидогенерация в B2B
- Компании не хотят вкладываться в обучение, потому что это очень дорого.
- И при этом быть экспертом в технической области, авторитетом для членов команды.Это совсем не просто, если по-честному, а не «за выслугу лет».
- Подготовка к еженедельной встрече с заказчиком.
- У кого-то был опыт ухода с пути менеджера на тех путь обратно, например с Engineering manager, VP, CTO, Head, Director назад в Tech Lead, Staff, Principal, Architect?
- Мне кажется, что именно сейчас, в эти сложные времена в Украине и мире вообще, с нуля очень трудно получить первую работу.
Итак, сейчас в каждой команде у нас 2-3 Back-end Engineers, 1-2 Front-end Engineers, 2-3 QA/AQA Engineers. Как правило, команда состоит из Senior/Middle+ специалистов, которые достаточно автономны (70-90% решений принимается самостоятельно). Продолжаем цикл материалов об ИТ-специальностях. Каждую описывает «типичный представитель» — опытный специалист и просто авторитетный коллега, тот же человек, который знает все тайные уголки своей профессии. Мы надеемся, эти материалы помогут школьникам, студентам, переквалификантам, студентам и всем, кто заинтересован в выборе ИТ-специальности.
Team Lead vs Tech Lead. В чем разница и зачем разделять эти роли
Там где это есть — суть есть роль «лида» очень быстро скатывается к «насяльника-я-так-сказал-и-если-даже-клиент-не-так-сказал-сам-дурак». Что тоже очень характерно для апологетов «единой проектной команды» замкнутого на единого господина типа «вассал моего вассала не мой вассал». Чтобы суметь защитить и себя и свою команду в случаях когда сроки сорваны(перенесены) не по причине разработчиков. У кого-то был опыт ухода с пути менеджера на тех путь обратно, например с Engineering manager, VP, CTO, Head, Director назад в Tech Lead, Staff, Principal, Architect?
Что должен знать и уметь DevOps
Описанные далее п.п.1 и п.п.2 к обсуждаемой теме вообще отношения не имеют. Роль построения взаимодействия с зазаказчиком — точно такая же роль, как и все остальные. Проблема именно в том, что все получают должность, а как играть роль и что там вообще надо играть — никто не знает. Если же мы описываем роль, то можно понять, кто эту роль в компании исполняет (лычки могут меняться) и для чего. Но не зависимо от метода выбора — назначение сверху или самоорганизация — название должности ни на что не влияет.
Сказали Шкурупий/Шкляров/Бойчук берем Скокова на должность ПМ’а вот и стал ты пм’ом. Если говорить о конкретных цифрах, то среди 1822 бывших украинских тимлидов база данных LinkedIn находит 852 проектных менеджеров и 346 системных архитекторов. Это совершенно другая роль, хотя нередко один человек может совмещать в себе обе эти роли в IT-проекте.
А если ничего не знаешь, то уметь быстро найти информацию и использовать ее. Помимо технических навыков, Technical Lead должен обладать навыками коммуникации, управления проектами, принятия решений и способностью видеть “большую картину”. Во-первых пойди разбери, кто что думает на самом деле (так что приходится уточнять «а что вы имеете ввиду под должностью тимлида?»), а во-вторых для манагерских позиций крайне важен опыт. Полагаю, что когда говорят о тимлиде как о должности (а, точнее, позиции), то говорят, на самом деле, о человеке, который достаточно квалифицирован, чтобы выполнять роль тимлида. Но как только возникнут проблемы — кто-то возьмется за их решение (или команду уволят). Тот, кто возьмет на себя решение проблем (например — быть модератором в споре) — будет выполнять роль лида.
Часто мы шутим о том, что DevOps это как ремонт, никогда не заканчивается. То есть оптимизацию и коммуникацию, которую ведут DevOps-специалисты, нельзя закончить, можно только остановить. Таски будут всегда, поэтому нам есть чем заниматься.
Эта позиция имеет смысл уже в разросшейся команде — от 5 человек. Здесь управление связано с непрерывной коммуникацией как с разработчиками, так и с коллегами из других команд, с менеджментом ожиданий, ресурсов и изменений. С ростом коллектива транзакционные издержки растут, поэтому взваливать эти функции на техлида или старшего разработчика будет непродуктивно. И в здоровых командах, где следят за эффективностью, появляется Team Lead.
В таком случае и выделенного тимлида не будет. В случае, когда необходимо делать подбор релевантного разработчика для задачи, избегая групповых конфликтов интересов при выборе пердпочитаемых тасков, это должен делать тим лид. Чтобы стать тимлидом, необходимо проявлять инициативу в работе, накапливать разнообразный технический опыт, развивать коммуникативные навыки, зарабатывать авторитет в коллективе. Техлид (Tech Lead) — это ключевая профессия в сфере информационных технологий, которая представляет собой уникальное сочетание технической экспертизы и лидерских качеств. Technical Leader – это не просто продвинутый программист или инженер – это профессионал, который стоит на стыке технических и управленческих аспектов IT-проектов.
Если очень коротко, то DevOps-специалисты автоматизируют разные этапы. А зря, какой смысл описывать «неуспешную» реальность, вместо того, чтоб делиться успешным опытом? К тому же я бы так поспешно не стал обобщать, и в нашей стране отрасль развивается, компании растут не только в количестве, но и в качестве, проекты становятся все сложнее, команды становятся все опытнее.
На позиции тимлида специалист учится эффективно общаться с людьми, управлять конфликтами, строить здоровую атмосферу внутри команды. В структуре IT-компании Tech Lead занимает уникальное место. Он является лидером технической команды, но его роль выходит за рамки обычного руководства. Он участвует в формировании технической стратегии проекта, в то же время поддерживая постоянное взаимодействие с другими ключевыми фигурами, такими как продакт-менеджеры, проектные менеджеры и бизнес-аналитики.
Я вроде бы работаю только с Terraform и только с Cloud, но на самом деле постоянно имею лабиринт по разным задачам. На встрече с командой прояснили немаловажную деталь технической реализации одного модуля. Решение, о котором мы раньше с ним договаривались, приведет к снижению перфоманса отдельных операций для определенных пользователей. Хорошо, что у техлида есть видение, как это можно обойти, но новая реализация требует немного больше времени. Пишу письмо, где кратко описываю проблему и возможные решения и предлагаю встретиться на 15 минут в ближайшее время, чтобы обсудить ситуацию и определиться с финальным вариантом. Более того, задачи профессионального роста членов в бизнес требованиях вообще нет.
Технический лидер IT-команды служит мостом между технической командой и другими отделами, включая менеджмент, маркетинг, продажи и поддержку клиентов. Эффективное обсуждение с техлидом технических аспектов проекта необходимо для обеспечения правильного понимания и согласованности целей проекта. Это тот человек, который способен принять мудрое решение, учитывая человеческие и технические факторы.
В противном случае, команда будет постоянно зацикливатся на пустяках (у проблемы может быть больше одного решения), и «забывать» о договоренностях. Кстати, хорошо, если модератор не является самым лучшим спецом — это позволит ему внимательнее слушать других. Роль тимлида есть — это программист (если мы о разработчиках говорим) с правом решающего голоса и ответственностью за решения, принимаемые командой. Если на проекте хороший тимлид, то ПМ не нужен.
Второе — для эффективной координации, создания здоровой и продуктивной атмосферы и ориентации на бизнес-цели и результаты. Например, как-то у нас возник вопрос по поводу скачивания «тяжелых» файлов в разрабатываемом дополнении к нашей системе. Более опытные коллеги предложили два варианта решения инженеру, перед которым стояла эта задача. Он решил исследовать проблему с нуля и увидел недостатки в обоих решениях.
Если честно, то меня уже начинает напрягать упоминание обязанности «раздавать задачи». Ну вот и получается, что тимлид — последствие недостаточно хорошего ПМ-а. Кстати, во многие компании сейчас ищут ПМ-ов обязательно с тех. Вот только если команда слабая — тим лиду будет очень тяжело.Если продолжить твою логику то, если команда сильная, тим лид тоже «существо бесполезное».