Статьи javatalks

В тим-лиды за 3-6 месяцев

18 апр 2020 22:36
zAlexandr Сообщения:445	Всем доброго времени суток! Ищу добровольца обкатать мою программу по наставничеству, цель которой - за 3-6 месяцев добиться трудоустройства этого самого дообровольца в роли тим-лида. Вернее это нечто среднее между наставничеством и коучингом: задача не только прокачать, но и помочь раскрыться, вдохновить. Причем поскольку речь идет о пробном заходе - все это бесплатно. Обратная связь и обсуждение сильных и слабых мест программы - это то, на что я рассчитываю взамен. Мне кажется мое предложение может быть интересно тем, кот хочет стать лидом или недавно случайно стал им (такое тоже бывает - не раз наблюдал), но кому не хватает знаний, уверенности в себе, опыта. На мой взгляд это все поправимо при наличии хорошей базы. То есть я не предлагаю вывести в лиды тех, кто только вчера свое первое "Hello, World!" написал. Нет конечно - нужен хороший стартовый уровень. Не ниже твердого мидла, по моим ощущениям. За последнее время накопилось несколько интересных идей, как этого добиваться. Кому интересно - пишите в личку. Познакомимся, поговорим голосом, попробуем определить исходные условия, цели и прочее. При наличии взаимного интереса составим индивидуальную "программу прокачки" и примемся за дело. В идеале через несколько месяцев доброволец откроет новую страницу своей профессиональной деятельности - попробует себя лидом. Коротко о себе, чтобы было понимание, на чем основана моя уверенность в возможности достижения цели. Последние несколько лет я являюсь лидом на проектах в крупнейший банках страны. Моя область - java, back-end. Специально не конкретизирую технологии и фреймворки, потому что не это станет объектом прокачки. У меня нет цели научить лучше писать код. Вовсе нет. Цель - научить успешно работать с командой: от формирования до вывода продукта в прод и дальнейшей поддержке. Помимо личного опыта у меня также есть и степень MBA, которая обогатила меня разнообразными и порой неожиданными знаниями. Я успешен, как тим-лид: и со сторны команды, и со стороны руководства у меня позитивная обратная связь. Так что, полагаю, мне есть что предложить в области наставничества. Жду откликов! Надеюсь на интересное сотрудничество! P.S. Как-то не сразу нашелся в каку ветку разместить свой пост. Тут вроде как никакой публичной дискуссии не предполагается... Ну если завяжется обсуждение - так где, как не в курилке о таком? :)

19 апр 2020 12:03
Роман Осипов Сообщения:897	Добрый день! zAlexandr: Специально не конкретизирую технологии и фреймворки, потому что не это станет объектом прокачки. Без конкретизации технологий нельзя прокачать до тимлида, так как в его зоне ответственности - выбор технологий решения задачи, понимание рисков и сроков. Можете сказать, что поможете прокачать софт скилы за полгода, но без прокачки технологий человеку тимлидом в некоторой области не стать. А таких разных областей в экосистеме Java очень много, все далеко не ограничивается протюненым Hello World на Spring Boot или на EE сервере.

19 апр 2020 12:09
zAlexandr Сообщения:445	И да, и нет... Все очень специфично для конкретного проекта, конкретной компании. Я не редко собеседую лидов - распределение обязанностей в разных компаниях сильно разнится. Часто тим-лиды (к моему удивлению) довольно слабы технически. Например, некоторые еще вводят понятие тех-лида, который как раз должен быть сосредоточен на технологической стороне вопроса. Но Вы правы в том, что тут акцент действительно на софт-скилах.

19 апр 2020 12:23
Роман Осипов Сообщения:897	zAlexandr: Например, некоторые еще вводят понятие тех-лида, который как раз должен быть сосредоточен на технологической стороне вопроса. Но Вы правы в том, что тут акцент действительно на софт-скилах. У вас в компаниях было разделение на руководителей проектов и на тимлидов по должностям? Или должности совмещались? То, о чем вы говорите, больше похоже на прокачку РП. Для тимлида из софт-скилов достаточно поддерживать нормальную психологическую обстановку в команде, за остальное отвечает РП.

