Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Карьера специалиста глазами менеджера

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

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

Проблематика

Итак, чтобы обсуждать так называемые «повышения», давайте прежде всего разберемся, что мы под этим подразумеваем. Я знаю по крайней мере две вещи, которые скрываются за этим словом:
1) повышение уровня сениорности;
2) повышение уровня зарплаты.

Менее опытные менеджеры могут спросить, зачем разделять эти два понятия. Дело в том, что в то время как менеджер имеет все полномочия пересматривать профессиональный уровень специалиста, он может иметь определенные ограничения в пересмотре его зарплаты. Объясняется это тем, что зачастую в компаниях существуют определенные политики, связанные с пересмотром зарплат. Например: «Зарплаты могут пересматриваться не чаще, чем раз в год» или «Все повышения должны быть одобрены высшим руководством», или «Бюджет на зарплаты не должен превышать Х» и т. д. Все эти политики накладывают определенные ограничения на решения ПМ-а о пересмотре зарплат.

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

Ошибка № 1 — придирки. Рассмотрим некую компанию X, в которой каждый год проходит оценка сотрудников и пересмотр их зарплат. Программист Петя уже фактически вырос до миддла, и у него с менеджером уже был разговор на эту тему. Но цикл оценки будет только через полгода, и менеджер искусственно оттягивает повышение Пети, чтобы попасть в этот цикл. Более того, чтобы аргументировать эту отсрочку, менеджер начинает придираться к Пете, объясняя, что он еще «ну не совсем миддл». В результате Петя может уйти, так и не дождавшись повышения, а менеджер рискует оставить о себе не самое приятное впечатление.

Ошибка № 2 — поспешность. Та же компания. Маша — трудолюбивый миддл-тестировщик. Она неплохо работает, но до сениора пока не дотягивает. Вот подходит долгожданный цикл оценки и менеджер решает: «Черт с ним, Маша с нами уже давно, повышу ее сейчас, чтобы потом не ждать еще год». В этом случае проект получает такого себе «недосениора», который может так и зависнуть на этом этапе, никогда по сути не став настоящим сениором.

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

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

Профессиональный рост

Если построить график зависимости уровня сениорности специалиста от времени, то получится интересная картинка.

На этом графике можно увидеть, что чем более сениорным становится специалист, тем сильнее замедляется его профессиональный рост. Это происходит потому, что с ростом сениорности специалист все меньше времени тратит на свое развитие. На графике я привел приблизительное соотношение между «полезным временем» для проекта и временем, которое тратится на саморазвитие для каждого из профессиональных уровней.

Например, джун тратит до 60% своего времени на саморазвитие, засыпая вопросами более опытных сотрудников, читая профессиональную литературу и работая над своими ошибками. С другой стороны, сениор может решить 90% проектных задач, загружен он всегда на 110%, но на собственное развитие времени у него остается мало. Давайте запомним эти примеры, так как эта концепция будет ключевой при дальнейшем рассмотрении уровня зарплат команды.

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

А для этого вам надо ответить на такие важные вопросы:
— Что означает каждый уровень сениорности и каковы критерии их достижения?
— Как и когда проводить оценку специалистов?
— И наконец, кто может дать им наиболее адекватную оценку?

Давайте отвечать по порядку.

Действительно, для начала нам необходимы критерии сениорности, понятные для специалистов и отражающие действительные потребности проекта. Они не должны представлять собой чек-лист из 50-ти вопросов. Достаточно, чтобы критерии отображали самые важные аспекты оценки.

Пример. Сениор должен:
1) уметь менторить джунов;
2) быть способным самостоятельно разобраться с 90% задач и предложить их решение;
3) уметь решать вопросы с лидом со стороны заказчика и т.д.

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

О, нет... Еще одна бюрократия? Зачем? Да, это еще одна бюрократия, но в ваших силах сделать ее не нудным опросником, а дискуссией, интересной и полезной для вашей команды. По своему опыту могу сказать, что из всей проектной бюрократии эта была самой востребованной всеми членами команды.

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

И все было бы просто замечательно, если бы все и всегда были готовы работать за одни и те же деньги. К сожалению или к счастью, это не так, а следовательно пора поговорить и о деньгах.

Зарплатный рост

Когда мы говорим о зарплатном росте, мы на самом деле подразумеваем всего два вопроса: «Когда?» и «На сколько?»

На эти вопросы мы ответим немного позже, а для начала, давайте вернемся к нашему любимому графику профессионального роста. Итак, мы определяли уровень сениорности исходя из той пользы, которую специалист приносит проекту. Соответственно «прирост пользы» можно конвертировать в «прирост к зарплате». Другими словами, если человек стал приносить проекту в 2 раза больше пользы, проект должен по сути удвоить его компенсацию. Это наиболее справедливая и прозрачная зарплатная политика.

Так когда и на сколько? Давайте, для наглядности, нарисуем наш график и разобьем его на равные интервалы, скажем, ежегодные, предполагая, что зарплата пересматривается раз в год 31-го декабря, ровно в 12:00 :).

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

Например, в случаях C, D, E повышения по графику выглядят вполне обоснованно. В случаях F и G лучше подождать следующего цикла, чтобы сумма прибавки выглядела более весомо. А в случаях A и В стоит эскалировать вопрос о повышении даже раньше срока.

Осталась одна неясность: как же все-таки измерить пользу для проекта в долларах, а не в процентах? В этом нам помогут вилки зарплат. В одних компания они формальные, в других — нет. В одних — открытые, в других — секретные. Но во всех они есть.
Вилки зарплат можно отобразить на рисунке следующим образом:

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

Изучили? Теперь внимание: используя такой подход, вы можете легко отделить профессиональный и зарплатный рост, так как на этом графике повышение зарплаты происходит при пересечении вертикальной линии (период пересмотра зарплаты), а повышение сениорности — при пересечении горизонтальной (соответствие критерию сениорности).

На самом деле подход к повышениям зарплаты изменился следующим образом:
— Раньше: Сениорность => Компенсация
— Теперь: A) Польза => Сениорность, B) Польза => Компенсация

