Эта грустная история случилась на моих глазах. Не берусь утверждать, что она уже совсем прям завершилась – мало ли, вдруг кто-то из её героев прочтёт, задумается, что-то изменит… Ну или плюнет мне в кружку.

Итак, пришли в компанию, почти одновременно, два распрекрасных программиста. Одного поля ягодки – опыт, квалификация, профессиональная любознательность, энергия. Раньше их карьеры развивались по одинаковому, иногда – равному треку (работали вместе).

Компания в нетерпении потирала ладошки, предвкушая результаты, развитие и непоколебимую дружбу двух программистов. Да, давайте их как-нибудь назовём – Коля и Вася. Всё было хорошо.

Беда на горизонте даже не отсвечивала.

Весна

Это было золотое время. Программисты были просто прекрасны. Быстро влились в коллектив – благо, был опыт работы и, соответственно, навыки ассимиляции в совершенно разных средах. Проекты, клиенты, задачи – всё было и знакомо, и привычно. Даже немножко скучновато – в компании до того момента не было программистов столь высокой квалификации, по сумме параметров.

Менеджеры, руководители проектов, заказчики – все тащились. Коля и Вася не знали поражений, брали и решали любые задачи. То, что раньше вызывало опасения, проблемы, просрочку и конфликты, теперь просто программировалось, сдавалось и оплачивалось.

Если кратко описать, чем именно занимались наши герои, получится так: самым сложным программированием.

Но потом случилось непоправимое – опыт Коли и Васи решили использовать шире. Их, как положено, попросили заняться чем-то между наставничеством и управлением.

Лето

Итак, обоим дали в одну руку джунов, в другую – карт-бланш. Цель, если можно так выразиться – парни, сделайте что-нибудь классное. Вы такие, прям такие, что слов нет. Хотим, чтобы вы не просто и не только программировали, но и как-то ещё наследили.

Ни у Коли, ни у Васи особого опыта работы с подчинёнными не было. Советовать им, разумеется, никто не брался – слишком уважаемые были личности. Пришлось нашим героям самостоятельно решать, куда и как двигаться.

Коля, поразмыслив, решил ничего особо не менять в структуре работы и направлении движения. Как занимался сложным программированием, так и продолжил, но уже не в одиночку, а с командой джунов. На том и решил построить успех своего новоиспечённого отдела.

Как это примерно выглядело. Коля сам общался с заказчиком – а это мог быть как клиент, так и руководитель проекта – после чего, как мог, объяснял джуну задачу, погружал в контекст, историю работы с клиентом и во всё, что считал нужным. Молодые программисты, получив такие задачи, искренне и честно пытались их решить.

Что-то получалось, что-то нет, но Коля не унывал. Объяснял ещё раз, помогал, общался с заказчиком на всём протяжении жизненного цикла задачи, включая конфликтные моменты.

Результаты первых трёх месяцев у Коли были просто великолепные. В цифрах, если грубо, команда выдала математически красивый результат: каждый джун производил столько же, сколько Коля в одиночку.

У Васи было хуже, сильно хуже. Он почти сразу выбросил из командного продуктового портфеля решение сложных задач, и сосредоточился на простых. Тех, с которыми могли справиться джуны почти без помощи новоявленного наставника. Именно почти – определённый процент новизны и сложности Вася сознательно оставил. Чтобы джуны, решая любую задачу, максимально часто сталкивались с чем-то новым.

Сложные задачи Вася решал сам. Поначалу вообще прям сам, но постепенно, месяца через два, начал немного декомпозировать – там, где это возможно. Отдавать куски сложных задач джунам, контролировать выполнение, качество архитектуры и кода.

Результаты, с точки зрения бизнеса, у Васи были отвратительные – в отличие от Коли. Вся команда Васи производила столько же, сколько он раньше делал один.

Между собой наши герои почти не общались – некогда было.

Осень

Коля очень много психовал, злился, выгорал. Как он ни старался объяснять джунам сложные задачи, поддерживать в процессе решения, улаживать конфликты – проблем становилось всё больше. Доля его участия всё возрастала. Взятые лично на себя задачи он едва успевал выполнять. Нерабочее время, выходные – всё было забито работой.

Времени на общение с заказчиками уходило всё больше с каждым днём. Основной темой разговоров теперь была «Ну Коля, опять твои тут понаделали». Коля, раньше сквозь зубы цедивший «разберусь» и шедший разбираться, теперь говорил «сам доделаю», гневно объявлял джуну «я забираю у тебя задачу» и садился закапываться сам.

Его джуны поначалу переживали – лидер злится, мы что-то делаем не так, надо что-то менять. Однако, понаблюдав за повторяющимся паттерном, сели Коле на шею. Не делали задачу, а делали вид, что делают задачу. Ну, какой-то код писали, что-то проверяли, тестировали, но до результата почти никогда не доходили. Достаточно было дождаться, пока заказчик взвоет, нажалуется Коле, и всё случится само собой.

Новых джунов Коля не брал – не смог бы решать задачи ещё за кого-то. Старых не выгонял – гордость не позволяла. Но непрестанно ныл, что людишек ему подсунули сильно так себе – ничего не могут и, главное, не хотят.

У Васи – примерно наоборот. С заказчиками почти не общался – только в самом начале, когда начинался проект, или надо было произвести хорошее впечатление. Модель представления команды была, как у Коли, только ровно наоборот. Вася не говорил «мы профессионалы, решаем сложные задачи». Его девиз – «мы джуны с экспертом за спиной».

К этому времени его джуны уже приближались по квалификации к мидлам. С горем пополам научились и программировать, и с заказчиком разговаривать, и конфликты урегулировать. Не от высокой осознанности и стремления к развитию метапредметных навыков, а потому что иначе не получалось – Вася загребал жар только чужими руками.

Он мог помочь, подсказать, направить, посоветовать – но только своему сотруднику. После первой итерации общения больше с заказчиками не контактировал, хоть кол на голове теши. Никогда не садился дорешивать задачу за джуна, даже если это приводило к потере заказчика.

