От разработчика до руководителя. Менеджмент для IT-специалистов - читать онлайн книгу. Автор: Камиль Фурнье cтр.№ 74

Там, где у вас меньше должностных уровней, используйте более широкие вилки зарплат. Меньшее количество должностных уровней и широкие вилки зарплат четче разграничивают уровень профессиональной подготовки, необходимой для каждого уровня. В таком случае становится легче определить, кто работает на каком уровне. При значительном разбросе должностей необходимо иметь более широкие диапазоны заработной платы, в идеале перекрывающие друг друга. Так, скажем, если инженер-программист получает зарплату в диапазоне $50 000–100 000, то «вилка» для ведущего инженера-программиста может составлять $80 000–150 000. Это означает, что сильный инженер-программист может зарабатывать больше ведущего инженера. Такой люфт нужен, чтобы удержать талантливых инженеров, хорошо работающих на достигнутом промежуточном должностном уровне, но еще не готовых взять на себя дополнительную ответственность, связанную с переходом на следующую должность. Этот же люфт хорошо работает при найме новых работников, готовых прийти в вашу компанию на более низкие должности в надежде на скорое продвижение по службе.

Внимательно относитесь к «горячим точкам» роста сотрудников. Распространено наличие в компаниях определенных должностных уровней, называемых «вверх или в сторону». На начальных должностных позициях долгое отсутствие карьерного роста может означать, что сотруднику пока не удалось достигнуть зрелости и независимости в работе, нужных, чтобы остаться в компании. В должностном расписании это открытые или скрытые точки разрыва. А каков в вашей организации самый низкий должностной уровень, где люди могут находиться всегда, не продвигаясь по карьерной лестнице, но вместе с тем и не работая плохо? Этот уровень в компании — критическая точка. Во многих случаях он располагается где-то вокруг должностной позиции ведущего инженера-программиста. Тот, кто находится в ней, зачастую надежный член команды, но по собственному выбору может оставаться на ней неопределенно долго. Следует ясно видеть критические точки в вашей организации. Вы даже можете использовать их, чтобы ясно представлять себе, с какого именно должностного уровня карьерный рост в вашей компании становится делом непростым. Лучше, если большинство членов команды будут находиться в этой точке, а меньшинство — выше или ниже.

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

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

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

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

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

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