Мы ввели понятие «пользы для проекта». Это понятие является ключевым как для определения уровня сениорности, так и для определения величины зарплаты. Таким образом, мы избавились от «порочной» связи «сениорность—компенсация», которая и была причиной описанных выше проблем.

Как-то все это очень сложно... Что мне это даст?

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

1. Критерии. Прежде всего подумайте, какие критерии сениорности соответствуют вашему проекту/команде/компании. Формализируйте их и объясните своим ребятам.

2. Оценка. Попросите техлидов помочь вам оценить свою команду, используя описанные выше критерии.

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

4. Регулярные 1×1-митинги. Назначьте регулярные 1×1-митинги со всеми членами команды, обозначив те из них, на которых будет проводится пересмотр уровня сениорности.

Маша и Петя (ответы). Давайте теперь еще раз рассмотрим те две неприятных ситуации, которые я приводил в начале статьи. Если представить их на графике, то можно увидеть, что Петя, по сути, находился в секторе B и вполне мог получить уровень миддла, ожидая цикла пересмотра зарплаты. Маша же, очевидно, была в секторе D, и в принципе могла получить свое повышение зарплаты, оставаясь миддлом и продолжая дальше расти на сениора. Видите, все совсем не сложно.

Итог

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

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

Удачи вам в вашей работе, поменьше стресса и неприятных ситуаций!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Хорошая статья :)
И это правильно, что отделяется профессиональный рост от рост зп. Потому что более качественно работать только ради повышения зп на очередные 200-300$ в конце года вряд ли будешь. А вот более качественно работать ради повышения пользы, сложности задач (и конечно же шильдика senior) — это другое дело :)

А так есть два совета — для компаний надо просто уменьшать бюрократию при пересмотре зп :)
И делать ее возможным хоть раз в три месяца. В зависимости от роста и развития конкретного человека. Ведь с учетом нынешней динамики развития технологий и времени проектов — год это часто очень много.
Люди просто не дорабатывают до конца года и уходят через 10-11 месяцев на +300+500 в другую компанию.

А для ребят программистов самый простой совет:
Рост можно разделить на две части — технический (технологии, сложность задач и т.д) и soft skills (коммуникации, общение с заказчиком, менторство, лидерство)

Лично я больше всего рос в техническом плане в двух случаях:
1) Когда задумывался о смене работы — изучал новые технологии, активно контрибьютил в опен соурс, пилил pet projects :)
И это позволяло быстро расти — намного быстрее, чем если просто пилить код на проекте.
2) Когда после этого приходил на новый проект на новых технологиях, разбирался с этим всем + опять же опыт новых людей и того, как они пишут код :)

А в плане софт скиллс — где-то в середине работы на проекте, когда влился и освоился в технической части и берешь на себя больше ответственности по тому, как проект будет развиваться. Плюс начинаешь заниматься менторингом и т.д.

И когда поняли что на нынешнем проекте многое узнали и выросли — самое время делать pet projects, изучать новинки, делать доклады на конференциях и т.д...
И со временем переходить на новую работу.

Все равно с моей точки зрения намного больше реального опыта у человека, который поработал по году на трех разных проектах, чем три года на одном :)
Ну и плюс у него больше ЗП )))
Так как переходить можно и на +500+1000$ на новое место. А на текущем месте для миддла вряд ли добавят больше чем +300$ через год.

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

Хорошая статья. Автор здраво рассуждает и пытается найти способ отказаться от измерений «на глазок», введя какие-то адекватные метрики и числовые измерения. Видно, что он долго думал об этом вопросе. Спасибо за статью.

Как понять, вырос ли уже программист до сениора или еще нет? Если вырос — то как это должно отразиться на его зарплате? А если нет — как это ему коммуницировать?

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

Это же надо придумать — повышение без повышения.

если честно эта градация джуниор-мидл-сеньор, и развитие между ними — полная лажа.

обычно с ростом до сеньора докидывают общественных обязательств, а так все сводится к одному — programming-motherfucker.com не зависимо от лычки

есть одна истинная градация — ставка за час. самая гибкая между прочим. можно заплатить 10 баксов за час, а можно 100, и хоть трейни называйте, кому какая разница после этого

124 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Great Article, thank you! I really liked the picture too:)

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

>Другими словами, если человек стал приносить проекту в 2 раза больше пользы, проект должен >по сути удвоить его компенсацию. Это наиболее справедливая и прозрачная зарплатная >политика.

В реальности так не бывает, мы не живем в чистом капитализме. В среднем синьер получает в 2 раза больше мидла, но делает явно в 4 раза больше, а если мидлу платить в соответствии с их вкладом, то они будут просто постоянно менять работы.. Другой пример из другой сферы, зп программиста в Швеции в среднем в 2 раза выше зп уборщицы, но он явно приносит больше пользы.
Так что этот довод противоречит политики социального равенства в Европе, но не на Украине.

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

У вас наверно скрам не в чести, иначе о синьорах бы не шла речь.

Не проследил связи. Что вы имеете ввиду?

Друзья, я вас поздравляю, мы на главной странице ain.ua в секции «почитать на выходных»!
Видно наши бурные дискусии не прошли незамеченными :)

Это всё хорошо, но кто у вас ниже джуна? Frанцуз?

В глобале — фрешер, а вот про французов не слышал ). Правда в статье я опирался на всем известные грейды, т.к. все остальное может сильно варьироваться от компании к компании.

В глобале — фрешер
Интересная ступенька. Готовит свежевыжатые соки для всех кто старше?

Скорее, из него выжимают все соки, потому и фрешер )

Пример. Сениор должен:
1) уметь менторить джунов;
2) быть способным самостоятельно разобраться с 90% задач и предложить их решение;
3) уметь решать вопросы с лидом со стороны заказчика и т.д.
Забыли самое главное — писать качественный, лего расширяемый, понимаемый и поддерживаемый код. Сениор может менторить джунов, предлагать красивые решения, иметь отличные софт скиллы, но если он пишет убогий и корявый код, который понимает только он — вряд ли его можно назвать Сениор. В то же время опыт написания хорошего кода приходит только со временем, причем по разным оценкам ( из собственного опыта весьма авторитетных гуру ) это от 5 — 10 лет.

