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

Грейды: оцифровка программистов. Часть первая

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

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

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

Проблемы

Классификация в рамках организаций и государств существует столько же, сколько и сами эти образования, начиная от Шумера, Древнего Египта, Индии, Китая, Греции, цеховых мастеров средневековья и масонских лож. Практически везде принципы были одинаковы и существовали ранги, одинаковые как для гражданских чинов, так и для воинских и флотских. К примеру, гражданский чин «статский советник» соответствовал придворному «камер-юнкер», воинскому «полковник» и флотскому «капитан I-го ранга» и все эти чины имели V-й класс чина.

На этих же принципах строилась классификация должностей предприятий индустриальной эпохи, со всеми вытекающими проблемами, как то:

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

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

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

Решения

Примерно с середины прошлого века начали предприниматься попытки решить проблемы классификации должностей. Наиболее известной из них является «метод направляющих таблиц Хея». В основу метода была положена оценка должностей по нескольким параметрам, сгруппированным в 3 категории — знания и навыки (know how), решение проблем (problem solving) и ответственность (accountability).

Небольшое число факторов позволило обеспечить универсальность методики и охватить практически любую деятельность и отрасль в США. Однако сложность, непрозрачность и дороговизна методики привели к тому, что в 90-годы Министерством труда США была поддержана открытая система O*NET с интернет-доступом как к методикам, так и ко всем агрегациям данных.

Так или иначе, но все существующие системы принимают во внимание:

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

Также некоторые учитывают и необходимые качества личности.

Следует отметит, что анализ классификаторов таких систем как O*NET (поддерживается Министерством труда США), Российского стандарта для ИТ-специальностей (поддерживается Министерством образования РФ), а также принципов методик «Хей Груп», «Уотсон Уайетт» показывает, что большая часть из них содержат общие принципы классификации (отличающиеся друг от друга количеством и деталями), но не предоставляют в основной массе рекомендации по оценкам достоверности методик измеримости параметров должностей.

Выводы

Закрытость методик классификации (за исключением O*NET), неочевидность принципов ранжирования должностей в рамках этих классификаций и несовпадение классификаторов, а также слабая проработка требований к должностям, востребованным ИТ-отраслью (за исключением российского стандарта), не позволяют назвать их абсолютной панацеей от указанных выше проблем.

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

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

Весь цикл статей.

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

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

Схожі статті

  • Огляд IT-ринку праці: ЛуцькОгляд IT-ринку праці: Луцьк

    Dmytro Skorokhod

    Сьома стаття циклу «Огляд ІТ-ринку праці», в якій ви дизнаєтесь про ІТ-галузь у Луцьку — огляд компаній, тематичні події, профільні внз та перспективи регіону. 29

  • Огляд ІТ-ринку праці: Івано-ФранківськОгляд ІТ-ринку праці: Івано-Франківськ

    Редакція DOU

    Представляємо восьму статтю з циклу «Огляд ІТ-ринку праці», в якій ми розповідаємо про ІТ-індустрію у місті — оглядаємо компанії, тематичні події, профільні виші і галузеві перспективи регіону. 5

  • Огляд IT-ринку праці: ЛьвівОгляд IT-ринку праці: Львів

    Валентина Шимкович

    В місті працює ІТ кластер, є кілька технічних вишів з інноваційними напрямками підготовки. Оборот ІТ-галузі Львова складає 14,4% ВРП міста Львова. 23




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

Работал в одной продуктовой компании, где-то 700 человек. Компания отличалась тем, что никаких тайтлов после менеджера проекта не было, т.е. никаких junior sinior team lead, никаких высших и старших, — ничего. Все просто инженеры, и всех это устраивало.

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

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

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

Дійові особи:

Гаврюша Обізянов, інженер.
Степан Cрака, главний інженер.

Шльома Гомельский, науковець.

Есть только один ранг: ЗП ;-)

Работаю в конторе много лет. Когда-то «лычки» были в основном просто мотивационными фишками. Типа 1 год опыта — салага, 2 года — новичок, 3 — девелопер, 4 — мидл, 5 — синьор, 6 — гуру и т.д. Звания давали за выслугу лет или как бонус отличившимся. Зарплата от звания зависела слабо: важнее было какой проект, какие технологии, уникальные знания и т.д. Мидл просидев 2 года на важном, тяжелом, сапортном проекте с чокнутым клиентом и спагетти-кодом мог получать больше синьора на чистеньком новом стартапе. Так же клиенты платили за проект и рейты не зависели от «званий» команды.
Хозяева сменились — контора стала бодишопом. Клиентов заставили платить за «звания» — многие выгнали синьоров из команд. Ввели официальные грейды с целью «уравнять» зарплаты. В итоге порезали «дорогих» мидлов и они разбежались. Теперь эти грейды используют что бы не поднимать зарплату старым сотрудникам. Типа еще не дорос до нового уровня — поработай еще годик. Новых с рынка, естественно, набирают на зарплату выше средней. Могут даже звание «накинуть» что бы переманить. Люди не слепые и это дело понимают: в итоге уходят к конкурентам на +500 баксов и новое «звание».

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

IMHO гоните в шею этих оптимизаторов. Это насколько нужно наплевательски относиться к людям [затратам на людей, прибыли компании], чтобы отдать системе правил сортировать людей? С тем же успехом можете ввести естественный отбор — и то справедливости будет больше.

