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

Грейды: оцифровка программистов. Приложение № 1: Перфотаблицы Хея

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

Прил. 1. Перфотаблицы Хея

На все вопросы рассмеюсь я тихо

На все вопросы не будет ответа

Ведь имя мое — Иероглиф




Группа «Пикник»

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

Корни происхождения этой странности можно проследить от 70-80-х годов ХХ века, когда бытовала шутка:

— Какие языки программирования будут применяться для расчета научных задач в XXI веке?
— Разные. Но главным среди них будет Фортран.

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

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

Вероятно, именно первоначальной «заточенностью» под обработку данных на перфокартах и объясняется относительная сложность метода. Кстати, в этом еще одно его родство с Фортраном, который с самого начала был ориентирован на перфокарты (к примеру, позиции строки с 1-й по 5-ю — область меток, а с 73-й по 80-ю — для нумерации перфокарт на случай «рассыпки» колоды — кто помнит эту трагикомедию, тот поймет всю важность нумерации). Так или иначе...

Хисторические заметки

Hay Group Inc. — компания, входящая в TOP-5 в своей области и специализирующаяся на кадровом консалтинге. Основана в 1943 году в Филадельфии, имеет несколько тысяч консультантов и сотрудников, работающих в сотне офисов более чем в 30 странах мира. И в Украине в том числе.

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

Данный метод чуть более, чем полностью, защищен авторским правом, и никогда не публиковался целиком. В США стоимость его внедрения для одной компании превышает 50 тыс. долларов, в других странах в разы, но не порядки, меньше.

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

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

Информация с сайта www.haygrouppaynet.com

Машина различий

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

Факторы Субфакторы Оценка
Знания и умения KH — know how Технические познания A,B,C,D,E...
Широта и сложность навыков I,II,III...
Коммуникативные навыки 1,2,3,4,5...
Решение проблем PS — problem solving Творческий потенциал Оценивается как процент от значения фактора Знания и умения
Сложность проблемы
Ответственность AC — accountability Подотчетность действий A,B,C,D,E...
Вклад в конечный результат 1,2,3...
Области влияния A,B,C,D,E...

Для конкретной должности по каждому фактору присваивается качественная оценка, затем полученные оценки переводятся в баллы по специальным (направляющим) таблицам, предоставляемым консультантами, а потом баллы из каждой таблицы суммируются. Так получается оценка для должности. Если это число отличается менее, чем на 15%, от другой должности, то должности принимаются аналогичными.

Затем полученный профиль переводится в так называемый короткий профиль, в котором сумма балов по всем факторам принимается за 100% и рассматривается соотношение факторов.

С помощью короткого профиля можно так интерпретировать окладную часть должности:

  • 55% оклада платится за знания и умения;
  • 18% оклада — за ответственность;
  • 27% — за решение проблем.

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

Чтобы все изложенное не напоминало анекдот «— Петька, прибор. — 30. — Что 30? — А что прибор?», даже очень упрощенный пример будет кстати.

Сферический PHP-программист

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

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

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

  • понимание принципов проектирования и программирования в ООП (PHP4/PHP5);
  • опыт разработки на PHP5 свыше 2-х лет, подтвержденный завершенными проектами;
  • базовые знания JavaScript/HTML/DHTML/CSS/AJAX;
  • опыт работы с MySQL;
  • опыт использования одного из фреймворков (ZendFramework, CodeIgniter, Kohana и т.п.);
  • опыт разработки сайтов с различными сервисами;
  • опыт работы в команде и применения GIT или SVN или Mercurial.

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

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