На своих проектах такие требования я обычно предъявляю даже к мед уровню.
Т.к. если только сениоры будут писать нормальный код, то перспектива у проекта может быть не сильно радужная.

2. Оценка.
Какие гарантии адекватной оценки ? Компания заинтересованная сторона. Также могут быть плохие/хорошие отношения в коллективе.

Вы подняли интересный вопрос. На эту тему можно дискуссировать долго, но в краце я бы ответил так: Объективную оценку человек конечно не получит, т.к. не существует какого-то объективного мерила для всех. С другой стороны если специалиста оценивает его непосредственный лид, то оценку можно считать адекватной в рамках данного проекта. Главное тут понимать, что это НЕ оценка знаний и умений человека в целом, а лишь оценка его полезности на данном проекте и в данной команде.
Я немного пытался раскрыть эту тему тут:
dou.ua/...ta/articles/1×1-meetings

Пример. Сениор должен:
1) уметь менторить джунов;
Потому, как готовым спецам мы платить не хотим, а хотим взять очередного юриста-выпускника айтишных недокурсов (иногда даже собственных))) по $15 в день, а продать кастомеру по $25 в час. Сеньеру же внушим, что это прямое продолжение карьерного роста, поднимем загрузку до
загружен он всегда на 110%
причем доплачивать за менторство или снимать часть других задач не будем.

Сплошной profit))

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

Это такой сарказм?) Не могу уловить интонацию)

точняк. сарказм :)
не могу говорить прям обо всех проектах, но зачастую набирать одних синьоров просто не рационально.
и без присмотра новичков тоже оставлять стоит. код-ревью, регулярные Q&A, может, даже план развития и список литературы — в этом определенно есть смысл.

но зачастую набирать одних синьоров просто не рационально.
Есть еще мидлы, например)

Вообще, насколько я помню, тот же Глобал еще лет так 7 назад принципиально не брал людей без опыта, и зп там стартовали с 1к. Были у них джуны, да, но с 6+ месяцами опыта. Они знают, как выглядит ± типичный workflow, быстро вливаются в проект и не доставляют особой головной боли.

Это не тот джун, который вчера продавал телефоны, а сегодня гордо именуется Junior QA /php/Java.
У джуна-девелопера есть хотя бы код-ревью, который с большой вероятностью предотвратит явные косяки, а QA же — это адЪ и Израиль.
Доводилось менторить вчерашних экономистов? Мне да. Хватило впечатлений до конца жизни))

Я в растерянности :) В одних темах пишут «почему компании не хотят брать трейни/джунов?» «как мы будем строить будущее ИТ, если не будем никого учить?», в другой — «из-за жадности набрали вчерашних юристов, кто их будет теперь учить?». Где правда?

«почему компании не хотят брать трейни/джунов?» «как мы будем строить будущее ИТ, если не будем никого учить?»
Это вопрошают вчерашние юристы и экономисты)))
«из-за жадности набрали вчерашних юристов, кто их будет теперь учить?»
Ну да. «От них пользы один вред».
Где правда?
Правда в том, что пока бакс был по 5 количество левых людей в айти стремилось к 0. Когда бакс был по 8, начали появляться первые экономисты, но их было мало и это не особо бросалось в глаза.
когда бакс стал по 11+ - началось безумие #вайтивайти
когда бакс стал по 11+ - началось безумие #вайтивайти
И вообще, для отрасли это не плохо. Конечно общее качество сервиса при этом страдает, но при правильной работе рекрутеров и менеджеров, есть возможность выбрать лучших из лучших.

да ну ладно. почему страдает? кто это качество мерял?
те, кто начали 10 лет назад джунами уже прокачались и стали лидами / архитекторами / менеджерами. А те, кто 5-7 лет работает уже может коучить-ментроить молодняк вполне.

при правильной работе рекрутеров и менеджеров
С этим у нас бяда-пичаль.
есть возможность выбрать лучших из лучших
Лучших из оставшихся. Из моей первой тимы почти все свалили в Европы.

похоже на то, как #коренные стонут о том, что #понаехали

не будет притока свежей крови, не будет развития индустрии.
а без этого и интересных проектов и высоких зарплат

похоже на то, как #коренные стонут о том, что #понаехали
я уже #поуехала
не будет притока свежей крови, не будет развития индустрии.
а без этого и интересных проектов и высоких зарплат
Это не кровь, но водица, это раз.

Согласные работать «за еду» демпингуют цены на специалистов, пока на уровне junior-middle, но через несколько лет просадят и синьеров. От этого выигрывают только хозяева галер. Опытные спецы очень активно валят, ибо смысл.

IT-сноб детектед
Про падение зарплат уже несколько лет говорят. Пока только растут. И вообще это рынок. Не умеете конкурировать — идете на пенсию.
Убер вон тоже всем таксистам поперек горла стал, т.к. в крупных городах лицензия таксиста стоит кучу денег и нервов. Но вот пользователи почему-то довольны. Совпадение?

IT-сноб детектед
да ладно
Пока только растут.
Ой ли. Растут на синьеров, тк их не хватает, джун-мидл скорее падают, особенно джун.
И вообще это рынок. Не умеете конкурировать — идете на пенсию.
Я-то как раз синьер))))) И конкурирую я на рынке покруче украинского, причем как понаехавшей в первом поколении мне тяжелее, чем местным))
Убер вон тоже всем таксистам поперек горла стал, т.к. в крупных городах лицензия таксиста стоит кучу денег и нервов.
Убер и ответственности меньше несет.
Но вот пользователи почему-то довольны.
Использование Убера запрещено для совершения рабочих поездок в моей (и не только) конторе. Совпадение?)
Я-то как раз синьер))))) И конкурирую я на рынке покруче украинского, причем как понаехавшей в первом поколении мне тяжелее, чем местным
Тогда тем более непонятно, откуда такая позиция. Аналогичным образом «местные» могут жаловаться на тех, кто понаехал и разбавил их уютное болотце.
Использование Убера запрещено для совершения рабочих поездок в моей (и не только) конторе. Совпадение?
Не знаю, в моей все ок. Гораздо проще, чем с киевским такси, где еще нужно обязательно предупреждать, что нужен чек, а потом его еще и заполнять самому.
Тогда тем более непонятно, откуда такая позиция.
Strict but fair.
Аналогичным образом «местные» могут жаловаться на тех, кто понаехал и разбавил их уютное болотце.
А я за еду не работаю))) И не продаю себя «со скидкой»)
Не знаю, в моей все ок. Гораздо проще, чем с киевским такси, где еще нужно обязательно предупреждать, что нужен чек, а потом его еще и заполнять самому.
А чем киевское такси отличается от Убера?) Ни там ни там нет ни лицензии, ни страховки на пассажира, ни какой-либо ответственности хоть за что-то. Я с европейским такси сравнивала.

