Всем привет. Сегодня продолжаем серию публикация от Олега Мельника. В предыдущих публикациях можно прочитать о том, кто такой техлид, а также о том, чем занимается тимлид.
Олег Мельник
Technical Lead в компании Proxify, а также преподаватель в OTUS
В организациях, которые применяют каскадный процесс или команды работают разрозненно, работа обычно передается между командами. Например, бизнес-группа определяет и предоставляет требования, группа по архитектуре решения определяет решения и проекты, группа разработки или доставки реализует решения и так далее.
Как вы понимаете, из-за меньшего взаимодействия и сотрудничества между различными функциями желаемый результат может не быть достигнут, и обычно происходит доработка, потому что каждая команда сосредотачивается на своей собственной области и выполняет то, что от них просят.
В Agile-организациях команда кросс-функциональна и обладает всеми навыками, необходимыми для создания идей и запуска. Это команда, которая начинает с понимания проблем и заканчивает поиском решений. В команде из 3-10 человек, как мы согласовываем решения, как мы сотрудничаем и помогаем друг-другу добиться успеха, как мы растем и т.д.?
Владелец продукта (Product Owner) подходит к проблемам с точки зрения результата, а не решений. Это помогает создать культуру вовлеченности и сотрудничества (команда разработчиков не делает то, что ей говорят бизнесы), и помогает ей находить пути для правильных решений проблем.
Обычно в Shaping Team входит только ведущий разработчик. Это означает, что у других разработчиков меньше возможностей для роста в таких областях, как техническое лидерство, дизайн и опыт решения проблем. Это также создает единую точку отказа и делает команду менее устойчивой, например, если ведущий разработчик уходит в отпуск или уезжает. Для решения этой проблемы создается роль ведущего специалиста по модулям, и эта роль чередуется между всеми разработчиками.
Мы так и работаем с ведущими специалистами более года, и этот подход дал очень хорошие результаты, создавая равные возможности роста для всех разработчиков и помогая укреплять доверие и сотрудничество, а также делиться знаниями/навыками.
Также мы предлагаем каждому разработчику участвовать на ранней стадии процесса формирования задач, прежде чем определиться с реализациями, чтобы понять проблемы, провести мозговой штурм идей/решений/вариантов и дать свои ранние отзывы. Понятно, что все люди разные, поэтому отдельные разработчики сами решают, хотят ли они участвовать в обсуждении или нет.
Затем Shaping Team разрабатывает решения с учетом полученных отзывов и проводит встречу для окончательной проверки решения.
Что это значит для моей роли ведущего специалиста, существует ли она до сих пор?
Да, я все еще существую, и моя роль не меняется, но теперь у меня больше шансов на успех, учитывая полученные ранее отзывы. Мы надеемся повысить эффективность команды благодаря ранним отзывам.
Что отличает хороших инженеров от плохих? Что сделает мою организацию наиболее успешной? Как мне научиться лучше руководить командой инженеров? Размышляя над этими вопросами, я осознаю, что в первую очередь все начинается с меня и с примера, который я подаю своей команде.
Хороший инженер проявляет инициативу | Плохой инженер ждет инструкций |
Хороший инженер постоянно старается стать лучше | Плохой инженер самодоволен |
Хороший инженер творческий человек | Плохой инженер хаотичен |
Хороший инженер дисциплинирован | Плохой инженер непредсказуем |
Хороший инженер задает вопросы | Плохой инженер боится показаться глупым |
Хороший инженер отвечает на вопросы | Плохой инженер обижается |
Хороший инженер ставит команду на первое место, потому что знает, что командный успех принесет и персональный успех | Плохой инженер сам за себя |
Хороший инженер строит отношения | Плохой инженер строит стену |
Хороший инженер учится на неудачах | Плохой инженер отрицает, что произошел сбой |
Хороший инженер нацелен на создание лучшего продукта | Плохой инженер сосредоточен на создании лучших технологий |
Хороший инженер создает то, что нужно заказчику | Плохой инженер реализует то, о чем просил заказчик |
Хороший инженер узнает своего клиента | Плохой инженер презирает своего клиента как глупого, глупого или некомпетентного. |
У хорошего инженера есть эго, и он знает, когда его проверять | Плохой инженер позволяет своему эго принимать решения за них |
Хороший инженер признает других хороших инженеров | Плохой инженер хочет всеобщего признания |
Хороший инженер постоянно учится и развивается | Плохой инженер решает вчерашние проблемы методами прошлой недели |
Хороший инженер - учитель, и он делает других инженеров лучше | Плохой инженер - это черная дыра |
Хороший инженер владеет проблемой и ее решением | Плохой инженер указывает на проблемы |
Хороший инженер - лидер | Плохой инженер думает, что он один |
На этом все! Данный цикл публикаций был подготовлен в преддверии старта курса Team Lead. Подробнее узнать о курсе можно по ссылке.
