Comments 87
Главное чтобы потом джуниор не превратился в ждуниора habrahabr.ru/post/183708/#comment_6387990
UFO just landed and posted this here
а уходит в другую фирму с двукратным ростом зп?
Бывает, что это проще, чем получить повышение зарплаты в своей.
Я и многие мои знакомые знают это не по наслышке. Кто-то уходит джуном, кто-то миддлом. Но в любом случае получается волшебство — работа та же, зарплата ощутимо выше даже с учетом повышения «в своей» :)
Я не понимаю, что мешает фирмам повышать джунам зарплату согласно их росту и согласно рынку. Да, вы вложите в него не 10к, а 20к, но при этом получите лояльного сотрудника, который через 3 года будет приносить вам 20-50к чистой прибыли в год.
Вероятно, причина в том, что я смотрю на проблему «со своей колокольни».
Я не понимаю, что мешает фирмам повышать джунам зарплату согласно их росту и согласно рынку. Да, вы вложите в него не 10к, а 20к, но при этом получите лояльного сотрудника, который через 3 года будет приносить вам 20-50к чистой прибыли в год.
Вероятно, причина в том, что я смотрю на проблему «со своей колокольни».
Была у нас ситуация, джуниор в итоге ушёл в другую фирму. Но я был даже этому рад. Я радовался его успехам, вспоминая какой он пришёл к нам и какой ушёл от нас. Некое чувство гордости даже за него =)
Не teamlider а team leader.
Классная иллюстрация к статье
Картинка веселая, <зануда> но хочется дать по макушке тому, кто баблы рисует в таком порядке. Люди в нашей стране читают с лева на право и сверху вниз. Поэтому бабл джуниора, как минимум, должен быть выше чем бабл PM'а.</зануда>
Люди в нашей стране пишут «слева направо», а не то, что вы написали.
Очевидно, автор иллюстрации привык читать справа налево, как в известных веселых картинках
Работал в компании, которая принимала в основном вчерашних студентов. Многие уходили, часть людей выросла в специалистов только в какой-то области по которой работали (наример субд), оставшиеся рано или поздно дорастали до более-менее грамотных разработчиков. В основном рост зависит от личных качеств человека (50%) и от понимания вещей описанных в статье у его ментора (50%). Страдает при таком подходе качество продукта и нервная система ведущих разработчиков (которые сами несколько лет назад были таким же джуниорами).
Самая большая проблема с хорошими джуниорами это научить их работать в команде. Это сложнее, чем сделать из него хорошего специалиста.
Всегда удивляло: когда человек идёт на курсы по программированию, он должен платить, и это логично, потому что его учат.
Но когда человек устраивается Junior'ом, он точно также обучается (даже ещё более качественно, т.к. обучение происходит на реальных примерах), при этом он отнимает время у более опытных товарищей, что, в совокупности, по логике, должно ещё больше увеличить взымаемую с него плату по сравнению с курсами. Но парадокс: в этом случае уже платят ему!
Если что, я не зажравшийся работодатель, а тот самый Junior.
Но когда человек устраивается Junior'ом, он точно также обучается (даже ещё более качественно, т.к. обучение происходит на реальных примерах), при этом он отнимает время у более опытных товарищей, что, в совокупности, по логике, должно ещё больше увеличить взымаемую с него плату по сравнению с курсами. Но парадокс: в этом случае уже платят ему!
Если что, я не зажравшийся работодатель, а тот самый Junior.
Я не программист, но junior'ы встречаются почти везде:) Так что выскажу свое мнение. Забыто минимум два момента:
1. Junior хотя и обучается, но при этом все же работает. Возможно, с учетом затрат времени опытных товарищей прибыли он приносит не так уж и много, но ведь приносит (если совсем не приносит — это действительно странно:))
2. Обучение происходит на реальных примерах — это да. Но с точки зрения junior'а это не всегда плюс — возможно, бОльшая часть того, чему он учится, ему в другом месте не понадобится. А со стороны работодателя (ну и заодно опытных товарищей) — junior учится именно тому, что надо, и именно так, как надо. Так что на выходе не кандидат с общими навыками, которого надо вводить в тему, а тот самый опытный товарищ. Другой вопрос, что этого опытного товарища надо удерживать — ну так любого специалиста надо:)
1. Junior хотя и обучается, но при этом все же работает. Возможно, с учетом затрат времени опытных товарищей прибыли он приносит не так уж и много, но ведь приносит (если совсем не приносит — это действительно странно:))
2. Обучение происходит на реальных примерах — это да. Но с точки зрения junior'а это не всегда плюс — возможно, бОльшая часть того, чему он учится, ему в другом месте не понадобится. А со стороны работодателя (ну и заодно опытных товарищей) — junior учится именно тому, что надо, и именно так, как надо. Так что на выходе не кандидат с общими навыками, которого надо вводить в тему, а тот самый опытный товарищ. Другой вопрос, что этого опытного товарища надо удерживать — ну так любого специалиста надо:)
Я Junior.
Первые 2-3 месяца на работе занимался R&D для нового проекта, можно сказать «обучался».
Зато теперь после этого самого R&D я тяну проект и помогаю Senior'ам разобраться в Ruby и Frontend'е.
Поэтому я думаю, что 2-3 месяца затрат я уже смог нивелировать. Вопрос в том — когда реально человек начинает приносить пользу.
Первые 2-3 месяца на работе занимался R&D для нового проекта, можно сказать «обучался».
Зато теперь после этого самого R&D я тяну проект и помогаю Senior'ам разобраться в Ruby и Frontend'е.
Поэтому я думаю, что 2-3 месяца затрат я уже смог нивелировать. Вопрос в том — когда реально человек начинает приносить пользу.
Можно разбить вопрос на два, тогда его будет просто понять.
Когда юниор способен приносить пользу? — Грубая оценка: примерно тогда, когда он может подменить опытного работника, если тот уйдет в отпуск или заболеет.
Когда он принес пользу? — Тогда, когда ему дали задание и он его выполнил.
Эти вопросы прямые, а изначальный больше похож на производную функции профита по времени, которая состоит из общей суммы от разных работников:)
Когда юниор способен приносить пользу? — Грубая оценка: примерно тогда, когда он может подменить опытного работника, если тот уйдет в отпуск или заболеет.
Когда он принес пользу? — Тогда, когда ему дали задание и он его выполнил.
Эти вопросы прямые, а изначальный больше похож на производную функции профита по времени, которая состоит из общей суммы от разных работников:)
По вашей логике можно считать так:
ЗП = а*прибыль_от_джуниора — б*потерянная_прибыль_на_обучение, где а и б — коэффициенты полезности джуниора и всех кто его учит соответственно.
Может оказаться, что ЗП должна оказаться меньше нуля. Причем заметье, первые пару месяцев на новой работе почти каждый сотрудник прибыли приносит гораздо меньше, чем получает ЗП. Так может тогда на испытательном сроке люди будут платить работодателю за возможность на него работать?
ЗП = а*прибыль_от_джуниора — б*потерянная_прибыль_на_обучение, где а и б — коэффициенты полезности джуниора и всех кто его учит соответственно.
Может оказаться, что ЗП должна оказаться меньше нуля. Причем заметье, первые пару месяцев на новой работе почти каждый сотрудник прибыли приносит гораздо меньше, чем получает ЗП. Так может тогда на испытательном сроке люди будут платить работодателю за возможность на него работать?
Может работодателю нанимать работника, который уже нужен и подходит для поставленных задач? По вашему алгоритму получается, что работодатель может нанять тысячу юниоров, не дать им ни одного задания и собирать с них бесконечное бабло.
Какое-то время на вход в проект, да и вообще на вникание во внутренние процессы понадобится даже для суперспеца и даже для продавца в магазине. Какое-то обучение всё равно нужно будет проводить, разница только количественная.
В прошлом веке была игра Сеттлерс II. Там была такая модель обучения военных: в крепость заходят рядовые, потом им туда заносят золотую монетку и один рядовой превращается в офицера, со следующей монетки офицер превращается в кого-то круче, а еще один рядовой в официра. Т.е. формировалась «карьерная» лесенка и она росла, а те кто не был в ней — ждали, чтобы попадать в лесенку (захватываться в лесенку) и рости. Таким образом, более выгоднее было заполнять крепость не рядовыми, а разными, чтобы они строились в ряд и повышались все сразу.
Применительно к нашей теме, компании было бы полезно иметь простые задачи, чтобы нанять на них юниора и он рос, принося пользу и получая положительную зарпплату. Например, он сразу же может вытаскивать замятую бумагу из принтера и т.п. Если компания не может разбить задачи на разные уровни сложности, то та лесенка будет с дырочками вместо ступенек.
Применительно к нашей теме, компании было бы полезно иметь простые задачи, чтобы нанять на них юниора и он рос, принося пользу и получая положительную зарпплату. Например, он сразу же может вытаскивать замятую бумагу из принтера и т.п. Если компания не может разбить задачи на разные уровни сложности, то та лесенка будет с дырочками вместо ступенек.
Можно было не объяснять — прекрасно помню.
Но дело не в том, чтобы просто разбить задачи на разные уровни сложности, но и как-то повышать уровень, чтобы джуниор не остался вечным вытаскивателем бумаги, даже если допустить, что бумага застревает столь часто, что отдельный человек для её вытаскивания окупается.
Но дело не в том, чтобы просто разбить задачи на разные уровни сложности, но и как-то повышать уровень, чтобы джуниор не остался вечным вытаскивателем бумаги, даже если допустить, что бумага застревает столь часто, что отдельный человек для её вытаскивания окупается.
Не понял как уменьшить картинку (в предпросмотре не срабатывают width=«200» height=«150»), здесь пример, справа watchtower, там рядовые, а когда внесут монетку, правый станет круче на 1 ступень(«позолотеет»), потом уже два правых, потом три, и так пока все не станут генералами из чистого золота:)
2VolCh, ну, не все же помнют:) А вот пусть между тем чтобы вытаскивать бумагу, ему будет задача поставлена, которую он еще не может выполнить, задача для следующего уровня мастерства:)
2VolCh, ну, не все же помнют:) А вот пусть между тем чтобы вытаскивать бумагу, ему будет задача поставлена, которую он еще не может выполнить, задача для следующего уровня мастерства:)
хороший лайф-хак
Я уже давно не джуниор, но меня тоже иногда удивляет, когда за какой-то особо интересный проект платят на порядок больше, чем за рутину. Он же такое интересный, его и бесплатно не грех сделать :)
Джуниор это инвестиции для компании. Достаточно рисковые.
В среднем, первые полгода-год он не окупается, а только тратит — тратит время лида и миддлов, свою зарплату, налоги, велосипеды, баги.
А в связи с тем, что в последнее время рынок перегрет, джуниоры хотят много денег сразу.
Поэтому сейчас мало компаний возьмут на воспитание джуниора без кабальных контрактов.
В среднем, первые полгода-год он не окупается, а только тратит — тратит время лида и миддлов, свою зарплату, налоги, велосипеды, баги.
А в связи с тем, что в последнее время рынок перегрет, джуниоры хотят много денег сразу.
Поэтому сейчас мало компаний возьмут на воспитание джуниора без кабальных контрактов.
Практика в крупных компаниях несколько другая.
Заключается соглашение с университетами, на практику с низкой зарплатой берётся студент. Таким студентам дают отдельные маленькие проекты, или некритичные части больших проектов. Если за 3 месяца он показывает хорошее развитие и результат — после получения диплома нанимают на позицию джуниора.
Дальше думаю ясно.
Заключается соглашение с университетами, на практику с низкой зарплатой берётся студент. Таким студентам дают отдельные маленькие проекты, или некритичные части больших проектов. Если за 3 месяца он показывает хорошее развитие и результат — после получения диплома нанимают на позицию джуниора.
Дальше думаю ясно.
В среднем, первые полгода-год он не окупается, а только тратит
Вот это всегда удивляло. Это как надо поставить процесс разработки, чтобы человек за целый год не мог сделать ничего полезного?
Джуниор — это человек, который знает синтаксис языка, но имеет мало опыта в реальной разаработке.
Ок, науськиваем его на какой-нибудь более-менее отдельный модуль. Сколько времени нужно, чтобы в нем разобраться? Ну месяца-то хватит.Если больше, то проблемы с архитектурой очевидны.Через месяц человек уже может править баги в этом модуле и дописывать какой-то функционал. Пары месяцев хватит, чтобы толковый человек прочитал результаты код ревью своего кода и осознал в чем есть ошибки и как сделать лучше.Если нет — ну что ж, три месяц как раз испытательный срок.
Студенты курса «операционные системы» в приличных институтах вполне себе пишут патчи для ядра линукс, вролне разбираются в его кодовой базе в качестве курсовой.
Юные хирурги, солдаты, ученые в первый год вполне приносят пользу, а программисты почему-то не могут…
Ну, тут может быть вариант, что пользу-то приносит, но пока зарплату и прочие траты (налоги, социалка и т. п.) не отрабатывает. Но вообще согласен — или очень неудачно наняли, или сильно завысили зарплату изначально, если за полгода он не смог хотя бы в ноль по бюджету выйти. Ну или вообще никого нанимать не надо было — и так бы справились :) Исключения равзе что проекты требующие глубоких теоретических и практических знаний в предметной области, но тогда лучше, наверное, специалиста в этой области обучить программированию, что часто подтверждается в топиках нужна ли «математика программисту».
Еще есть проблема в том, что никоим образом невозможно определить, в «плюс» джуниор для компании работает, или в «минус», если работа идет в команде. Оценивает все это руководитель и часто очень субъективно.
Да, в принципе очень сложно оценить полезность программиста в деньгах.
Вот например человек исправил название переменной aaa1 на numOfClients. Это он сколько пользы принес? На 100 рублей? Или на 0 рублей, потому что клиент этого не заметит?
Я верю, что теоретически можно подсчитать, в какой момент технологический долг начнет приносить компании ощутимые убытки и насколько этот долг уменьшит такой рефакторинг, но не верю, что в «нормальных» компаниях таким занимаются.
Вот например человек исправил название переменной aaa1 на numOfClients. Это он сколько пользы принес? На 100 рублей? Или на 0 рублей, потому что клиент этого не заметит?
Я верю, что теоретически можно подсчитать, в какой момент технологический долг начнет приносить компании ощутимые убытки и насколько этот долг уменьшит такой рефакторинг, но не верю, что в «нормальных» компаниях таким занимаются.
Вопрос еще в том, сколько будет «стоить» этот подсчет, и какой смысл тратить эти «деньги» :)
Это вам сейчас есть над чем подумать в конструктиве, а как вы будете пользу от бухгалтера вычислять?
Эмпирически — убрать бухгалтера, посадить чувака с улицы за МРОТ и посмотреть на результаты :)
Мне кажется что это касается не только программистов, на самом деле. У них наверное это наиболее «остро» стоит, но думаю и в других отраслях точно так же. Точно так же из эникейщиков со временем можно вырастить нормального админа, к примеру.
А можно вырастить эникейщика, который может работать с вдвое большим количеством эникеев и считает себя кулхацкером :) Грань в самосознании тонкая :)
Это я не поржать, а к тому что человек должен хотеть куда-то развиваться, иначе он не сможет вырасти из эникейщиков вообще никогда. Не заинтересованного не вырастишь.
Это я не поржать, а к тому что человек должен хотеть куда-то развиваться, иначе он не сможет вырасти из эникейщиков вообще никогда. Не заинтересованного не вырастишь.
Естественно, всё упирается в желание. Я вот начал работать в 16 лет эникеем и все 12 лет работы стремился узнавать что то новое, в итоге сейчас я считаю себя неплохим, средней руки админом, но я всё ещё хочу учится и развиваться дальше (при чём уже и в программировании в том числе)
Ну эникейщик по определению должен развиваться больше чем программист. Новый софт и оси, новые версии старого, новое железо и т. п. А программист в теории может десятилетиям ничего нового в программировании не изучать, а просто выдавать результат — работающую программу, если его заказчиков/работодателей не интересуют такие вещи как качество кода, использование современных технологий и методологий, несовместимость с современным софтом/железом и т. п. Вон не так давно серия постов была о человек который до недавнего времени писал и успешно продавал бухгалтерский софт на FoxPro для DOS — вырос он как программист за 20 лет? Сомнительно.
Возвращаясь к вопросу о возможности сэкономить, наняв Джуниора. Уровень молодого специалиста все время растет, соответственно, должна расти и зарплата.
Должна…
Во многих компаниях, как я могу наблюдать, вообще нет такого понятия как «джуниор». В них все — «программисты»/«инженер-программисты». И довольно странно порой видеть человека, проработавшего в компании лет 10, который получает не на много больше, чем новый работник.
И компании обычно отечественные, советского образца. Такое наблюдалось на прошлой работе после ухода половины отдела. Тем кто работает долго — платили немного, когда все ушли постарались заинтересовать новых работников.
Математика простая: ушло условно 4 человека с зарплатой в 10 рублей — наняли 2-их на 12, оставшиеся 16 поделили еще на шестерых. Итого имеем 6 старых работников с зарплатой по 13 рублей, 2 новых с 12. Доп расходов нет — ситуация для работников «улучшилась».
Математика простая: ушло условно 4 человека с зарплатой в 10 рублей — наняли 2-их на 12, оставшиеся 16 поделили еще на шестерых. Итого имеем 6 старых работников с зарплатой по 13 рублей, 2 новых с 12. Доп расходов нет — ситуация для работников «улучшилась».
Это нормально. Многим через 10 лет надо снижать зарплату. Потому что ничего кроме «наш проект уникальный, мы не можем делать так, как остальные, поэтому мы вводим ещё 23 новых процесса информирования начальства» они больше не могут. Вот эти ребята работают в глубокий минус. Вплоть до «проект закрыт по финансовым соображениям — заказчик убежал к конкурентам».
Про одну компания как-то услышал фразу: «не просто дают знания, но и платят стипендию», имя в виду, что на ту з/п, что это компания считала нужным платить работникам, иначе как стипендией назвать было нельзя. Шли на эти деньги по большей части студенты, ну или те, кому было край как надо работу найти.
Неудивительно, что уход работника происходил сразу, как только ему подворачивалось что-то поприличнее. Рук-во при том думало, что экономит, а все коллеги уходящего начинали грустить, т.к. любого работника заменить на студента — это не месяц и не два натаскиваний его… Про качество продукта компании говорить даже не буду, и так понятно.
В общем, платите работникам хорошо — и будет вам счастье! )
Неудивительно, что уход работника происходил сразу, как только ему подворачивалось что-то поприличнее. Рук-во при том думало, что экономит, а все коллеги уходящего начинали грустить, т.к. любого работника заменить на студента — это не месяц и не два натаскиваний его… Про качество продукта компании говорить даже не буду, и так понятно.
В общем, платите работникам хорошо — и будет вам счастье! )
Да, нужен понятный карьерный рост. Во многих крупных западных компаниях эта возможность выстроена, причем очень гладко, повышения регулярные, порой даже раз в полгода. Поэтому тот, кто сегодня джуниор, поднабравшись опыта будет расти внутри компании, все время чуть-чуть да и улучшать свои позиции, плюшки, зарплату. При непрерывном прогрессе опыта и плюшек очень редко кто уходит. Просто организовывать надо все правильно.
Не всем нужен карьерный рост, если это не символический «лвлап», влияющий только на зарплату, монитор и кресло.
Личное наблюдение — после отказа от предлагаемого повышения приходится увольняться, потому условия работы как-то ухудшаются. Вроде ничего конкретного, вернее мелочи какие-то типа премии на 5% меньше выписали, не разрешили на полчаса раньше уйти, коллегам мониторы меняют, а ты в конце очереди оказываешься, и т. п., но как-то капля за каплей…
Личное наблюдение — после отказа от предлагаемого повышения приходится увольняться, потому условия работы как-то ухудшаются. Вроде ничего конкретного, вернее мелочи какие-то типа премии на 5% меньше выписали, не разрешили на полчаса раньше уйти, коллегам мониторы меняют, а ты в конце очереди оказываешься, и т. п., но как-то капля за каплей…
Я не рассматриваю вариант, когда опытный тим-лид, чувствует в себе силы и желание помогать молодому поколению программистов, делясь своим опытом. Это прекрасно! Но я такого не встречал. Самый распространенный случай — Джуниор стоит дешевле.
Возможно, в сайтоклепальных конторах так дело и обстоит, но в фирмах, занимающимися средствами разработки, я многократно наблюдал мотивацию нанимать студентов и даже старшеклассников на летнюю практику, полугодовой интерншип и т.п., когда о «вложении в будущего сотрудника» речи даже не идёт.
Причин несколько:
1) социальная ответственность — понятие, по-видимому, в России незнакомое. «Соседские дети хотели бы научиться программировать, но в школах/вузах их научить некому — неужели дадим их таланту пропасть?»
2) вложение в экосистему — «чем больше программистов будет вокруг через десять лет, тем лучше будет всем, и в частности для нас рынок будет шире и лучше».
3) реклама — «если первое, с чем он привыкнет работать как программист, будет наш продукт, то наверняка он продолжит им пользоваться и в дальнейшем».
Мне кажется, что не стоит забывать, что не всякий джуниор = студент/только выпустившийся из университета.
Инженер, который сменил род деятельности тоже будет на первых порах джуниором (как по факту, так и по приставке в названии должности). К примеру, QA перешл в разработчики или наоборот. У такого инженера есть определенный опыт за плечами. Но его нужно поднатаскать под новый для него род деятельности, и это не всегда убытки в полугодовой перспективе. Как уже заметили, любой новый человек, даже если он супер специалист в своем деле, на новом проекте даже в первый месяц не принесет особо много прибыли кампании т.к. в проект надо еще влиться.
Инженер, который сменил род деятельности тоже будет на первых порах джуниором (как по факту, так и по приставке в названии должности). К примеру, QA перешл в разработчики или наоборот. У такого инженера есть определенный опыт за плечами. Но его нужно поднатаскать под новый для него род деятельности, и это не всегда убытки в полугодовой перспективе. Как уже заметили, любой новый человек, даже если он супер специалист в своем деле, на новом проекте даже в первый месяц не принесет особо много прибыли кампании т.к. в проект надо еще влиться.
Вот интересно посмотреть на статистику по возрасту Junior'ов. В каком возрасте не стыдно начать Junior'ом?
Мне в 38 не стыдно. Другой вопрос, что похоже работодателям за меня стыдно.
Стыдно не начать, если есть такая возможность и желание. Другой вопрос в отношении работодателя к вашему возрасту
Спасибо, вынес одну ценную мысль — четко понимать для каких задач берется джуниор. Соответственно, можно из него вырастить узкоспециализированного профессионала, который закроет определенный фронт работ. Причем для узкого круга задач человека подготовить можно гораздо быстрее, чем разработчика-универсала, который умеет всё.
На практике обычно все происходит иначе — руководство решает влить денег в проект, чтобы было быстрее/лучше, открывается вакансия, под нее находится джуниор. Далее тимлид уже по факту думает что бы ему такое дать, чтобы не мешал работать и сам справлялся. Ну да, человек растет, но вширь, т.к. кидают ему задачи простые и абсолютно разные.
На практике обычно все происходит иначе — руководство решает влить денег в проект, чтобы было быстрее/лучше, открывается вакансия, под нее находится джуниор. Далее тимлид уже по факту думает что бы ему такое дать, чтобы не мешал работать и сам справлялся. Ну да, человек растет, но вширь, т.к. кидают ему задачи простые и абсолютно разные.
Хорошая статья, но почему-то у меня сложилось впечатление, что вы работали всегда только в одной компании, максимум — в двух, через призму которых вы и делаете обобщение.
Ага, примерно с момента появления первых коммерческих компиляторов. В чем смысл этой фразы?
Но ее осознает каждый настоящий руководитель/teamlead. На эту тему могу рассказать анекдот: на одном проекте осталось двое сотрудников: программист и менеджер. Программист подходит к менеджеру и спрашивает «Слушай, значит, я теперь тимлид?».
По-мойму здесь перепутаны директор, менеджер и тимлид. Это ведь не тимлид решает, кого нужно нанимать, чтобы проект стал более рентабельным, итд.
В последнее время, многие компании начали открывать у себя вакансии для молодых неопытных программистов.
Ага, примерно с момента появления первых коммерческих компиляторов. В чем смысл этой фразы?
фактически, вы становитесь наставником этого человека, и не каждый руководитель или тим-лид эту ответственность осознает.
Но ее осознает каждый настоящий руководитель/teamlead. На эту тему могу рассказать анекдот: на одном проекте осталось двое сотрудников: программист и менеджер. Программист подходит к менеджеру и спрашивает «Слушай, значит, я теперь тимлид?».
Но я такого не встречал. Самый распространенный случай — Джуниор стоит дешевле.
По-мойму здесь перепутаны директор, менеджер и тимлид. Это ведь не тимлид решает, кого нужно нанимать, чтобы проект стал более рентабельным, итд.
Это ведь не тимлид решает, кого нужно нанимать, чтобы проект стал более рентабельным, итд.Вот тут не согласен с вами. Директор мыслит категориями вложений-прибыли: «Давайте наймем еще человека, чтобы ускорить сроки и увеличить прибыль». Менеджер тоже слабо представляет кто нужен проекту: «Можно усилить тех.поддержку или разработку внеплановых задач, которые вечно срывают сроки». И только тимлид знает, что «На поддержке больше всего проблем вызывает СУБД, а вне плана чаще всего приваливают доработки отчетов, значит нам нужен чувак со знанием xxxSQL и yyyСУБД, коммуникабельный и флегматичный одновременно (техподдержка)».
Естественно, на практике круг ответственностей и роли могут быть достаточно сильно искажены личными качествами всех этих руководителей.
Вы не о том. Я говорю о финансах в плане конкретных чисел, а не каких-либо категорий в стиле «ускорить», «увеличить». В компаниях, где работал я, финансами занимались менеджеры и директора проектов. Тимлид не отвечает за финансы и не должен забивать себе голову чужими обязанностями.
Далее: рассказы про менеджеров, которые ничего не знают и что-то там слабо представляют я с вашего позволения оставлю за бортом, поскольку не считаю таких людей квалифицированными менеджерами. И также замечу, что поскольку вы говорите о техподдержке, то менеджеры на таких «проектах» имеют как правило гораздо большую возможность вникать в детали процесса, поскольку техподдержка не является проектной деятельностью в большинстве случаев.
Далее: рассказы про менеджеров, которые ничего не знают и что-то там слабо представляют я с вашего позволения оставлю за бортом, поскольку не считаю таких людей квалифицированными менеджерами. И также замечу, что поскольку вы говорите о техподдержке, то менеджеры на таких «проектах» имеют как правило гораздо большую возможность вникать в детали процесса, поскольку техподдержка не является проектной деятельностью в большинстве случаев.
Самый распространенный случай — Джуниор стоит дешевле. Если это ваш случай — откажитесь от этой идеи.
Есть аутсорсинговые компании, делающие ставки именно на джуниоров. При том, если джуниор вырастает до сеньора, то его не очень то пытаются удержать, если тот требует зп хотя бы среднюю по стране в этой технологии.
Если представить, что весь персонал это пирамида (уровень снизу вверх), то такие компании увеличивают пирамиду, закладывая новый фундамент, а не достраивая ее на основании более опытных сотрудников.
Мне кажется, такой подход особенно оправдан в отделах саппорта. А сеньорам можно делегировать более сложные и ответственные задачи.
Есть такая классическая книга «Управление фирмой, оказывающей профессиональные услуги». Там как раз с этой пирамиды всё и начинается. И в именно уникальностью услуг (в смысле бизнес-процессов, а не в смысле рынка) определяется форма этой пирамиды. Если услуга отлажена и есть чёткий бизнес-процесс по которому её могут делать младшие специалисты, основание пирамиды должно расширятся. Иначе, оставляем джуниоров по минимуму.
Интересная статья.
А может кто-то сказать, как подобное происходит с juniour web-дизайнерами? Что им на начальном этапе доверяют, какие требования?
Заметил, что в вакансиях на младших программистов требуют «базовые навыки и понимание принципов одного ОО языков, а дальше научим», а вот у дизайнеров сразу «владение на высоком уровне вектор, растр, флеш и т д»
А может кто-то сказать, как подобное происходит с juniour web-дизайнерами? Что им на начальном этапе доверяют, какие требования?
Заметил, что в вакансиях на младших программистов требуют «базовые навыки и понимание принципов одного ОО языков, а дальше научим», а вот у дизайнеров сразу «владение на высоком уровне вектор, растр, флеш и т д»
Я бьюсь уже долгое время и не могу никак найти ответ, может вы скажите хоть: до какого возраста джуниоров компании готовы трудоустраивать у себя? Понятно что седовласый джуниор 50ти лет это бред, и 45ти, а 40? а 35? Где проходит эта черта. Причем я имею в виду полного нуба, который перешел в эту сферу из других тех. специальностей, не гения и не тунеядца.
Sign up to leave a comment.
Воспитываем Джуниора