ЗЫ. У меня одноклассница в 21 год разбилась в такси, на нахождение несколько недель в реанимации друзья и знакомые скидывались. К сожалению, не спасло.

А я за еду не работаю))) И не продаю себя «со скидкой»)
у «местных» может быть другое мнение
А чем киевское такси отличается от Убера?)
Принципиально — ничем. Но с Убером проще. В Лондоне компании принимают выписки с него, как travel expense. Может, кто-то и отказывается, но не слышал.
К сожалению, не спасло.
Сочувствую. Но как это относится к уберу или «войтивайти»?
у «местных» может быть другое мнение
Тут, как говорится, конкуренция и рынок. По крайней мере, я не демпингую рынок и отказываюсь работать за меньшие деньги, чем местные.
Принципиально — ничем. Но с Убером проще.
Не всегда. Я могу выйти из аэропорта, сесть в любое такси и поехать по счетчику, не переплачивая, как в Украине.
В Лондоне компании принимают выписки с него, как travel expense.
Кто-то принимает, кто-то не принимает. Многие компании предпочитают не связываться (в тч в ЮК), тк у Убера нет лицензии такси.
Но как это относится к уберу или «войтивайти»?
К Уберу то относится так — перевозчик несет ответственность за пассажиров, в Европах такси в этом плане не отличается от тех же авиакомпаний. Убер не является перевозчиком как таковым, потому ответственности ни за что не несет — нет страховки на пассажира, нет контроля за состоянием авто и водителя.

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

Насчет #вайтивайти — я не знаю, почему вы пожелали сравнивать с Убером, о не суть. Удешевление поездки, которое дает Убер [в Европах, тк в Украине один хер] достигается за счет отсутствия страховок, лицензий и ответственности. Другими словами — снижение качества услуги и повышение риска для жопы пассажира.
Аналогичная фигня с юристами-девелоперами — упала цена, но и качество упало вслед за нею.

Аналогичная фигня с юристами-девелоперами — упала цена, но и качество упало вслед за нею.
совершенно не аналогичная. ответственность за качество перед заказчиком несет компания-исполнитель, а не отдельный Вася Пупкин.

демпинг? не знаю — не слышал. зато регулярно слышу, как друзьям приходят офферы на еще больше денег, хотя потолок, казалось бы, достигнут был на текущем месте.
7-10 лет назад люди начинали с ЗП в 200-300 баксов в месяц, помнится. Сейчас приходит народ без опыта и хочет в 2-3, а то и 4 раза больше. Это называется демпинг? По-моему, как раз наоборот: зажрались и офигели.

вообще у вас есть только голословные эмоциональные утверждения, поэтому дискутировать можно очень долго, но вот толку — ноль.

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

Если верить ДОУ (а если не верить ДОУ, то кому вообще верить?), то все в индустрии хорошо dou.ua/...mns/jobs-and-trends-2015

Да, вырос интерес к разработке, но это проблема людей без опыта, т.к. у них конкурс теперь жестче.

Вы читаете, что я пишу, или просто высказываетесь от балды?

совершенно не аналогичная. ответственность за качество перед заказчиком несет компания-исполнитель, а не отдельный Вася Пупкин.
От этого Вася станет лучше кодить? Нет, за Васей закрепят ментора, который потом будет если чо за Васю отгребать. Это то, о чем я писала вначале.
демпинг? не знаю — не слышал. зато регулярно слышу, как друзьям приходят офферы на еще больше денег, хотя потолок, казалось бы, достигнут был на текущем месте.
Я кажется писала, что синьеры дорожают, тк их мало.
7-10 лет назад люди начинали с ЗП в 200-300 баксов в месяц, помнится.
350-400, иногда даже 500.
Сейчас приходит народ без опыта и хочет в 2-3, а то и 4 раза больше.
Пруф? Хотеть можно что угодно, реально джунов берут на 300 баксов без проблем.
вообще у вас есть только голословные эмоциональные утверждения, поэтому дискутировать можно очень долго, но вот толку — ноль.
Да ну. Как раз эмоции тут в вас. Хотите пруфов — их есть у меня. Открываем ЗП Доу и смотрим нижний квартиль для джуниор девелопера/тестера в 2011 и в 2015. Делаем выводы.
пресловутое падение качества — покажите метрики (окромя личных утверждений), по которым это можно определить.
Даже ТС соглашался, а вам покажи. Кто будет выкладывать такого рода статистику?
Если верить ДОУ (а если не верить ДОУ, то кому вообще верить?), то все в индустрии хорошо dou.ua/...mns/jobs-and-trends-2015
Статейку читали-то?
Рост количества откликов во многом идет за счет джуниоров и людей, которые ищут первую работу в ИТ. Для них открывается все больше школ, курсов и тренингов.
На вакансии миддл и синьор уровня приходит по 4-5 резюме, на вакансии джуниор, QA и PM — свыше 20. При этом львиная доля компаний размещает только вакансии миддл и выше.
По нашим оценкам, за последние 12 месяцев уехало от 2 до 5 тыс. программистов.
Очень показательно.
Да, вырос интерес к разработке, но это проблема людей без опыта, т.к. у них конкурс теперь жестче.
Джуны на 300 баксов станут мидлами на 800-1000, мидлы подешевеют. За ними подешевеют синьеры.

Конечно, это при условии, что народ не будет массово валить.

Пользователям лишь бы дешевле.