Люди — самое ценное что есть в компании. И самый рискованный актив. Один демотивированный человек может похоронить компанию, а один мотивированный — поднять прибыль на проценты и десятки процентов.

Это может не понимать линейный персонал. Но если назвался руководителем — работать с людьми обязан. Иначе дурак тот, кто нанял бездельника на эту должность.

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

PS. Я лично считаю современную систему ранжирования несовершенной. Все говорят о командной работе, об эффективном взаимодействии, даже о хорошем соц.пакете. Но всё это хорошо в статике, в застывшей картинке. А стоит попробовать двинуть с места — и оказывается что ваша система состоит из коробки передач от Белаза, дворников от Икаруса, кузова от Мазератти, колёс от трактора, водителя Формулы-1, в бензопаке — ракетное топливо, а заводить надо с толкача.

152 коментарі

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

Судя по лучшим комментариям, никто так особо и не понял в чем соль грейдов. А между тем в SAP наверное лучшая в Украине грейдинговая система, а еще ДТЭК отвалил кучу бабок за попытки внедрить у себя.

По сути: нужна совершенно другая модель. Фундамент — основанная на ISO9001 модель процесса и разделения отвественности. Ценность (но не цену) каждого может определить именно дерево процесса. А никак не бюрократическая попытка предоставить очередное «очевидное» показательное решение, созданное чтобы объяснить (как религия) существующее положение вещей.

Где-то уже такое есть? В смысле «оцифровка» программистов (и не только) по системе качества?

IMHO гоните в шею этих оптимизаторов. Это насколько нужно наплевательски относиться к людям [затратам на людей, прибыли компании], чтобы отдать системе правил сортировать людей? С тем же успехом можете ввести естественный отбор — и то справедливости будет больше.

Люди — самое ценное что есть в компании. И самый рискованный актив. Один демотивированный человек может похоронить компанию, а один мотивированный — поднять прибыль на проценты и десятки процентов.

Это может не понимать линейный персонал. Но если назвался руководителем — работать с людьми обязан. Иначе дурак тот, кто нанял бездельника на эту должность.

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

PS. Я лично считаю современную систему ранжирования несовершенной. Все говорят о командной работе, об эффективном взаимодействии, даже о хорошем соц.пакете. Но всё это хорошо в статике, в застывшей картинке. А стоит попробовать двинуть с места — и оказывается что ваша система состоит из коробки передач от Белаза, дворников от Икаруса, кузова от Мазератти, колёс от трактора, водителя Формулы-1, в бензопаке — ракетное топливо, а заводить надо с толкача.

Я лично считаю современную систему ранжирования несовершенной.

Какую именно?

Это насколько нужно наплевательски относиться к людям [затратам на людей, прибыли компании], чтобы отдать системе правил сортировать людей?

Также нужно выгнать бухгалтеров и кадровиков, использующих программы учета, а еще продажников, пользующихся CRM. Это ж надо так наплевательски относиться к клиентам и деньгам, чтоб использовать автоматизацию. Да и программистов всех выгнать...всех-всех, ибо зачем они тогда нужны, если все надо ручками

Не совсем это имел в виду. Не всё ручками, ой не всё. Но с человечесикм фактором нужен крайне грамотный ПОДХОД к моделированию ситуации. К самой модели у меня претензии.

А без цифры здесь сложно. И плохо получится. Причина банальна — память ограничена. Объясню на примере почему нельзя без цифры: Вот, была Тимошенко при власти — что о ней говорили? А сейчас что? Сейчас Янукович при власти — что говорят? Спросите любого — каково общее мнение? А теперь ключевой вопрос — по супер-справедливой системе ранжирования, именуемой выборами (без цифрового моделирования), КОГО ВЫБЕРУТ на следующие?

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

А с цифрой — заметьте ЧТО моделируют. Не человека, а группу. Средний образ. Тот самый «нулевой потенциал»! А нужно моделировать процесс турда. И при хорошем моделировании, на зарплатах можно существенно сэкономить — будет видно: кто полезен, кому надо работы накинуть, а кого гнать поганой метлой к конкурентам.

Я бы с удовольствием сам подержал в руках данный вопрос. Не в курсе, в Днепре нигде подобных разроботок не ведётся? Может внутри компаний под собственные задачи? По прибыльности проект сравним с ядерными исследованиями — люди «вечным двигателем» являются!

// В Привате когда работал, идея возникала (и даже есть концепт, и даже было официальное внедрение), но там как раз с набором критической массы проблемы: объяснить людям, что на работе бывает интересно — сложно. Что это ещё и рискованно — нереально. А что интерес к работе жизненно необходим самим людям — те кто это понял чувствуют себя одиночками. Я даже на Хакатоне поднять концепт не могу — люди банально не поверят, что вся работа может быть организована по принципу (и продуктивности) Хакатона.

Вот подумал: Не кремний делает долину Кремниевой. А что?

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

Советую Вам подумать о создании своей «компании мечты», основанной на тех принципах, которые Вы так категорично выдвигаете. Возможно она стала бы раем для девелоперов, где к каждому из них относились бы как к «пану», а не холопу на продажу. А еще в ней писали бы только качественный и полезный софт.
Только, боюсь, конкуренты — бодишопы легко задавят такой рай (как уже неоднократно делали). Нас тут сидят сотни демотивированных в душном опенспейсе, а компания не только не «хоронится», но и скупает еще больше девелоперов. Посмотрите сюда — бодишопы побеждают:
dou.ua/...-february-2012

