Комментарии 64
Тут нет единой правильной формулы и правильного пути. Все люди разные.
Для кого-то стартап будет отличным вариантом. Ответственность и неизвестность сыграет отличным мотиватором. И он быстро «прокачается» на разноплановых задачах
Кому-то намного комфортнее пройти этот путь в большой компании «с методом под боком»
в маленьком стартапе, где от каждого разработчика требуется решать сразу много разноплановых задач, или в большой компании, где все процессы уже более-менее стандартизованы и поставлены на поток?
если стартап полагается на джуна — это так себе стартап.
или основатели ничего не понимают в тех. скиллах или у них нет ресурсов на настоящего спеца.
учится в стартапе не у кого, кроме себя самого, а это малоэффективно и не все так могут.
1. Небольшое количество разработчиков.
2. Дай бог, чтобы эти разработчики были нормальной квалификации. Но присутствие даже одного джуна вызывает опасение, что они там все вчерашние студенты. В лучшем случае позавчерашние.
3. Горящие сроки и связанные с этим компромиссы. Потому что стартапу нужно срочно закрепиться на рынке, у него нет времени на нормальную разработку.
4. Слабо развитая инфраструктура. Потому что доводить её до ума для команды из десяти человек — некому.
Но новичкам обычно выбирать не приходится.
Джуны бывают разные. Зачастую после первого роста, компании, которым повезло растить джуна превращаются в "stepping stone", и джун уходит дальше, на лучшие начала. Такой поток сохраняется.
Да, найм джуна — это не усиление команды, а частичное ее ослабление на срок обучения
И вот это хроническое, во всяких мелких вебстудиях. Хорошо если есть процесс в компании по типу стажерства и в компании есть рост на года.
джун уходит дальше, на лучшие начала
Чаще всего причиной этого является эмоционально понятное, но ошибочное поведение компании «мы в тебя вложились, поэтому теперь ты нам обязан и мы будем тебе недоплачивать»
Поддерживаю. В моем представлении должно быть так — сначала "ты пока обучаешься, поэтому мы тебе платим мало", потом "ты уже обучился и хорошо знаешь наш проект, поэтому мы тебе платим нормальную зарплату".
Как это знакомо, это случилось со мной на втором году карьеры. Как-то я услышал при общении на кухне в обед, что компания использует этот подход и после этого как отрезало.
За 2-3 месяца желание работать и проявлять инициативу упало до 0, т.к. осознал что в ближайшее время никакого роста не будет. При этом не известно когда работник "отработает долг".
Да, в итоге я ушёл. Но проработал лишние полгода, только ради того что бы помочь закрыть проект над которым работал, и который некому кроме меня было закончить. Я мог бы этого не делать, но был благодарен конторе.
Я как-то был джуном, но потом в бухгалтерии лежала стопка договоров с размером з/п и я её немного подсмотрел незаметно. Через пару недель я уволился)
Вы уверены, что в той фирме 100% зарплаты «в белую» выплачивалось?
Видал и такие фирмы, где официальная зарплата всего навсего 10% от реальной…
Соответственно, ни в каких бухгалтерских документах 90% суммы вы бы не увидели.
И тут задача работодателя обеспечить такую среду, из которой он не захочет уходить к другим: хорошая команда, возможности для развития, возможности проявить себя, интересные задачи.
Зп тоже влияет. Но она не всегда на первом месте. Человек может жертвовать частью зп ради «плюшек» описанных выше. Но и платить годами человеку зп, которую он перерос давно — не правильно.
Проблема в том, что если вы — обычная небольшая ИТ компания, то вы не сможете конкурировать за джуна с гигантами. Ну никак. Ни по деньгам, ни по количеству печенек в офисе. Можно пробовать конкурировать по задачам или уровню личной свободы, но джунам это как раз обычно не нужно. Они еще не попробовали разного, не наелись энтерпрайз-уныния, им любая работа кажется одинаково интересной.
Опять же про деньги: джуны часто жалуются что им долго не повышают зп. Хотя по факту на самом деле просто первое время им переплачивают — платят больше, чем та польза которую они приносят. Просто потому, что на меньшую сумму никто не согласится. И только где-то через год может быть реальная польза от него догоняет его зарплату, а ему-то кажется что он вырос и потому зарплата тоже должна вырасти. Хотя по факту он просто до нее наконец дорос.
Джуны хотят попробовать всякого разного, боятся засидеться на одном месте — вдруг они выбрали неправильное место и неправильный стек, засидятся тут, а потом их на работу никто не возьмет с таким опытом.
В общем куча причин есть ухода джунов, с которыми вы ничего не сможете сделать, если вы не условный Яндекс, где хотя бы авторитетом и строчкой в резюме можно взять, ну и офисом модным.
И поэтому мало желающих с ними возиться, особенно в малом и среднем бизнесе. Потому что это действительно как правило инвестиции, которые никогда не окупятся.
1) они делали свою работу, когда были джунами
2) это норм, что они уходят, если вы не можете обеспечить им «хорошую среду» (писал выше про задачи, команду и все такое). Я думаю и ты можешь перейти в другую компанию, если тебя заинтересуют, или если будет «плохо» на текущей.
Мидлы роняют стейдж
Синьоры роняют прод
Вы случайно не попутали наставничество с рабством? Своего джуна, как это прекрасно.
1) Просто так заставить джуна как раба работать за тебя, а самому целыми днями бездельничать — невозможно. Ибо джун такого наворотит — его нужно контролировать, проверять, направлять. Это занимает кучу времени.
2) Разумеется, джуна не поставят пилить архитектуру (впрочем, и такое бывает, но это показатель плохой организации труда). Джуна поставят делать не самую интересную работу. Например, косяки выгребать из кода за другими. Джуну кажется что это рабство, эксплуатации и т.п. Но, глядя в чужой хоть и неидеальный код, джун таким образом, начинает понимать — а как на самом деле выглядит изнутри выглядит та система над которой работает фирма.
С учётом того что у банка денег на кого угодно хватит.
Денег то может и хватит, но человеческие ресурсы ограничены.
Скорей всего многие ответят на него по разному и имеют разные причины.
Я вижу так:
Во-первых, удивительно, но на «рынке» реально мало толковых специалистов. Даже мидлов. Сейчас есть много ребят, которые прошли курс на, условно, JavaRush и хотят сразу 100500 в минуту и быть синьорами. И получается, что легче компании «вырастить» своего условного мидла. Который будет и с хорошими техническими знаниями. И сразу еще со знаниями бизнес-процессов внутри компании и ее целями.
Во-вторых, в этом есть что-то… (Не знаю какое слово подобрать правильнее.)
Если у компании есть возможность взять стажеров и джунов и дать им хорошие и качественные знания, то почему бы и нет? На рынке будет больше хороших специалистов. Будет больше конкуренция среди них, подталкивающая их больше развиваться.
Тут главное понимать, что есть условная команда «в мыле», которая и так загруженна «по самые уши», то такой команде нельзя давать (или брать) Джуна. Я про то и пиши в статье, что это ответственный шаг. И команда должна быть готова к нему. Нельзя взять Джуна и просто забить на него. Так будет только хуже всем.
Ну я вот конкретный тимлид. Беру иногда студентов. Мне по фану кого-то поучить чему-то, посмотреть как они развиваются. Ну и кучу мелких рутинных задач есть на кого сгрузить — им все равно полезно для развития на начальном этапе, а более ценных сотрудников отчасти разгружает.
скорее всего ему делают предложение «от которого нельзя отказаться».
Может где-то такое и есть, но я не встречал.
Зачем ему конкретно головняк, ради какого-то «светлого будующего» банка или отрасли в целом.
У каждого свои причины. Кому-то нравится учить. Кто-то так развивает софт-скилы. У кого-то единственный способ усилить команду, это взять джуна (других не дают)
Не могу ответить за всех
Ну то есть я тимлид, у меня не хватает ресурсов, встаёт вопрос что делать. И я говорю давайте джуна наймём, нам полегчает?
так ты, как тимлид, и должен в первую очередь понимать, полегчает или нет. если джуна мало, то твоя задача доказать, что нужен миддл или сеньор.
С учётом того что у банка денег на кого угодно хватит.
у банка лишних денег нет, потому их у него и много
Не сбрасывайте со щетов ворох конторок, где понятие команды весьма условно (если вообще есть). А должности в лучшем случае младший и старший разработчик. И то годами не меняющиеся.
1. 100+ резюме, 10+ собесов,…, взял джуна и естественно не кого попало
2. вырастил джуна (вероятность 1/2-3/4)
3. получаю уведомление что «рекрутёръ атакують», начинаю превентивный движ
4. затем оказывается, что денег на апгрейд ставки нет(а я же взял нормального, поэтому офферы уже естественно есть )
5. подписал ему заявление
6. «у вас же есть ставка джуна», goto 1.
эта музыка будет вечной.
Если вы берете Джуна «на вырост», что бы самим его обучить до нужного вам уровня, то у вас должна быть под это условная вакансия под мидла.
Если вы можете позволить только Джуна, то, наверное, не стоит удивляться, что они потом, когда набираются опыта, уходят на позицию выше, где им ее могут предложить?
Тут, на мой взгляд, другого не может быть.
Даже если у вас Мега крутая компания и люди, они рано или поздно уйду на позицию выше, если вы сами ее им не дадите.
эта музыка будет вечной.
это изначально можно прикинуть и экономически оценить.
ну например из моей последней практики:
- среднее время работы джуна в конторе — 2 года.
- из них 2 месяца — это чистые убытки, ты за ним постоянно смотришь, консультируешь целыми днями. причем первые 2 недели — это вообще целый рабочий день парное программирование.
- а потом тратишь на него меньше времени. но всё равно много. и это пока идут убытки
- а где-то через полгода он начинает выходить в 0 (выдает чуть больше пользы и чуть меньше проблем).
- последние полтора года идет прибыль с джуна. часть этой прибыли, разумеется, идет в зачет первого убыточного полугода.
- ну и где-то около года из двух лет работы — джун приносит чистую прибыль и радует тебя.
- можно делать апгрейд ставки, а можно не делать — зависит от особенностей фонда оплаты труда конкретного предприятия.
- но задачей с точки зрения бизнеса является не вечное удержание, а удержание как минимум хотя бы до тех пор, чтобы джун окупил свое обучение и принес сверх этого какую-то разумную прибыль. сколько именно — это оценки только ваши. по моим прикидкам 1,5 года (из которых 1 год — это убытки и их компенсация, а 0,5 года это прибыльный период) — это самый минимум целесообразности удержания джуна. если меньше, то нет смысла изначально его нанимать.
- если удалось более менее точно прикинуть время обучения и время получения прибыли и с учетом этого корректно установить заработную плату, то с экономической точки зрения это выгодно и то, что он уйдет потом — уже не принципиально для выгоды предприятия.
- не значит, что не нужно пытаться удерживать обученного специалиста, но это не критично, если вы корректно оценили убытки и прибыль с джуна.
А что не так с Google-программистами?
это те, кто нагугливают готовые решения. а не думают своей головой.
у них очень быстро растет квалификация на примитивных задачах.
но при попытке использовать таких гуглепрограммистов для сколько нибудь сложных вещей — сталкиваешься, что их квалификация резко упирается в потолок. и этот потолок довольно невысок.
потому что готовых решений вашей комплексной конкретной задачи в гугле еще не существует (будет существовать если вы задачу решили и напишете статью об этом).
есть только решения для маленьких подчастей вашей задачи.
если человек способен собрать из маленьких пусть и нагугленных подчастей хорошую комплексную систему — то это не гуглепрограммист.
если же он пытается нагуглить комплексное решение — это гуглепрограммист.
я встречался даже когда вбивают в поиск локальные пути к своим файлам своего проекта (типа /home/vasyapupkin/projects/mysuperproject_uniquename) в поисках решения — то есть даже не способны сформулировать корректный запрос для поисковой системы, не могут абстрагировано выделить проблему, которую нужно нагуглить.
неприятный сюрприз в том, что на примитивных задачах у них на удивление отличные решения (это если гуглепрограммист освоил термин best practics и добавляет это словосочетание к описанию проблемы). и это вводит в заблуждение. ты думаешь, что раз твой джун так хорошо решил маленькую проблемку по работе, то он уже крепкий специалист… но нет.
совсем недавно на Хабре была об этом целая статья.
Интерестно, а изменилось что-нибудь в процессе в связи с удаленной работой? Все же как я понял статья писалась про людей которые сидят в офисе
Для сложившихся специалистов — не имеет значения.
Для джунов — только сложнее стало. По удаленке сложнее скиллы прокачивать, так как стало суше-формальнее взаимодействие с опытными коллегами, которые бы при очном общении запросто подсказывали.
Тему подняли интересную, но аргументация статьи — ерунда с кучей каких-то непрофессиональных комплексов и вот почему:
Почему-то многие команды и руководители считают, что джун вольется в коллектив и работу над проектом как-то «самостоятельно»
Не считают. Есть процессы адаптации и onboarding'а и не только джунов. В команду\проект может не влиться и матёрый, бородатый сеньор.
Это сейчас подавляющее большинство из нас — опытных разработчиков — уверенные в себе профессионалы.
Кину камень в ваш огород — вы выкатываете релизы в часы пик, которые парализуют работу бизнеса. Т.е. зарелизить новый серверный бэк в разгар дня — норма. Обратная совместимость — нет, не слышали, blue-green deployment — тоже мимо.
Любой джун — это проблема команды разработки. Он отвлекает старших разработчиков, роняет прод, пишет плохой код и тратит бесценное время своих коллег на исправление его ошибок.
Это не проблема джунов. Это проблема корпоративной культуры, если её нет, то сколько не клей пластырь на воздух, он не приклеится. Правильный сетап — когда команды и специалисты понимают зачем и как им нужно растить джунов, а ещё лучше сами инициирует подобные действия.
Современная разработка — это работа в поле высокой неопределенности, бесконечная гонка под лозунгом «это надо было реализовать еще вчера».
Нет. Это лишь значит что на проекте отвратительные процессы и никчёмный менеджмент.
Крайне важно давать джуну боевые задачи, пусть это и отразится на графике спринта и еще больше затянет сроки.
Да важно и нет, не отобразится, но только при условии — Scrum Master или тимлид или ПМ не спят в уголочке, безвольно пуская слюни, а хотя бы занимаются черновым планированием спринта.
Что же действительно важного вы не написали:
- Фидбэк — обратная связь — мощный инструмент с которым надо очень аккуратно работать. Им можно как поломать карьеру человека, так и сильно её ускорить.
- Менторство — более эффективно чем парное программирование, развивает навыки R&D и решения проблем, а не безголового — делай как я и пофиг если не эффективно.
- Правильная коммуникация — не стоит "дрючить" джуна слишком часто или жёстко, так и забывать о нём не стоит, джун должен понимать что его статус отслеживают. Это же работает и в обратную сторону: джун должен понимать что обратившись к этому человеку он получит помощь, но слишком часто отвлекать более опытного товарища тоже не стоит: потыкался, что-то попробовал, погуглил, собрал пачечку вопросов и пошёл их разъяснять.
- Процессы — должны быть чёткие инструкции куда бежать и что делать.
- Нормальная команда и руководители — я видел несколько поломанных карьерных судеб у действительно стоящих людей, но на старте они столкнулись с конченными мудаками и уродами.
Как не испортить своего джуна