— Сынок, возьми у меня пирожки! Очень вкусные!
— А с чем у Вас, бабуль?
— Ну, тут нынче разные. С картошкой, с капустой, с мясом, с говном!
— Что? Как это — с говном? Зачем Вы их продаете?
— Я их не продаю, они — бесплатные...
— Да какая разница! Кто же будет жрать говно? Не спорю, нахаляву — это круто! Но ведь это же — говно!
— Ну так берешь или нет?
— Ох Вы, бабуля, и странная...
— Бери, сынок, вкусные же пирожки... А эти — вообще бесплатно!
— Хе... говно в тесте, смешно же...
— Бери-бери...
— Ну давайте... Возьму у вас один с капустой, один с мясом, и... ну ладно — и два с говном...

поправочка: «некоторым пользователям»

ну и прекрасно: каждому свое

А давай на экономистов-маркетологов, «входящих в айти», посмотрим с несколько другой стороны.
Все эти люди по своей первой специальности должны более-менее понимать процессы в экономике, анализировать текущее состояние дел и хоть как-то прогнозировать развитие ситуации.
Отнаблюдав прошлый кризис 2008 и методы выхода нашей страны из него, достаточно просто было понять, что рыбы на внутреннем рынке все меньше и есть ее будет кто-то другой.
Т.е. грамотный экономист-маркетолог должен был схватиться за голову в 2009 и начать активно бегать в 2010-2011-2012 в поисках вариантов. Т.е. сейчас идет вал непрофессионалов в своей предыдущей области.
Но есть и хорошая новость — часть из этих людей таки найдет свое призвание в IT. Особенно с ростом влияния фактора «или сдохнешь физически, работая на 2-х работах в попытках прокормить семью, или научишься пилить свой код»

по $15 в день, а продать кастомеру по $25 в час
но согласитесь, было бы странно, если бы было наоборот )
А если серьезно, то кроме профитабилити есть есть еще спектр проектных задач, где некоторые будут весьма рутинными для сениора, но вполне подходящими для джуна.
Возьмите всех сениоров на проект, дайте им такие задачи и готовьтесь к атришену.
но вполне подходящими для джуна
Для джуна или джуна с ментором?))
Возьмите всех сениоров на проект, дайте им такие задачи и готовьтесь к атришену.
Кроме синьеров и джунов специалистов нет?)

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

Далее его надо только ревьювить изредка. Хотя ревьювить надо любого специалиста, особенно ньюкамера, хоть и синьйора.

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

Раскажите о своем пороге качества?

Выше писали, что есть годный код.

Вы так говорите как будто это что-то плохое :)

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

причем доплачивать за менторство или снимать часть других задач не будем.

По поводу задач — ну у нормальных специалистов все-равно 7-8 часовой рабочий день. И если менеджер накинет закидывать больше менторинг задач, то будет меньше продакшен задач делаться.
И тут задача менеджера — балансировать нагрузку.

Лично у нас на прошлом проекте, когда были факапы с планированием (в том числе и из-за пришедших джунов) — то просто не сделали все задачи в спринте и перенесли на следующий.
Менеджмент злился.
Но программистов овертаймить не заставляли. Хотя можно было по личному желанию со ставкой х1.5

Но программистов овертаймить не заставляли.
Мне приходилось. Бесплатно.

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

Лично я овертаймил и иногда овертаймлю, когда сам что-то сделал не так, как хотел и мой перфекционизм требует это исправить/доделать :)
Но это целиком добровольно :)

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

habrahabr.ru/post/282674
" Каково это — быть разработчиком, когда тебе сорок (перевод)"

В статье ощущается лень и недосказанность, как остался без десерта.
Как-то и ответить даже не на что.

Бюрократия начинается там, где взаимодействие с людьми.
Её преимущества и недостатки зависят от того, какая цель доминирует — делать работу или оформлять работу.
Очень важно вовремя опомниться и иметь возможность изменять бюрократию.

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

Повышение зарплатности — всестороннее реальное признание.
Но необходимо для себя понимать сам процесс, на что соглашаешься, с кем и чем имеешь дело.

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

Когда специалист работает так, как предполагалось изначально, менеджер уверенно попадает в назначенные сроки, отмечает выполнение задач весь процесс как задумывал и не обмазывает всех своим мылом, то какие вопросы могут быть к специалисту в данном цикле?

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

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

Сеньёр должен, менеджер должен, но не у всех есть возможность отстоять и получать желаемое, особенно критично, если это уместно и адекватно текущему статусу.

Когда специалист работает так, как предполагалось изначально, менеджер уверенно попадает в назначенные сроки, отмечает выполнение задач весь процесс как задумывал и не обмазывает всех своим мылом, то какие вопросы могут быть к специалисту в данном цикле?
Не совсем понял на счет «какие вопросы»... Вопросов собственно никакихи нет, все очень хорошо, все большие молодцы, и все получили свою заслуженную ЗП (а может и какие-то бонусы). Но причем тут повышение? Вопросы как раз были бы, если бы все было плохо )

Вопросы про камни преткновения на пути к стремлению в это состояние.

все очень хорошо, все большие молодцы, и все получили свою заслуженную ЗП (а может и какие-то бонусы)

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

Мне нравится то, как в статье описано про опеку подчинённых, но:
Процесс, описанный в статье, реализован ли в реальности?
Если да, то насколько удовлетворительно это работает?
Так же и с учётом ваших возможностей как PM.

Мне нравится то, как в статье описано про опеку подчинённых, но:
Процесс, описанный в статье, реализован ли в реальности?
Если да, то насколько удовлетворительно это работает?
Так же и с учётом ваших возможностей как PM.
Резонный вопрос. Да, все мои изложения — это только практический опыт без книжной теории.
На всех моих проектах был реализован именно такой подход, и как раз из-за его успешности, я решил поделиться им с аудиторией )
С другой стороны, сениор может решить 90% проектных задач, загружен он всегда на 110%, но на собственное развитие времени у него остается мало.

Я правильно понял: представитель одного из «лидеров рынка» заявил что в их компании возможности для развития технических специалистов синьйор-уровня практически отсутствуют?

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

если честно эта градация джуниор-мидл-сеньор, и развитие между ними — полная лажа.

