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

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

Я рассказываю эту историю по очень важной причине: там, где моему приятелю сопутствовал успех, я потерпела неудачу, хотя следовала тому же шаблону. Этот урок очень важен для каждого, кто хочет создать хорошую командную культуру. То, что хорошо для одной компании (создающей определенный продукт и работающей в определенной отрасли), не всегда подойдет другой, даже если они имеют много общего. Мы оба были руководителями в стартапах, когда создали свои должностные расписания, и компании наши были очень схожи по размерам. Но чтобы быть успешными, нашим организациям нужны были разные вещи. Моя первая попытка создать должностную лестницу провалилась, поскольку в моей команде необходимо было ее тщательно детализировать. Цель упрощенной схемы состояла в том, чтобы люди не зацикливались на своих должностных уровнях и возможностях продвижения, а вышло так, что недостаток подробностей подтолкнул к тому, чтобы они зациклились еще больше. Инженеры-программисты настаивали, что заслуживают более высоких должностных уровней потому, что детали были расплывчаты. Это породило массу проблем.

Создание должностного расписания

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

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

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

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

Используйте описания и в подробной, и в обобщенной форме. Я разбила расписание на два документа. Первый представлял собой довольно краткую таблицу, позволявшую мне одним взглядом окидывать должностные обязанности разных уровней и видеть, как они возрастают по мере повышения уровня должности работника. Это очень помогало, потому что по мере написания документа я могла видеть переход от одного уровня к другому и то, как расширяется объем работы сотрудника, набор необходимых навыков и умений, а также возрастают обязанности. Второй документ представлял собой расширенную версию первого. Его написание тоже помогало мне, потому что я могла изложить полное представление об исполнителях той или иной должности на том или ином уровне. Вместо того чтобы только зримо очерчивать набор навыков и качеств, необходимых работникам, полная версия должностного расписания, словно хорошее заключение по работе, дает описание работы сотрудника на том или ином уровне. Вы — и ваши сотрудники — можете увидеть, как профессиональные навыки взаимодействуют при росте адекватного данной позиции работника. Сколько уровней должно быть в вашем должностном расписании? Для ответа на этот вопрос вы должны ответить на два следующих: 1) как вы оплачиваете труд работников? 2) как вы оцениваете их особые достижения?

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

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

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