Фактор «Знания и умения», субфактор «Технические познания»
Уровень Описание
E Понимание и применение основ теоретических знаний, получаемых через академическую подготовку или на практике.
Работа требует понимания и применения принципов, концепций и методов, связанных с этими знаниями. На этом уровне, важно понимать «почему» надо делать тем или иным образом, в дополнение к «что» и «как» надо делать. Данный уровень так же включает рабочие места, для которых требуются широкие познания в различных областях.
F Требуется практическое применение предметных знаний в широком диапазоне ситуации, профессиональные навыки, когда теоретические знания дополнены реальным опытом работы или повышены за счет дополнительного обучения по специализации.
Главное — практическое применение знаний, а не их приобретение. Этот уровень также требует знаний в нескольких специализированных областях (уровень E в паре областей и уровень D в остальных).
Уровень нашего испытателя E+ (E в PHP, D — в остальных, требуется приобретение новых навыков)
Фактор «Знания и умения», субфактор «Широта и сложность навыков»
Уровень Описание
I Индивидуальный вклад в выполнение комплексных задач или комбинацию задач и функций. Требуется понимание того, как работа соотносится с работой других сотрудников. Может привлекаться к работам, в которых необходимо знание других подразделений или областей деятельности организации.
Сюда же относятся руководители нижнего звена, планирующие, контролирующие и оценивающие работу подчиненных.
I+ Требует управления полным циклом операций без непосредственной помощи со стороны руководителя, руководства группой работников с различными функциями, ответственности за результат всей группы.
Уровень испытателя I
Фактор «Знания и умения», субфактор «Коммуникативные навыки»
1 Предполагает коммуникации для получения или предоставления информации, наличие навыков корректной формы вопросов и получения разъяснений. Требования к навыкам могут включать использование специальных терминов.
2 Требует частого влияния на изменения мнения или окружающей ситуации, а также внимания к чужой точке зрения. Умение излагать техническую или функциональную информацию в доступной форме для неспециалистов в данной области.
Требуется для распределения работ, наблюдения и контроля за ходом выполнения, оценки результатов, а также для должностей, отвечающих за развитие и подготовку сотрудников.
Уровень испытателя 1+

После проведения таких оценок по фактору «Знания» применяется одна из
направляющих таблиц и вычисляются баллы. В нашем случае это 200 баллов.

I
1 2
E- 152 175
E 175 200
E+ 200 20

Фактор «Решение проблем» подразумевает меру новаторского мышления и уровень его самостоятельности и оценивается не в баллах, а в процентах от фактора «Знания». Должность нашего испытателя характеризуется:

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

и соответствует 38% по фактору «Решение проблем» (выбирается из соответствующей направляющей таблицы). В баллах это 38% от 200 или 76 баллов.

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

Общий вес должности: 200 + 76 + 87 = 363

Короткий профиль должности «сферический PHP-программист» запишется так:

KH — 55, PS — 21, AC — 24,

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

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

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

Сие тайна великая есть

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

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

Для этой же истории будут вполне очевидны следующие выводы:

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

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

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

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

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

Схожі статті




22 коментарі

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

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

как сумма средней з/п по больнице (городу)

с учетом зарплат, к примеру, водителей, уборщиц или какой средней?

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

Как Вы определите равенство «конкретных» специалистов, чтоб взять среднее?

Ну, есть же зарплатная вилка для типичных джунов, мидлов, сениоров, ПМ-ов — любой опытный HR сейчас назовёт текущие запросы программеров. Предлагаешь существенно ниже — никто не идёт. Чуть выше — идут халявщики, которые не дотягивают до нужного уровня. Да, не каждый будет прыгать по работам за +100 у.е. к з/п. Но рынок труда можно и нужно постоянно мониторить.

PS: Или даже так, как у меня на работе: потекли кадры с конторы — поднимаем чуток это «среднее» в расчётах. Адаптивная система, блин.

Тогда Вы, наверное, согласитесь, что неплохо бы поточнее понимать среднее и за что оно платится. Грубо говоря, это позволило бы дать ориентир для более точного «поднятия». Скажем, на 15-20% повышение точности было бы интересно?

Да, в нашей компании придумали как измерять программистов — с помощью KPI (Key Performance Indicators). И описанный в статье метод тоже чем-то хорош.

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

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

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

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

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

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

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

Что бы сотрудник не убежал нужна не зарплата — а мотивация.

В моём комментарии на три уровня вверх написано:

плюс бонус за текущие заслуги для мотивации

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

процентная надбавка, зависящая от цены потери этого специалиста

Спасибо, ждем продолжения.

