• Зарплатные велосипеды

    Posted on March 18th, 2009 Александр Орлов 19 comments

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

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

    Сравнение бананов с помидорами. Поскольку практически все менеджеры у нас – это технические люди (хотя бы в недалеком прошлом), то им смерть как нужны метрики. Без метрик, говорят, как людей друг с другом сравнить? Ясно, что никак. Потому что без метрик, это будет субъективный подход! В результате придумываются какие-то метрики.

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

    - Ну что, в чем сравнивать? Ну, давай в строках кода. Вот ваш архитектор сколько строк написал? 1,000? Ну, нормально. Мой тестер написал 50,000.

    - Постой, так нельзя сравнивать. Сложность несравнима. Прототип писать – гораздо сложнее.

    - Ну, давай поставим коэффициент сложности. Например, 5.

    - Почему именно 5?

    - А сколько? Ну, давай 10.

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

    - Нет, так нельзя. Нужно как-то это измерить. Пусть разработка прототипа сложнее разработки тестов в 10 раз (хотя я в этом очень сомневаюсь…). Ну еще за переписку с нуля накинем коэффициент 2. В итоге получается, что твой архитектор написал 20,000 кода, мой тестер 50,000.

    - …

    В итоге, все снова сводится к субъективности, поскольку

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

    Размножение субъективных параметров. Некоторые компании в попытках убежать от субъективности придумывают не один параметр оценки, а несколько десятков (лично видел, более сотни). То есть, они говорят:

    - Ну, тут ясно дело, что просто так людей по параметру “Contribution” фиг сравнишь. Больно субъективный параметр. Метрики-то нет. Давайте придумаем 50 параметров.

    И действительно:

    придумывают 50 параметров, каждый из которых (внимание!) тоже субъективный!

    Вот, например, параметр “Coding Skills” – ну, там, насколько хороший код человек пишет. Допустим, применяется 10 бальная шкала оценки. И чем, скажем, отличается оценка 5 от оценки 6? Думаете, хоть один менеджер сможет это объяснить?..

    И так, примерно 50 параметров. В итоге у человека, который первый раз видит эту таблицу с сотней строк, может сложиться впечатление, что да – вот она, СИСТЕМА! Беспристрастная и справедливая. А субъективность, между тем, осталась, никуда не делась.

    Всевидящее око менеджера. В некоторых системах пересмотра зарплат оценку человека по набору параметров производит менеджер. Единолично и единовластно. Особенно, это популярно, когда присутствует как раз система с 50 параметрами.

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

    часть информации менеджеру все равно будет не видна

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

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

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

    Повышаем того, кто работает больше других. Напоследок, еще одна популярная ошибка. Менеджеры, сравнивая людей, получают в итоге некоторый список от 1 до N по размеру вклада человека в работу команды и проекта. Используя ли какие-то метрики, или используя систему performance review – не так важно.

    После чего, повышение получают те, кто находятся сверху списка. Это, конечно, не верно. Нужно:

    смотреть на то, насколько велик вклад человека в сравнении с его грэйдом (зарплатой)

    Вполне может оказаться так, что пришел студент на маленькую зарплату и как начал, как начал работать. Конечно, он не дотягивает до суперзвезд, которые трудятся в команде уже 5 лет, ну так у него и зарплата в 2.5 раза ниже.

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

    Кому в процентном отношении больше повышать зарплату? Ну да, студенту.

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

    Резюме. Подводя итог – коллеги, не изобретайте велосипед. :)

     

    19 responses to “Зарплатные велосипеды”

    1. andrei_kulabukhau

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

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

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

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

    3. 2 andrei_kulabukhau Попытался погуглить – и сразу что-то не нашлось. Может быть, зря я вообще батон-то на всех покрошил? :) Если в ближайшие дни не найду, придется самому рассказывать, что ли.

    4. 2 bskaplou

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

      Понятно, что есть еще всякие другие повышения: инфляционные, рыночные и пр.

      Меру субъективности параметров сравнивать сложно, потому как – какая метрика? :)

      Системный подход, в целом, хорош. Но при применении его к параметрам оценки людей возникают иногда очень причудливые метрики. :)

    5. Почему при оценке ЗП не пытаются исходить из обработанных объектов как в промышленности? В разработки программного продукта (ПП) объектом обработки является ситуация и классы ситуаций, имеющие порядок роста – константу или функцию и каждая свой вес и вероятность возникновения (её можно оценить предварительно, её можно определить в процессе функционирования ПП). Каждая ситуация обрабатывается с т.з. функционала пользователя аналитиком (может породить новые для архитектора), архитектором с т.з. единства и концептуальной целостности системы, правил и принципов её построения (может породить новые), проектировщиком с т.з. места и формы обработки кодом, программистом с т.з. кода, непосредственно обрабатывающего заданные ситуации во время функционирования ПП; и тестером, который проверяет соответствие обработки ситуаций заданным требованиям аналитика, архитектора, проектровщика и программиста, а ещё, возможно и самими архитекторами и проектировщиками?
      Да, каждый вид и формат и цели обработки одной и той же ситуации различаются, могут порождать новые ситуации, не видимые для верхнего уровня, но для этого и существуют разные роли, обладающие разными знаниями, которые между собой равны как единицы смысла и различаются в цене по оплате образования. Отговорки, что все эти ситуации посчитать нельзя, не принимаются – а что же тогда делает вся эта арава :) )) Помимо целевой обработки ситуаций, создания, продажи и внедрения ПП, есть и ситуации, нацеленные на передачу знаний. Расчёты аналогичны.
      Из такого подхода очевидно, что чем меньший в байтах код обрабатывает чем больше ситуаций, и чем меньше всё это производилось, тем лучше команда. Из этого же подхода следует, что если от студента ожидалась обработка 10-ка ситуаций в месяц (на каждую чуть менее 2-ух дней), а он делает 20, значит и повышать ЗП нужно в 2 раза. Из этого же подхода следует, что бонусы каждому от продажи каждого экземпляра ПП пропорциональны доле обработанных ситуаций. Т.е. по предложенному подходу оценивать нужно обработанные людьми ситуации, а уже по этому показателю – людей.

    6. 2Александр Орлов:
      Странные результаты можно получить применяя что угодно и чему угодно … Действительно оценка деятельности человека задача непростая и то, что с ней довольно часто не справляются лишнее тому доказательство. Однако сознательный отказ метрик в пользу – просто в пользу отказа от них :) кажется не очень хорошей идеей.

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

      Набор вменяемых метрик – это как минимум способ не забыть о значимых аспектах при оценке работы человека.

    7. 2 bskaplou – если можно придумать какую-то метрику, которая будет помогать сравнивать вклад людей – здорово. Я говорю, что, во-первых, вряд ли эта метрика будет адекватна применима ко всем, во-вторых, метрик не будет достаточно, чтобы получить адекватную картину вклада человека.

    8. 2 Александр Орлов:
      >>метрик не будет достаточно, чтобы получить
      >>адекватную картину вклада человека.
      Из чего сделан такой вывод???

      Я тут растекусь мыслею по древу с вашего позволения..
      Примерно вот такая модель немного отражает картину
      1. Есть тим из N человек
      2. Есть бюджет из M (от money) бабла
      3. Есть текущий мапинг M на N ,назовём его C (от contribution), вот такого рода мапинг
      - за прошлый период Вася наделал 10% работы C[Вася] = 10
      - Петя в прошлм периоде делал 20% работы C[Петя] = 20
      аналогично для всех из N
      4. Сумма всех значений из C = 100
      5. Для решения задачи – раздать M всем из N в соответствии с вкладом в работу, надо дать каждому из N бабла из M в соответствии с C. Вася += M/100 * C[Вася]. Могут быть более сложные системы распределения M, но нас сейчас волнует С, а не M.
      6. для поддержания адекватности C оно переодически корректируется, обычно раз в год но бывает чаже/реже.

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

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

      Возможно если бы за строки кода платили бы в Долларах, за коммуникабельность в Евро, а за натаскивание менее опытных в Рублях, было бы проще, но нет – за всю работу платят в одной валюте :(
      Это и заставляет сводить эти разные типы активности к единой валюте.

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

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

      Метрики спущенные сверху склонны сравнивать ‘бананы с помидорами’ так как:
      1. В метрики разные люди вкладывают разный смысл и от этого не избавиться (ограничение наложено отсутствием коллективного разума у Homo sapiens).
      2. Разные менеджеры знают разные вещи с разной достоверностью о своих людях, например один менеджер знает сколько строк кода кто пишет с 80% точностью но возможно мало знает откуда идёт все гениальные идеи – 20% точности, другой знает мало про строки кода – 20% точности, но знает кто генерировал идеи понравившиеся заказчику – 80% точности.
      3. Разным командам свойственна разная важность активностей. Например если в команде много junior инженеров то роль коучинга больше, если все senior то меньше.

    9. 2 bskaplou

      >> Понятно что аспекты человеческой
      >> деятельности многоранны, и учесть все
      >> активности человека на практике невозможно.
      >> Для нашей задачи это значит что получить
      >> бесконечноточные значения в C невозможно. Но
      >> это не мешает найти набор метрик которы
      >> позволит адекватно приблизить C к идеальному.

      А адекватность как оценить? Как узнать, насколько ты приблизился к идеальному С?

      И таки как сравнить бананы с помидорами-то? :)

    10. Антон Непомнящих

      Я для себя пока нашел единственный нормальный критерий какую з/п человеку поставить – сколько бы я ему дал, если бы он пришел завтра и сказал, что хочет уйти? :)

      Потому что когда человек уходит, ты начинаешь ему предлагать повышение з/п и все такое… А ведь можно было заранее просто дать столько, сколько заслуживает :)

      И интуитивно так и получается – исходишь из текущего уровня з/п и текущей полезности человека. Но я взял себе на заметку – надо подумать как соотнести эти два параметра. Спасибо!

      Мне кажется, здесь та же проблема – субъективность. Может это ты думаешь, что он такой молодец, а другие думают по-другому?.. Надо покопать насчет 360 – у нас такого пока не применяется, а мне кажется, было бы полезно.

      З.Ы. Правда – очень интересно было бы узнать как в других фирмах с этим дело. Недавно интервью с Артемом Бойцовым было как в гугле с этим (кстати – супер-интервью! спасибо! :) ), но конечно, если было бы поподробнее, было бы совсем круто ;)

    11. Критерий здравого смысла очевидно никто не отменял. Это именно то зачем нужен ‘сложный человеческий мозг’ 1шт.

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

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

    12. 2 bskaplou

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

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

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

    13. 2 aynvudo

      Очень сложно, боюсь, я не понял. :)

      Что такое ситуация? Как их можно сравнивать между собой? Какой-нибудь реальный примерчик бы очень помог.

    14. Возьмите за образец альпинистов. Для альпинистов есть сложности маршрутов. Кто такой крутой альпинист? Тот кто быстрее всех проходит самые сложные маршруты.
      Как оценить стал ли альпинист круче чем был год назад – посмотрите на то, маршруты какой сложности он проходил год назад и за какое время.
      Вау! Метрика существует!

    15. Время прохождения маршрута можно сравнить только на одном маршруте, логично? :) Как сравнить крутость альпинистов на разных маршрутах одинаковой сложности?

      И еще один важный момент. Горные маршруты – это все-таки более-менее из одной области.

      Представим теперь, что перед нами есть проект – покорение самой высокой вершины. И есть команда:
      – Альпинисты, которые много тренируются в зале и на других вершинах
      – Условно, “снаряжологи” – те, кто готовят снаряжение и попутно придумывают уникальную штуковину, которая поможет альпинистам сберечь 20% сил при подъеме.
      – Группа поддержки, которая следит за лавинами. В частности, во время экспедиции обнаруживает неожиданную лавину и ее обрушивает. А иначе альпинистам были бы кранты.
      – …

      И вот экспедиция пошла и таки закончилась успешно. Вершина покорена! Вопрос – кому и насколько поднимать зарплату?

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

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

      Не надо идеализировать и замерять время с точностью до десятых долей. Тогда разные маршруты одинаковой сложности можно соизмерять.

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

      >И вот экспедиция пошла и таки закончилась успешно. Вершина покорена! Вопрос – кому и насколько поднимать зарплату?

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

    17. Это не ответ на вопрос “Кому и насколько поднимать зарплату”. :) Что значит “проблема плохо детализирована”?

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

      Скажу честно, я не видел каких-то численных метрик, которые бы адекватно “сравнивать бананы с помидорами”. Хотя смотрел много. И, конечно, это не значит, что их не бывает. :) Буду рад узнать что-то новое.

    18. andrei_kulabukhau

      2Александр Орлов: Ну что, нашлись в Сети “велосипеды”? Рассказ тогда в студию, чтоб типа крошки от батона прикрыть :) Надеюсь ты не связан обязательством о неразглашении такого рода информации с Sun’ом и Intel’ом?

    19. :) ) Быстро не нашлись, долго так пока и не поискал. Расскажу, расскажу, дайте время. :)

    Leave a reply

    You must be logged in to post a comment.