P.S. И, кстати, систему правил грейдирования у нас то же не первый год внедряют: что бы сотрудники не спрашивали почему им не повышают зарплату — во всем виновата «СИСТЕМА».

Деньги нужны и время. Либо просто время, но десяток лет.
И потом — я так подумал, может в этот самый момент есть уже такая компания, надо просто в неё войти?

Очень много компаний так начинались. Если не сказать все. Но задаче не в начинании, а в регулярной и целевой работе. В компании нет ДНК, которое бы гарантировало рост по заданному алгоритму и наследование. Как раз наоборот — есть человеческие инстинкты, которые говорят о невозможности компаний вообще. А ещё рыночные механизмы, которые на свой лад твердят: не надо вкладывать, надо продавать!

И не всё так плохо! И не настолько «демотивированных» (смотрим голосование по компаниям). И мы не в раю, все знаем что зарплату платят не из благих побуждений — для работодателя сэкономленные деньги даже ЛУЧШЕ заработанных.

У меня хороший стаж в аду. В разных вариациях сего явления. Могу со всей отвественностью заявить — рая нет, а вот ад можно модифицировать до вполне приемлемого уровня. Я и сейчас хочу в ад зайти :) Создавать собственный не рискую — до войны с государственной машиной я ещё не дорос [пробовал].
Главное — знать: в аду и в раю сидят те же люди. Просто одни думают что в аду жарят грешников и это их судьба, другие — что есть избыток нерастраченной энергии, и идут жарить грешников уверовавших в судьбу :)

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

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

Руководителя любого уровня, дейтсвительно считающего что виновата система — понизить до раба.

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

// Мы все умрём. ©Доктор Хауз

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

хороший пост и годная тема.
попробую её утрировать (для разнообразия).
вот допустим конторе нужен спец:
восьмирукий Шива- швец, жнец и на дуде игрец.
0) уровень спеца : junior, middle, senior
= получаем такую скромную матрицу 3 Х 3 , это только начало.
дальше — больше
1)выбираем на собеседовании Шиву нужной конфигурации
(junior швец, middle жнец , senior на_дуде_игрец )
— договариваемся, что он прокачает скиллзы швеца,
и дальше...
2) он хочет развиваться \ не хочет развиваться.
3) он «на дуде игрец» хороший но ленивый.
4) он увлечённый, талантливый жнец, но заказов на жатву нет.

5) он хороший пацан \ он говнистый интриган и карьерист .

и так далее.
каким калькулятором это всё считать?

:-))

Даже если кому-то вообще нужна справедливость, в чём я лично сильно сомневаюсь, то
подсчитать \ оценить всё
математически — сложно из-за субъективности,

субъективно — нехорошо из-за неточности.

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

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

на примере более-менее прогрессивных систем грейдирования
... создать виджет для мобайл девайса — неплохая тема.

неплохая, согласен. Если сама метода будет хороша...

В мобайл девайсе, в частности, в Ведроиде, есть сенсор магнитного поля :)

Не пойдет, нужен, как минимум, томограф

Чем в качестве оценки не подходят сертификации? Есть авторитетные сертификации почти по всему (технологиям, английскому, менеджмент, скраму). Это и есть та универсальная «плюс-минус лапоть» оценка.

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

«Вы, профессор, воля ваша, что-то нескладное придумали! Оно, может, и умно, но больно непонятно. Над вами потешаться будут.» («Мастер и Маргарита»).

Ваша правда, потому в народ и пошел :) Только не я его придумал, но чую — есть что-то

2) он хочет развиваться \ не хочет развиваться.
3) он «на дуде игрец» хороший но ленивый.
4) он увлечённый, талантливый жнец, но заказов на жатву нет.

5) он хороший пацан \ он говнистый интриган и карьерист .

Вот тут хорошо подсказали, ни одна сертификация не даст таких оценок

В статье, кстати, перечислено 8 проблем — если их решение не полезно, не принесет прибыль и т.д., то хотелось бы знать аргументы «почему»

Вот это уже ближе к теме статьи! Давайте обсудим именно эти 8 проблем и как система оценки может их решить.

— несогласованность подходов по оплате для разных подразделений и филиалов;

Происходит из различия условий (стоимости жизни, удобства работы и т.д.) в разных местах. Грейды тут никак не помогут — единственный выход: создание «силиконовой долины» с одинаковыми условиями жизни и работы.

— непрозрачность системы классификации, бесконтрольность и неуправляемость;

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

С этим надо бороться, но возникает вопрос: «а судьи кто»? Даже если будет единая тарифная сетка то «в уставе порядки писаны, а времян и случаев нет». Если человек думает что ему недоплачивают — он все равно будет недоволен.

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

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

— уравниловка в назначении премий и прочих дополнительных стимулов;

И при чем грейды к премиям? Синьору надо всегда давать больше премий и печенек, чем джуну? Премия зависит только от реального вклада в проект — иначе какой в ней смысл?

— перекосы в оплате: для вновь вводимых должностей уровень оплаты обычно выше, чем для давно существующих;

— несбалансированность ставок (могут быть как ниже, так и выше) относительно рыночной ситуации;

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

