Комментарии 90
"Лучше день потерять, а потом за пять минут долететь" (с)
Прям басня Крылова получилась :) но мне очень понравилась, отличная басня!
Имхо, тут дело не только в разных стратегиях, примененных Колей и Васей. Преобладающую роль играет характер и лидерские способности, которые не у всех бывают и которые, в принципе, наверное можно искусственно развить, но это трудно. Предположу, что у Коли таких способностей изначально не было, а у Васи были. Я много раз наблюдал как при одинаковых условиях старта кто-то легко становился лидом и легко подчинял команду, причем люди подчинялись с удовольствием, а кто-то при всем старании становился чуть ли не изгоем и скатывался в вечные склоки с командой и в конце концов сходил с дистанции.
У Коли просто не было опыта общения с оборзевшими сотрудниками. Такое не только на работе встречается, а ещё в семье, с друзьями и т.д. Думаю если бы Коле подсказали как вести себя в такой ситуации, всё бы решилось иначе.
В некоторых компаниях тимлиды (и не только) как бы в постоянном соревновании между собой. Это не всегда хорошо, но частенько бывает, когда идет борьба за KPI и премии. При таком раскладе Коле не только не подскажут, а еще и неправильно подскажут и подпихнут ногой. :-)
Опыт конечно важен но свойства характера никуда не денутся. Иногда их можно опытом преодолеть, а иногда его нет.
Не, тут ключевое именно стратегия.
Тут играют два момента:
Нельзя замыкать все на себе. Да, это греет ЧСВ, важный шишка, без тебя работа не работается. Для некоторых это стратегия выживания - незаменимого не уволить. Но это плохо для команды - незаменимых в команде быть не должно, но могут быть в чём-то уникальные специалисты, вот их и надо взращивать. Плохо для бизнеса - незаменимые это фактор отказа, причем внезапного отказа. И плохо для самого специалиста - это не только тормозит его развитие, но и перегружает лишней работой. Нужно делегировать максимум из того, что вообще можно делегировать, иначе эффективное управление не построить.
Экспертиза и самостоятельность. Если джуны не будут получать опыт самостоятельно, если их слишком опекать, если устранить фактор отбора, если решать проблемы за них, они не вырастут. Такой подход фактически лишает их опыта и экспертизы, и убивает в них самостоятельность, инициативу. Они ждут указку сверху и верят что ты все за них решишь и разрулишь. Это плохой подход. Гораздо эффективнее позволить им собирать свои ошибки самостоятельно, нарабатывать опыт. А свою экспертизу стоит использовать для подсказок и ненавязчивого направления в правильную сторону. Стоит стать консультантом для них. Твоя экспертиза их подстрахует, и они это знают, в остальном они вольны принимать решения сами, в том числе неправильные, и пожинать последствия своих ошибок. Внешне конечно это выглядит не очень, много ошибок по началу, но это ожидаемо - нельзя делать работу за них, но можно направлять и давать обратную связь. И ни в коем случае нельзя отнимать задачи или фиксить их ошибки - это мощный удар по самолюбию и их самостоятельности, по мотивации делать свою работу хорошо, по стремлению к совершенству. Они четко должны знать, что свои косяки будут разгребать сами, так что в их же интересах все сделать хорошо. И они должны боятся, что их код улетит на прод без проверки и наделает там проблем, что за ответом пройдут именно к ним. Конечно самые жёсткие косяки нужно пресекать, возвращать на доработку, но всякую мелочь нужно оставлять. Такой подход не только тебя разгружает, но и даёт огромный буст к опыту твоей команды. И они к тебе приходят не по мелочам, как в первом, а только для консультаций о чем-то, что их опыту пока не по плечам или вызывает сомнения.
Цель, если можно так выразиться – парни, сделайте что-нибудь классное.
Ни у Коли, ни у Васи особого опыта работы с подчинёнными не было
Мне кажется, что первая проблема возникла еще где-то здесь - когда двум людям, которые до тех пор не руководили командой поручили лидерские задачи с максимально размытыми требованиями, по принципу "ну они же эксперты - справятся"
По-моему, это довольно часто встречающаяся проблема в компаниях, которые хотят растить специалистов с менеджерской направленностью (лидов/линейных менеджеров и т.д.), никогда не прибегая к найму сложившихся специалистов извне. Проработал сколько-то лет в компании, успешно завершил несколько проектов как технический специалист - значит, готов не только вводить в курс дела новых коллег, но и следить за их развитием на проектах, к которым ты никакого отношения никогда не имел.
По-хорошему - компания должна была подойти с умом к процессу выращивания новых специалистов: посмотреть сложившиеся практики в других компаниях, на то, сколько людей обычно вовлечено в процесс обучения/вовлечения (training manager, ментор, линейный менеджер, проектный менеджер, technical lead...) и хотя бы часть людей нанять с внешнего рынка, иначе получается, что должен тащить человек-оркестр (Вася или Коля). Многие могут такую нагрузку попросту не потянуть.
не берусь судить, кто из друзей правСтандартная ситуация — крайности плохи, нужен баланс между ними.
Неестественный рассказ. Не клеится связка лето осень. У Коли джуны летом все задачи щёлкали, прям не хуже него, а осенью он ничегошеньки не смог им объяснить уже. Вася его отравил мышьяком? Моцарт и Сальери?
Не сочтите за паранойю, у нас деревенские традиции такие есть, а пол-России в третьем поколении оттуда. Я сталкивался и лично и по рассказам с глупыми и завистливыми людьми
Так в статье же прямо написано. Джуны просекли что выгоднее быть жертвой и ничего не делать за туже зп, т.к. Коля забыл прописывать по жопе в случае факапов и просто выполняет их работу.
С точки зрения компании молодец Вася. Он организовал конвейер по производству кадров внутри компании.
С точки зрения разработчиков - молодец Коля. Он показал компании что он весьма важен для компании. А значит при просьбе такого работника повысить ЗП компания, как минимум рассмотрит такой вариант, а не отправит "за забор".
С точки зрения разработчиков - молодец Коля. Он показал компании что он весьма важен для компании. А значит при просьбе такого работника повысить ЗП компания, как минимум рассмотрит такой вариант, а не отправит "за забор".
Не поможет, потому что Коля со своими отделом - не единственный в компании, кроме него имеется целый отдел с Васей во главе.
PS Работал я с таким токсичным козлом, который для вас "молодец". Чтобы быть незаменимым, он постоянно организовал конфликты, склоки и подставы, так чтобы все кто с ним работал не выдерживали с ним более нескольких месяцев. Начальство хотело иметь отдел, а главой отдела поставило этого козла, который постоянно занимался токсичной травлей своих подчинённых, так что они сами увольнялись, а он таким образом продолжал быть незаменимым. И он не выращивал джунов, как Коля из статьи, а специально нанимал опытных разработчиков, чтобы они были недовольны когда об них постоянно вытирают ноги, и сами уходили от него.
Не поможет, потому что Коля - не единственный в компании, кроме него имеется целый отдел с Васей во главе.
В данном случае действия Васи действительно свели на нет все действия Коли. Но ведь в сказочке говорится что "Между собой наши герои почти не общались – некогда было". Собственно именно поэтому выиграла компания.
Разделяй и властвуй - лозунг на все времена.
И что стало с фирмой?
С точки зрения компании молодец Вася. Он организовал конвейер по производству кадров внутри компании.
А компании это точно нужно - производить кадры. Кадры таким образом ведь производятся не для себя, а для рынка. И получившимся в результате мидам придется платить по рынку, то есть больше - иначе сбегут.
Для компании было бы идеально, чтобы джуны становились джунами-специалистами, то бишь кодерами: способными делать куски решений по технологиям, используемым в компании, но не способными ни делать целостное решение, ни, тем более, ставить себе задачи, общаясь самостоятельно с заказчиками. Такие специализированные кодеры вполне могут производительно работать на компанию не хуже мидов-универсалов, но вот денег им за это сильно больше платить не надо - куда они денутся-то.
Однако для использования таких кодеров нужен специалист, который будет разбираться с постановкой задачи и нарезать ее на куски для кодеров. Ни из Коли, ни из Васи такого специалиста не получилось. И что-то я вообще не вижу, чтобы такое хоть сколько-нибудь массово получалось в индустрии разработки программ.
А вот для разработчиков это как раз и хорошо, что не получается: у них есть массовая возможность заниматься более творческой работой, причем за значительно большие деньги.
И получившимся в результате мидам придется платить по рынку, то есть больше - иначе сбегут.
Вообще, выращенным мидлам можно платить немного ниже рынка, мало кто меняет привычную работу, на которой вырос как специалист, на +20% к зарплате, особенно если на текущем месте хотя бы раз в год да происходит прибавка. Ну и опять же таки, толковый миддл делает работу быстрее и качественнее, чем толковый продвинутый джун, и с него и доход заметно больше получается. Поэтому в типичном случае от роста сотрудников выигрывают все, и сами сотрудники, и компания.
Разница зарплат джуна и мидла в РФ, ЕМНИП - она далеко не 20%, а раза в два. Но проблема отрасли разработки в том, что она в массе своей не научилась разделять задачи на части разной сложности и поручать выполнение менее сложных задач менее квалифицированному персоналу. Т.е., если брать аналогии с промышленностью, то разработка ПО так и не перешла от стадии ремесленного производства к стадии мануфактуры.
PS Как это можно сделать (и можно ли вообще - в этом тоже есть сомнения) - не знаю, утверждать ничего не буду. Просто описываю сложившееся положение.
По метрике бас-фактора, Коля -- никудышний сотрудник от входа.
Прям про воспитание детей. За кого родичи решали все проблемы, тот вырастает инфантилом. Мне кажется, что автор сочинил эту притчу, закамуфлировав детско-родительские отношения и пример отъёма ответственности по типу "мне проще самой сделать, чем от вас просить!". Очень распространённая проблема воспитания, когда сыновья вырастают неряхами.
Вот это:
Он почти сразу выбросил из командного продуктового портфеля решение сложных задач, и сосредоточился на простых. Тех, с которыми могли справиться джуны почти без помощи новоявленного наставника. Именно почти – определённый процент новизны и сложности Вася сознательно оставил. Чтобы джуны, решая любую задачу, максимально часто сталкивались с чем-то новым.
Это же эффективная практика воспитания детей:
Зона ближайшего развития — теоретический конструкт о пространстве задач, которые ребёнок не может освоить самостоятельно, но способен освоить с помощью взрослых.
Да только готового рецепта этой зоны ближайшего развития нет. Все строго индивидуально, и более того - постоянно надо менять и двигать. А на это тоже нужны ресурсы и талант.
Даже каждая пара ребенок-взрослый индивидуальна. Со мной дети спокойно гуляют по 15км пешком (ладно, признаюсь, к концу второго дня таких прогулок ныть начали). А с дедушкой через 400м "ножки устали, возьми на ручки". У одной бабушки по заветам психологов принятие, объяснения, обнимашки, т.д. и глаза на мокром месте по любому поводу, а другая по советскому обычую может разве что поржать над таким концертом и "а я у бабушки совсем не плачу". Вот где правильно? Зоны развития, которые сможет реализовать каждая бабушка будут очень различаться. А у меня будет свой вариант для каждого из детей. Потому что опробованное и прекрасно себя зарекомендовавшее со старшим ребенком совершенно не работает с младшим. И наоборот - на старшую не оказывало никакого влияния, а с младшей оказалось мастхев. Плюс ревность сюда добавьте: "почему сестре (младшей) задание простое и маленькое, а мне сложное и большое?!"
Ну хз, наблюдаю оба этих подхода в жизни. Один постоянно занят и задачи неделями висят, второй все время на связи, задачки шустро пролетают, еще и джуны выросли. А вот у первого джуны что-то не задерживаются, уходят на другие проекты.
Он почти сразу выбросил из командного продуктового портфеля решение сложных задач, и сосредоточился на простых.
Объясните мне как это вообще возможно в реальной жизни, а не в басне??
Разве не может сотрудник отказаться от джунов, тимлидства и прочего менторства? Или это обязаловка?
Есть ощущение, что так делают из-за банальной экономии на раздельных позициях пм/тл/архитектов, сваливая всё работу на программистов. В результате и старое сломали, и новое не построили. Разделение труда ведь не просто так придумали, может в этом есть смысл.
А кому тогда давать стажеров и джунов? Мидлы могут чему-то плохому научить.
Спросить хочет человек или нет конечно предварительно надо.
В данной схеме важно, чтобы у всех участников не было более 80-90% загруженности, иначе на «передачу опыт» будет назначен низкий приоритет и эффективность будет откровенно хромать.
Увы, тимлиды слишком много времени сидят на разнообразных продуктовых встречах. Добавляем сюда необходимость писать код, чтобы не утрачивать навыков. Сверху накидываем ложечку всяких код и дизайн ревью, на которые вся команда ему скидывает все самое странное. И получаем что времени нет от слова совсем.
Одного стажера при хорошей и самостоятельной команде наверно можно вытянуть. Но это нерегулярно и мало как правило.
будет понятно, чему мидл будет «учить» джуна.
Мидл способный хорошо учить джунов это готовый сеньор уже. Знать все правильные решения и уметь их донести до другого человека это очень много.
Тимлид пишет код? Это делают программисты, но тут тоже бывает оптимизация. Может тимлиду ещё полы начать мыть, чтобы навык не утрачивать.
Код дизайн у тимлида? А что и за архитектора работу делать?
Это всё не обязанности тимлида, которые на него могут упасть лишь в случае, когда на прямых исполнителей этих обязанностей было сэкономлено. Тимлид может уметь всё это делать, но если это его обязанности, тимлид ли он?
З.Ы. Универсальный сотрудник, этот тот который делает всю работу одинаково плохо.
А что у вас тимлид делает?
Кто от разработки сообщает продуктовым людям что вон та фича противоречит математике, вот эта требует переделки всей архитектуры приложения, а воон та потребует еще пары сотен серверов чтобы она заработала? Ну и заодно выступает щитом для разработки от вопросов А когда будет готово? И вот тут надо немного (все) по другому сделать?
Кто ревьюит сложный код? Типовой код понятно что ревьюит любой другой разработчик. А когда прям сложно кто?
А кто архитектуру в начале придумывает, а потом ревьюит если не он придумал? Сеньоры это хорошо и они делают заметную часть работы, но иногда им им надо с кем-то поговорить.
Писать код тимлиду просто надо. Чтобы четко знать каково его команде живется. Может там ужас полный в процессах или постановках или архитектуре или еще в чем угодно. А люди скромные и терпят. Когда своими руками код в прод пишешь это все сразу замечается.
В отличии от всех самых крутых IC тимлид стой или иной уверенностью знает все приложение в своей области. И может понять как что-то с чем-то интерферирует. И выдавать это знание понятным языком на всех встречах. А тот же IC может идеально знать и писать свой небольшой участок и не лезть никуда больше.
Идём дальше, как он этим должен заниматься? То есть какова цель его действий. Наверное в том, чтобы его «подданные» максимально эффективно исполняли свои обязанности. Вот приходит под вечер пятницы ПМ после совещания, глаза светятся, лицо горит, жопа тоже горит, идеи из всех щелей лезут, говорит давай собирай народ, сейчас будем улучшать всё на 146%. И что нужно тимлиду делать? Бросить все дела и собирать всех от стажёра до сеньора или отправить ПМ-а отсыпаться до понедельника (а то и до следующего полного сбора)? Получается тимлид излоирует команду от лишних внешних воздействий. Развивает проф. навыки в соответствии с желанием и возможностями специалиста, не давать Васе задачи по бд, когда ему интересна алгоритмика, Коли не давать коммуникативных задач, если он просил меньше общения. И это ещё не затрагивая организацию внешних и внутренних коммуникаций. Работа по организации людей, даже без учёта конкретной специализации, не такая простая, но когда она хорошо сделана, разница очевидна.
Вот теперь вернёмся к вопросу, что тимлид может в реальности делать. Сложим ваши описание тимлида и получаем, что тимлид должен затыкать все дыры в работе коллектива. Некому писать код, пишет код. Некому делать ревью — делает ревью. Некому разработать архитектуру — разрабатывает. И по останочному принципу занимается прямым обязанностями
Ну и заодно выступает щитом для разработки от вопросов А когда будет готово?
От сюда делается вывод. Это не тимлид. Это типичный герой автора статей, одной из которых мы сейчас накручиваем рейтинг. Работает за руководителя, за программиста, за архитектора, подрабатывает за пм-а. И всё делает хуже, чем мог бы, времени то не хватает. А знаете почему ему нужно писать код? Это его отдушина в этом аду и соломка на тот момент, когда он выгорит, чтобы не остаться без средств к существованию и пойти работать хотя бы простым программистом.
Из вашего текста я понял что у вас тимлид передает тикеты разработчикам и прикрывает их от бизнеса (это совпало с моим). Ну и встречи 1 на1 с ними проводит.
Как-то мало на 40 рабочих часов с учетом что у тимлида обычно 5-6 разработчиков. Не находите?
Передать тикеты ну пусть день в неделю займет. 1на1 с учетом периодичности раз в две недели еще полдня. Прикрывать зависит от бизнеса, но в среднем потребляет нервы, а не время занимает. Осталось еще 3.5 дня в неделю. По моим прикидкам.
Тимлид пишет код? Это делают программисты
Роль тимлида - это разновидность роли программиста, естественно, он тоже пишет код. Роль архитектора выделяется в отдельного человека лишь на достаточно крупных проектах. В подавляющем большинстве проектов в принципе нет работы для специализированных архитекторов, эта роль также делегируется программистам.
Мидл - это тот, кто хорошо выполняет свой участок работы . В том числе и решает сложные задачи. Но он не потянет на декомпозицию программы для джунов. Как раз в том и сила сеньора, что он не просто может задачу закрыть, а разными методами написать программу, в том числе и таким, что один джун будет делать вот это, другой вот это и т.д.
Я вот поэтому синьором себя полноценным не считаю, т.к. когда надо что-то сделать , я выясняю, что допустим 7 из 10 функций я знаю, как делать , а 3 из 10 нет, надо будет покопаться. А пока эти 3 не пойму как делать , то и структуру программы не представишь. У меня был случай, когда по прошествии некоторого отрезка времени пришлось сменить среду программирования - т.к. в текущей задача никак не решалась. А твёрдый сеньор, наверняка бы это заранее знал.
Сначала берется из воздуха тезис, что хороший кодер автоматически обладает навыками педагогики и менеджмента. Потом этим тезисом лупят "Колю" по сутулой спине. Удобно. А главное, ни слова про ЛПР, которые всю кашу заварили.
Проблема "Коли" только в том, что он повелся на авантюру жадного руководства. Именно жадность и недальновидность толкает на все эти эксперименты с "выращиванием". В жизни чтобы производить что-то нужен капитал: площади, помещения, станки, склады, сырье. В процессе производства профессионалов из буратин капиталом являются качественная архитектура, покрытый тестами код, живая документация, рабочие процессы и уже существующий сильный коллектив. Если из всего этого у вас только "Коля", который все на себе тащит, то проблема тут не в "Коле", а в рваче, который решил Б-га за бороду ухватить за мелкий прайс.
Проблема "Коли" только в том, что он повелся на авантюру жадного руководства.
А почему это авантюра, и почему руководство жадное? Вы знаете какой-то другой способ готовить программистов, кроме как давать джунам задачи под руководством опытного разработчика?
Авантюра (фр. aventure) — рискованное и сомнительное дело, предпринятое в надежде на случайный успех
Берем сеньора, даем N джунов. Через Х месяцев получаем сеньора + N мидлов.
Как по вашему, это детерминированный исход событий? Или таки авантюра "авось проканает"?
Как по вашему, это детерминированный исход событий? Или таки авантюра "авось проканает"?
Это стандартный процесс обучения. Он в принципе не бывает детерминированным. Даже если вы возьмёте не сеньора-программиста, а профессора, кого-то он обучит, кого-то нет. Это зависит, к слову, от многих факторов, и один из первостепенных - способности и мотивация самих джунов. И повторю свой предыдущий вопрос, от которого вы убежали: вы знаете какой-то другой способ готовить программистов, кроме как давать джунам задачи под руководством опытного разработчика?
Я вот не знаю. Да, есть сеньоры, которые в принципе не способны передавать свои знания (их, к слову, меньшинство), или просто не желают этим заниматься (этих побольше). Но насколько я знаю, у всех сеньоров есть такая штука, как рот, и они всегда могут это озвучить и не брать джунов.
Не я убежал от ответа, а вы видимо убежали от чтения моего первого коммента, где я свою позицию пояснил. Да, старший учит младшего. Это очевидно. Но обучение ремеслу разработки это чуть сложнее, чем просто накинуть на сеньора пачку буратин и надеяться, что он это как-то разгребет. А именно это и произошло в нашей занимательной задачке:
Ни у Коли, ни у Васи особого опыта работы с подчинёнными не было.
Советовать им, разумеется, никто не брался – слишком уважаемые были
личности. Пришлось нашим героям самостоятельно решать, куда и как
двигаться.
А мой поинт в том, что если вы хотите нанимать джунов завтра, то вы должны были раскошелиться на сеньоров вчера и на мидлов сегодня. Чтобы все эти люди строили устойчивую систему, где джун и ничего не сломает и легко сможет влиться в работу. Также вы должны были вложиться в грамотный HR-процесс. И уж точно не пускать это на самотек и усмотрение самих сеньоров. Выращивание должно быть системой, а не игрой в рулетку "авось проканает".
Почему я так думаю? Потому что я видел всю дичь с наймом толпы джунов в компанию к единственному сеньору на 2х предыдущих работах. Ничего кроме "Коли" там в принципе получиться не может. И, наоборот, я вижу как легко джун вливается в мой текущий коллектив, преимущественно сеньорский.
Но обучение ремеслу разработки это чуть сложнее, чем просто накинуть на сеньора пачку буратин и надеяться, что он это как-то разгребет.
Что такое "как-то разгребёт" ? Что в вашем понимании "обучение ремеслу разработки"? Обязательно взять человека, который не знает, какой стороной к себе ставить клавиатуру, и потом выделить ему персонального ментора, вести за ручку по продуманному плану обучения, с контрольными заданиями и оценками перформанса? Или всё-таки взять уже готового джуна, который прошёл это с теми, кто деньги за такое получает, т.е. хотя бы на курсах, и знает основы своей платформы, в курсе про гит и тому подобные инструменты, и посадить его уже на рабочие задачи, где сеньор выполняет роль консультанта и контролёра, а не тратит своё время на такую непрофильную задачу, как полноценное обучение?
Выращивание должно быть системой, а не игрой в рулетку "авось проканает".
Я прошу прощения, но вы, по сути, утверждаете, что обучение возможно только в крупных компаниях. Подавляющее большинство компаний мелкие и средние, и организовывать внутри себя курсы по обучению разработчиков они не должны, и прекрасно обойдутся простым вариантом, без всех этих хлопот. Другое дело, что джунов не должна быть толпа, сеньору в команду хватит одного-двух. Но это вопрос из другой плоскости, в обсуждаемой басне про перегрузку Коли толпой джунов ничего не упоминалось, вы просто домыслили что-то из личного негативного опыта.
Один может научить, другой нет. Даже при желании (а не факт, что и желание было).
Просто Василий вырос из уровня кодера до тимлида. И доказал, что заслуживает апгрейда. Развитие - это нормально.
А Николай так и остался вечным кодером. Да, сильным, перформящим, но кодером. Это как лучшая лошадь в колхозе. Таких не повышают.
Это не рост, это разные сферы деятельности. Кто-то умеет и ему нравится быть руководителем, кому-то оно нахрен не надо и не нравится, зато он при этом офигительный разработчик. Заставить такого человека быть лидом - вместо отличного программера получаем, в лучшем случае, посредственного руководителя. Это не апгрейд вообще ни разу.
Ну и так в целом, в статье описан антипаттерн "бросаем в воду, авось выплывут", кто-то и выплывет, а кто-то утонет к чертям. Синьор программер вовсе не тождественнен опытному лиду, это как взять и посадить за комп лучшего водителя службы доставки - ну а что, с машиной он вон как ловко управляется, талантливый человек, значит и с программированием разберется моментально.
Согласен, и самая правильная тактика - это выявлять таких неформальных лидеров, и делать их формальными, тогда новое назначение не будет вызывать сильного стресса ни у коллектива, ни у нового руководителя, это будет просто формализация и так уже по факту имеющегося руководителя. А брать и назначать просто успешного разработчика, в надежде что он и руководителем будет отличным - это авантюра.
Тут я очень сильно не согласен.
Рост означает в том числе, что человек в состоянии применить имеющиеся знания "вширь", то есть на более масштабную сферу деятельности, чем написание кода и решение офигительных тасков В ОДИНОЧКУ. А больший масштаб, как следствие, требует привлечения других сотрудников для решения объёма задач, с которыми даже один суперсеньор чисто физически не справится за требуемое время.
Другими словами, переход в лиды - это апгрейд на качественно новый уровень. Да, для этого придётся увеличивать свои знания в менеджменте и качать софт-скиллы. Но это же и есть продвижение.
А пример с машиной - вообще не в тему. Корректнее сравнить, что лучшего водителя поставили бригадиром над другими водилами. Предметная область то не меняется.
По вашему получается что любой "рукамиводитель", вообще невдупляющий что там эти странные красноглазики в своих кампухтерах делают, прямо вот так качественно на более высоком уровне чем "суперсеньор". Какой тогда смысл пяток-другой лет работать программистом, если можно сразу стать круче любого "мегасиньора" программера, просто пойдя в менеджмент?
Пример с водителем очень даже в тему, даже вот и ваш - поставили мы лучшего водителя бригадиром над другими водителями - он дело все и развалил, потому что умение ловко управляться с многотонным грузовиком вовсе не означает такого-же умения управлять людьми, ресурсами и даже желания вообще всем этим заниматься. Человеку нравится грузовиком управлять, а не своими коллегами.
Нет, не любой. Я же специально написал, что переход в лиды - это следующая ступень роста разработчика (а не просто поставленный дурак менеджер). То есть имеется в виду, что эффективно управлять программистами сможет только более опытный (бывший) программист, если он прокачает данный скилл.
Конечно, человек должен хотеть расти в этом направлении - это базовое условие. Иначе так и будет всё время баранку крутить до пенсии (не говорю, что это плохо, но тогда и круг задач, которые он сможет решать, будут только этой баранкой и ограничены).
А я про то, что это не ступень роста - это уже "уход в сторону", опять же я это не считаю негативным явлением, но и не считаю ступенью развития именно как разработчика. Как бывший шофер, ставший бригадиром, он уже ушел в другую плоскость и профессиональным водителем считаться может с огромной натяжкой (да, возможно, при этом из него получится очень хороший руководитель, потому что он будет в отличи от пришедших со стороны, очень хорошо понимать объект управления)
А куда разработчику развиваться, если он уже достиг потолка, как не в лиды? И откуда браться хорошим лидам,как не из бывших прогеров?
То, что лид уже не кодит - это нормально, это и есть рост обязанностей. Сеньор тоже не будет уже джунские задачи делать - потому что overqualified.
Следующая ступень после лида, это R&D manager. И тут уже сложнее, нужен несколько другой опыт, чем просто тимлида.
Хотя есть ещё одна версия - по стечению обстоятельств Коле досталась команда идиотов. И он вовремя этого не определил и продолжал тащить за всех. А Василию повезло с адекватными джунами.
Мы должны сделать выводы что обучение и менторство ничто, а делегирование все? Вроде бы должна быть золотая середина а мне внушают что если выкинуть из гнезда птенчиков, то они обязательно полетят. Вроде бы Коля ведь тоже помогал и обучал их. Не пойму почему они не обучались?
И чуть не по теме. Что за фетиш обучать людей, а не брать обученных? Как только научатся поверьте они уйдут на соответствующую позицию, или здесь потребуют другую ЗП. Мне кажется надежда на лояльность на года иллюзия. А то что они сделают пока научатся задёшево все равно проходит не без мидлов. Да и минус репутация. На хрен они джуны кому упёрлись?
Узнал в себе Колю. У меня на проекте есть задачи, которые надо сделать. Там есть и легкие и сложные, разные. Если я буду их выстраивать по уровню сложности - пожалуй половина зависнет до тех пор, пока я их не возьму. А джун будет простаивать в этот момент, потому что он их решить пока не может. И не понятно, что лучше.
Да и как-то я стал замечать, что лет 8 назад у меня лучше получалось управляться с джунами. Кажется тогда я был Васей. Интересно, что произошло за эти 8 лет.
общение (в т.ч.обучение, не говоря уж о руководстве — это отдельный скилл, который так же атрофируется при неприменении, и «накачивается» при регулярном использовании)
Джуну можно давать рутинные и несложные задачи, которые самому (с уровня собсвенного величия и превосходства) уже не хочется делать лично :)
Я как "Вася" действовал, дали мне нового сотрудника после курсов 1С. Через 3 месяца он мог делать очень много. Оставалось убедить его поверить в себя и стать самостоятельным. Что он и сделал.
а что, после начала статьи прям никому не было понятно, чем закончится? сказочка с предсказуемым финалом, никакой интриги
По моим наблюдениям, из очень(!) хороших программистов редко получаются хорошие тимлиды. Такие люди не доверяют окружающим, не без оснований считая их глупее, и предпочитают всегда всё делать сами. Подлинное же искусство руководителя это не работать, а не-работать. Организовать все так, чтобы подчинённые как можно больше делали всё сами, а он бы только наблюдал за ходом процесса.
Подлинное же искусство руководителя это не работать, а не-работать. Организовать все так [чтобы работало без него]
именно потому некоторые возвращаются из «руководителей» в «специалисты».
А руководителю просто времени не будет всё самому делать. Постоянные митинги, звонки, отчёты, паверпоинт, вот это всё. И про людей нельзя забывать.
Как говорил наш майор на военке: "Хороший командир это тот, который сидит в сторонке и курит бамбук пока его солдаты выполняют поставленные им задачи".
Не верю в историю, извините.
Во-первых не верю в то что по методу Коли можно добиться высокой производительности от джунов. Понятно что с объяснениями от Коли производительность джуна будет лучше чем у Васи где джун плывет как-нибудь сам и он справится с более сложными задачами. Но "каждый джун производил столько сколько Коля в одиночку"? Извините но нет даже близко. Хорошо уже если производительность всех вместе не упала.
Во-вторых непонятно с чего вдруг Коля стал резко выгорать а Вася (который по версии истории, напомню, тащил все сложные вещи на себе) нет. Полагаю что это полный бред. Вероятнее всего Коля тупо брал на себя намного больше работы (или начальство свалило на него гораздо больше работы) а Вася элегантно увернулся прикрывшись тем что у него тут джуны и делать эту работу он не может. Это кстати заодно позволит прекрасно объяснить "не верю №1" - Коля стал работать больше, вот его производительность и выросла. Но мы простите тогда получаем тут несколько иную историю - пока Коля закрывал потребности бизнеса работавший в разы меньше Вася "учил джунов". Ну а потом силы у Коли закончились, да.
В-третьих я не верю что вообще в целом подход "пусть джун делает все сам" работает а "вот хорошо расжеванное техзадание" нет. Джуна надо научить хорошим практикам и подход №2 с этим (при правильном подходе) справляется, а подход №1 - не особо. Разумеется постоянно жить с №2 невозможно и в какой-то момент надо разработчику дать больше самостоятельности, но обыкновенно это и считается "переходом из джуна в миддлы". Научившийся на подходе №2 джун обычно довольно неплохо представляет как должно выглядеть поставленное самому себе задание и умеет его решать, остается лишь попрактиковаться. А правильно поставленные процессы (прежде всего покрытие кода тестами и своевременные review) делают этот процесс довольно безопасным и не требующим большого надзора.
В-четвертых я не верю что мотивацию джунов определяет то к кому они попали - к Васе или к Коле. Мне доводилось видеть синьоров которые внезапно "разучивались" решать сложные задачи - не получается и не получается, кто-нибудь другой возьмет и сделает. Видел я и массу джунов горевших желанием делать сложные задачи хотя им не спешили их выдавать. Тут проблема может быть только в том что Коля грубо говоря запрещал джунам делать сложные задачи, прямо по рукам бил если они начинали такой заниматься, но по моим наблюдениям это чаще приводит к уходу мотивированного джуна из компании туда где дают заниматься сложными задачами а отнюдь не к тому что он просто начинает ничего не делать. Но разумеется у Васи должна была быть та же самая проблема - не случайно же он старался сложные задачи не брать вообще а те что брал решал сам. То есть неготовность видеть что человек уже вырос и ему можно постепенно давать более сложные поручения на мой взгляд полностью ортогональна разнице подходов Васи и Коли. Если уж на то пошло то подход Коли мне кажется позволяет начать поручать сложные задачи джуну раньше. А реальную мотивацию у джунов проследить тоже несложно - "получить статус миддла". Те кто старается делать сложные задачи промотируются, те кто халявит и у них вечно все более-менее сложное "не получается" - нет.
В-пятых есть еще такое понятие как лояльность которое в статье не затронуто вообще. Обычная тема - джун набрался опыта и уходит туда где предложили зарплату выше. А теперь внимание вопрос: какой джун уйдет с большей вероятностью - тот который учился у старших товарищей остающихся в компании или тот которому предложили учиться самостоятельно?
Какое направление имеет больший вес - командная работа (софт навыки) или индивидуальный профессионализм (хард)? Если совсем просто - то задача решается одним быстрым профи, или командой из 5 середняков.
Речь не о том, что либо то, либо другое, вопрос о том, что имеет преимущество, и самое главное - для кого. Если смотреть с точки зрения менеджмента (сиречь бизнеса), то безусловно первое, даже невзирая на то, что это будет несколько затратнее. С точки зрения самого работника/специалиста, скорее всего (ну или чаще всего) второе. Потому что ему, в основном, выгоднее понимать свой профессионализм (выше доходы), а общаться с другими, В ОСОБЕННОСТИ с джунами/стажерами - это напряг. И далеко не все на это готовы. Даже так - мало кто к этому готов. Командная работа требует определенный уровень коммуникаций, умений, которые явным образом денег не приносят.
Тем не менее, правила диктует бизнес ;-) поэтому, имеет место некоторый баланс между первым и вторым, с преимуществом в первом. Поэтому развивайте навыки, коммуникации - это востребовано.
С точки зрения самого работника/специалиста, скорее всего (ну или чаще всего) второе. Потому что ему, в основном, выгоднее понимать свой профессионализм (выше доходы), а общаться с другими, В ОСОБЕННОСТИ с джунами/стажерами — это напряг
По-моему, во все времена и во всех профессиях среди работников преобладали как раз первые — кому комфортнее остановиться на каком-то привычном круге выполняемых задач и привычном круге коммуникаций, и не напрягать свой моск этим самым профессиональным ростом.
Программировали два товарища