19 апр 2020 13:26
zAlexandr Сообщения:445	Тут я уже не согласен - РП это более высокая гранулярность, так как на одном проекте (под одним РП) может быть несоклько команд, каждую из которых драйвит лид. И РП может в команду вообще не "заходить", ограничиваясь общением с лидами. Конечно в разных компаниях все очень и очень специфично. Мой же последний опыт таков, что тим-лид отвечает за результат, который выдает команда. На нем и формирование команды, и ревью, и delivery готовой функциональности. И это резко контрастирует с тем, как мне недавно коллега на собеседовании рассказывал, что у них в команде есть специальный человек, который занимается ТОЛЬКО ревью. Тим-лид же что-то вроде королевы в Великобритании. Если же вернуться к моему предложению, то, например, среди прочего, я бы хотел заострить внимание на ревью кода. Что стоит смотреть внимательно, а что по диагонали; как дать обратную связь (положительную или отрицательную). И очень не хочется вязнуть в мелочах, потому что это наставничество-коучинг, а не книга рецептов. Как дать корректную обратную связь по ревью новичку, который написал полную чепухню... (да еще и тестами не покрыл). Дадите резко - можете подавить инициативу; дадите слишком мягко - будет косячить и дальше, а лид будет тратить свое время на комменты и дальше, подчищая все ляпы. Или вот собеседование... Много ли людей умеют его проходить, а тем более проводить? Стоит ли, собеседуя, например, в Сбер в прикладную команду на мидла, распрашивать про особенности работы GC? А Вы умеете необидно закончить собеседование через 10 минут после начала, если видите, что кандидат вообще никакой? Или спалите на него цулый час, соблюдая приличия (хотя отказ очевиден уже в самом начале)? Это тоже софт-скил и это работа лида (в моем понимании). Не думаю что стоит больше времени уделить тому, как поднимается контекст спринга, но при этом упустить, некоторые базовые вещи в области ТК (аттестации, прохождение испытательного срока) или же деловой переписке. Если человек не знает, как try-catch отработает, то мы просто не сможем начать - предполагается, что все это уже есть. Так что софт-скилов у хорошего лида вагон и маленькая тележка должно быть.

19 апр 2020 20:21
Староверъ Сообщения:10008	Роман Осипов: Без конкретизации технологий нельзя прокачать до тимлида, так как в его зоне ответственности - выбор технологий решения задачи, понимание рисков и сроков. Даже если в роль лида входит выбор технологий - это не означает что лид (как и разработчик) должен затачиваться на какие-то конкретные технологии. Одним из возможных навыков для прокачки может быть как раз умение выбрать среди технологий в которых не силен, а затем и процесс погружения в них. Но в целом по теме вродь понятно что речь идет про стратегию/свое поведение/про ведение проекта. Роман Осипов: Для тимлида из софт-скилов достаточно поддерживать нормальную психологическую обстановку в команде, за остальное отвечает РП. Да вроде знание процессов, как и другие навыки РП, лиду тоже не помешают (я б даже сказал являются обязательными, но возможно у меня в этом плане завышенные ожидания). Часто менеджеры сильно не разбираются в дев процессах (JIT/ToC/CD), а неплохо бы чтоб кто-то разбирался. Особенно учитывая что в части этих процессов (CI и CD) много технических аспектов. Courses: Java Beginner, Java Professional \| Downsides of anemic model
	Изменен:19 апр 2020 18:33

19 апр 2020 23:57
Роман Осипов Сообщения:897	Староверъ: Даже если в роль лида входит выбор технологий - это не означает что лид (как и разработчик) должен затачиваться на какие-то конкретные технологии. Одним из возможных навыков для прокачки может быть как раз умение выбрать среди технологий в которых не силен, а затем и процесс погружения в них. Но в целом по теме вродь понятно что речь идет про стратегию/свое поведение/про ведение проекта. Умение выбрать среди технологий в которых не силен весьма зыбкая тема - высока цена ошибки. Часто технология является именно тем, чем преподносится авторами? На моей практике не припомню таких - везде есть недостатки, про которые явно и не узнаешь, пока не попробуешь. Вот, например, я последние четыре года занимаюсь интеграцией. Есть простая с виду задача гарантированной упорядоченной доставки данных из БД Oracle на десятки тысяч клиентов и обратно, данные не должны теряться от слова совсем. Вот, допустим вы тимлид и надо решить эту задачу пользуясь своей общей эрудицией, продумать архитектуру. Какие технологии выберете? Уверен, что в любом вашем решении сейчас будут существенные недостатки, т.к. надо погрузиться в технологии попробовать их, а уже потом принимать решения. Ценность тимлидов без узкой специализации на мой взгляд сомнительна. Староверъ: Да вроде знание процессов, как и другие навыки РП, лиду тоже не помешают (я б даже сказал являются обязательными, но возможно у меня в этом плане завышенные ожидания). Часто менеджеры сильно не разбираются в дев процессах (JIT/ToC/CD), а неплохо бы чтоб кто-то разбирался. Особенно учитывая что в части этих процессов (CI и CD) много технических аспектов. У нас почему-то принято взваливать задачи не на тех кто должен, а на тех кто может. Почему тимлид должен выполнять задачи аналитика, РП или девопса?