— формальность классификации, не влияющая на реальные оклады;

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

Я пообещал дать развернутый ответ в следующей части статьи, но кратко

— несогласованность подходов по оплате для разных подразделений и филиалов;

Происходит из различия условий (стоимости жизни, удобства работы и т.д.) в разных местах. Грейды тут никак не помогут — единственный выход: создание «силиконовой долины» с одинаковыми условиями жизни и работы.

Не вопрос, что эти различия есть и будут, но вообще-то неплохо иметь прозрачные критерии — почему. К примеру, на банках со сгущенным молоком в СССР были указаны пояса и различная стоимость.

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

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

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

— несбалансированность ставок (могут быть как ниже, так и выше) относительно рыночной ситуации;

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

То есть если вы переплачиваете за нефть в 1,5 раза или рассчитываете купить в 1,5 раза дешевле, чем котировки — это нормально?

— формальность классификации, не влияющая на реальные оклады;

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

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

— уравниловка в назначении премий и прочих дополнительных стимулов;

И при чем грейды к премиям? Синьору надо всегда давать больше премий и печенек, чем джуну? Премия зависит только от реального вклада в проект — иначе какой в ней смысл?

Помимо премий за проект часто существуют и другие виды

Для роздумів:
Стандартний карєрний шлях тих хто попадає в Гугл, дані по ЛінкедІн:

Software Engineer at ...->Senior Engineer at...-> Super Puper Engineer at... -> Software Engineer at Google

Есть вопрос! В нашей компании есть оценка деятельности, есть грейды, но всё это строго засекречено. Если рассказать публике о своём грейде и оценке — можно получить «строгий выговор». У всех так, как у нас?

Нет! Подумай сам: узнать свою рыночную стоимость ты можешь (сходить на собеседование), а узнать свою стоимость внутри компании запрещается с угрозой?

Свою стоимость знаешь: она составляет 14 попугаев, а производительность у тебя 3 из 5 (всегда округляется). А вот посмотреть на показатели других никак нельзя под страхом расстрела.

посмотреть цену и показатели других нельза — это правильно. просто с точки зрения психологии (хоть сию науку многие пользователи ДОУ не любят)

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

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

Нет, ну у всех. Какой смысл в такой «системе»?

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

Не знаю как «у всех», но у многих. «Вилки» часто закрытая информация, то есть менеджер вилку сотрудника может видеть, а сам сотрудник — нет.

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

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

Во многих комментариях путаются грейды и salary ranges (те самые вилки), хотя это совсем не одно и то же.

На самом деле salary ranges это вещь, которая ИМХО должна быть у любой более ли менее крупной компании (с мелкими проще). Вопрос в том как их использовать.

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

Основное, что включает range это:
— Job Role
— Location
— Salary Min
— Salary Max

— Salary Midpoint (медиана)

А дальше возникает Compa Ratio — соотношение зарплаты конкретного работника к медиане, средней по рынку. Сама по себе сумма ни о чем не говорит, а вот ratio говорит о многом.

Если чей-то ratio 2, то задача это видеть и понимать, почему именно так, а не иначе. Возможно в случае с этим сотрудником он действительно должен получать в 2 раза больше среднего, но тогда это должно соотноситься с остальными показателями (эффективность, роль в проекте, опыт и т.д.).

Понятно, что если ratio всех сотрудников «зашкаливают», то это либо мы что-то делаем не так, либо наши ranges — херня.

Если относиться к ranges не как к ограничителю, а как к ориентиру, то многое изменится. Хотя, не спорю — соблазн велик :)))

Во многих комментариях путаются грейды и salary ranges (те самые вилки), хотя это совсем не одно и то же.

Не одно и то же, но де-факто salary ranges во многих компаниях завязаны именно на грейды. Да и все до единой из 8ми проблем, озвученных автором статьи (и который якобы система единых грейдов должна помочь решить), связаны исключительно с размерами тех или иных материальный компенсаций.

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

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

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

Главный вопрос даже не в том ставим ли мы вилку на грейд или вяжем ranges на роли, а в том как мы с ними работаем, например:
1. НЕТ!!! Вилка это жесткое правило и никто и никогда у нас из нее не должен вылазить
2. Вилка это ориентир, и если кто-то за нее вылазит, то мы должны четко понимать, почему это так

Один из методов анализа в HR системах заключается в сравнение «позиции» сотрудника в своей «вилке» и показателей эффективности и компетентности. Но это уже отдельная тема :)

Один из методов анализа в HR системах заключается в сравнение «позиции» сотрудника в своей «вилке» и показателей эффективности и компетентности. Но это уже отдельная тема :)

Лично я не очень понимаю почему оценивать компетентность эффективность и присваивать грейд должен HR специалист а не непосредственный начальник и коллеги? Опять же: если начальник не управляет зарплатой и бонусами подчиненных то какой же он начальник?

Так оценивает эффективность и компетенции как раз таки руководитель, у которого есть доступ в HR систему.

Я бы сказал по другому — что это за HR система, к которой нет доступа у непосредственных руководителей :)

Именно salary ranges (те самые вилки) — и есть зло. Они появляются потому что в больших конторах зарплату человеку утверждает HR менеджер, который этого человека может и не видел вовсе. Бодишопы нанимают людей пачками: некогда разбираться чего каждый стоит. Вводим 3 — 5 грейдов, лепим ярлыки и продаем.
Опрос показал что главная жалоба не в том что сотрудникам недоплачивают — а как раз в том, что им непонятно как их оценивают (и оценивают ли или просто лепят ярлыки).

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

