Всем привет. Сегодня продолжаем серию публикация от Олега Мельника. В предыдущих публикациях можно прочитать о том, кто такой техлид, а также о том, чем занимается тимлид.
Олег Мельник
Technical Lead в компании Proxify, а также преподаватель в OTUS
В организациях, которые применяют каскадный процесс или команды работают разрозненно, работа обычно передается между командами. Например, бизнес-группа определяет и предоставляет требования, группа по архитектуре решения определяет решения и проекты, группа разработки или доставки реализует решения и так далее.
Как вы понимаете, из-за меньшего взаимодействия и сотрудничества между различными функциями желаемый результат может не быть достигнут, и обычно происходит доработка, потому что каждая команда сосредотачивается на своей собственной области и выполняет то, что от них просят.
В Agile-организациях команда кросс-функциональна и обладает всеми навыками, необходимыми для создания идей и запуска. Это команда, которая начинает с понимания проблем и заканчивает поиском решений. В команде из 3-10 человек, как мы согласовываем решения, как мы сотрудничаем и помогаем друг-другу добиться успеха, как мы растем и т.д.?
Владелец продукта (Product Owner) подходит к проблемам с точки зрения результата, а не решений. Это помогает создать культуру вовлеченности и сотрудничества (команда разработчиков не делает то, что ей говорят бизнесы), и помогает ей находить пути для правильных решений проблем.
Обычно в Shaping Team входит только ведущий разработчик. Это означает, что у других разработчиков меньше возможностей для роста в таких областях, как техническое лидерство, дизайн и опыт решения проблем. Это также создает единую точку отказа и делает команду менее устойчивой, например, если ведущий разработчик уходит в отпуск или уезжает. Для решения этой проблемы создается роль ведущего специалиста по модулям, и эта роль чередуется между всеми разработчиками.
Мы так и работаем с ведущими специалистами более года, и этот подход дал очень хорошие результаты, создавая равные возможности роста для всех разработчиков и помогая укреплять доверие и сотрудничество, а также делиться знаниями/навыками.
Также мы предлагаем каждому разработчику участвовать на ранней стадии процесса формирования задач, прежде чем определиться с реализациями, чтобы понять проблемы, провести мозговой штурм идей/решений/вариантов и дать свои ранние отзывы. Понятно, что все люди разные, поэтому отдельные разработчики сами решают, хотят ли они участвовать в обсуждении или нет.
Затем Shaping Team разрабатывает решения с учетом полученных отзывов и проводит встречу для окончательной проверки решения.
Что это значит для моей роли ведущего специалиста, существует ли она до сих пор?
Да, я все еще существую, и моя роль не меняется, но теперь у меня больше шансов на успех, учитывая полученные ранее отзывы. Мы надеемся повысить эффективность команды благодаря ранним отзывам.
Что отличает хороших инженеров от плохих? Что сделает мою организацию наиболее успешной? Как мне научиться лучше руководить командой инженеров? Размышляя над этими вопросами, я осознаю, что в первую очередь все начинается с меня и с примера, который я подаю своей команде.
Хороший инженер проявляет инициативу |
Плохой инженер ждет инструкций |
Хороший инженер постоянно старается стать лучше |
Плохой инженер самодоволен |
Хороший инженер творческий человек |
Плохой инженер хаотичен |
Хороший инженер дисциплинирован |
Плохой инженер непредсказуем |
Хороший инженер задает вопросы |
Плохой инженер боится показаться глупым |
Хороший инженер отвечает на вопросы |
Плохой инженер обижается |
Хороший инженер ставит команду на первое место, потому что знает, что командный успех принесет и персональный успех |
Плохой инженер сам за себя |
Хороший инженер строит отношения |
Плохой инженер строит стену |
Хороший инженер учится на неудачах |
Плохой инженер отрицает, что произошел сбой |
Хороший инженер нацелен на создание лучшего продукта |
Плохой инженер сосредоточен на создании лучших технологий |
Хороший инженер создает то, что нужно заказчику |
Плохой инженер реализует то, о чем просил заказчик |
Хороший инженер узнает своего клиента |
Плохой инженер презирает своего клиента как глупого, глупого или некомпетентного. |
У хорошего инженера есть эго, и он знает, когда его проверять |
Плохой инженер позволяет своему эго принимать решения за них |
Хороший инженер признает других хороших инженеров |
Плохой инженер хочет всеобщего признания |
Хороший инженер постоянно учится и развивается |
Плохой инженер решает вчерашние проблемы методами прошлой недели |
Хороший инженер - учитель, и он делает других инженеров лучше |
Плохой инженер - это черная дыра |
Хороший инженер владеет проблемой и ее решением |
Плохой инженер указывает на проблемы |
Хороший инженер - лидер |
Плохой инженер думает, что он один |
На этом все! Данный цикл публикаций был подготовлен в преддверии старта курса Team Lead. Подробнее узнать о курсе можно по ссылке.
Комментарии (14)
yantishko
06.10.2021 17:03+3у нас на проекте было тоже разбиение по модулям и 3 уровня бэкапа на всякий-всякий случай, один раз спасло :)
Racheengel
07.10.2021 08:50+1У плохого инженера софт тормозит больше и падает чаще, чем у хорошего.
Если софт упал, плохой инженер фиксит точечно место падения, хороший фиксит причину :)
iliasm
07.10.2021 17:11+2У хорошего инженера есть эго, и он знает, когда его проверять
по-русски так теперь тоже говорят? и в плане грамматики и в плане смысла, мне одному плохо от фразы "проверять эго"?
а так — да, мы за всё хорошее, против всей фигни
Mike-M
07.10.2021 22:25С большинством тезисов согласен, но чтобы они работали, требуется выполнение одного важного условия: тех же тезисов должен придерживаться каждый член команды.
Иначе нет смысла, скажем, сыпать гору рацпредложений тем, кто не умеет слушать и слышать.
Alex_Mtrskn
Не согласен очень с некоторыми пунктами:
Творчество и хаос - две стороны одной медали. Они друг без друга не существуют. Хороший инженер одновременно и творческая личность, но у него есть и черты хаотичности - просто он контролирует свой хаос.
Ну это вообще к любому работнику относится. Заменить "инженер" на "уборщик" и ничего не поменяется в утверждении.
Лучшие и продвинуты технологии и методы дают лучший продукт. Я бы сказал, что хороший инженер как раз сосредоточен на создании лучших технологий и методов, чтобы быстрее и качественнее создавать продукт.
Каким бы хорошим инженер не был, он никогда не сможет знать бизнес заказчика лучше чем заказчик. Также и клиентов заказчика он не будет лушче заказчика знать (ну только может если он юиксер). Поэтому представление инженера о продукте может сильно отличаться от заказчика и уход в "то, что нужно заказчику" может вылиться в редкую херню. Инженер должен в первую очередь понимать о чем просит заказчик и если надо корректировать его относительно возможностей реализации или улучшения продукта. Все остальное - мир розовых поней срущих радугой.
Ранее было: Плохой инженер сосредоточен на создании лучших технологий. Разве создание лучших технологий это не развитие? Как раз без развития лучших технологий инженер будет решать вчерашние проблемы методами прошлой недели.
Нет. Это вообще нигде не работает. Человек может быть отличным учителем, но не быть отличным инженером; также он может быть гениальным инженером, но не уметь учить. Всем, наверное, знаком феномен ВУЗовского преподавателя, когда преподаватель разбирается замечательно в теме, может двигать передовую науку, но как преподаватель он полный ноль. Преподавание - это навык, который надо развивать и над которым надо работать.
Почем хороший инженер не может указывать на проблемы? К примеру, когда проблема находится со стороны соседнего отдела или поставщика. Хороший инженер будет сообщать о проблеме либо вышестоящему руководству, либо ответственному за этот сектор в компании, а не будет тратить свое время и время своих людей на решение неспецифической задачи.
А как лидерство и одиночество связаны? Инженер может быть лидером, может делегировать, но подходить к контролю за процессами будто он один. То есть не отпускать все на самотек, а продумывать контрольные точки в разработке.
yarchex
Автор пишет со стороны своего опыта, Вы - со стороны Вашего опыта.
Вспомнил анекдот:
Судья слушает мнение одной стороны и говорит: "Я согласен с тобой"
Судья слушает мнение другой стороны и говорит: "И с тобой я тоже согласен"
Кто-то спрашивает: "Ну не может быть, чтобы оба были правы !"
Судья отвечает: "И ты тоже прав !"
Alex_Mtrskn
Нет, автор пишет со стороны вселенной с единорогами
ivanych
Просто у автора опыта больше, чем у вас. К некоторым изложенным идеям вы просто пока не готовы.
Alex_Mtrskn
Как вы быстро оценили мой опыт.
Надеюсь вы являетесь талантливым рекрутером.
Ибо по критерию из поста "Хороший инженер строит отношения" вы уже не проходите в категорию "Хороший инженер"
Ну а вообще как "хороший инженер" могли бы и расписать в чем я не прав.
Кстати, только что подумалось:
По этому критерию ни Эдисон, ни Тесла не являются хорошими инженерами (война токов).
И по этому критерию тоже оба провалились.
Ну тут как бы тоже как минимум у Эдисона провал.
Так что, мы вычеркиваем Эдисона и Теслу из списка хороших инженеров?
Alex_Mtrskn
Ну так что, комменты будут? Что с теслой и эдиссоном делаем?
ivanych
Выпейте чаю, посмотрите Смешариков, примиритесь с тем, что у автора больше опыта. Вот и всё.
Alex_Mtrskn
Слив засчитан
vya
Плохой инженер никогда не признает себя плохим инженером.
ozonar
То есть в команде должен быть только один хороший инженер? Весьма непросто работать в команде, где несколько лидеров, по моему опыту это вообще невозможно.