Только сейчас осознал интересный нюанс: почему научный подход выглядит так разумно на бумаге и так криво, когда его применяют к оценке персонала. А думаю причина в том, что научный подход хорошо применим к оценке позиции (должности).
Поставим задачу описать что должен знать и уметь человек, что бы, скажем, заменить меня на проекте. Это вполне понятная и решаемая задача: я хорошо знаю что приходится делать и как часто а что не нужно или может сделать другой.
Но если поставить задачу оценить сотрудника — тут проблема в разы сложнее и хуже поддается научному подходу. На текущем месте я использую, в разные дни, скажем от 40 до 60% своих умений. Плюс я могу хорошо разобраться в новой технологии, но очень нескоро выучить английский на отлично. В итоге моя фактическая отдача будет зависеть от позиции.
Может в этом и секрет: надо оценивать не сотрудника, а позицию. При этом учитывать и сложность проекта, и степень ответственности и качество кода и т.д. И зарплату платить не за то, что кто-то знает 10 языков, а за то, как он работает на конкретном месте.
Тогда и грейды и переаттестация каждые полгода ненужны будут. Зарплата должна зависеть от 3 вещей:
1. Рынок. Средняя зарплата выросла — сотрудник знает что ему повысят без всяких аттестаций. Понизилась — понизят и смотри следующие способы повышения.
2. Успехи и «косяки» сотрудника и команды. Хорошо работаешь — через полгода накинут 10%, плохо — не накинут, облажался — сам виноват. У начальства все ходы записаны.
3. Переход на новую позицию. Хочешь повышения в 2 раза — вот новая позиция, которая столько стоит. Пройдешь проверку соответствия — добро пожаловать.

Вот это и есть справедливая система: не синьор получает больше мидла, а девелопер на проекте А получает больше девелопера на проекте Б потому что работа сложнее. Или ДБА получает больше ПМ, потому что база очень сложная и нагруженная.

Может в этом и секрет: надо оценивать не сотрудника, а позицию.

Хей с Вами бы согласился

Для конкретной должности по каждому фактору присваивается качественная оценка

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

сложна для продажи клиенту
В этом я вижу одно из препятствий для успешного применения грейдинга в бодишопах.
Зачем ее вообще продавать клиенту?! Если я правильно понимаю она нужна в первую очередь внутри компании, что бы сотрудники не думали что им недоплачивают и не ходили «налево».
Клиенту-же надо всегда стараться продавать сотрудника за максимум. Сотрудник-то не знает за сколько его продали. Да и клиенту не обязательно знать что конкретно каждый девелопер умеет. Он платит за абстрактных «синьоров», «мидлов» и «джунов» — вот и чудненько. А дальше уже работа техлида и ПМа, кого, сколько и почем набрать что бы работу делали.
А еще лучше — пусть клиент платит за проект, а не за «головы» (но ту же сумму). Тогда появляется гибкость. Например в начале проекта можно взять больше синьоров, меньше QA. А ближе к фазе стабилизации — синьоров отпустить и взять больше QA и джунов для багфикса. Иначе получается глупо: свои синьоры сидят на сапорте «бесконечных» старых проектов (потому что их уже продали), а на новые проекты синьоров переманивают из других контор за большие деньги.

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

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

Кто -то отлично покопал про Хея. У меня возник вопрос к жанру: если это аналит. статья, то какая гипотеза и что мы изучаем? Если это критика- то чего именно?

Может есть смысл вспомнить про ЦЕЛЬ применения методики ранжирования должностей в т.ч. и по Хею: это для того, чтобы было легче систематизировать кадровикам уровни позиций и соответственно показать прозрачность и некую(заметьте у Хея она своя есть) логику оплаты труда. А еще чтобы смотреть на рынок труда и конкурентов и быть в состоянии понимать свой уровнень на нем с оплатой (опять же предполагал Хей не без доли гениальности, что эта фишка поможет продавать услугу, дабы каждый из игроков рынка мог сравнить себя по единым критериям).А теперь внимание!!! Мелким текстом(как пишут в побочных эффектах в фарма) в методике грейдирования должно быть сказано( адля профи HR в отсутвии этого текста служит МОЗГ), что оно ПРЯМО связано с политикой оплаты в компании и может быть методом для определения размера оплаты ТОЛЬКО в компании с ориентацией на внутренний бюджет и на не дефицитном рынке кандидатов. ОПА — оба критерия не выполняются для настоящего рынка ИТ.. Для таких рынков как ИТ где есть дефицит спецов и компании в оплате ориентируются на коллег по рынку как наиболее значимый фактор, клияющий на найм, оценка позиции нужна. чтоб понять кто нужен.. однако не влияет она на оплату... :)

У меня возник вопрос к жанру: если это аналит. статья, то какая гипотеза и что мы изучаем? Если это критика- то чего именно?

В первом абзаце есть ссылка на первые две статьи цикла.

Замечательное примечание, про мелкий текст. С одной поправкой — не кто-то, а никто (nemo — лат.:). Если без шуток:

У меня возник вопрос к жанру: если это аналит. статья, то какая гипотеза и что мы изучаем? Если это критика- то чего именно?

о традиционно серебряной, по мнению автора, пуле

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