Да не являются salary ranges сами по себе никаким злом, это просто информация. Зло — это то, что люди делают ими прикрываясь.
Топор — не зло, зло — это когда Раскольников им бабушку стукнул.

Ни одна из проблем, которые вы указали, а именно:

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

не связаны напрямую с рейнджами, а с процессами в компании, вернее их отсутствием.

а с процессами в компании, вернее их отсутствием.

Не соглашусь. Процесс вполне себе может присутствовать, но организован от может быть именно так как описано выше.

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

Иногда читая статью о какой-то фирме разработчика ПО иногда диву даюсь зачем там такая Армия менеджеров? чем они там занимаються? Сам работаю на фирме где один менеджер на всех и как-то хватает, и контор кучу знаю, все как-то работают и отлично себя чувствуют, а главное работа делаеться и заказы продолжают идти

...не предоставляют в основной массе рекомендации по оценкам достоверности методик измеримости параметров должностей...

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

В таком случае, критериев должно быть несколько:
1. Удельный вес проекта в получении компанией прибыли и в достижении бизнес-целей компании (поможет стратегическая карта)
2. Для менеджеров проекта (имею в виду все виды ответственных за поиск и привлечение клиентов, постановку ТЗ, контроль сроков и взаимодействий, презентацию и защиту результата, проч.): уровень ответственности принимаемых решений (поможет тот же Уотсон-Уайетт: зачем делаем, что делаем, как делаем)

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

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

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

ИМХО

Удельный вес и значимость проектов — это хорошо, это прогрессивно

Удельный вес и значимость проектов — это хорошо
Да нифига это не хорошо!
Сотрудник не виноват, что он работает на менее прибыльном проекте нежели его коллега. В результате к вам придет толпа и будет просить/требовать чтобы их перевели на самый прибыльный и «значимый» проект...

Я же не сказал — прибыльность. Если будет учтена сложность проекта — чем это плохо?

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

А во-вторых, это проблему не решает. Придет к вам та же толпа: Мы хотим больше, переведите нас на самый «сложный» проект...

Не согласен. Как вы можете продать проект заказчику, не оценив сложность?
Понятно, что вопрос субъективный ( dou.ua/...​evolyuciya-odnoj-metriki ). Впрочем, и прибыльность не всегда оценивается объективно (понятия упущенной прибыли, гудвилла и т.д.).

Не согласен.

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

Имхо, утопия...

С такими подходами мы бы до сих пор сидели в пещерах, ссылаясь на теорему Геделя

Как я люблю «красивые» философско-пространные ответы :)

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

Еще раз повторю — проблема в том, что сотрудники будут «проситься» на «выгодные» проекты и избегать «невыгодных».

Несколько лет назад я лично пробывал ввести похожую практику. Первый же вопрос от сотрудников: А как я могу выбирать проект?

Навскидку: ответ сотруднику: «Ты мастер или гроссмастер (по принятой системе грейдирования)», ну и дальше по принципу отбора на супертурниры. Вот и один из мотиваторов

И что? На одном проекте («выгодном») будут работать все мастера, а на другом все недомастера?

Это вопросы администрирования, а не грейдирования

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

З.Ы. Вроде отвечал на этот пост. Мой ответ грохнули что ли?

И если сотрудники будут думать о том, как бы им попасть на «хлебный» проект

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

Работал в одной продуктовой компании, где-то 700 человек. Компания отличалась тем, что никаких тайтлов после менеджера проекта не было, т.е. никаких junior sinior team lead, никаких высших и старших, — ничего. Все просто инженеры, и всех это устраивало.

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

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

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

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

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

Такие звания могут отображать авторитет инженера — но для работодателя пользы в них мало.

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

Консультанты и сотрудники — «две большие разницы». Есть красные дипломы, научные звания, сертификации и т.д. Да, это добавляет балов на собеседовании. Но при поиске сотрудников решающим фактором не является (может для консультантов и по-другому).

Если грейды будут обще-украинскими — чем они будут лучше, например, от той же классификации и сертификаций Microsoft? www.microsoft.com/...ew-by-name.aspx Что бы получить «крутое» звание Microsoft Certified Architect нужно пройти серьезнейшую оценку. И это будет «общемировое» звание, а не только Украинский грейд.

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

А может он и не нужен — хотя когда я вижу зарплатные опросы на ДОУ, у меня всякий раз возникает ощущение его нужности.

Вначале они придумывают тайтлы, теперь еще грейды

Грейды они конечно не придумывают, все придумано давно.

Я работал в компании с грейдами (не IT). Не совсем понимаю, зачем это в IT в текущей ситуации с кадрами. В той компании это нужно было, чтобы, скажем, сравнить сотрудника отдела продаж, сотрудника IT, и, скажем, какого-нибудь Operations тим, лида.

У меня, как админа, отвечающего за стек бизес приложений, был грейд 7, как у менеджеров-середняков, (и секретарши генерального :)). У Senior Management Team был грейд повыше.

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

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