20 апр 2020 08:42
zAlexandr Сообщения:445	Роман, я полагаю у нас всех тут довольно интересный и разообразный опыт. Любая сложная задача многогранна. Наличие необходимости знаний в предметной области не отменяет наличия других аспектов. А попытка объять необъятное - значит потратить много времени, денег, но не получить результата. Так, например, еще одним важным навыком лида является умение сосредоточиться на конкретной задаче и довести ее до завершения. Возможно слышали расхожее выражение, про то, как делаются дела на постсоветском пространстве: "Если хотите делать бизнес в России - привыкайте часами совещаться и ни к чему не приходить". Обидный для нас взгляд со стороны, правда? Мы отвлеклись от темы. У меня есть прдложение: на безвозмездной основе я готов выступить в роли наставника. Критерием достижения цели считаю трудоустройство в роли лида. При этом на все это должно уйти не более полугода. Наиболее вероятно - 3 месяца. Но это зависит от стартовых условий. Кому интересно - приглашаю к общению.

20 апр 2020 10:14
Роман Осипов Сообщения:897	Ок, даже интересно, найдете ли учеников. Нормальный мидл и так загружен задачами на пол года вперед, ему от технологий бы не отстать хотя бы - cо временем он сам мутирует в тимлида или сеньера. И почему есть уверенность, что ваши знания, которые вы собираетесь передать - истинные и не введут человека в заблуждение? Если есть желание нести свет в массы - лучше напишите книгу, и если она действительно будет полезна, то вы окажете помощь гораздо большему кругу лиц.
	Изменен:20 апр 2020 08:16

20 апр 2020 10:30
zAlexandr Сообщения:445	Роман, Вы несколько категоричны. Мои знания безусловно не истинны, потому как тут в принципе нет "правильно и не правильно". Есть работающие, обкатанные практикой подходы, которые успешно применяются последние годы. Есть серьезный бэкграунд в виде пройденного обучения. Кому-то эти наработки и опыт подойдут, кому-то нет. И я бы не замахивался на такие громкие фразы, как "ученики". К наставничеству это еще более-менее может быть применимо, но к коучингу - вообще не подходит расстановка "ученик-учитель". Что же каксается "сам мутирует", то тут не соглашусь. Человек может хотеть стать лидом, но по ряду причин постоянно откладывать практические шаги к этому. Часто люди тормозят себя своей неуверенностью: "я еще не готов" или же наоборот "староват я уже, чтобы меняться". А кто-то да, выходит в эту плоскость как-то сам естественным образом развившись. Мог бы трансформироваться раньше на пару-тройку лет, если бы ему помогли. Но и так справился. Словом, это очень специфично. Как scrum - кому-то подходит, кому-то нет. Но все приэтом понимаю, что это не единственный выбор и возможны варианты.

20 апр 2020 11:13
Староверъ Сообщения:10008	Роман Осипов: Умение выбрать среди технологий в которых не силен весьма зыбкая тема - высока цена ошибки. Часто технология является именно тем, чем преподносится авторами? На моей практике не припомню таких - везде есть недостатки, про которые явно и не узнаешь, пока не попробуешь. Конечно лучше знать чем не знать, уметь чем не уметь. Но на практике приходится так же решать и задачи в которых не разбираешься. И в таких случаях нужно провести анализ возможных решений, попытаться не допустить ошибку. Конечно чем сложней и обширней задача, тем выше вероятность ошибки. Ну и че? Сделать все равно надо. Роман Осипов: У нас почему-то принято взваливать задачи не на тех кто должен, а на тех кто может. Почему тимлид должен выполнять задачи аналитика, РП или девопса? Лид ведет за собой команду. Как он ее может вести за собой если он не умеет создавать продукт, не знает как распределять задачи, в какой последовательности что делать, как приоритеты расставить, как настроить CI, какой стратегии ветвления следовать, как выстроить тестирование и пр? Если лид - это чел который лучше всех кодит, ну так это просто самый опытный разработчик в команде. За неимением настоящего лида этот самый опытный и будет называться лидом, это частый сценарий. Но говорить что все эти задачи по определению не лидские.. Уф. И вообще на это все можно же и с обратной стороны посмотреть - счас можно встретить команды с таким ролями как BE dev, UI dev, UX, верстальщик, UI designer, DBA, BA, Team Lead, Architect, QA, AQA, PM, Ops. Зоопарк. И возможно многие такие роли возникают в командах именно потому что разработчики кроме как накодить ничего не умеют? Конечно все знать нельзя.. Но это также не значит что нужно уходить в другую крайность и кроме кодинга ничего не знать, расчитывать что наймут кого-то другого кто будет знать вместо тебя. zAlexandr: Как scrum - кому-то подходит, кому-то нет. Я уже совсем уж оффтоплю.. Но Scrum никому не подходит :) Это давно уже устаревшее виденье. Он выгодно выделяется только если сравнивать с жестким вотерфолом обвешенным бюрократией. Courses: Java Beginner, Java Professional \| Downsides of anemic model
	Изменен:20 апр 2020 09:32