Результаты команды Васи – как в абсолютном выражении, так и в пересчёте на человека – догнали результаты команды Коли. И продолжали расти, т.к. Вася набирал новых джунов.

Между собой Коля и Вася общались редко. В основном – на совещаниях у начальства, куда обоих приглашали. Вася рассказывал, как у него дела. Коля огрызался.

Зима

Коля ушёл из команды. Или команда ушла из Коли. Может, Коля их бросил. Не сошлись характерами. Разные мнения и определения звучат – смотря кого спросить. Но факт один: команды больше нет.

Есть Коля, который снова работает один, решает сложные задачи, нравится заказчикам, менеджерам, руководителям проектов и начальству. И есть несколько джунов, которые за год ничему особо не научились, после расставания с Колей потыкались, помыкались, никуда не приткнулись, как-то самоорганизовались в подобие команды, пересели на несложные задачи и как-то пытаются выжить.

Коля, если спросить, говорит одно: я дал им шанс поработать с экспертом, научиться, подняться и тоже стать уважаемыми людьми. Не захотели, не воспользовались, не подхватили. Я, Коля, сделал всё, что мог. Любой, кто это слушает, понимающие и сочувственно кивает головой.

Джуны Васи стали мидлами, и тащат на себе новых джунов, коих становится всё больше. Даже какие-то тимлидки выросли – пока маленькие, бестолковые, но с 2-3 джунами справляются, и в плане роста навыков, и в части управления с командообразованием.

Дошло дело и до сложного программирования – того самого, с которого начинал свой путь в компании сам Вася. Только теперь его делают мидлы, которые поголовастее. Сам Вася делает только суперсложные вещи – что-то новое, прорывное. Ровно для того, чтобы передать полученный опыт и паттерны мидлам, те – джунам и т.д.

Коля и Вася теперь часто общаются – снова подружились, нет яблока раздора, повода для сравнения, в т.ч. на совещаниях у начальства. Тем более, Коля туда больше не ходит.

P.S.

Я, если честно, не знаю и не берусь судить, кто из друзей прав. К обоим отношусь очень хорошо. У обоих учусь, с обоими нравится взаимодействовать и что-то вместе делать, строить, развивать. Каждый, на текущий момент, хорош в своём.

А вы как думаете?

