Карьера специалиста глазами менеджера
Пора повышать или еще подождать? Как понять, вырос ли уже программист до сениора или еще нет? Если вырос — то как это должно отразиться на его зарплате? А если нет — как это ему коммуницировать? Рано или поздно каждый ПМ задается такими вопросами, но, к сожалению, не каждый может на них ответить.
Как вы уже поняли, в данной статье мы будем поднимать довольно тонкие и весьма противоречивые вопросы. По этой причине я попытался по максимуму абстрагироваться от какой-либо компании или проекта. Как говорится, все имена вымышлены, а все совпадения — случайны.
Проблематика
Итак, чтобы обсуждать так называемые «повышения», давайте прежде всего разберемся, что мы под этим подразумеваем. Я знаю по крайней мере две вещи, которые скрываются за этим словом:
1) повышение уровня сениорности;
2) повышение уровня зарплаты.
Менее опытные менеджеры могут спросить, зачем разделять эти два понятия. Дело в том, что в то время как менеджер имеет все полномочия пересматривать профессиональный уровень специалиста, он может иметь определенные ограничения в пересмотре его зарплаты. Объясняется это тем, что зачастую в компаниях существуют определенные политики, связанные с пересмотром зарплат. Например: «Зарплаты могут пересматриваться не чаще, чем раз в год» или «Все повышения должны быть одобрены высшим руководством», или «Бюджет на зарплаты не должен превышать Х» и т. д. Все эти политики накладывают определенные ограничения на решения ПМ-а о пересмотре зарплат.
Тут как раз и кроется большинство ошибок, которые касаются карьерных и зарплатных ожиданий проектной команды. Я выделил две наиболее распространенные.
Ошибка № 1 — придирки. Рассмотрим некую компанию X, в которой каждый год проходит оценка сотрудников и пересмотр их зарплат. Программист Петя уже фактически вырос до миддла, и у него с менеджером уже был разговор на эту тему. Но цикл оценки будет только через полгода, и менеджер искусственно оттягивает повышение Пети, чтобы попасть в этот цикл. Более того, чтобы аргументировать эту отсрочку, менеджер начинает придираться к Пете, объясняя, что он еще «ну не совсем миддл». В результате Петя может уйти, так и не дождавшись повышения, а менеджер рискует оставить о себе не самое приятное впечатление.
Ошибка № 2 — поспешность. Та же компания. Маша — трудолюбивый миддл-тестировщик. Она неплохо работает, но до сениора пока не дотягивает. Вот подходит долгожданный цикл оценки и менеджер решает: «Черт с ним, Маша с нами уже давно, повышу ее сейчас, чтобы потом не ждать еще год». В этом случае проект получает такого себе «недосениора», который может так и зависнуть на этом этапе, никогда по сути не став настоящим сениором.
Почему так происходит, и как правильно поступить ПМ-у в описанных ситуациях? Как я уже говорил выше, основная причина подобных проблем кроется в смешивании понятий зарплатного и профессионального роста.
Давайте сначала рассмотрим специфику профессионального и зарплатного роста по отдельности, а потом попробуем сформировать некий набор правил, которые позволят ПМ-у принимать правильные решения.
Профессиональный рост
Если построить график зависимости уровня сениорности специалиста от времени, то получится интересная картинка.
На этом графике можно увидеть, что чем более сениорным становится специалист, тем сильнее замедляется его профессиональный рост. Это происходит потому, что с ростом сениорности специалист все меньше времени тратит на свое развитие. На графике я привел приблизительное соотношение между «полезным временем» для проекта и временем, которое тратится на саморазвитие для каждого из профессиональных уровней.
Например, джун тратит до 60% своего времени на саморазвитие, засыпая вопросами более опытных сотрудников, читая профессиональную литературу и работая над своими ошибками. С другой стороны, сениор может решить 90% проектных задач, загружен он всегда на 110%, но на собственное развитие времени у него остается мало. Давайте запомним эти примеры, так как эта концепция будет ключевой при дальнейшем рассмотрении уровня зарплат команды.
Итак, что же нам дает приведенный выше график? На самом деле, гораздо больше, чем может показаться на первый взгляд, но для того, чтобы его использовать правильно, надо разобраться в основных понятиях, которые он описывает.
А для этого вам надо ответить на такие важные вопросы:
— Что означает каждый уровень сениорности и каковы критерии их достижения?
— Как и когда проводить оценку специалистов?
— И наконец, кто может дать им наиболее адекватную оценку?
Давайте отвечать по порядку.
Действительно, для начала нам необходимы критерии сениорности, понятные для специалистов и отражающие действительные потребности проекта. Они не должны представлять собой чек-лист из
Пример. Сениор должен:
1) уметь менторить джунов;
2) быть способным самостоятельно разобраться с 90% задач и предложить их решение;
3) уметь решать вопросы с лидом со стороны заказчика и т.д.
Как проводить оценку? Это очень зависит от команды и ролей, которые в ней присутствуют. Хорошо, когда такие оценки проводятся техлидами как людьми, наиболее приближенными к работе каждого сотрудника. Оценка должна обсуждаться с оцениваемым специалистом и проводиться на регулярной основе.
О, нет... Еще одна бюрократия? Зачем? Да, это еще одна бюрократия, но в ваших силах сделать ее не нудным опросником, а дискуссией, интересной и полезной для вашей команды. По своему опыту могу сказать, что из всей проектной бюрократии эта была самой востребованной всеми членами команды.
А все потому, что если человек знает, какой у него текущий профессиональный уровень, знает что ему надо делать, чтобы достичь следующего, и знает, что достигнув его, он получит свое «повышение» — он будет расти. А если растет он — растет и проект. Причем, заметьте, пока мы и словом не обмолвились о зарплате. В этой схеме менеджер имеет в своем распоряжении все необходимые полномочия.
И все было бы просто замечательно, если бы все и всегда были готовы работать за одни и те же деньги. К сожалению или к счастью, это не так, а следовательно пора поговорить и о деньгах.
Зарплатный рост
Когда мы говорим о зарплатном росте, мы на самом деле подразумеваем всего два вопроса: «Когда?» и «На сколько?»
На эти вопросы мы ответим немного позже, а для начала, давайте вернемся к нашему любимому графику профессионального роста. Итак, мы определяли уровень сениорности исходя из той пользы, которую специалист приносит проекту. Соответственно «прирост пользы» можно конвертировать в «прирост к зарплате». Другими словами, если человек стал приносить проекту в 2 раза больше пользы, проект должен по сути удвоить его компенсацию. Это наиболее справедливая и прозрачная зарплатная политика.
Так когда и на сколько? Давайте, для наглядности, нарисуем наш график и разобьем его на равные интервалы, скажем, ежегодные, предполагая, что зарплата пересматривается раз в год
Сделав такой рисунок, ответить на ключевые вопросы становится несложно. Ответ я бы сформулировал так: повышать зарплату надо всегда, когда это представляется возможным, и когда сумма повышения выглядит привлекательно.
Например, в случаях C, D, E повышения по графику выглядят вполне обоснованно. В случаях F и G лучше подождать следующего цикла, чтобы сумма прибавки выглядела более весомо. А в случаях A и В стоит эскалировать вопрос о повышении даже раньше срока.
Осталась одна неясность: как же все-таки измерить пользу для проекта в долларах, а не в процентах? В этом нам помогут вилки зарплат. В одних компания они формальные, в других — нет. В одних — открытые, в других — секретные. Но во всех они есть.
Вилки зарплат можно отобразить на рисунке следующим образом:
Итак, вилки зарплат представляют из себя своего рода маппинг профессионального уровня на уровень зарплат. Конечно, сами по себе они не дадут ответа на вопрос «На какую же сумму мне повысить зарплату Маше?», но если эти вилки наложить на график сениорности, то может получиться вполне рабочее руководство по работе с зарплатами для вашей команды. На рисунке это будет выглядеть примерно так:
Изучили? Теперь внимание: используя такой подход, вы можете легко отделить профессиональный и зарплатный рост, так как на этом графике повышение зарплаты происходит при пересечении вертикальной линии (период пересмотра зарплаты), а повышение сениорности — при пересечении горизонтальной (соответствие критерию сениорности).
На самом деле подход к повышениям зарплаты изменился следующим образом:
— Раньше: Сениорность => Компенсация
— Теперь: A) Польза => Сениорность, B) Польза => Компенсация
Мы ввели понятие «пользы для проекта». Это понятие является ключевым как для определения уровня сениорности, так и для определения величины зарплаты. Таким образом, мы избавились от «порочной» связи «сениорность—компенсация», которая и была причиной описанных выше проблем.
Как-то все это очень сложно... Что мне это даст?
Ну, во-первых, все не так уж и сложно. Тут было много математики, графиков и различных умозаключений, но это была лишь теория. На практике же это применяется довольно легко. Попробуем обернуть всю изложенную информацию в практические советы.
1. Критерии. Прежде всего подумайте, какие критерии сениорности соответствуют вашему проекту/команде/компании. Формализируйте их и объясните своим ребятам.
2. Оценка. Попросите техлидов помочь вам оценить свою команду, используя описанные выше критерии.
3. Прозрачность. Встретьтесь со своими ребятами на 1×1-митингах. Нарисуйте им описанный выше график и расскажите, как он работает и почему. Тут нет никакой секретной информации, кроме разве что вилок зарплат, которые можно обозначить просто значками долларов. Обсудите с ними, где они сейчас находятся и что им нужно сделать для достижения следующего уровня.
4. Регулярные 1×1-митинги. Назначьте регулярные 1×1-митинги со всеми членами команды, обозначив те из них, на которых будет проводится пересмотр уровня сениорности.
Маша и Петя (ответы). Давайте теперь еще раз рассмотрим те две неприятных ситуации, которые я приводил в начале статьи. Если представить их на графике, то можно увидеть, что Петя, по сути, находился в секторе B и вполне мог получить уровень миддла, ожидая цикла пересмотра зарплаты. Маша же, очевидно, была в секторе D, и в принципе могла получить свое повышение зарплаты, оставаясь миддлом и продолжая дальше расти на сениора. Видите, все совсем не сложно.
Итог
Как мы уже поняли, описанный выше подход успешно решает проблемы Маши и Пети, но на самом деле, он приносит и много других дивидендов.
Прежде всего, если следовать указанным практическим советам, специалисты будут фокусироваться на пользе, которую они могут принести проекту, и на своем профессиональном росте как мериле этой пользы. Но самое главное — они оценят справедливое отношение к их карьере и к работе в целом. А чем больше будет справедливости в вашей работе, тем меньше будет в ней стресса. Стресса для вас, для вашей команды, и, как следствие, для вашего заказчика. К тому же, это будет позитивно сказываться на вашей репутации как менеджера.
Удачи вам в вашей работе, поменьше стресса и неприятных ситуаций!