обычно с ростом до сеньора докидывают общественных обязательств, а так все сводится к одному — programming-motherfucker.com не зависимо от лычки

есть одна истинная градация — ставка за час. самая гибкая между прочим. можно заплатить 10 баксов за час, а можно 100, и хоть трейни называйте, кому какая разница после этого

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

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

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

а еще раз был у меня 1 трейни в команде — ему можно было поручить более серьезные таски чем миддлу и быть уверенным что он сделает лучше.

есть такая штука что конторы смешивают проф. синьора и определенный уровень софт скиллов которые нужны для «общих» обязательств.

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

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

с зп лучше, ее легче соотносить с той работой которую человек делает реально на проекте, ибо вариации очень много, и легче отобразить проф скил через ставку. грубо говоря от 3 до 300 долларов в час, и всем будет понятно кто на что способен, а не когда три несчастных грейда — и сиди гадай как и кто человека оценивал...

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

Исходный тезис не правильный. Развитие сениора не замедляется никогда, просто из плоскости накопления базовых знания развитие переходит в плоскость решения аналитических задач и быстрого моделирования решений из накопленной и систематизированной информации. Этот скилл ГОРАЗДО реже распространнен.

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

из плоскости накопления базовых знания развитие переходит в плоскость решения аналитических задач и быстрого моделирования решений из накопленной и систематизированной информации
Приведенный выше график обобщает эти два скила. Просто накопление базовых знаний затормаживается довольно быстро (я бы сказал на мед уровне человек должен уже приобрести основной объем). И действительно, более важным становится скил систематизации и анализа. К сожалению и в этой области происходит остановка в развитии, т.к. обычно на проекте применяется ограниченный спектр моделей и шаблонов, и внедрять что-то новое может быть весьма болезненно с точки зрения бизнеса.
т.к. обычно на проекте применяется ограниченный спектр моделей и шаблонов
круто, что накопленный опыт с предыдущих проектов позволяет говорить что-то типа «давайте, тут внедрим сборщик ХХХ потому что он снимет наши проблемы с YYY»

Просто на работе Джун вынужден расти, а Сениор — не всегда.
Просто реалии жизни)

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

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

Сразу чувствуется ответ опытного PMа. Важен ответ, содержание же не важно.
Какой вообще возможный спектр ваших реакций? Без привязки к текущему проекту.

уточнение: при этом никаких жалоб на что угодно(кроме зп?) не звучало и даже в условно-доверительной беседе человек прямо говорит: не, всё устраивает, а там нифига наверняка не известно, зато +20%, потому иду туда?

Вы знаете хотя бы один проект где не на что пожаловаться?
Давайте представим на минутку что в компании на другой стороне улицы точно такой же проект

Вы знаете хотя бы один проект где не на что пожаловаться?
да. это не идеальный проект, а тот, в котором проблемы меня не бесят, а преимущества — вдохновляют.
что в компании на другой стороне улицы точно такой же проект
а вот, никогда-никогда в жизни не встречал ситуации, когда о какой-то компании, куда зовут, знал бы столько же, как о текущей компании, где сейчас работаю.
потому при переходе на «такой же проект в компании на другой стороне улицы» есть ненулевая вероятность, что и технологии не те, и бухгалтер налажает с налоговой, и кухня будет в подвале, и выходы в туалет надо будет трекать.
потому переходить исключительно из-за 20% надбавки мне кажется станной затеей.
риск высок, цель не оправдывает его.

1. За сколько процентов в плюс поменяли бы вы?
2. Если я лично знаю половину людей с проекта с другой стороны улицы(в конце концов в индустрии остаются одни знакомые лица) в достаточной степени что бы получить достоверную информацию и уверен в своей оценке происходящего там? По крайней мере что туалет не надо трекать , кухня не в подвале, к батареи не пристегивают? Компании бухгалтерию не доверяю.
3. Откуда уверенность что текущий проект хороший?

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

написал дофига, а потом передумал.
это всё сугубо индивидуально.
знаю таких, которые на +10% переходили.
у меня даже смена на +300% в принципе была в первую очередь из-за необходимости развития.

я только хотел сказать, что если возможны риски(инсайдеры не смогут ответить на незаданные вопросы, правда?), то +20% как-то слабовато. тем более, такую сумму обычно можно и в текущей компании получить.
а если нельзя — то проблема потолка серьезнее просто суммы.

я только хотел сказать, что если возможны риски(инсайдеры не смогут ответить на незаданные вопросы, правда?), то +20% как-то слабовато. тем более, такую сумму обычно можно и в текущей компании получить
а если нельзя — то проблема потолка серьезнее просто суммы.
Всех рисков вы никогда не узнаете :) Сегодня заказчик есть, а завтра выяснилось что заказчик махлюет с тестами и влетел на миллиардные штрафы. Ну и проект кончился. Такие риски не в принципе учесть нереально. Риски типа «мне не нравится кондиционер или кресло или рожа соседа» — я рисками вообще не считаю. Это можно решить поговорив с менеджером.
Касательно +20% — цифра взята сознательно, послушать господина PMа на тему повысят или нет( я конечно в курсе что глобал в данной ситуации обычно просто повышает), но ведь интересно послушать.

У меня было, что искал проект поинтереснее, пусть даже с понижением. А то последние повышения зарплаты погоды не делали и «задолбала контора» никак не перевешивали

вангую кучу недовольства в этом чате и пару тем «ненавижу манагеров» на форуме. кто вы вообще такой чтобы оценивать работу других специалистов?

Как понять, вырос ли уже программист до сениора или еще нет? Если вырос — то как это должно отразиться на его зарплате? А если нет — как это ему коммуницировать?

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

Это же надо придумать — повышение без повышения.

Наваял резюме, потом посмотрел профайл автора. Я думал речь идет о небольшой компании на 40-50 человек ... Но на Глобале система оценки персонала была разработана ИМХО лучшая из мне известных, причем насколько я знаю, внешними консалтерами. Как она работает — сори, вопрос второй :) чесно грю — не знаю. То, что здесь написано — это прыжок лет на 10 — 12 взад , когда еще «ничего не было»... зачем ?! неужели в реализации все так хреново?