Теперь возьмем, скажем, продуктовую IT компанию. High Risk / High Return. У меня сейчас есть некоторый критичный код, и сотрудники его поддерживающие, один ключевой, и пара человек «подрастает». Проблемы в этом коде могут быть фатальными для компании, такова суть бизнеса. Грейды были бы абсолютно вредны.

В стартапе — даже обсуждать не хочется, и так понятно, что не нужно.

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

грейдинг разного уровня качества и сложности применяется во всех более-менее крупных отечественных компаниях
Более-менее: на мой взгляд, в софтваре это от 100 человек
Возьмем большой аутсорс. Здесь, наверное, есть какой-то смысл для бизнеса, но только в условиях гарантированного предсказуемого притока новых кадров. А когда позиция закрывается месяцами, если вообще закрывается, то грейдирование уменьшает возможности маневрирования как для сотрудников, так и для компаний. Тяжело переманить человека обещаниями дать ему грейд 7-го уровня (на котором он и останется годами). В общем, смысл наверное есть, но компаниям надо взвешивать плюсы и минусы.
Мои плохие прогнозы всегда сбывались. Помяните мое слово через 1,5-2 года (тогда систему грейдов будет уже поздно внедрять — этот процесс растягивается минимум на год, а в медиане — на 2): через год украинский аутсорс ожидает очень серьезная бифуркация.
Если компании к ней не подготовятся — будет плохо и самим разработчикам. Не стройте иллюзий по поводу «лыж на запад» — в той ситуации удастся более-менее сносно устроиться максимум 15%, для остальных — это локальный обвал и девальвация почище 98 и 08 годов для остальных отраслей

через год украинский аутсорс ожидает очень серьезная бифуркация.

Якого рода фазовий перехід?

А детальніше і серйозно?

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

Плохие долгосрочные прогнозы по Европе и США ударят не только по украинскому аутсорсингу, но в первую очередь по самим Штатам и Европе. Если Штаты снова накроет кризис, то у нас у всех будет ядерная зима, потому что во всех компаниях одним из первых сворачивается или замораживается IT направление, а инвесторы перестает отдавать деньги в высокие технологии, предпочитая держать их в трехлитровых банках (ну или в крайнем случае вкладывая только в надежные и вечные отрасли).

Так что рост рейтов аутсорса здесь ни при чем. Пока рынок растет — растут и рейты, когда начнет падать — сначала начнутся сокращения, а потом — снижения рейтов и, как следствие, зарплат. Мы же все это уже проходили в 2008-2009.

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

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

Java/.NET программисты — это кавалерия, потому что порог входа большой
PHP программисты — это пехота, потому что их много

Erlang, Haskell программисты — это вот на слонах которые, потому что их мало

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

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

Текст — шутка, конечно, но...

Хорошее сравнение :) Хотя тестировщики больше смахивают на заградотряд — ни шагу назад ;)

А тимлиды — танкисты, потому что хрен достучишься.

А аналитиков я так понимаю вы в медчасть запишете? Ибо всех лечат :)

Дійові особи:

Гаврюша Обізянов, інженер.
Степан Cрака, главний інженер.

Шльома Гомельский, науковець.

Увы систематизация как эго, растет....

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

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

Берите аналоги из ВУЗов:
профессор
доцент
преподаватель (старший преподаватель)
ассистент
инженер (ведущий инженер)

лаборант (старший лаборант)

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

Есть только один ранг: ЗП ;-)

Правильно. Если контора рассчитает З/П сотрудникам согласно методики Шлеера-Меера, а конкуренты будут предлагать больше, то эти сотрудники долго задерживаться не станут. Потери на адаптацию и вход в струю нового сотрудника — отдельная песня.

Ну есть куча критериев. Если опустить не интересность проекта ибо это субъективно ...

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

Чем больше денег тем грязнее игра это очевидно. При том что в грязную игру вас могут втянуть против вашей же воли. К тому же далеко не все руководствуются моральными принципами, если они вообще есть в наличии. В любом случае доказать что либо будет весьма трудно и барышня может сказать что не @#$%^&@#, а подарили. ;-)

Работаю в конторе много лет. Когда-то «лычки» были в основном просто мотивационными фишками. Типа 1 год опыта — салага, 2 года — новичок, 3 — девелопер, 4 — мидл, 5 — синьор, 6 — гуру и т.д. Звания давали за выслугу лет или как бонус отличившимся. Зарплата от звания зависела слабо: важнее было какой проект, какие технологии, уникальные знания и т.д. Мидл просидев 2 года на важном, тяжелом, сапортном проекте с чокнутым клиентом и спагетти-кодом мог получать больше синьора на чистеньком новом стартапе. Так же клиенты платили за проект и рейты не зависели от «званий» команды.
Хозяева сменились — контора стала бодишопом. Клиентов заставили платить за «звания» — многие выгнали синьоров из команд. Ввели официальные грейды с целью «уравнять» зарплаты. В итоге порезали «дорогих» мидлов и они разбежались. Теперь эти грейды используют что бы не поднимать зарплату старым сотрудникам. Типа еще не дорос до нового уровня — поработай еще годик. Новых с рынка, естественно, набирают на зарплату выше средней. Могут даже звание «накинуть» что бы переманить. Люди не слепые и это дело понимают: в итоге уходят к конкурентам на +500 баксов и новое «звание».

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

Браво! Озаглавить «ПАМЯТКА ОЗАБОЧЕННОМУ БЮРОКРАТУ», взять в рамку, повесить на стену.

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

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