20 апр 2020 11:40
Роман Осипов Сообщения:897	Староверъ: Ну и че? Сделать все равно надо. Зачастую лучше честно признаться, что знаний не хватает и лучше ничего не делать, чем потом тащить неправильную архитектуру, чтобы потом выбросить все и переделывать. Или хотя бы обозначить заказчику риски, что может быть надо будет со временем все выбросить - это профессиональный подход. К сожалению разработчики часто замалчивают/берут эти риски на себя, а потом мы имеем то что имеем. Староверъ: Но это также не значит что нужно уходить в другую крайность и кроме кодинга ничего не знать, расчитывать что наймут кого-то другого кто будет знать вместо тебя. Во первых это дэмпинг и штрейкбрехерство. Во вторых, чтобы успешно кодить - надо знать, что конкретно кодить, прорабатывать архитектуру. И здесь и так достаточно проблем для кодера, чтобы отвлекаться на чужие задачи. Если кодер занимается не своими задачами, то он зачастую не эффективен, т.к. талантливых одновременно во всех областях людей очень ограниченное количество. И вероятность, что хорошего кодера выставят на мороз, мне кажется не очень велика, чтобы заморачиваться прокачкой софт-скилов. Почему в коде вы придерживаетесь SRP, а в жизни - нет?
	Изменен:20 апр 2020 09:44

20 апр 2020 13:10
zAlexandr Сообщения:445	Какая неожиданно бурная дискуссия получается! Спасибо, кстати, помогло мне понять плохую подачу моего предложения. Сформулировал бы точнее - вряд ли бы нашлось о чем поговорить. Староверъ: Но Scrum никому не подходит :) Это давно уже устаревшее виденье. Он выгодно выделяется только если сравнивать с жестким вотерфолом обвешенным бюрократией. Соглашусь. Для более-менее сложного проекта он не подойдет. Но... есть такие компании, как Сбер, ВТБ и другой крупняк, которые по нему пытаются работать. И это данность, как гравитация или скорость света в вакууме - нужно знать и учитывать в своей работе особенности прочтения методологии у конкретного работодателя. Роман Осипов: Или хотя бы обозначить заказчику риски, что может быть надо будет со временем все выбросить - это профессиональный подход. К сожалению разработчики часто замалчивают/берут эти риски на себя, а потом мы имеем то что имеем. Вот Вы, кстати, интересно подсветили еще один важный для лида скил - умение общаться с заказчиком. И да, те лиды, которые не успели сформироваться лидами, а были назначены просто как самые опытные разработчики - часто недорабатывают в коммуникациях, а потом огребает вся команда. Еще раз обращу внимание: на мой взгляд мы слишком жарко дискутируем что правильно, а что нет. Нет тут правильного ответа. Есть работающие или не работающие практики. Есть работодатели, которые придерживаются определенных подходов и ценностей. И чтобы получить у них хорошо оплачиваемую работу нужно понять и принять его ценности. И не в абстрактном, а именно в конкретном контексте нужно стать эффективным производственником.

20 апр 2020 13:18
Роман Осипов Сообщения:897	Как стать мидлом за 2.5 месяца, кстати, работающий рецепт есть: https://javarush.ru/groups/posts/com.javarush.story.18

20 апр 2020 14:07
zAlexandr Сообщения:445	А ведь зацепило Ваше сравнение моего предложения с JavaRush... :) Если бы открывал школу джунов, то сравнение бы мне пожалуй польстило, а тут скорее обидно.

Модераторы:Нет
Сейчас эту тему просматривают:Нет