... чем более сениорным становится специалист, тем сильнее замедляется его профессиональный рост. Это происходит потому, что с ростом сениорности специалист все меньше времени тратит на свое развитие.
Кто Вам такое сказал? есть некие цифры в подтверждение? Я думаю, что «профессиональный рост» и «время ... на свое развитие» зависит от человека, но не от его «сениорности».
как же все-таки измерить пользу для проекта в долларах, а не в процентах?
Почему именно «пользу для проекта» ? ИМХО грубая ошибка — ставить з-п в серьезную зависимость от проекта, где работает чел. Ситуация № 1: два проекта с разными рейтами-системами оплаты и пр. и пр. (один — сервис, второй — старт-ап). У Васеньки, которого срочно перекинули с проекта на проект, должна уменьшится-увеличицца зарплата только от факта перевода? Хорошо если перевели на более жирный проект, а если наоборот?
Ситуация № 2. Проект закрылся, заказчик застрелился (реальный случай :) ). И что, польза Васеньки резко устремилась к нулю?
Ситуация № 3
Итак, мы определяли уровень сениорности исходя из той пользы, которую специалист приносит проекту.
Допустим, на проекте есть мидл, который пашет уже полтора года и наваял львиную часть кода, и парт-тайм синьор, который ревьювит код и консультирует по архитектурным решениям. Если измерить пользу в $, боюсь что мидл будет более ценным ... более прибыльным — почти наверняка :) Слово «польза» я бы постоянно брал в кавычки, сие понятие весьма неопределенно в данном контексте.
вилки зарплат представляют из себя своего рода маппинг профессионального уровня на уровень зарплат
Уровень зарплат — где, в каком масштабе? По проекту, по компании, по городу, по отрасли? Понимаемо ли, что если эти вилки не соответствуют рынку труда, то можно лехко демотивировать человека, предложив ему з-п как в два раза меньше, так и в два раза больше рынковой?
...чем больше будет справедливости в вашей работе
Отнюдь не справедливости :( , см. нижее. Справедливость — субЪективное понятие. Карьерный и зарплатный рост, их критерии, вилки зарплат и ранжирование — должны быть понятными, прозрачными и одинаковыми для всех, т.е. содержать как можно меньше иксепшенов (без них ни один продукт думаю не обходится :8) )
Вопщем, Вы еще в начале большого пути ;) успехов .

вот, нашол Омара Хайама про справедливость .. за последние 1000 лет ИМХО ничего не поменялось
В этом мире не вырастет правды побег
Справедливость — не правила миром вовек.
Не считай, что изменишь течение жизни.
За подрубленный сук не держись, человек!

Кто Вам такое сказал? есть некие цифры в подтверждение? Я думаю, что «профессиональный рост» и «время ... на свое развитие» зависит от человека, но не от его «сениорности».
Хорошо отметили, что «профессиональный рост» и «время ... на свое развитие» это совершенно разные понятия.
На этом графике можно увидеть, что чем более сениорным становится специалист, тем сильнее замедляется его профессиональный рост. Это происходит потому, что с ростом сениорности специалист все меньше времени тратит на свое развитие.
Бред.

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

Согласенн с вами, но между этими «да» и «нет» есть очень большой диапазон «наверное». Если бы всегда можно было односложно отвечать на такие вопросы, работа менеджера сильно бы упростилась )

Хорошая статья. Автор здраво рассуждает и пытается найти способ отказаться от измерений «на глазок», введя какие-то адекватные метрики и числовые измерения. Видно, что он долго думал об этом вопросе. Спасибо за статью.

И вам спасибо за отзыв. Рад что понравилось, надеюсь что-то найдет себе применение и у читателей )

Мне кстати интересен вот этот момент

С другой стороны, сениор может решить 90% проектных задач, загружен он всегда на 110%, но на собственное развитие времени у него остается мало.
А также что в графике у синьйора 95% проектных задач, и только 5% на саморазвитие.

В таком случае любой человек (хоть и синьйор) просто скатится в рутину и перестанет развиваться. Ну и его обгонят 23-летние синьйоры через время.

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

Поэтому все-равно часть рабочего времени тратил и трачу на развитие. И себя, и каких-то новых штук в проекте. А компании (и я тоже) от этого только выигрывают :)

Более интересен ИМХО этот момент:

джун тратит до 60% своего времени на саморазвитие, засыпая вопросами более опытных сотрудников
Вот и вопрос: а что, синьор не развиваецца, отвечая на эти вопросы и обсуживая в режиме диалога 60% времени джуна? Тогда до какого процента поднимается его занятость — до 150% ? Или упомянутые «опытные сотрудники» — это чиста виртуальные кони в вакууме?
Поэтому все-равно часть рабочего времени тратил и трачу на развитие.
Еще раз — сие зависит от человека. Кто-то учится, кто-то других учит и при этом наконец сам понимает, кто-то забил...
Вот и вопрос: а что, синьор не развиваецца, отвечая на эти вопросы и обсуживая в режиме диалога 60% времени джуна?
Он сатанеет)))))))

Приветствую. Я честно говоря ожидал именно такой реакции от критиков ).
И конечно вы правы — все зависит от конкретного человека. Я не хочу претендовать на изобретателя этой теории, это просто статистика из моего опыта и из опыта моих коллег за последние 10 лет.
Человек — существо ленивое, и не многие из нас осознанно тратят достаточно своего личного времени на саморазвитие. Просто на работе Джун вынужден расти, а Сениор — не всегда. Таким образом иногода молодые меды обгоняют сеноиров, скатившихся в рутину, как бы прискорбно это не звучало.
А вообще, тема карьерного плато стоит отдельной статьи и дискуссии.

Забавно, что бюрократия компании подаётся как что-то нерушимое: «пересмотр тайтлов/зарплат производится только раз в Х полугодий, поэтому нам надо плясать от этих ограничений».

И половина статьи посвящена тому, как оттянуть повышение и не дать его вовремя. При этом краткосрочным решением может быть просто быть честным с программером и сказать, как эта бюрократия работает на самом деле. И почему программиста «невозможно» повысить прямо сейчас. Может, он поймёт и простит.А может тоже оказаться честным и сказать «ну тогда извините, за углом дают +500 уже сейчас».

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

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