Все от проблемы "

синьор джавист

" а не синьер девелопер, синьерный ждавист действительно узкое и не переносимое звание и это тоже звание, но если ты синьер девелопер не зависимо от технологий (то есть умеешь понимать подходы выбора технологий не важно от кого они, проблемы БД не важно чья она, проблемы работы с железон не важно оно ARM, RISC, CISC итд...) то тогда это легко переноситься, а если твой талант только в том что ты хорошо знаешь чем 1.6 отличаеться от 1.5 и что нового пофиксили, а что старого сломали то это тоже знание но и продавать его надо тому кто его купит, ведь никто не продает БелАЗы миллионерам хотя они и стоят одинаково с брабусами

Назначаем девелоперам ранги с соответствующей зарплатной сеткой, общей для всех компаний, и они садятся смотреть демотиватор отныне и присно, и во веки веков. АМИНЬ. Потому что нет смысла напрягаться или менять работу, ведь зарплата останется той же, в соответствии с зарплатной сеткой. И весь украинский аутсорсинг потеряет мотивацию и обороты и репутацию, и завязнет в болоте. Ай как замечательно! Интересно, кто это придумывает эту ахинею? С какой целью?

Да, в таком формальном варианте это полная ахинея. Кстати, в самом начале статьи именно это и сказано, только поделикатнее

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

Только не в варианте статьи

при интересе и поддержке сообщества ДОУ, подойти и к созданию единого классификатора.

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

Это не только не очевидно, но и, вообще говоря, не верно.
Стандартизация и единая система классификации были актуальны в индустриальную эпоху. ИТ-отрасль — это не конвейерная сборка с фиксированный и заранее известным набором операций. Сомневаюсь, что навязывание единой классификации пойдет на пользу отрасли, тем более такой бурно растущей и быстро меняющейся, как IT: технологии и потребности в них слишком быстро и часто непредсказуемо меняются, количество технологий и инструментов постоянно растет. Локальная система классификации должностей, со всеми ее недостатками, гораздо точнее отражают потребности конкретной компании и гораздо более гибкая к изменениям политики компании и рынка.
Тренд развития IT отрасли таков, что все больше реальный доход IT специалиста зависит не от красивого названия его должности, и не за потенциальные знания, которые он не знает куда применить, а от реального умения решать поставленные задачи.
На похожую тему есть хорошее видео от RSA.org «Детей готовят к будущему старыми методами»:
www.youtube.com/...h?v=CS5dfjeBdLQ

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

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

Что мешает программистам создать свой рейтинг? В конце концов у всех цеховых сообществ во все века были свои рейтинги

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

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

Я понимаю, когда грейды вводятся в большой компании, чтобы стандартизировать систему внутри компании (как сделано, например, в Глобале). Но зачем распространять эти уровни на разные компании с разными принципами работы?

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

Я — никак не собираюсь. Но есть ряд небезынтересных, на мой взгляд, методик

Окей, посмотрим, в чем они заключаются, и как они будут оценивать технический уровень разработчика или QA.

А как же принцип сравнивать сравнимое? К примеру, конечно, звание «гроссмейстер» в шахматах еще не гарантирует, что его носитель 100% выиграет у любителя и тем более у мастера, но как бы все же о многом говорит. В случае же с мастерами Урюпинска и Бердичева (локальные звания) никакой полезной информации в них нет

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

Более подходящим под реалии IT может быть такой пример:
— Есть некий Иванов — профессиональный гид-проводник в Альпах, и Петров — профессиональный гид-проводник в Гималаях.
— Некий Вася Пупкин решил, что неплохо бы сделать глобальную систему грейдов для гидов-проводников и по каким-то своем критериям определил, что грейд Петрова оказался на 2 ступени выше грейда Иванова.
— Собираясь в экспедицию через Альпы, Вам нужно нанять одновременно и Петрова и Иванова, на должности руководителя экспедицией и его помощника и назначить соответствующие зарплаты.
Вопросы:
1) Кому из них Вы доверите руководство походом, а кого назначите помощником?
2) Какому из гидов Вы предложите большую оплату?
3) Поможет ли Вам глобальная система грейдов сделать правильный Выбор?
4) Обойдетесь ли Вы без локальных грейдов?

Шахматист уровня 1-го разряда просчитывает основные варианты всего-лишь на 3-4 полухода вперед, мастер — до 5-7, гроссмейстер — до 10. Уровня Гарри Каспарова в лучшие годы — до 15-17. Так что это лишь теоретически игра с полной информацией. Инновации в шахматах — это дебютные новинки и опровержение оценки некоторых сложных эндшпильных позиций (условно, эндшпиль с двумя слонами против ладьи и т.д.). По большому счету, и любой проект можно считать теоретически «полным», однако на практике всегда масса неопределенностей. Кроме того, есть серии матчей (считай — этапы проектов), в которых на каждого претендента работает целая команда — аналогий на самом деле значительно больше. Но это просто к слову, так сказать, в защиту шахмат как схожей модели

Так что это лишь теоретически игра с полной информацией.

По большому счету, и любой проект можно считать теоретически «полным», однако на практике всегда масса неопределенностей.

Термины игр с полной/неполной/совершенной информацией имеют четкое определение в Теории игр и классификация шахмат и IT проектов по этим определениям однозначна.

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

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

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

