Согласен, игнорирование проблем команды - также является ошибкой тимлида. Коммуникация - важный инструмент управления, и без нее сложно создать сильную и эффективную команду. Важно не просто слушать, а еще и слышать коллег, учитывать их мнение. Баланс между авторитарностью и открытостью к диалогу - важная задача.
пока это ружье не снесет пол лица функционалу при попытке расширения
Верно сказано! Могу только дополнить, что отсутствие рефакторинга, если он сильно нужен проекту, может привести к удорожания поддержки или внедрению новых фич в проект.
По сути, задача тимлида - поставить проект на рельсы. В эту задачу также входит и развитие команды, в том числе научить их самостоятельности. "Само" ничего работать не будет)
Уже пора смириться с тем, что произошла смена поколений и на смену взрослым людям приходят выпускники ВУЗов и курсов. И с такими людьми можно успешно строить команду.
Далеко не все молодые разработчики таки. Многое зависит от подхода к их адаптации и обучению.
В статье меня это порадовало: "Техзадание: «Сделать авторизацию на сайте»". И что это плохо.
А что в этом хорошего?) ТЗ/спецификации должны содержать все информацию, для того чтобы разработчик мог успешно выполнить задачу и ее потом протестировали. Я не поддерживаю подход, когда в тикете написано "Нужно сделать авторизацию. Инфу дам на созвоне". Как в таком случае потом пройдет тестировании задачи? "Оперативная память" человека не настолько велика, чтобы все нюансы запомнить на созвоне. А когда все перед глазами, то и тимлид/техлид смогут сразу сказать, что есть нюансы в этой фиче, разработчик четко выполнит задачу с первого раза (баги не считаем) и тп.
Ну сейчас ИИ эпоха. И кодер, которому нужна разжёванная постановка до последней детальки - ну пойдет в жпт чат вобъёт её - получит код и будет чилить
Не спорю, ИИ упрощает работу и может дать базу. Но вот качество такого кода под вопросом... Потом мы удивляемся, почему с ИБ все плохо, с архитектурой проекта все плохо и тп и тд
Согласен, это действительно неприятная проблема, не только для сотрудников, но и я для бизнеса в целом. Тимлид не должен вести себя подобным образом! Задача тимлида - быть лидером команды и проекта, а не приватизировать себе интересные задачи. Челленджами обязательно нужно делиться с командой, чтобы развивать экспертизу
Это здорово, когда в команде поддерживается такая атмосфера! Видно, что у Вас доверие и взаимопонимание на высоком уровне)
Но у меня есть вопрос: если руководитель поручает Вам рулить проектом, значит, Вы уже не просто участник, а тот, кто несет ответственность за его успех. Бывало ли, что приходилось балансировать между поддержанием такой дружеской атмосферы и необходимостью быть более требовательным?
На моем опыте, примерно 10% ушли сами по какой-либо причине, с остальными пришлось расстаться по нашей инициативе. То есть 1-2 из 10 отсеянных джунов уходят по своему желанию.
Остальные джуны, которые к нам приходят, работают по 1.5+ лет.
Тут, на самом деле, еще нужно понимать из-за чего уходят джуны. Причины могут быть разными. Например, джун мог начать упираться в потолок в плане развития (да, через полгода тоже можно начать упираться). Или же процесс повышения ЗП выстроен не совсем корректно, но это уже совсем другая история.
Резюме: с текучкой нужно работать и искать причины, почему через полгода люди уходят из компании. Как по мне, полгода очень малый срок, особенно для джуна.
Опыта с возрастными джунам не очень много, всего несколько кейсов. И опыт этот больше положительный, чем негативный. Возрастных джунов можно разделить на 2 категории: новички, с опытом. С новичками чуть проще, так как их нужно учить, а не переучивать.
В целом, если человек понимает, что он джун, не имеет комплексов по типу: "как это мной, 40-летним мужиком, будет руководить 25 летний пацан", развивается и тд, то для меня нет особой разницы 20 лет тебе или 38.
Вспомнился мем на эту тему:
Я тридцатилетний джун, и все синьоры в офисе младше меня. В итоге они рассказывают мне, как правильно писать код, а я рассказываю им как правильно сидеть, чтоб спина не болела.
Как и говорилось в статье - менторить не для всех. Лично мне доставляет большое удовольствие наблюдать за ростом свои сотрудников. Видеть, как твой ученик уверенно набирается опыта и знаний намного ценнее, чем какая-либо финансовая мотивация.
Потому, тут дело не в реальности, а в самом отношении человека к этому делу)
На самом деле особой разницы, какого возраста будет джун. Если человек готов показывать уровень, развиваться и учиться, то зеленый свет и не важно, 20 лет тебе или под 40.
Как по мне, основная проблема возрастных джунов - деньги. Часто это люди с семьями или другими обязательствами (ипотека например). Получать ЗП джуна они часто не готовы.
Согласен. Я всегда за то, чтобы на берегу определить ожидаемый результат и оформить все в виду документа - ТЗ.
Согласен, игнорирование проблем команды - также является ошибкой тимлида. Коммуникация - важный инструмент управления, и без нее сложно создать сильную и эффективную команду. Важно не просто слушать, а еще и слышать коллег, учитывать их мнение. Баланс между авторитарностью и открытостью к диалогу - важная задача.
Верно сказано! Могу только дополнить, что отсутствие рефакторинга, если он сильно нужен проекту, может привести к удорожания поддержки или внедрению новых фич в проект.
По сути, задача тимлида - поставить проект на рельсы. В эту задачу также входит и развитие команды, в том числе научить их самостоятельности. "Само" ничего работать не будет)
Уже пора смириться с тем, что произошла смена поколений и на смену взрослым людям приходят выпускники ВУЗов и курсов. И с такими людьми можно успешно строить команду.
Далеко не все молодые разработчики таки. Многое зависит от подхода к их адаптации и обучению.
А что в этом хорошего?) ТЗ/спецификации должны содержать все информацию, для того чтобы разработчик мог успешно выполнить задачу и ее потом протестировали. Я не поддерживаю подход, когда в тикете написано "Нужно сделать авторизацию. Инфу дам на созвоне". Как в таком случае потом пройдет тестировании задачи? "Оперативная память" человека не настолько велика, чтобы все нюансы запомнить на созвоне. А когда все перед глазами, то и тимлид/техлид смогут сразу сказать, что есть нюансы в этой фиче, разработчик четко выполнит задачу с первого раза (баги не считаем) и тп.
Не спорю, ИИ упрощает работу и может дать базу. Но вот качество такого кода под вопросом... Потом мы удивляемся, почему с ИБ все плохо, с архитектурой проекта все плохо и тп и тд
TeamLead - это лидер команды. На то он и лидер, что вести людей за собой. Молодое поколение прекрасно поддается воспитанию
P.S. всегда можно напомнить, что у машин есть замечательная вещь - багажник :)
Согласен, это действительно неприятная проблема, не только для сотрудников, но и я для бизнеса в целом. Тимлид не должен вести себя подобным образом! Задача тимлида - быть лидером команды и проекта, а не приватизировать себе интересные задачи. Челленджами обязательно нужно делиться с командой, чтобы развивать экспертизу
Это здорово, когда в команде поддерживается такая атмосфера! Видно, что у Вас доверие и взаимопонимание на высоком уровне)
Но у меня есть вопрос: если руководитель поручает Вам рулить проектом, значит, Вы уже не просто участник, а тот, кто несет ответственность за его успех. Бывало ли, что приходилось балансировать между поддержанием такой дружеской атмосферы и необходимостью быть более требовательным?
Могу порекомендовать крутой инструмент "5 почему". С его помощью можно попробовать добраться до сути.
Также хорошая практика - cross-ревью. Часто это "заходит" ребятам и они более ответственно подходят к ревью и написанию кода.
Возможно также, что в команде не хватает сильного человека, который сможет взять на себя ревью и разгрузить Вас.
На моем опыте, примерно 10% ушли сами по какой-либо причине, с остальными пришлось расстаться по нашей инициативе. То есть 1-2 из 10 отсеянных джунов уходят по своему желанию.
Остальные джуны, которые к нам приходят, работают по 1.5+ лет.
Тут, на самом деле, еще нужно понимать из-за чего уходят джуны. Причины могут быть разными. Например, джун мог начать упираться в потолок в плане развития (да, через полгода тоже можно начать упираться). Или же процесс повышения ЗП выстроен не совсем корректно, но это уже совсем другая история.
Резюме: с текучкой нужно работать и искать причины, почему через полгода люди уходят из компании. Как по мне, полгода очень малый срок, особенно для джуна.
Опыта с возрастными джунам не очень много, всего несколько кейсов. И опыт этот больше положительный, чем негативный. Возрастных джунов можно разделить на 2 категории: новички, с опытом. С новичками чуть проще, так как их нужно учить, а не переучивать.
В целом, если человек понимает, что он джун, не имеет комплексов по типу: "как это мной, 40-летним мужиком, будет руководить 25 летний пацан", развивается и тд, то для меня нет особой разницы 20 лет тебе или 38.
Вспомнился мем на эту тему:
Как и говорилось в статье - менторить не для всех. Лично мне доставляет большое удовольствие наблюдать за ростом свои сотрудников. Видеть, как твой ученик уверенно набирается опыта и знаний намного ценнее, чем какая-либо финансовая мотивация.
Потому, тут дело не в реальности, а в самом отношении человека к этому делу)
На самом деле особой разницы, какого возраста будет джун. Если человек готов показывать уровень, развиваться и учиться, то зеленый свет и не важно, 20 лет тебе или под 40.
Как по мне, основная проблема возрастных джунов - деньги. Часто это люди с семьями или другими обязательствами (ипотека например). Получать ЗП джуна они часто не готовы.
График усредненный. В среднем через 4-6 месяцев джун начинает приносить прибыль.
около 60% джунов активно работают и показывают рост
Мне, как тимлиду, достаются уже прошедшие все этапы джуны. Наймом, стажировками и прочим занимаются другие ребята. Про это они рассказали в статье: https://habr.com/ru/companies/agima/articles/828454/