«на самом деле нет» — великолепный ПМский ответ. Вроде и ответил, и ощущение будто ответил, а на самом деле ничего не сказал по существу :D

Вроде и ответил
я процитировал кусок из текста автора топика, который говорит против вашего ощущения «бюоркратия подается как нечто нерушимое».
великолепный ПМский ответ
лол. я не РМ. такой же технарь, как и вы.
процессы редко строят ради процессов
Их строят с разными целями (обычно ради бухгалтерии), но потом совсем не стремятся каждый случай рассматривать индивидуально, а ссылаются на процессы как причину отложить/отсрочить/не делать.

Да, «эскалировать вопрос раньше срока» тоже бывает, но как и всякое исключение, это будет требовать нервов и поиска путей заставить менеджера делать свою работу, а не прикрываться процессами.

Если вы обратите внимание, в конце статьи я как раз и советовал объяснить специалисту как работает бюррократия, как один из обязательных шагов.
Конечно, компания должна быть гибкой, и действительно при большом желании можно обойти общие процессы (как я и рекоммендовал в случаях А и В в зарплатном росте). Вот только избыток гибкости может негативно сказаться на всем бизнесе. Если каждое второе повышение будет спонтанным — компании будет весьма нелегко планировать свой рост.

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

Если человек настроен категорично вопрос все равно придется решать здесь и сейчас взвесив все за и против, иначе имхо лучше просто честно сказать «нет» и не морочить голову.

Чем более сениорным становится специалист, тем сильнее замедляется его профессиональный рост. Это происходит потому, что с ростом сениорности специалист все меньше времени тратит на свое развитие.

Тоесть причина не в том что наступает граница применения своих знаний на галере, а то что разработчик обленился? Рили?

если человека загрузить на 100%, при этом большинство задач будет уже из области компетенции — когда он будет развиваться? во сне?

Вот давайте не будем, если вы хотите развиваться, а вам этого не дают, то просто смените работу.

что именно «не будем»?

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

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

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

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

Изначальный посыл был на тему того что менеджер который утверждает что разработчики не растут, когда становятся скиловыми, из-за лени «слегка неправ». Хотя бы исходя из принципа Парето.

Вся эта ветка в принципе мимо темы.

та где там про лень-то увидели?

контекст этой строки

С ростом сениорности специалист все меньше времени тратит на свое развитие.

у кого что болит, называется. Автор объяснил, чтоу сениора времени на обучение не хватает из-за перегруженности по рабочим вопросам. А вы почему-то увидели только «лень», о которой ни слова сказано не было.

Мне жаль что вы не видите связи между нахождением в стойле где на тебя льют рутинные однообразные задачи и ленью.

а вы находитесь «в стойле где на тебя льют рутинные однообразные задачи»? Тогда понятно.

Ни слова о себе не сказал за этот тред. Но пусть будет так, хорошую фантазию стоит поощрять.

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

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

Поэтому смена проекта и/или конторы рулит

Можно искать разные объяснения этому факту, но из своего опыта могу сказать, что статистически — это так.
Со своей стороны, я не думаю, что специалист вдруг обленился. Определенная лень есть у всех нас, а вопрос всегда состоит в том сколько экстра усилий я должен вложить, и что я буду с этого иметь. Просто в то время как джун имеет возможность развиваться в рабочее время, сениору приходится, как говорится, работу работать. Кроме все прочего, джуну помогают расти сениоры (иногда насильно), а сениор в большей части предоставлен сам себе. Вот тут и становится описанный выше вопрос.

Плюс сіньор, як правило, рішає задачі по «трафарету» з досвіду, тому що так дешевше і надійніше, ніж досліджувати нові рішення. А використання досвіду ніяк не добавляє в рості.

Хорошая статья :)
И это правильно, что отделяется профессиональный рост от рост зп. Потому что более качественно работать только ради повышения зп на очередные 200-300$ в конце года вряд ли будешь. А вот более качественно работать ради повышения пользы, сложности задач (и конечно же шильдика senior) — это другое дело :)

А так есть два совета — для компаний надо просто уменьшать бюрократию при пересмотре зп :)
И делать ее возможным хоть раз в три месяца. В зависимости от роста и развития конкретного человека. Ведь с учетом нынешней динамики развития технологий и времени проектов — год это часто очень много.
Люди просто не дорабатывают до конца года и уходят через 10-11 месяцев на +300+500 в другую компанию.

А для ребят программистов самый простой совет:
Рост можно разделить на две части — технический (технологии, сложность задач и т.д) и soft skills (коммуникации, общение с заказчиком, менторство, лидерство)

Лично я больше всего рос в техническом плане в двух случаях:
1) Когда задумывался о смене работы — изучал новые технологии, активно контрибьютил в опен соурс, пилил pet projects :)
И это позволяло быстро расти — намного быстрее, чем если просто пилить код на проекте.
2) Когда после этого приходил на новый проект на новых технологиях, разбирался с этим всем + опять же опыт новых людей и того, как они пишут код :)

А в плане софт скиллс — где-то в середине работы на проекте, когда влился и освоился в технической части и берешь на себя больше ответственности по тому, как проект будет развиваться. Плюс начинаешь заниматься менторингом и т.д.

И когда поняли что на нынешнем проекте многое узнали и выросли — самое время делать pet projects, изучать новинки, делать доклады на конференциях и т.д...
И со временем переходить на новую работу.

Все равно с моей точки зрения намного больше реального опыта у человека, который поработал по году на трех разных проектах, чем три года на одном :)
Ну и плюс у него больше ЗП )))
Так как переходить можно и на +500+1000$ на новое место. А на текущем месте для миддла вряд ли добавят больше чем +300$ через год.

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

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

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

А по поводу гнаться за баблом... Ну оно ведь тоже важно — путешествия, техника и все такое :)
Да и чем больше тебе платят, тем больше от тебя ждут отдачи — приходиться соответствовать :) Что тоже полезно для профессионального роста.

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

перефразирую Новосельцева:
проходить Чаще могут.... но не проходят...

Підписатись на коментарі