Иллюстративные примеры (правда, не с альпинистами) планировались в следующих частях. Кроме того, я попробую более детально рассмотреть проблемы (мнимые или реальные), на попытки решения которых направлены современные системы грейдирования. Но все же должен обратить внимание, что статья больше пытается рассмотреть нужность и применимость существующих методик (как и сами методики), а не предложить что-либо совершенно новое

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

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

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

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

Как минимум, он мог бы внести больше ясности в зарплатные опросы, а как максимум — для выполняющих, к примеру, аутсорс-проекты для Европы, иметь гармонизированную с ЕСовской классификацию

Написано насколько правильно настолько и скучно :)
Как для людей, которые в этом разбираются (позволю себя отнести к ним :) - ничего нового.
Кто с этим не сталкивался — как не понимали нах оно надо, так и не понимают :)

ИМХО конечно...

С этим все сталкиваются, просто многие не догадываются. А ведь если понимать правила, то вероятность улучшить собственные условия повышается

Не надо усложнять, всего есть три ранга — падаван, джедай и джедай-мастер :-)

+ столько же за темную стороную. дарта вейдера не считаем (этот левел недостижим в принципе)

Да, для менеджеров, и Дарт Вейдер как гуру управления персоналом.

Да, по-идее, генерал стройбата инженерных войск немного не дотягивает до лейтенанта ВВС :)

Ну не скажите, хотя до обер-гофмаршала точно не дотягивает www.akunin.ru/istoria/tabel

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

ЗЫ Я сам в ВВС служил, так что в теме.

ХР-Кафе по этой теме вроди как через 3 дня только... или это такой анонсик того, о чем там ХР будут говорить.

Нет, это анонсик следующих частей

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

Это плохо для самих разработчиков, если посмотреть в корень

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

Разве цель не сравнивать мягкое с теплым не полезна?

Эта цель такая же академическая, как и предыдущая... Возможно есть какая-нибудь прикладная цель? Как это улучшит/упростит работу и/или принесет прибыль?

Вы еще спросите, в чем смысл пипл итд менджмента )))

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

В статье, кстати, перечислено 8 проблем — если их решение не полезно, не принесет прибыль и т.д., то хотелось бы знать аргументы «почему»

несогласованность подходов по оплате для разных подразделений и филиалов;

Разные подходы к оплате. Это проблема? Чья?

непрозрачность системы классификации, бесконтрольность и неуправляемость;

бесконтрольность кем? неуправляемость кем? Если мы не понимаем закономерности, не значит, что ее нет...

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

лучше их уволить и развалить проект?

уравниловка в назначении премий и прочих дополнительных стимулов;

сетка зарплат обеспечит меньшую уравниловку? Как?

перекосы в оплате: для вновь вводимых должностей уровень оплаты обычно выше, чем для давно существующих;

если «должности» заменить на «сотрудники», то справедливо. Но проблема ли это отсутствия сетки?

формальность классификации, не влияющая на реальные оклады;

Как эту проблему решит еще большая формализация?

несбалансированность ставок (могут быть как ниже, так и выше) относительно рыночной ситуации;

как эту проблему решит унификация должностей? Вы считаете, что люди на столько одинаковые?

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

только тех, у кого зарплата меньше, чем у коллеги. Почему у него меньше зарплата? Плохо работает — его проблема. Хорошо — почему не повышают на регулярных пересмотрах? Чем аргументируют?

Спасибо. Я постараюсь аргументированно, с примерами ответить во второй части статьи

Коментар порушує правила спільноти і видалений модераторами.

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

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

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

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

относительно четкая граница — если два достаточно квалифицированных разработчика получат разные решения — значит искусство

Не льстите себе.

Аж передернуло от Вашего сравнения: Ван Гог и разработка ПО... Так недалеко и до параллелей вида «Слесарь Вася VS Моцарт».

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

Странные статьи пошли нынче...

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

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

Просто для поддержания интриги (типа часть первая открывает не меряно вопросов, часть 35-я на все ответит), стиль таки зело суховат.
За практичность — вопросы есть (причем или очень очевидные, если ты с ними сталкивался, или вообще невтему — если не сталкивался), ответов нет. Печаль.

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

Чтоб дать ответы, сначала нужно сформулировать вопросы. Эк Вы загнули — 5 тысяч знаков далеко не самого сложного и сухого текста — уже издевательство над мозгом (не заметили лулзов с перекрещиванием пород и статскими советниками?)

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

заметил также намек на «сообщество ДОУ, помогите сформировать единый класификатор».

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

Вброса нет — прямой намек. Если сообщество не озаботится этим само, то это сделают за него и, возможно, совсем не так, как было бы приемлемо сообществу

Я, грешным делом, подумал что Глобал опубликовал вилки по грейдам, как и обещал Х лет назад. Аж но нет, всё стабильно, и это радует!

А нотариально заверенного скриншота не осталось? Можно было бы поинтересоваться.

Да это где-то в отзывах компаний. Через пару лет Роман (вроде бы) отписал что никаких вилок не будет. Но надежда теплилась ;)

Тут
web.archive.org/...ic/all-comments
слово «вилки» зустрічається 44 рази.

а включая слово «вилка» — 66

когда администрация даёт ссылки на веб архив — это не может не радовать! Удобно, правда?

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