Комментарии (82)


  1. gennayo
    13.12.2022 09:25
    +14

    "Лучше день потерять, а потом за пять минут долететь" (с)


    1. Jubilus
      14.12.2022 03:54

      Цитаты великих людей


      1. aakhamef
        14.12.2022 15:20

        Великих птиц, осмелюсь поправить :-)


        1. Jubilus
          15.12.2022 12:33

          Да, спасибо, что-то я не подумал.


  1. mpakfm
    13.12.2022 09:26
    +3

    Прям басня Крылова получилась :) но мне очень понравилась, отличная басня!


    1. BombaBomba
      15.12.2022 11:01

      В басне должна быть мораль.


  1. lymes
    13.12.2022 09:38
    +31

    Имхо, тут дело не только в разных стратегиях, примененных Колей и Васей. Преобладающую роль играет характер и лидерские способности, которые не у всех бывают и которые, в принципе, наверное можно искусственно развить, но это трудно. Предположу, что у Коли таких способностей изначально не было, а у Васи были. Я много раз наблюдал как при одинаковых условиях старта кто-то легко становился лидом и легко подчинял команду, причем люди подчинялись с удовольствием, а кто-то при всем старании становился чуть ли не изгоем и скатывался в вечные склоки с командой и в конце концов сходил с дистанции.


    1. spaceatmoon
      13.12.2022 14:20
      +5

      У Коли просто не было опыта общения с оборзевшими сотрудниками. Такое не только на работе встречается, а ещё в семье, с друзьями и т.д. Думаю если бы Коле подсказали как вести себя в такой ситуации, всё бы решилось иначе.


      1. lymes
        13.12.2022 14:41
        +2

        В некоторых компаниях тимлиды (и не только) как бы в постоянном соревновании между собой. Это не всегда хорошо, но частенько бывает, когда идет борьба за KPI и премии. При таком раскладе Коле не только не подскажут, а еще и неправильно подскажут и подпихнут ногой. :-)


      1. oleg_rico
        14.12.2022 14:04

        Опыт конечно важен но свойства характера никуда не денутся. Иногда их можно опытом преодолеть, а иногда его нет.


    1. 0x131315
      14.12.2022 19:21

      Не, тут ключевое именно стратегия.

      Тут играют два момента:

      1. Нельзя замыкать все на себе. Да, это греет ЧСВ, важный шишка, без тебя работа не работается. Для некоторых это стратегия выживания - незаменимого не уволить. Но это плохо для команды - незаменимых в команде быть не должно, но могут быть в чём-то уникальные специалисты, вот их и надо взращивать. Плохо для бизнеса - незаменимые это фактор отказа, причем внезапного отказа. И плохо для самого специалиста - это не только тормозит его развитие, но и перегружает лишней работой. Нужно делегировать максимум из того, что вообще можно делегировать, иначе эффективное управление не построить.

      2. Экспертиза и самостоятельность. Если джуны не будут получать опыт самостоятельно, если их слишком опекать, если устранить фактор отбора, если решать проблемы за них, они не вырастут. Такой подход фактически лишает их опыта и экспертизы, и убивает в них самостоятельность, инициативу. Они ждут указку сверху и верят что ты все за них решишь и разрулишь. Это плохой подход. Гораздо эффективнее позволить им собирать свои ошибки самостоятельно, нарабатывать опыт. А свою экспертизу стоит использовать для подсказок и ненавязчивого направления в правильную сторону. Стоит стать консультантом для них. Твоя экспертиза их подстрахует, и они это знают, в остальном они вольны принимать решения сами, в том числе неправильные, и пожинать последствия своих ошибок. Внешне конечно это выглядит не очень, много ошибок по началу, но это ожидаемо - нельзя делать работу за них, но можно направлять и давать обратную связь. И ни в коем случае нельзя отнимать задачи или фиксить их ошибки - это мощный удар по самолюбию и их самостоятельности, по мотивации делать свою работу хорошо, по стремлению к совершенству. Они четко должны знать, что свои косяки будут разгребать сами, так что в их же интересах все сделать хорошо. И они должны боятся, что их код улетит на прод без проверки и наделает там проблем, что за ответом пройдут именно к ним. Конечно самые жёсткие косяки нужно пресекать, возвращать на доработку, но всякую мелочь нужно оставлять. Такой подход не только тебя разгружает, но и даёт огромный буст к опыту твоей команды. И они к тебе приходят не по мелочам, как в первом, а только для консультаций о чем-то, что их опыту пока не по плечам или вызывает сомнения.


  1. AlanRow
    13.12.2022 10:05
    +29

    Цель, если можно так выразиться – парни, сделайте что-нибудь классное.

    Ни у Коли, ни у Васи особого опыта работы с подчинёнными не было

    Мне кажется, что первая проблема возникла еще где-то здесь - когда двум людям, которые до тех пор не руководили командой поручили лидерские задачи с максимально размытыми требованиями, по принципу "ну они же эксперты - справятся"


    1. Fedoresko1
      13.12.2022 20:07

      Ну а что по аналогии же с известным способом обучения плаванию. )


  1. sensem
    13.12.2022 11:26
    +3

    По-моему, это довольно часто встречающаяся проблема в компаниях, которые хотят растить специалистов с менеджерской направленностью (лидов/линейных менеджеров и т.д.), никогда не прибегая к найму сложившихся специалистов извне. Проработал сколько-то лет в компании, успешно завершил несколько проектов как технический специалист - значит, готов не только вводить в курс дела новых коллег, но и следить за их развитием на проектах, к которым ты никакого отношения никогда не имел.
    По-хорошему - компания должна была подойти с умом к процессу выращивания новых специалистов: посмотреть сложившиеся практики в других компаниях, на то, сколько людей обычно вовлечено в процесс обучения/вовлечения (training manager, ментор, линейный менеджер, проектный менеджер, technical lead...) и хотя бы часть людей нанять с внешнего рынка, иначе получается, что должен тащить человек-оркестр (Вася или Коля). Многие могут такую нагрузку попросту не потянуть.


  1. dolovar
    13.12.2022 12:04
    +1

    не берусь судить, кто из друзей прав
    Стандартная ситуация — крайности плохи, нужен баланс между ними.


  1. Dr_Dash
    13.12.2022 12:14
    +14

    Неестественный рассказ. Не клеится связка лето осень. У Коли джуны летом все задачи щёлкали, прям не хуже него, а осенью он ничегошеньки не смог им объяснить уже. Вася его отравил мышьяком? Моцарт и Сальери?


    1. Dr_Dash
      13.12.2022 13:10

      Не сочтите за паранойю, у нас деревенские традиции такие есть, а пол-России в третьем поколении оттуда. Я сталкивался и лично и по рассказам с глупыми и завистливыми людьми


      1. akuli
        13.12.2022 19:02
        -1

        Вы сейчас из деревни пишете?


    1. spaceatmoon
      13.12.2022 14:23
      +1

      Так в статье же прямо написано. Джуны просекли что выгоднее быть жертвой и ничего не делать за туже зп, т.к. Коля забыл прописывать по жопе в случае факапов и просто выполняет их работу.


  1. shasoftX
    13.12.2022 12:27
    +1

    С точки зрения компании молодец Вася. Он организовал конвейер по производству кадров внутри компании.

    С точки зрения разработчиков - молодец Коля. Он показал компании что он весьма важен для компании. А значит при просьбе такого работника повысить ЗП компания, как минимум рассмотрит такой вариант, а не отправит "за забор".


    1. Jianke
      13.12.2022 14:32
      +2

      С точки зрения разработчиков - молодец Коля. Он показал компании что он весьма важен для компании. А значит при просьбе такого работника повысить ЗП компания, как минимум рассмотрит такой вариант, а не отправит "за забор".

      Не поможет, потому что Коля со своими отделом - не единственный в компании, кроме него имеется целый отдел с Васей во главе.

      PS Работал я с таким токсичным козлом, который для вас "молодец". Чтобы быть незаменимым, он постоянно организовал конфликты, склоки и подставы, так чтобы все кто с ним работал не выдерживали с ним более нескольких месяцев. Начальство хотело иметь отдел, а главой отдела поставило этого козла, который постоянно занимался токсичной травлей своих подчинённых, так что они сами увольнялись, а он таким образом продолжал быть незаменимым. И он не выращивал джунов, как Коля из статьи, а специально нанимал опытных разработчиков, чтобы они были недовольны когда об них постоянно вытирают ноги, и сами уходили от него.


      1. shasoftX
        13.12.2022 14:38
        +1

        Не поможет, потому что Коля - не единственный в компании, кроме него имеется целый отдел с Васей во главе.

        В данном случае действия Васи действительно свели на нет все действия Коли. Но ведь в сказочке говорится что "Между собой наши герои почти не общались – некогда было". Собственно именно поэтому выиграла компания.

        Разделяй и властвуй - лозунг на все времена.


        1. Ivan22
          13.12.2022 16:12
          +2

          как это действия Васи свели на нет? Если весь отдел васи делал только простенькие запросы, для джунов. Все сложное делал ТОЛЬКО Коля


          1. shasoftX
            13.12.2022 18:04

            В конце выращенные им мидлы уже делали и то, что он делал в начале

            Дошло дело и до сложного программирования – того самого, с которого начинал свой путь в компании сам Вася. Только теперь его делают мидлы, которые поголовастее.


            1. Ivan22
              13.12.2022 19:31
              +1

              не прошло и полгода...


      1. MrSung
        13.12.2022 23:23

        И что стало с фирмой?


        1. PuerteMuerte
          15.12.2022 14:29

          Не знаю насчёт той фирмы, но работал в такой же. Ничего не стало, как работала, так и работает, и начальник тот там же. Задачи-то он закрывает, несмотря на свою токсичность, а клиенты видят работу, а не внутренние отношения в том отделе.


    1. mvv-rus
      13.12.2022 23:43

      С точки зрения компании молодец Вася. Он организовал конвейер по производству кадров внутри компании.

      А компании это точно нужно - производить кадры. Кадры таким образом ведь производятся не для себя, а для рынка. И получившимся в результате мидам придется платить по рынку, то есть больше - иначе сбегут.

      Для компании было бы идеально, чтобы джуны становились джунами-специалистами, то бишь кодерами: способными делать куски решений по технологиям, используемым в компании, но не способными ни делать целостное решение, ни, тем более, ставить себе задачи, общаясь самостоятельно с заказчиками. Такие специализированные кодеры вполне могут производительно работать на компанию не хуже мидов-универсалов, но вот денег им за это сильно больше платить не надо - куда они денутся-то.

      Однако для использования таких кодеров нужен специалист, который будет разбираться с постановкой задачи и нарезать ее на куски для кодеров. Ни из Коли, ни из Васи такого специалиста не получилось. И что-то я вообще не вижу, чтобы такое хоть сколько-нибудь массово получалось в индустрии разработки программ.

      А вот для разработчиков это как раз и хорошо, что не получается: у них есть массовая возможность заниматься более творческой работой, причем за значительно большие деньги.


      1. PuerteMuerte
        15.12.2022 14:33

        И получившимся в результате мидам придется платить по рынку, то есть больше - иначе сбегут.

        Вообще, выращенным мидлам можно платить немного ниже рынка, мало кто меняет привычную работу, на которой вырос как специалист, на +20% к зарплате, особенно если на текущем месте хотя бы раз в год да происходит прибавка. Ну и опять же таки, толковый миддл делает работу быстрее и качественнее, чем толковый продвинутый джун, и с него и доход заметно больше получается. Поэтому в типичном случае от роста сотрудников выигрывают все, и сами сотрудники, и компания.


        1. mvv-rus
          16.12.2022 04:44

          Разница зарплат джуна и мидла в РФ, ЕМНИП - она далеко не 20%, а раза в два. Но проблема отрасли разработки в том, что она в массе своей не научилась разделять задачи на части разной сложности и поручать выполнение менее сложных задач менее квалифицированному персоналу. Т.е., если брать аналогии с промышленностью, то разработка ПО так и не перешла от стадии ремесленного производства к стадии мануфактуры.

          PS Как это можно сделать (и можно ли вообще - в этом тоже есть сомнения) - не знаю, утверждать ничего не буду. Просто описываю сложившееся положение.


  1. KongEnGe
    13.12.2022 12:45
    +1

    По метрике бас-фактора, Коля -- никудышний сотрудник от входа.


  1. engine9
    13.12.2022 12:48
    +5

    Прям про воспитание детей. За кого родичи решали все проблемы, тот вырастает инфантилом. Мне кажется, что автор сочинил эту притчу, закамуфлировав детско-родительские отношения и пример отъёма ответственности по типу "мне проще самой сделать, чем от вас просить!". Очень распространённая проблема воспитания, когда сыновья вырастают неряхами.

    Вот это:

    Он почти сразу выбросил из командного продуктового портфеля решение сложных задач, и сосредоточился на простых. Тех, с которыми могли справиться джуны почти без помощи новоявленного наставника. Именно почти – определённый процент новизны и сложности Вася сознательно оставил. Чтобы джуны, решая любую задачу, максимально часто сталкивались с чем-то новым.

    Это же эффективная практика воспитания детей:

    Зона ближайшего развития — теоретический конструкт о пространстве задач, которые ребёнок не может освоить самостоятельно, но способен освоить с помощью взрослых.


    1. anka007
      13.12.2022 14:22
      +2

      Да только готового рецепта этой зоны ближайшего развития нет. Все строго индивидуально, и более того - постоянно надо менять и двигать. А на это тоже нужны ресурсы и талант.

      Даже каждая пара ребенок-взрослый индивидуальна. Со мной дети спокойно гуляют по 15км пешком (ладно, признаюсь, к концу второго дня таких прогулок ныть начали). А с дедушкой через 400м "ножки устали, возьми на ручки". У одной бабушки по заветам психологов принятие, объяснения, обнимашки, т.д. и глаза на мокром месте по любому поводу, а другая по советскому обычую может разве что поржать над таким концертом и "а я у бабушки совсем не плачу". Вот где правильно? Зоны развития, которые сможет реализовать каждая бабушка будут очень различаться. А у меня будет свой вариант для каждого из детей. Потому что опробованное и прекрасно себя зарекомендовавшее со старшим ребенком совершенно не работает с младшим. И наоборот - на старшую не оказывало никакого влияния, а с младшей оказалось мастхев. Плюс ревность сюда добавьте: "почему сестре (младшей) задание простое и маленькое, а мне сложное и большое?!"


      1. engine9
        13.12.2022 14:42

        Я вряд ли смогу ответить на ваш вопрос, т.к. не спец в педагогике. Мне показалось, что описываемое в посте очень перекликается с воспитанием детей.


    1. 0x131315
      14.12.2022 19:29

      Ну хз, наблюдаю оба этих подхода в жизни. Один постоянно занят и задачи неделями висят, второй все время на связи, задачки шустро пролетают, еще и джуны выросли. А вот у первого джуны что-то не задерживаются, уходят на другие проекты.


  1. Ivan22
    13.12.2022 13:06
    +5

    Он почти сразу выбросил из командного продуктового портфеля решение сложных задач, и сосредоточился на простых.

    Объясните мне как это вообще возможно в реальной жизни, а не в басне??


    1. aleksandy
      13.12.2022 13:29
      +10

      Как-как? Эти задачи решал Коля со своей командой.


    1. BugM
      13.12.2022 13:29
      +4

      Никак. На то это и басня.


    1. gennayo
      13.12.2022 13:49

      Так речь идёт не о продуктовой разработке, а о поддержке.


      1. Ivan22
        13.12.2022 14:03
        +4

        т.е. в поддержке можно сказать "изините, этот баг очень сложен для нашей команды джунов, не будем его чинить, ждите пока мы не прокачаемся" ???


        1. gennayo
          13.12.2022 23:12

          Очевидно же, что кроме команд Васи и Коли были и другие, явно в конторе кроме Васи и Коли были другие программисты.


    1. akuli
      13.12.2022 19:12
      +2

      Видимо в этом прикол и заключался


  1. sshemol
    13.12.2022 13:30

    Разве не может сотрудник отказаться от джунов, тимлидства и прочего менторства? Или это обязаловка?


    1. MrNutz
      13.12.2022 15:47

      Везде по разному. Где то буквально навязывают и отказаться будет сродни испортить отношение с начальством.


  1. WicRus
    13.12.2022 14:22
    +5

    Вот о5 25! Зачем портить специалистов? Если они занимались программированием, то пусть им и занимаются. Если они выросли из сеньёров, повысить до архитекторов и дать им в подчинение сеньёров, пусть с ними работают. Зачем давать им джунов (если ещё джунов, а не стажёров), разница в квалификации не позволит эффективно взаимодействовать. Джунов поручить мидам и тимлидам, они вполне справятся.
    Есть ощущение, что так делают из-за банальной экономии на раздельных позициях пм/тл/архитектов, сваливая всё работу на программистов. В результате и старое сломали, и новое не построили. Разделение труда ведь не просто так придумали, может в этом есть смысл.


    1. BugM
      13.12.2022 17:15
      +1

      А кому тогда давать стажеров и джунов? Мидлы могут чему-то плохому научить.

      Спросить хочет человек или нет конечно предварительно надо.


      1. WicRus
        13.12.2022 22:50
        +1

        В первую очередь тимлиду, это его паства. В его компетенции следить, кто, кого и чему учит. Если мидла будет «учить» сеньор (под надзором того же тимлида), то ± будет понятно, чему мидл будет «учить» джуна.
        В данной схеме важно, чтобы у всех участников не было более 80-90% загруженности, иначе на «передачу опыт» будет назначен низкий приоритет и эффективность будет откровенно хромать.


        1. BugM
          14.12.2022 00:40
          +3

          Увы, тимлиды слишком много времени сидят на разнообразных продуктовых встречах. Добавляем сюда необходимость писать код, чтобы не утрачивать навыков. Сверху накидываем ложечку всяких код и дизайн ревью, на которые вся команда ему скидывает все самое странное. И получаем что времени нет от слова совсем.

          Одного стажера при хорошей и самостоятельной команде наверно можно вытянуть. Но это нерегулярно и мало как правило.

          будет понятно, чему мидл будет «учить» джуна.

          Мидл способный хорошо учить джунов это готовый сеньор уже. Знать все правильные решения и уметь их донести до другого человека это очень много.


          1. WicRus
            14.12.2022 09:11
            +1

            Тимлид сидящий на продуктовой встрече? Там сидит ПМ и иже с ним, если конечно его строчку не оптимизировали.
            Тимлид пишет код? Это делают программисты, но тут тоже бывает оптимизация. Может тимлиду ещё полы начать мыть, чтобы навык не утрачивать.
            Код дизайн у тимлида? А что и за архитектора работу делать?
            Это всё не обязанности тимлида, которые на него могут упасть лишь в случае, когда на прямых исполнителей этих обязанностей было сэкономлено. Тимлид может уметь всё это делать, но если это его обязанности, тимлид ли он?
            З.Ы. Универсальный сотрудник, этот тот который делает всю работу одинаково плохо.


            1. BugM
              14.12.2022 22:47

              А что у вас тимлид делает?

              Кто от разработки сообщает продуктовым людям что вон та фича противоречит математике, вот эта требует переделки всей архитектуры приложения, а воон та потребует еще пары сотен серверов чтобы она заработала? Ну и заодно выступает щитом для разработки от вопросов А когда будет готово? И вот тут надо немного (все) по другому сделать?

              Кто ревьюит сложный код? Типовой код понятно что ревьюит любой другой разработчик. А когда прям сложно кто?

              А кто архитектуру в начале придумывает, а потом ревьюит если не он придумал? Сеньоры это хорошо и они делают заметную часть работы, но иногда им им надо с кем-то поговорить.

              Писать код тимлиду просто надо. Чтобы четко знать каково его команде живется. Может там ужас полный в процессах или постановках или архитектуре или еще в чем угодно. А люди скромные и терпят. Когда своими руками код в прод пишешь это все сразу замечается.

              В отличии от всех самых крутых IC тимлид стой или иной уверенностью знает все приложение в своей области. И может понять как что-то с чем-то интерферирует. И выдавать это знание понятным языком на всех встречах. А тот же IC может идеально знать и писать свой небольшой участок и не лезть никуда больше.


              1. WicRus
                15.12.2022 16:15

                Ну вот, чтобы понять, что должен делать тимлид, нужно понять, что это вообще за строчка в штатном расписании. Teamlead от англ. team leader — руководитель группы. Тут сразу видно объект применения — «группа», читай непосредственные исполнители и то, что с ними делают. Из чего легко сделать вывод, что занимается тимлид в первую очередь людьми, не кодом, не продуктом/проектом, не мытьём полов, людьми.

                Идём дальше, как он этим должен заниматься? То есть какова цель его действий. Наверное в том, чтобы его «подданные» максимально эффективно исполняли свои обязанности. Вот приходит под вечер пятницы ПМ после совещания, глаза светятся, лицо горит, жопа тоже горит, идеи из всех щелей лезут, говорит давай собирай народ, сейчас будем улучшать всё на 146%. И что нужно тимлиду делать? Бросить все дела и собирать всех от стажёра до сеньора или отправить ПМ-а отсыпаться до понедельника (а то и до следующего полного сбора)? Получается тимлид излоирует команду от лишних внешних воздействий. Развивает проф. навыки в соответствии с желанием и возможностями специалиста, не давать Васе задачи по бд, когда ему интересна алгоритмика, Коли не давать коммуникативных задач, если он просил меньше общения. И это ещё не затрагивая организацию внешних и внутренних коммуникаций. Работа по организации людей, даже без учёта конкретной специализации, не такая простая, но когда она хорошо сделана, разница очевидна.

                Вот теперь вернёмся к вопросу, что тимлид может в реальности делать. Сложим ваши описание тимлида и получаем, что тимлид должен затыкать все дыры в работе коллектива. Некому писать код, пишет код. Некому делать ревью — делает ревью. Некому разработать архитектуру — разрабатывает. И по останочному принципу занимается прямым обязанностями

                Ну и заодно выступает щитом для разработки от вопросов А когда будет готово?

                От сюда делается вывод. Это не тимлид. Это типичный герой автора статей, одной из которых мы сейчас накручиваем рейтинг. Работает за руководителя, за программиста, за архитектора, подрабатывает за пм-а. И всё делает хуже, чем мог бы, времени то не хватает. А знаете почему ему нужно писать код? Это его отдушина в этом аду и соломка на тот момент, когда он выгорит, чтобы не остаться без средств к существованию и пойти работать хотя бы простым программистом.


                1. BugM
                  15.12.2022 17:07

                  Из вашего текста я понял что у вас тимлид передает тикеты разработчикам и прикрывает их от бизнеса (это совпало с моим). Ну и встречи 1 на1 с ними проводит.

                  Как-то мало на 40 рабочих часов с учетом что у тимлида обычно 5-6 разработчиков. Не находите?

                  Передать тикеты ну пусть день в неделю займет. 1на1 с учетом периодичности раз в две недели еще полдня. Прикрывать зависит от бизнеса, но в среднем потребляет нервы, а не время занимает. Осталось еще 3.5 дня в неделю. По моим прикидкам.


            1. PuerteMuerte
              15.12.2022 14:38

              Тимлид пишет код? Это делают программисты

              Роль тимлида - это разновидность роли программиста, естественно, он тоже пишет код. Роль архитектора выделяется в отдельного человека лишь на достаточно крупных проектах. В подавляющем большинстве проектов в принципе нет работы для специализированных архитекторов, эта роль также делегируется программистам.


  1. panzerfaust
    13.12.2022 14:28
    +6

    Сначала берется из воздуха тезис, что хороший кодер автоматически обладает навыками педагогики и менеджмента. Потом этим тезисом лупят "Колю" по сутулой спине. Удобно. А главное, ни слова про ЛПР, которые всю кашу заварили.

    Проблема "Коли" только в том, что он повелся на авантюру жадного руководства. Именно жадность и недальновидность толкает на все эти эксперименты с "выращиванием". В жизни чтобы производить что-то нужен капитал: площади, помещения, станки, склады, сырье. В процессе производства профессионалов из буратин капиталом являются качественная архитектура, покрытый тестами код, живая документация, рабочие процессы и уже существующий сильный коллектив. Если из всего этого у вас только "Коля", который все на себе тащит, то проблема тут не в "Коле", а в рваче, который решил Б-га за бороду ухватить за мелкий прайс.


    1. PuerteMuerte
      13.12.2022 14:35
      +5

      Проблема "Коли" только в том, что он повелся на авантюру жадного руководства.

      А почему это авантюра, и почему руководство жадное? Вы знаете какой-то другой способ готовить программистов, кроме как давать джунам задачи под руководством опытного разработчика?


      1. panzerfaust
        13.12.2022 14:43
        +2

        Авантюра (фр. aventure) — рискованное и сомнительное дело, предпринятое в надежде на случайный успех

        Берем сеньора, даем N джунов. Через Х месяцев получаем сеньора + N мидлов.

        Как по вашему, это детерминированный исход событий? Или таки авантюра "авось проканает"?


        1. PuerteMuerte
          13.12.2022 19:08
          +1

          Как по вашему, это детерминированный исход событий? Или таки авантюра "авось проканает"?

          Это стандартный процесс обучения. Он в принципе не бывает детерминированным. Даже если вы возьмёте не сеньора-программиста, а профессора, кого-то он обучит, кого-то нет. Это зависит, к слову, от многих факторов, и один из первостепенных - способности и мотивация самих джунов. И повторю свой предыдущий вопрос, от которого вы убежали: вы знаете какой-то другой способ готовить программистов, кроме как давать джунам задачи под руководством опытного разработчика?

          Я вот не знаю. Да, есть сеньоры, которые в принципе не способны передавать свои знания (их, к слову, меньшинство), или просто не желают этим заниматься (этих побольше). Но насколько я знаю, у всех сеньоров есть такая штука, как рот, и они всегда могут это озвучить и не брать джунов.


          1. panzerfaust
            13.12.2022 19:33
            -1

            Не я убежал от ответа, а вы видимо убежали от чтения моего первого коммента, где я свою позицию пояснил. Да, старший учит младшего. Это очевидно. Но обучение ремеслу разработки это чуть сложнее, чем просто накинуть на сеньора пачку буратин и надеяться, что он это как-то разгребет. А именно это и произошло в нашей занимательной задачке:

            Ни у Коли, ни у Васи особого опыта работы с подчинёнными не было.
            Советовать им, разумеется, никто не брался – слишком уважаемые были
            личности. Пришлось нашим героям самостоятельно решать, куда и как
            двигаться.

            А мой поинт в том, что если вы хотите нанимать джунов завтра, то вы должны были раскошелиться на сеньоров вчера и на мидлов сегодня. Чтобы все эти люди строили устойчивую систему, где джун и ничего не сломает и легко сможет влиться в работу. Также вы должны были вложиться в грамотный HR-процесс. И уж точно не пускать это на самотек и усмотрение самих сеньоров. Выращивание должно быть системой, а не игрой в рулетку "авось проканает".

            Почему я так думаю? Потому что я видел всю дичь с наймом толпы джунов в компанию к единственному сеньору на 2х предыдущих работах. Ничего кроме "Коли" там в принципе получиться не может. И, наоборот, я вижу как легко джун вливается в мой текущий коллектив, преимущественно сеньорский.


            1. PuerteMuerte
              13.12.2022 20:13

              Но обучение ремеслу разработки это чуть сложнее, чем просто накинуть на сеньора пачку буратин и надеяться, что он это как-то разгребет.

              Что такое "как-то разгребёт" ? Что в вашем понимании "обучение ремеслу разработки"? Обязательно взять человека, который не знает, какой стороной к себе ставить клавиатуру, и потом выделить ему персонального ментора, вести за ручку по продуманному плану обучения, с контрольными заданиями и оценками перформанса? Или всё-таки взять уже готового джуна, который прошёл это с теми, кто деньги за такое получает, т.е. хотя бы на курсах, и знает основы своей платформы, в курсе про гит и тому подобные инструменты, и посадить его уже на рабочие задачи, где сеньор выполняет роль консультанта и контролёра, а не тратит своё время на такую непрофильную задачу, как полноценное обучение?

              Выращивание должно быть системой, а не игрой в рулетку "авось проканает".

              Я прошу прощения, но вы, по сути, утверждаете, что обучение возможно только в крупных компаниях. Подавляющее большинство компаний мелкие и средние, и организовывать внутри себя курсы по обучению разработчиков они не должны, и прекрасно обойдутся простым вариантом, без всех этих хлопот. Другое дело, что джунов не должна быть толпа, сеньору в команду хватит одного-двух. Но это вопрос из другой плоскости, в обсуждаемой басне про перегрузку Коли толпой джунов ничего не упоминалось, вы просто домыслили что-то из личного негативного опыта.


      1. DvoiNic
        13.12.2022 15:42
        +1

        разработчик разработчику рознь.
        Один может научить, другой нет. Даже при желании (а не факт, что и желание было).


  1. Racheengel
    13.12.2022 16:40
    -1

    Просто Василий вырос из уровня кодера до тимлида. И доказал, что заслуживает апгрейда. Развитие - это нормально.

    А Николай так и остался вечным кодером. Да, сильным, перформящим, но кодером. Это как лучшая лошадь в колхозе. Таких не повышают.


    1. vvbob
      13.12.2022 23:13
      +3

      Это не рост, это разные сферы деятельности. Кто-то умеет и ему нравится быть руководителем, кому-то оно нахрен не надо и не нравится, зато он при этом офигительный разработчик. Заставить такого человека быть лидом - вместо отличного программера получаем, в лучшем случае, посредственного руководителя. Это не апгрейд вообще ни разу.

      Ну и так в целом, в статье описан антипаттерн "бросаем в воду, авось выплывут", кто-то и выплывет, а кто-то утонет к чертям. Синьор программер вовсе не тождественнен опытному лиду, это как взять и посадить за комп лучшего водителя службы доставки - ну а что, с машиной он вон как ловко управляется, талантливый человек, значит и с программированием разберется моментально.


      1. DvoiNic
        14.12.2022 08:10
        +1

        добавлю, что «лид» — это скорее роль, чем должность. В том смысле, что не обязательно лида назначать — даже в «горизонтальной команде» по факту все равно возникает авторитет, лидер. Пусть даже он не имеет должности руководителя.


        1. vvbob
          14.12.2022 09:54

          Согласен, и самая правильная тактика - это выявлять таких неформальных лидеров, и делать их формальными, тогда новое назначение не будет вызывать сильного стресса ни у коллектива, ни у нового руководителя, это будет просто формализация и так уже по факту имеющегося руководителя. А брать и назначать просто успешного разработчика, в надежде что он и руководителем будет отличным - это авантюра.


          1. DvoiNic
            14.12.2022 10:07
            +2

            А брать и назначать просто успешного разработчика, в надежде что он и руководителем будет отличным — это авантюра.

            дык Принцип Питера же…


      1. Racheengel
        14.12.2022 15:37

        Тут я очень сильно не согласен.

        Рост означает в том числе, что человек в состоянии применить имеющиеся знания "вширь", то есть на более масштабную сферу деятельности, чем написание кода и решение офигительных тасков В ОДИНОЧКУ. А больший масштаб, как следствие, требует привлечения других сотрудников для решения объёма задач, с которыми даже один суперсеньор чисто физически не справится за требуемое время.

        Другими словами, переход в лиды - это апгрейд на качественно новый уровень. Да, для этого придётся увеличивать свои знания в менеджменте и качать софт-скиллы. Но это же и есть продвижение.

        А пример с машиной - вообще не в тему. Корректнее сравнить, что лучшего водителя поставили бригадиром над другими водилами. Предметная область то не меняется.


  1. Racheengel
    13.12.2022 18:50
    +4

    Хотя есть ещё одна версия - по стечению обстоятельств Коле досталась команда идиотов. И он вовремя этого не определил и продолжал тащить за всех. А Василию повезло с адекватными джунами.


  1. GbrtR
    13.12.2022 20:47
    +2

    А в чём мораль басни?

    Джуны в течении всего времени язык в ж… засунув молчали? ЛПРы (это не автор статьи случайно?) не проверяли состояние дел? Николай который был не счастлив, но держил язык в том же месте что и его джуны?

    Наиболее пострадавшие это наверное джуны, как самые уязвимые. Потеряли время и не выросли, особенно по сравнению с конкурентами из Васиной команды. Николай приобрёл ценный опыт — не лезть в лиды, это не его, ну и кое чему всё равно научился. Компания конечно не заработала, но по большому счёту это для неё продольно-поперечно.

    What did we learn?


  1. Xiaomi-top
    13.12.2022 20:50
    +1

    Мы должны сделать выводы что обучение и менторство ничто, а делегирование все? Вроде бы должна быть золотая середина а мне внушают что если выкинуть из гнезда птенчиков, то они обязательно полетят. Вроде бы Коля ведь тоже помогал и обучал их. Не пойму почему они не обучались?

    И чуть не по теме. Что за фетиш обучать людей, а не брать обученных? Как только научатся поверьте они уйдут на соответствующую позицию, или здесь потребуют другую ЗП. Мне кажется надежда на лояльность на года иллюзия. А то что они сделают пока научатся задёшево все равно проходит не без мидлов. Да и минус репутация. На хрен они джуны кому упёрлись?


    1. Racheengel
      14.12.2022 16:06

      Неучи дешевле :)


  1. onets
    13.12.2022 21:37
    +3

    Узнал в себе Колю. У меня на проекте есть задачи, которые надо сделать. Там есть и легкие и сложные, разные. Если я буду их выстраивать по уровню сложности - пожалуй половина зависнет до тех пор, пока я их не возьму. А джун будет простаивать в этот момент, потому что он их решить пока не может. И не понятно, что лучше.

    Да и как-то я стал замечать, что лет 8 назад у меня лучше получалось управляться с джунами. Кажется тогда я был Васей. Интересно, что произошло за эти 8 лет.


    1. arheops
      14.12.2022 07:12

      За эти 8 лет у вас разрыв поколений произошел и разница в квалицифкации повысилася, ваш Кэп.


    1. DvoiNic
      14.12.2022 08:24

      возможно, 8 лет просто усиленно занимались разработкой.
      общение (в т.ч.обучение, не говоря уж о руководстве — это отдельный скилл, который так же атрофируется при неприменении, и «накачивается» при регулярном использовании)


    1. Racheengel
      14.12.2022 15:51

      Джуну можно давать рутинные и несложные задачи, которые самому (с уровня собсвенного величия и превосходства) уже не хочется делать лично :)


  1. t278
    14.12.2022 04:04

    Я как "Вася" действовал, дали мне нового сотрудника после курсов 1С. Через 3 месяца он мог делать очень много. Оставалось убедить его поверить в себя и стать самостоятельным. Что он и сделал.


  1. unnamsa
    14.12.2022 08:33

    а что, после начала статьи прям никому не было понятно, чем закончится? сказочка с предсказуемым финалом, никакой интриги


  1. GBR-613
    14.12.2022 16:13

    По моим наблюдениям, из очень(!) хороших программистов редко получаются хорошие тимлиды. Такие люди не доверяют окружающим, не без оснований считая их глупее, и предпочитают всегда всё делать сами. Подлинное же искусство руководителя это не работать, а не-работать. Организовать все так, чтобы подчинённые как можно больше делали всё сами, а он бы только наблюдал за ходом процесса.


    1. DvoiNic
      14.12.2022 16:16

      Подлинное же искусство руководителя это не работать, а не-работать. Организовать все так [чтобы работало без него]

      именно потому некоторые возвращаются из «руководителей» в «специалисты».


    1. Racheengel
      14.12.2022 16:16

      А руководителю просто времени не будет всё самому делать. Постоянные митинги, звонки, отчёты, паверпоинт, вот это всё. И про людей нельзя забывать.


  1. zweroboy1
    14.12.2022 20:52

    Как говорил наш майор на военке: "Хороший командир это тот, который сидит в сторонке и курит бамбук пока его солдаты выполняют поставленные им задачи".


  1. 0serg
    15.12.2022 09:08

    Не верю в историю, извините.

    Во-первых не верю в то что по методу Коли можно добиться высокой производительности от джунов. Понятно что с объяснениями от Коли производительность джуна будет лучше чем у Васи где джун плывет как-нибудь сам и он справится с более сложными задачами. Но "каждый джун производил столько сколько Коля в одиночку"? Извините но нет даже близко. Хорошо уже если производительность всех вместе не упала.

    Во-вторых непонятно с чего вдруг Коля стал резко выгорать а Вася (который по версии истории, напомню, тащил все сложные вещи на себе) нет. Полагаю что это полный бред. Вероятнее всего Коля тупо брал на себя намного больше работы (или начальство свалило на него гораздо больше работы) а Вася элегантно увернулся прикрывшись тем что у него тут джуны и делать эту работу он не может. Это кстати заодно позволит прекрасно объяснить "не верю №1" - Коля стал работать больше, вот его производительность и выросла. Но мы простите тогда получаем тут несколько иную историю - пока Коля закрывал потребности бизнеса работавший в разы меньше Вася "учил джунов". Ну а потом силы у Коли закончились, да.

    В-третьих я не верю что вообще в целом подход "пусть джун делает все сам" работает а "вот хорошо расжеванное техзадание" нет. Джуна надо научить хорошим практикам и подход №2 с этим (при правильном подходе) справляется, а подход №1 - не особо. Разумеется постоянно жить с №2 невозможно и в какой-то момент надо разработчику дать больше самостоятельности, но обыкновенно это и считается "переходом из джуна в миддлы". Научившийся на подходе №2 джун обычно довольно неплохо представляет как должно выглядеть поставленное самому себе задание и умеет его решать, остается лишь попрактиковаться. А правильно поставленные процессы (прежде всего покрытие кода тестами и своевременные review) делают этот процесс довольно безопасным и не требующим большого надзора.

    В-четвертых я не верю что мотивацию джунов определяет то к кому они попали - к Васе или к Коле. Мне доводилось видеть синьоров которые внезапно "разучивались" решать сложные задачи - не получается и не получается, кто-нибудь другой возьмет и сделает. Видел я и массу джунов горевших желанием делать сложные задачи хотя им не спешили их выдавать. Тут проблема может быть только в том что Коля грубо говоря запрещал джунам делать сложные задачи, прямо по рукам бил если они начинали такой заниматься, но по моим наблюдениям это чаще приводит к уходу мотивированного джуна из компании туда где дают заниматься сложными задачами а отнюдь не к тому что он просто начинает ничего не делать. Но разумеется у Васи должна была быть та же самая проблема - не случайно же он старался сложные задачи не брать вообще а те что брал решал сам. То есть неготовность видеть что человек уже вырос и ему можно постепенно давать более сложные поручения на мой взгляд полностью ортогональна разнице подходов Васи и Коли. Если уж на то пошло то подход Коли мне кажется позволяет начать поручать сложные задачи джуну раньше. А реальную мотивацию у джунов проследить тоже несложно - "получить статус миддла". Те кто старается делать сложные задачи промотируются, те кто халявит и у них вечно все более-менее сложное "не получается" - нет.

    В-пятых есть еще такое понятие как лояльность которое в статье не затронуто вообще. Обычная тема - джун набрался опыта и уходит туда где предложили зарплату выше. А теперь внимание вопрос: какой джун уйдет с большей вероятностью - тот который учился у старших товарищей остающихся в компании или тот которому предложили учиться самостоятельно?