Думаем внедрить аттестацию сотрудников(программисты) и пересмотр з/п по результатам аттестации.
Приблизительно идея следующая:
сделать тарифную сетку на 3-5 позиций.
раз в год проводить ревью всего сделанного сотрудником за год, и соотвественно — его положение в тарифной сетке. Исходя из этого получаем з/п.
Основной вопрос в том как оценивать человека, какие метрики собирать. Оно понятно что в идеальном варианте можно внедрить PSP/TSP и в методике умные люди все уже просчиталии все коеффициенты подбили.
Но у нас нет возможности держать отдельного человека для сбора метрик, и ведения статистики. Не говоря уже о том что собирать и какие коеффициенты факторам вешать.
Второй вопрос — как сформулировать требования позиций тарифной сетки. В общих словах "быть инициативным, стремиться к самосовершенствованию" — ет скорей "для галочки".
Формировать конкретный набор пунктов из метрик?
Что хотелось бы в идеале: некую простую методику и софтину которая автоматизирующую процесс по максимуму.
Может идея неверна в корне? Как тогда организовать процесс "хочу больше денег"?
Здравствуйте, itslave, Вы писали:
I>Может идея неверна в корне? Как тогда организовать процесс "хочу больше денег"?
Вообще тема для холивара
Если рассматривать качество работы от конечного результата, то главный показатель — выполненная работа. Если вы поручаете человеку решить определенную задачу и он ее решает в срок и при этом решает так, что переделывать за ним не надо, значит он на уровне "хороший исполнитель". Если при этом он еще и проектирует инструменты для других разработчиков — уровень "очень хороший исполнитель". Если помимо всего вышеперечисленного разработчик еще и новые инструменты изучает и внедряет — уровень "мастер".
А все метрики — вещь субъективная. Тем более, что все задачи разные и требуют различных подходов, объемов кода, уровня документирования и т.д.
Здравствуйте, itslave, Вы писали:
I>Может идея неверна в корне?
Сто раз уже обсуждалось. Идея неверна в корне.
В лучшем случае вы получите типа "объективную" формулу,
под которую начальник будет подбирать входные так, чтобы получилось то, что надо.
В худшем случае эту формулу будут применять недумая.
I>Как тогда организовать процесс "хочу больше денег"?
Пусть непоссредственный начальник просто делает свою работу.
А именно, общается с подчиненными, отсележивает кто и как работает,
отслеживает настроения в команде и т.п.
В этом случае у начальника никогда не возникнет проблем с тем,
кому стоит поднять зарплату и почему это стоит сделать.
Формула никогда не учтет самых важных факторов.
Ну как ты к примеру формально оценишь готовость сотрудника делиться своим опытом и желанием помочь другим?
А это много стоит...
В общем с каждым сотрудником лучше индивидуально решать вопрос о зарплате,
не свалить это на тупую формулу.
P.S. Понижать зарплату — это демотивировать сотрудника и по сути потерять его.
Здравствуйте, morm, Вы писали:
M>Вообще тема для холивара M>Если рассматривать качество работы от конечного результата, то главный показатель — выполненная работа. Если вы поручаете человеку решить определенную задачу и он ее решает в срок и при этом решает так, что переделывать за ним не надо, значит он на уровне "хороший исполнитель".
M>Если при этом он еще и проектирует инструменты для других разработчиков — уровень "очень хороший исполнитель".
Или недозагруженный исполнитель, у которого есть на это время
M>Если помимо всего вышеперечисленного разработчик еще и новые инструменты изучает и внедряет — уровень "мастер".
Или "мастер брать мало простых задач", быстро их делать и в свободное время заниматься тем, что интересно
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, itslave, Вы писали:
I>>Может идея неверна в корне?
А>Сто раз уже обсуждалось. Идея неверна в корне.
Тут я не согласен. Скорее так: внедрение правильного процесса(из дискуссий на рсдн я понял что есть каг минимум 1 правильный процесс — psp/tsp) очень сильно удорожает разработку.
А>Пусть непоссредственный начальник просто делает свою работу. А>А именно, общается с подчиненными, отсележивает кто и как работает,
Я как бы и согласен, но это субъективизм. Вопрос появления недовольных "а почему мы с Васей работаем одинаково(ну я уверен что работаем одинаково), а он получает на 200 баксов больше?". Вот хотелось бы хоть какой нибудь формализации процесса. А>P.S. Понижать зарплату — это демотивировать сотрудника и по сути потерять его.
Ну уж не знаю, сам я до последнего был категорическим противником... Но наблюдаю за человеком которому на ~40% повысили зп по моей инициативе, с расчетом что перестанет ваньку валять и начнет работать. Он прямым текстом озвучивал недостаточную зп, ниже средней по рынку, как главный фактор из-за которого он не впахивает.
После повышения зп производительность в общем и целом осталась на том же уровне, беседы мимо кассы. Что с ним делать?
Здравствуйте, morm, Вы писали:
M>Здравствуйте, itslave, Вы писали:
I>>Может идея неверна в корне? Как тогда организовать процесс "хочу больше денег"?
M>Вообще тема для холивара M>Если рассматривать качество работы от конечного результата, то главный показатель — выполненная работа. Если вы поручаете человеку решить определенную задачу и он ее решает в срок и при этом решает так, что переделывать за ним не надо, значит он на уровне "хороший исполнитель". Если при этом он еще и проектирует инструменты для других разработчиков — уровень "очень хороший исполнитель". Если помимо всего вышеперечисленного разработчик еще и новые инструменты изучает и внедряет — уровень "мастер".
Да, но насколько он хороший исполнитель? Он лучше соседа Васи, за которым тоже почти не надо переделывать? Так уж получается что у всех кто делает работу в срок должна быть одинаковая зп, вне зависимости от обьемов и сложности работы. M>А все метрики — вещь субъективная. Тем более, что все задачи разные и требуют различных подходов, объемов кода, уровня документирования и т.д.
Ну ка ни крути обьективней чем "делают вовремя что почти переделок не требуется".
I>Я как бы и согласен, но это субъективизм. Вопрос появления недовольных "а почему мы с Васей работаем одинаково(ну я уверен что работаем одинаково), а он получает на 200 баксов больше?". Вот хотелось бы хоть какой нибудь формализации процесса.
Чего именно вы хотите достичь? Хотите, чтобы Петя, который получает на 200 баксов меньше Васи, вдруг перестал хотеть повышения зарплаты до уровня Васи? И вы всерьез ожидаете, что после введения аттестации Петя неожиданно прозреет и перестанет хотеть повышения? Уверяю вас, этого не произойдет.
Так какова же ваша цель? Видимо, Пети, которые получают меньше Вась, долбают менеджеров вопросами "а почему я получаю меньше Васи". Цель — избавится от долбания менеджеров, так? Давайте проведем простой анализ затрат и доходов от внедрения аттестации.
Затраты:
1. Минимум 1 рабочий день каждого человека в компании. Он уйдет на переключение контекста (выход из текущей работы), заполнение форм и отчетов, вход обратно в контекст текущей задачи. Это интегрированные оценки, реально у кого-то может уйти чуть меньше, у кого-то чуть дольше, но матожидание будет именно 1 день.
2. В зависимости от высоты и ширины иерархического дерева (т.е. по 5 подчиненных у одного начальника или по 5 начальников у одного подчиненного — во втором случае затраты времени вырастут многократно), от 1 до 3 рабочих дней уйдет у менеджмента. На беседы (аттестация всегда предполагает минимум 1 беседу, и в некоторых случаях 2ю), прочтение и подписание бумаг и форм.
3. Разработку и внедрение собственно форм. Если вы решите сделать все самостоятельно (потому что 20% сотрудников уже работали в больших конторах, где все было формализовано, в т.ч. аттестация, и знают, как это устроено там) — посчитайте расходы (я не в курсе, т.к. в тех компаниях, где я работал, для внедрения аттестаций привлекали сторонние организации).
По самым скромным оценкам, кроме значительных капитальных затрат из пункта (3) вы получите операционные расходы в количестве 1-1.5% (иными словами, вся компания потеряет 1-1.5%). Это, на самом деле, очень большая цифра, даже если вам так не кажется.
Доходы:
Никаких. Потому что теперь недовольные подчиненные будут ровно так же долбать начальника, только не со словами "а почему Вася больше получает", а "почему у Васи выше грейд, хотя Вася в прошлом году закоммитил в три раза меньше строк кода и закрыл в два раза меньше багов". Только теперь менеджерам придется не просто раздавать повышения, основываясь на своей интуиции и оценках, а еще и подгонять результаты аттестации под эту самую интуицию и оценки. Вы же не можете всерьез думать, что аттестация внесет объективность?
Однако ж, у процесса аттестации в некоторых реализациях есть положительный момент. Во всех мне известных формах аттестации есть пункты "что вы бы хотели изменить в компании", "что вы хотите изменить в офисе", "что вы бы хотели изменить в своей работе". Эти пункты, если их действительно читать, дают очень сильную обратную связь. Что, в свою очередь, здорово поднимает мотивацию.
Второе достоинство: правильно организованный процесс аттестации работает не _против_ подчиненных (как вы хотите сделать), а _на_ них. Для этого у аттестации есть вторая ветвь (ЕМНИП, это первым ввел Интел). Аттестация работает в обе стороны: не только начальник оценивает своих подчиненных, но и подчиненные ровно так же оценивают начальника (возможны варианты реализации со своими плюсами и минусами, можно обсудить, если интересно). И результаты этих аттестаций _намного_ более ценнЫ, чем аттестация начальником своих подчиненных. Потому что один плохой начальник наносит вреда много больше, чем несколько плохих подчиненных.
Подвожу краткий итог. Из ваших сообщений мне показалось, что вы хотите с помощью введения процесса аттестации сказать подчиненным "сидите и не высовывайтесь, все равно каждого из вас оценивает ваш начальник, только раньше он делал это наобум, а сейчас по науке". Это мотивации не добавляет, а вот расходы увеличивает. Если вашей целью является что-то другое — расскажите, пожалуйста, что именно. Только без экивоков вида "мы хотим объективной оценки пользы от сотрудника", это тема для "Священных Войн", а не для этого раздела.
I>После повышения зп производительность в общем и целом осталась на том же уровне, беседы мимо кассы. Что с ним делать?
Пересмотреть понятие производительности? Или, вероятно, стоит человеку дать новый проект (или хотя бы новый модуль, в общем, что-то новое). Похоже, что вашему сотруднику просто до чертиков надоело пилить одну и ту же пудовую гирю. Какая она бы ни была золотая, это надоедает.
Здравствуйте, itslave, Вы писали:
I>Я как бы и согласен, но это субъективизм. Вопрос появления недовольных "а почему мы с Васей работаем одинаково(ну я уверен что работаем одинаково), а он получает на 200 баксов больше?". Вот хотелось бы хоть какой нибудь формализации процесса.
Ну так эти люди так же будут недовольны тем, что у них система оценки негодная, её придумали идиоты и она не связана с реальной продуктивностью.
Плюс (если вы бездушной формальной методикой хотите с себя ответственность перед лицом подчиненных снять) на практике в компаниях с внедренной системной мотивации повысить грейд хотят все и тут начинается драма, что к соответсвию формальным показателям пришло больше людей, чем вы можете себе позволить повысить (исходя из зарплатного бюджета) и тут начальник опять оказывается крайним.
Здравствуйте, SkyDance, Вы писали:
SD>Доходы: SD>Никаких. Потому что теперь недовольные подчиненные будут ровно так же долбать начальника, только не со словами "а почему Вася больше получает", а "почему у Васи выше грейд, хотя Вася в прошлом году закоммитил в три раза меньше строк кода и закрыл в два раза меньше багов". Только теперь менеджерам придется не просто раздавать повышения, основываясь на своей интуиции и оценках, а еще и подгонять результаты аттестации под эту самую интуицию и оценки. Вы же не можете всерьез думать, что аттестация внесет объективность?
Это ты еще в некоторой степени романтически описал ситуацию. На деле будет гораздо хуже: сотрудники начнут максимизировать функционал, который отвечает за деньги. Вот несколько пунктов:
1. В случае большого коэффициента по багам упадет производительность и наоборот.
2. Как оценивать людей, которые пишут ядро системы и клепают формы? Одинаково — по числу строк кода? Или разводить разлапистую табличку, которую надо постоянно пересматривать?
3. Как оценивать пресейловую активность? По факту заключения контрактов? Тогда архитекторы будут напрямую зависеть от качества работы сейлов, что не есть правильно.
4. Есть известный факт: реальная производительность программистов в одной компании может различаться в 10 и больше раз. Вряд ли с зарплатой будет то же самое, что вызовет обиды, непонимание и уход лучших.
По-моему, ситуация очень проста: у топикстартера нет внутренней уверенности в том, что он поступает правильно с размером зарплаты, и пытается прикрыться цифрами. Это со временем пройдет, хотя в себе самом, несомненно, покопаться стоит.
Здравствуйте, itslave, Вы писали:
I>Я как бы и согласен, но это субъективизм. Вопрос появления недовольных "а почему мы с Васей работаем одинаково(ну я уверен что работаем одинаково), а он получает на 200 баксов больше?". Вот хотелось бы хоть какой нибудь формализации процесса.
1. Зачем делать размер зарплаты — публичным? Если Вася и Петя знают про зарплату друг друга — то вы уже попали. Не важно какая будет система — недовольные будут по-любому. Это просто психология — зависть, высокое самомнение, недооценка окружающих.
2. [Devil advocate mode]
Вы считаете что зарплата сотрудника должна зависить от его производительности? От пользы которую он приносит компании?
А должны ли по вашему, влиять на зарплату такие факторы как
-Возраст
-Наличие жены/детей
-Необходимость снимать жилье
-Наличие вакансий на аналогичные должности (по набору скилов) в других компаниях
?
[/Devil advocate mode]
Какое из двух утверждений вам ближе:
1) Я плачу зарплату сотрудникам чтобы удовлетворить их базовые потребности согласно пирамиде Маслоу (первые два уровня — физиология + безопасность).
2) Я плачу зарплату сотрудникам в соответствии с пользой, которую они мне (моей компании) приносят.
I>Ну уж не знаю, сам я до последнего был категорическим противником... Но наблюдаю за человеком которому на ~40% повысили зп по моей инициативе, с расчетом что перестанет ваньку валять и начнет работать. Он прямым текстом озвучивал недостаточную зп, ниже средней по рынку, как главный фактор из-за которого он не впахивает. I>После повышения зп производительность в общем и целом осталась на том же уровне, беседы мимо кассы. Что с ним делать?
Увольнять, конечно.
Принцип "сначала дайте мне кучу денег, а потом я начну работать" — не работает. Человек сначала должен доказать что он может лучше работать, и потом, когда руководство видит, что он действительно работает лучше (новая зона ответственности, новые обязанности, и т.п.) — только тогда ему повышают зарплату.
Есть люди которые живут с позицией "да за такую маленькую зарплату я не то что хорошо работать не буду, я просто начну слегка вредить!". Вот от таких (имхо) надо избавляться сразу
Здравствуйте, itslave, Вы писали:
I>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, itslave, Вы писали:
I>>>Может идея неверна в корне?
А>>Сто раз уже обсуждалось. Идея неверна в корне. I>Тут я не согласен. Скорее так: внедрение правильного процесса(из дискуссий на рсдн я понял что есть каг минимум 1 правильный процесс — psp/tsp) очень сильно удорожает разработку.
Правильный процесс не сильно удорожает разработку, но облегчает жизнь и наводит порядок.
К аттестациям это не имеет прямого отношения.
Особенности процесса и формальные метрики, которые вы посчитаете нужным мерить,
можно и нужно использовать при аттестации, но только как иллюстрации при беседе.
А>>Пусть непоссредственный начальник просто делает свою работу. А>>А именно, общается с подчиненными, отсележивает кто и как работает,
I>Я как бы и согласен, но это субъективизм. Вопрос появления недовольных "а почему мы с Васей работаем одинаково(ну я уверен что работаем одинаково), а он получает на 200 баксов больше?". Вот хотелось бы хоть какой нибудь формализации процесса.
Субъетивизм — это хорошо. Это означает, что человек берет на себя ответственность
и не боится работать с людьми
Но чтобы процедура аттестация была более прозрачной и понятной,
вы вправе определить и озвучить темы для разговора.
Например это могут быть следующие темы:
— профессиональные навыки (языки программирования, технологии, методики)
— продуктивность (качество работы, ответственность, упорство)
— гибкость и креативность
— инициативность (готовность помогать коллегам и подменять их, самостоятельность)
— коммуникативные навыки (языки, навыки в презенциях и умение передать идеи другим)
— конфликность и восприятие критики
— желание развиваться
— ...
Будет отлично, если сотрудник так же сможет высказать что он думет о начальстве.
Правда это получится не совсем аттестация, но пользы будет больше.
А>>P.S. Понижать зарплату — это демотивировать сотрудника и по сути потерять его. I>Ну уж не знаю, сам я до последнего был категорическим противником... Но наблюдаю за человеком которому на ~40% повысили зп по моей инициативе, с расчетом что перестанет ваньку валять и начнет работать. Он прямым текстом озвучивал недостаточную зп, ниже средней по рынку, как главный фактор из-за которого он не впахивает. I>После повышения зп производительность в общем и целом осталась на том же уровне, беседы мимо кассы. Что с ним делать?
Что делать? Делайте что хотите.
Можете его уволить. Можете понизить зарплату и тогда скорее он уволится сам.
Можете оставить как есть или даже еще повысить зарплату.
Вы начальник — вам и карты в руки.
Никакая формула/метрика/процесс не избавит вас от необходимости принимать решения и нести за них отвественность.
Если вы чувствуете, что это не для вас, то вы не на своем месте.
Здравствуйте, SkyDance, Вы писали:
SD>Подвожу краткий итог. Из ваших сообщений мне показалось, что вы хотите с помощью введения процесса аттестации сказать подчиненным "сидите и не высовывайтесь, все равно каждого из вас оценивает ваш начальник, только раньше он делал это наобум, а сейчас по науке". Это мотивации не добавляет, а вот расходы увеличивает. Если вашей целью является что-то другое — расскажите, пожалуйста, что именно. Только без экивоков вида "мы хотим объективной оценки пользы от сотрудника", это тема для "Священных Войн", а не для этого раздела.
Не совсем так. Я относительно недавно начальник, раньше с вопросами мотивации-денег сталкивался с другой стороны баррикад. И как оказывается, с этой стороны все видится ну просто совсем по иному, я себе представлял что разница будет существенно меньше.
В идеале хотелось бы научиться распознавать ситуацию недовольства зарплатой на ранних этапах и сразу же принимать решение. Но я понимаю что до этого уровня просветления мне еще предстоит долгий путь, и для начала бы хотелось бы научиться аргументированно отвечать на вопрос "хочу больше денег". Не, ну шашкой махать я умею, хотелось бы чтобы без ущерба для дела ет происходило.
Здравствуйте, RGB_Dart, Вы писали:
RGB>1. Зачем делать размер зарплаты — публичным? Если Вася и Петя знают про зарплату друг друга — то вы уже попали. Не важно какая будет система — недовольные будут по-любому. Это просто психология — зависть, высокое самомнение, недооценка окружающих.
За без малого 10 лет работы девелопером в 3х разных фирмах я ни разу не сталкивался с ситуацией когда чья то зп — тайна для коллег. Несмотря ни на какие подписанные бумажки, скорее раньше чем позже все всё узнают.
Здравствуйте, bkat, Вы писали:
B>Правильный процесс не сильно удорожает разработку, но облегчает жизнь и наводит порядок. B>К аттестациям это не имеет прямого отношения. B>Особенности процесса и формальные метрики, которые вы посчитаете нужным мерить, B>можно и нужно использовать при аттестации, но только как иллюстрации при беседе.
Согласен, но увы нам до этого далеко.
B>Будет отлично, если сотрудник так же сможет высказать что он думет о начальстве. B>Правда это получится не совсем аттестация, но пользы будет больше.
Вы не первый кто высказал идею о фидбеке и она мне нравится. Вопрос: как это сделать конструктивно и анонимно(боюсь что без анонимности народ будет бояться высказать что думает).
B>Что делать? Делайте что хотите. B>Можете его уволить. Можете понизить зарплату и тогда скорее он уволится сам. B>Можете оставить как есть или даже еще повысить зарплату. B>Вы начальник — вам и карты в руки. B>Никакая формула/метрика/процесс не избавит вас от необходимости принимать решения и нести за них отвественность. B>Если вы чувствуете, что это не для вас, то вы не на своем месте.
Да не хочется дров наломать по неопытности. Поэтому и советуюсь.
Здравствуйте, minorlogic, Вы писали:
M>Для начала озвучьте задачу которую вы хотете решить. Какого результата выхотите добиться ?
Чтобы работали больше и денег просили меньше. И чтобы оно все само собой было по формулам и объективно.
10.08.2011 20:05, itslave пишет:
> Думаем внедрить аттестацию сотрудников(программисты) и пересмотр з/п по > результатам аттестации. > Приблизительно идея следующая: > сделать тарифную сетку на 3-5 позиций. > раз в год проводить ревью всего сделанного сотрудником за год, и > соотвественно — его положение в тарифной сетке. Исходя из этого получаем > з/п.
Садитесь в кабинете некоей толпой начальников, приглашаете человека и
разговариваете с ним, обсуждаете его работу, договариваетесь об оплате
на следующие полгода.
> Основной вопрос в том как оценивать человека, какие метрики собирать. > Оно понятно что в идеальном варианте можно внедрить PSP/TSP и в методике > умные люди все уже просчиталии все коеффициенты подбили. > Но у нас нет возможности держать отдельного человека для сбора метрик, и > ведения статистики. Не говоря уже о том что собирать и какие > коеффициенты факторам вешать.
Вот и не делайте эту глупость. Во-первых, объективных метрик не
существует. Во-вторых, ваши сотрудники начнут работать на метрики, а не
на выпуск продукта. В-третьих, некоторые идеально подстроятся под ваши
метрики, другие (часто более грамотные) уволятся.
11.08.2011 0:42, itslave пишет:
> Ну уж не знаю, сам я до последнего был категорическим противником... Но > наблюдаю за человеком которому на ~40% повысили зп по моей инициативе, с > расчетом что перестанет ваньку валять и начнет работать. Он прямым > текстом озвучивал недостаточную зп, ниже средней по рынку, как главный > фактор из-за которого он не впахивает.
Бред какой-то. Таким образом вы стимулируете сотрудников работать хуже.
> После повышения зп производительность в общем и целом осталась на том же > уровне, беседы мимо кассы. Что с ним делать?
Уволить.
11.08.2011 11:31, itslave пишет:
> В идеале хотелось бы научиться распознавать ситуацию недовольства > зарплатой на ранних этапах и сразу же принимать решение. Но я понимаю > что до этого уровня просветления мне еще предстоит долгий путь, и для > начала бы хотелось бы научиться аргументированно отвечать на вопрос > "хочу больше денег". Не, ну шашкой махать я умею, хотелось бы чтобы без > ущерба для дела ет происходило.
А здесь общего решения не существует. К каждому человеку индивидуальных
подход. Я, например, без проблем некоторых без повышений и премий
оставлял и абсолютно честно и открыто объяснял человеку почему. Многие
исправлялись, некоторые увольнялись (и хорошо).
11.08.2011 11:34, itslave пишет:
> За без малого 10 лет работы девелопером в 3х разных фирмах я ни разу не > сталкивался с ситуацией когда чья то зп — тайна для коллег. Несмотря ни > на какие подписанные бумажки, скорее раньше чем позже все всё узнают.
Ну "наивные" манагеры верят в то, что это тайна и эту великую тайну
знают только они.
11.08.2011 9:46, RGB_Dart пишет:
> (новая зона ответственности, новые обязанности, и т.п.) — только тогда > ему повышают зарплату.
Я если человек просто четко выполняет свои обязанности и не ИБД, то что
делаете? Не повышаете?
Тогда ждите, что выполнять свои обязанности он будет хуже, но ощутите вы
это через некое длительное время на провалах перед заказчиками.
11.08.2011 10:07, bkat пишет:
> > Будет отлично, если сотрудник так же сможет высказать что он думет о > начальстве. > Правда это получится не совсем аттестация, но пользы будет больше.
Вот это очень скользкий момент. С ним надо аккуратнее. Для такого
эффективнее анонимная аттестация (снизу вверх). Ну а дальше уже
вышестоящим внимательно смотреть на результаты (бывает личная неприязнь,
а бывает, что действительно начальник "не приведи Господи")
11.08.2011 11:39, itslave пишет:
> B>можно и нужно использовать при аттестации, но только как иллюстрации > при беседе. > > Согласен, но увы нам до этого далеко.
Достаточно, если ты будешь отмечать где-то у себя "плохие" и "хорошие"
(с твоей точки зрения) действия подчиненных — это тебе поможет с
аргументацией. Запомни, память человека очень ненадежная штука, на нее
опасно полагаться.
> > Вы не первый кто высказал идею о фидбеке и она мне нравится. Вопрос: как > это сделать конструктивно и анонимно(боюсь что без анонимности народ > будет бояться высказать что думает).
В силу неопытности не лезь в это раньше времени.
> > Да не хочется дров наломать по неопытности. Поэтому и советуюсь.
Наломаешь так или иначе. Просто будь готов ответить за свои действия и
обосновать их.
Здравствуйте, itslave, Вы писали:
I>Здравствуйте, bkat, Вы писали:
B>>Правильный процесс не сильно удорожает разработку, но облегчает жизнь и наводит порядок. B>>К аттестациям это не имеет прямого отношения. B>>Особенности процесса и формальные метрики, которые вы посчитаете нужным мерить, B>>можно и нужно использовать при аттестации, но только как иллюстрации при беседе.
I>Согласен, но увы нам до этого далеко.
Вести беседу по заранее означенным темам проще, чем собирать метрики.
На самом деле просто не надо оценку людей делать на основе формальных метрик.
Метрики — это метрики, а люди — это люди.
B>>Будет отлично, если сотрудник так же сможет высказать что он думет о начальстве. B>>Правда это получится не совсем аттестация, но пользы будет больше. I>Вы не первый кто высказал идею о фидбеке и она мне нравится. Вопрос: как это сделать конструктивно и анонимно(боюсь что без анонимности народ будет бояться высказать что думает).
Сложный вопрос.
Если считаете что лучше анонимно, то делайте анонимно.
Анонимная анкета позволит грубо понять что есть недовольство
или выявить очевидные проблемы (печеньки не вкусные и освещение фиговое).
До сути можно добраться только общаясь с людьми.
У нас не анонимно. Проблем особых нету.
Фидбек — штука опциональная.
Кому есть что сказать, и кто хочет это сделать, у тех есть такая возможность.
Но выстроить такой уровень доверия чтобы люди говорили в открытую — это и в самом деле не просто.
Может действительно лучше начать с анонимных анкет.
Те, кто захотят в открытую, сделают это сами.
B>>Что делать? Делайте что хотите. B>>Можете его уволить. Можете понизить зарплату и тогда скорее он уволится сам. B>>Можете оставить как есть или даже еще повысить зарплату. B>>Вы начальник — вам и карты в руки. B>>Никакая формула/метрика/процесс не избавит вас от необходимости принимать решения и нести за них отвественность. B>>Если вы чувствуете, что это не для вас, то вы не на своем месте. I>Да не хочется дров наломать по неопытности. Поэтому и советуюсь.
Что-то конкретное сложно посоветовать, потому что мы не знаем деталей.
Что за человек, в чем проблемы и пр...
Рассказывать о деталях тут тоже не стоит.
Это все равно будет не то, что вы реально испытываете.
Здравствуйте, itslave, Вы писали:
I>Формировать конкретный набор пунктов из метрик?
В свое время думал над этим вопросом. Мысли следующие:
В конкретном проекте, если там не полный бардак, каждый из сотрудников прекрасно знает свой вклад в проект, а также сравнительную квалификацию себя и коллег.
Соответственно, нужно попросить каждого из команды, включая менеджера, отранжировать всех остальных членов команды по:
1) Технической грамотности;
2) Вкладу в проект;
3) Важности для проекта (потеря кого из команды будет наиболее болезненна);
Менеджера тоже б неплохо чтоб оценил народ. А далее обработать эти данные достаточно реально. Обычно эти данные прекрасно сходятся с мнением менеджера, и приблизительно все оценивают одинаково.
Увы, так никто никогда не делает, наверно есть какие то веские причины.
Здравствуйте, itslave, Вы писали:
I>Думаем внедрить аттестацию сотрудников(программисты) и пересмотр з/п по результатам аттестации. I>Но у нас нет возможности держать отдельного человека для сбора метрик, и ведения статистики. Не говоря уже о том что собирать и какие коеффициенты факторам вешать.
Имхо, если даже метрики собирать некому — лучше с этим не заморачиваться, объективной оценки все-равно не получится, т.к. она под большим вопросом даже и при наличии этих метрик...
I>Может идея неверна в корне? Как тогда организовать процесс "хочу больше денег"?
Может это и утопия, но мне кажется что нужно не делать з/п работников "коммерческой тайной", а наоборот пусть она будет общеизвестной и _фиксированной_ для каждой позиции. За каждый год работы в компании — надбавка в сколько-то процентов, только чтобы это было ощутимым плюсом, а не смех вызывало. И если человек хочет больше денег, но не через год, а прямо сейчас — только расширение круга обязанностей. Например первая ступень — "тупокодер на премодерации", вторая — "кодер на постмодерации", третья — "кодер + премодератор" и т.п., ну тут конечно сильно зависит от общего количества сотрудников, если их мало — пары уровней наверно хватит.
Вся атестация в этом случае — оценка на уровне "справляется/не справляется". Если не справляется — увольнение (ну или на ставку ниже), справляется — зарплата по ставке. И никаких "у тебя как-то не очень получается (с моей т.з., хотя я и не вникал), поэтому шиш а не повышение, но обязанности оставим"...
Ну и индексация в соответствии с инфляцией и ситуацией на рынке конечно.
Конечно отдельные люди будут уходить, но: 1. Кто-то всегда будет уходить. Если уходят слишком часто — нужно повышать _все_ ставки, а не "держать" отдельных людей, вызывая недовольство остальных. 2. Если человек видит, что з/п прибавляется по простым и понятным правилам (а не результатам "аттестации", проведенной непойми кем и как), вряд-ли он просто так уйдет на чуть большие деньги.
Вообще же, главная проблема всяких "аттестаций" в том, что они нацелены на _уменьшение_ ФОТ, а не на его увеличение, что закономерно вызывает отрицательную реакцию и нежелательную напряженность в коллективе... Вот скажите, вы бы стали внедрять "аттестацию", которая приведет к _росту_ ФОТ на 50%?
Здравствуйте, minorlogic, Вы писали:
M>Для начала озвучьте задачу которую вы хотете решить. Какого результата выхотите добиться ,
Минимальная текучка кадров, прогнозируемость результата. Ну главное, чтобы коллективе был здоровый климат.
Здравствуйте, Vzhyk, Вы писали:
V>Наломаешь так или иначе. Просто будь готов ответить за свои действия и V>обосновать их.
Не сомневаюсь
Но от ето обсуждение уже кучу дров существенно уменьшило. Пасибо усем!
Здравствуйте, itslave, Вы писали:
I>Здравствуйте, minorlogic, Вы писали:
M>>Для начала озвучьте задачу которую вы хотете решить. Какого результата выхотите добиться , I>Минимальная текучка кадров, прогнозируемость результата. Ну главное, чтобы коллективе был здоровый климат.
Тогда атестация к этому никакого отношения не имеет.
Здравствуйте, ObjectXplorer, Вы писали: OX>Вот скажите, вы бы стали внедрять "аттестацию", которая приведет к _росту_ ФОТ на 50%?
Та я только "за", все ж таки люди ответственней к работе относиться и меньше пальцы по собеседованиям бегать. В чем я вижу некислый выигрыш для проекта в целом. Хотя народ аргументированно доказывает что я неправ... в общем надо думать.
Тока вот почему-то думаю что мой начальник будет "слегка" недоволен такой арифметикой
Здравствуйте, itslave, Вы писали:
I>Здравствуйте, ObjectXplorer, Вы писали: OX>>Вот скажите, вы бы стали внедрять "аттестацию", которая приведет к _росту_ ФОТ на 50%? I>Та я только "за", все ж таки люди ответственней к работе относиться и меньше пальцы по собеседованиям бегать. В чем я вижу некислый выигрыш для проекта в целом. Хотя народ аргументированно доказывает что я неправ... в общем надо думать. I>Тока вот почему-то думаю что мой начальник будет "слегка" недоволен такой арифметикой
Вот-вот... На одной из прошлых работ что-то подобное пытались внедрить, так получалось, что в лучшем случае можно получить на 50% больше з/п, вот только для этого надо было по всем пунктам 10 из 10 набрать, а составлены они были так, что на практике дай бог на ту же цифру выити, если не меньше... А на реальное повышение, да еще и "выравнивание" по верхнему уровню руководство не пойдет, т.к. уменьшение текучки и улучшение климата — оно где-то в будущем, а денежки, они здесь и сейчас, живые...
Так что я бы на месте сотрудника вашей компании (не имею ничего против именно вашей, просто сейчас речь о ней) рассматривал это как тревожный звоночек и начал подыскивать новую работу... А как показывает практика — смена работы один из лучших способов получить максимальную прибавку, т.е. вы рискуете растерять наиболее ценных сотрудников (которые быстро работу найдут) еще на этапе внедрения...
Правда работать кардинально лучше народ тоже за повышение не станет, выгода тут только в долгосрочной перспективе за счет сохранения специфических знаний/навыков в компании и устранении "негативных настроений", распространяемых уходящими сотрудниками. С нашей с вами точки зрения это замечательно, но возможно у руководства другие планы и "лучше синица в руках"... С т.з. бизнеса такой подход тоже имеет право на жизнь, к сожалению.
nvb>Это ты еще в некоторой степени романтически описал ситуацию. На деле будет гораздо хуже: сотрудники начнут максимизировать функционал, который отвечает за деньги.
Я наблюдал процесс внедрения аттестации в компании ориентировочно из 900 человек. По крайней мере в первые два года никакой тенденции с максимизации "аттестуемого" функционала не появлялось.
Кроме того, напомню, что аттестация — это не процесс перевода одних цифр (кол-во строк кода, кол-во багов в системе) в другие (грейд/левел, зарплата). Аттестация обычно включает:
1. Со стороны работника — "хвастовство" тем, что он за этот аттестационный период сделал.
2. Со стороны менеджера — согласен ли он с хвастовством, и правду ли вообще работник написал.
3. (100% лукавство) со обеих сторон — некий такой размытый план "что я буду делать в следующем аттестационном периоде". Почему лукавство? Потому что работник крайне редко распоряжается своей судьбой в корпорации, на что его бросят — то он и вынужден будет делать. В итоге этот пункт превращается в полнейший фарс.
Далее, на основании всего это обычно делается оценка, какова была производительность сотрудника (иногда по нескольким пунктам): выше среднего, средняя, ниже среднего. В некоторых продвинутых системах аттестации также вводится вторая шкала — ощущенческая, со стороны менеджера: "сотрудник сделал больше, чем я от него ждал", "сотрудник сделал ровно столько, сколько я ждал", "сотрудник сделал меньше, чем я ожидал". По комбинации оценок этих двух шкал и предлагаются дальнейшие действия (например, если сотрудник сделал меньше, чем ожидалось, да еще и ниже среднего — зарплату ему не поднимают, и вообще думают, а может, уволить его).
Короче говоря. Какой бы сложной ни была система аттестации, всё это видимость и дымовая завеса. Которая к тому же отнимает много времени у менеджеров, т.к. нужно свои личные оценки подгонять под все эти аттестационные формы.
nvb>По-моему, ситуация очень проста: у топикстартера нет внутренней уверенности в том, что он поступает правильно с размером зарплаты, и пытается прикрыться цифрами. Это со временем пройдет, хотя в себе самом, несомненно, покопаться стоит.
Полностью с вами согласен. Не уверен только насчет "пройдет". У меня создалось впечатление, будто менеджмент в компании автора хочет взять и переложить ответственность за назначение зарплаты "в никуда". Т.е. сделать вид, что это как бы и не начальство вовсе зарплаты определяет. Я сомневаюсь, что работников ИТ можно так легко обмануть.
RGB>Принцип "сначала дайте мне кучу денег, а потом я начну работать" — не работает. Человек сначала должен доказать что он может лучше работать, и потом, когда руководство видит, что он действительно работает лучше (новая зона ответственности, новые обязанности, и т.п.) — только тогда ему повышают зарплату.
К сожалению, этот же принцип "сперва добейся" (С) слишком часто злоупотреблялся (тут вообще лучше английское слово abused, но в русском языке его эквивалент несет чуть-чуть иной смысловой оттенок). Работники теперь тоже не хотят работать за обещания — "вот ты сначала все сделай, а потом мы посмотрим, и, наверное, повысим зарплату". Это прокатывает с недостаточно опытной молодежью (чего греха таить, самого так раза три прокатывали, причем последний раз довольно жестко — и ведь уже за 25 лет мне было).
Лучше, чтобы события "повышение" и "добавление нагрузки" происходили одновременно. Напоминаю — нагрузка должна приходить из _другой_ области деятельности. Потому что пилить золотую гирю тоже надоедает -> производительность пиления падает.
I>В идеале хотелось бы научиться распознавать ситуацию недовольства зарплатой на ранних этапах и сразу же принимать решение. Но я понимаю что до этого уровня просветления мне еще предстоит долгий путь, и для начала бы хотелось бы научиться аргументированно отвечать на вопрос "хочу больше денег". Не, ну шашкой махать я умею, хотелось бы чтобы без ущерба для дела ет происходило.
О, вот это уже конструктивно.
Аттестация как инструмент не даст вам возможности почувствовать недовольство зарплатой. Скажу, возможно, крамольную мысль — недовольство зарплатой наступает в тот момент, когда разработчик осознает, что Петя, который только что поменял место работы, стал получать на 15% больше, — потому что рынок всегда растет (как минимум вслед за инфляцией), а зарплаты в компании стараются удерживать на уровне, который был по приходу сотрудника.
Аргументированно ответить на вопрос "хочу больше денег"? Ответить — или отказать? Можно же аргументированно повысить зарплату. А можно аргументированно отказать. Вообще, признаться, я не очень понимаю, отчего вы задаете этот вопрос. Если у вас есть контроль за зарплатой сотрудников (суть вы сами решаете свой бюджет), у вас есть финансовый поток, вы знаете, сколько вы человеку недоплачиваете — вы можете все решить самостоятельно. А если у вас нет контроля за зарплатой (и вы пойдете к какому-то еще менеджеру за разрешением на повышение зарплаты работника) — тогда ваши страдания вообще не имеют смысла, вы ничего не решаете и отказывать можете со словами "денег нет".
I>Вы не первый кто высказал идею о фидбеке и она мне нравится. Вопрос: как это сделать конструктивно и анонимно(боюсь что без анонимности народ будет бояться высказать что думает).
Тут стоит понимать, что никакой анонимности быть не может. Во-первых, потому, что рабочие группы у конкретного менеджера обычно довольно узкие (3, ну даже пусть 10 непосредственных подчиненных). "Раскидать" отзывы по людям — проще простого. Во-вторых, у каждого конкретного сотрудника обычно свои обиды на начальника. Если вдруг одинаковая обида проявилась сразу у нескольких подчиненных — это повод для немедленного расставания с таким начальником, настроить против себя значительную часть команды — признак никудышного менеджера. А если обиды все разные — начальник, опять же, легко догадается, где чья.
Далее, в анонимных посланиях люди зачастую могут "в сердцах" сказать то, о чем они потом раскаются и пожалеют. А вот высказать что-то под своим именем — это уже очень серьезно, т.к. если человек решился открыто высказаться против своего менеджера — значит, уже _РЕАЛЬНО_ наболело и молчать об это нельзя. Опять же плохой признак для менеджера.
Про конструктивность фидбека разговор отдельный. Я знаю такие варианты:
1. "Прозрачное руководство". Когда менеджер не занимается "фильтрацией информации" и прочим сокрытием важных для работников деталей. В этом случае работники обычно в курсе сложностей у оного менеджера и конструктивность фидбека будет изначально определяться моральным обликом работников. К сожалению, за 12 лет в Москве я лишь однажды встретил сравнительно прозначный подход к руководство. (Как оффтопик, отмечу — именно в той компании собрались превосходные команды как с профессиональной точки зрения, так и просто с человеческой).
2. "Менеджер-файрволл" (aka "односторонний передаст"). Существенной частью забот менеджера является тщательная фильтрация всей информации, как поступающей сверху (чтобы не дай бог работники не узнали о том, что их проект скоро закрывают), так и снизу (нехорошо, чтобы начальство вдруг узнало о проблемах с моралью в команде). В этом случае конструктивного фидбека от работников быть не может, т.к. каналы коммуникаций перекрыты менеджером.
3. "Менеджер из команды" (aka "вратарь-удила"). Возможно только в случае, если менеджер не был откуда-то назначен, а получился сам собой из одного из членов команды. Встречается в основном там, где менеджер является не привилегированной должностью, а, скорее, неким способом для команды избавиться от не самых интересных вопросов (снабжения и т.п.). Любой фидбек будет конструктивен.
OX>Вообще же, главная проблема всяких "аттестаций" в том, что они нацелены на _уменьшение_ ФОТ, а не на его увеличение, что закономерно вызывает отрицательную реакцию и нежелательную напряженность в коллективе... Вот скажите, вы бы стали внедрять "аттестацию", которая приведет к _росту_ ФОТ на 50%?
Совершенно верно.
Но, как и для любого другого изменения, затраты на внедрение аттестации могут превышать экономию на ФОТ. Поэтому автор темы поступил совершенно правильно, сначала решив посчитать, а стоит ли овчинка выделки.
OX> вы рискуете растерять наиболее ценных сотрудников (которые быстро работу найдут) еще на этапе внедрения...
Это крайне маловероятно. Ценные сотрудники отлично понимают свою важность (порой незаменимость) в компании. Они вообще не парятся на тему аттестации. Так, поворчат чутка, а потом просто пойдут к начальство требовать прибавки в соответствии с рынком. И если им начнут впаривать "мы не можем, потому что у нас порядки, и только на аттестации мы будем повышать", начальство может ждать неприятный сюрприз с полным провалом "отмазочной аттестации"
Здравствуйте, SkyDance, Вы писали:
SD>К сожалению, этот же принцип "сперва добейся" (С) слишком часто злоупотреблялся (тут вообще лучше английское слово abused, но в русском языке его эквивалент несет чуть-чуть иной смысловой оттенок). Работники теперь тоже не хотят работать за обещания — "вот ты сначала все сделай, а потом мы посмотрим, и, наверное, повысим зарплату". Это прокатывает с недостаточно опытной молодежью (чего греха таить, самого так раза три прокатывали, причем последний раз довольно жестко — и ведь уже за 25 лет мне было).
Недавно так же "вляпался" — и тоже за 25, точнее даже за 26 И ведь и сделал все, и о повышении заранее договорились, а год спустя руководство сделало круглые глаза и со словами "у тебя и так выше среднего по региону" предложило +3 тысячи рублей максимум. Но с другой стороны оно и к лучшему, незачем в таких компаниях работать
Здравствуйте, SkyDance, Вы писали:
OX>> вы рискуете растерять наиболее ценных сотрудников (которые быстро работу найдут) еще на этапе внедрения...
SD>Это крайне маловероятно. Ценные сотрудники отлично понимают свою важность (порой незаменимость) в компании. Они вообще не парятся на тему аттестации. Так, поворчат чутка, а потом просто пойдут к начальство требовать прибавки в соответствии с рынком. И если им начнут впаривать "мы не можем, потому что у нас порядки, и только на аттестации мы будем повышать", начальство может ждать неприятный сюрприз с полным провалом "отмазочной аттестации"
Ну как же — сами говорите, либо аттестация превратится в профанацию либо — неприятный сюрприз, ничего хорошего в любом случае не выходит... Ну не затевать же это все только ради того, чтобы вчерашних студентов гнобить и зарплату им "обоснованно" не прибавлять — молодежь нынче амбициозная, ее не запугать
Здравствуйте, SkyDance, Вы писали:
SD>Это крайне маловероятно. Ценные сотрудники отлично понимают свою важность (порой незаменимость) в компании. Они вообще не парятся на тему аттестации. Так, поворчат чутка, а потом просто пойдут к начальство требовать прибавки в соответствии с рынком. И если им начнут впаривать "мы не можем, потому что у нас порядки, и только на аттестации мы будем повышать", начальство может ждать неприятный сюрприз с полным провалом "отмазочной аттестации"
Это как раз таки наиболее вероятно.
Аттестация — железный неповоротливый бюрократический механизм, которым в первую очередь раздавит и этих "незаменимых специалистов" и их начальника (который не сможет ничего сделать).
То, что сотрудники ощущают собственную важность и незаменимость, не обязательно кореллирует с тем, как ощущает верхнее руководство, да и начальник, который методики внедрил или набор критериев разработал — тоже сильно вряд ли захочет публично признавать свою неправоту.
OX>Ну как же — сами говорите, либо аттестация превратится в профанацию либо — неприятный сюрприз, ничего хорошего в любом случае не выходит... Ну не затевать же это все только ради того, чтобы вчерашних студентов гнобить и зарплату им "обоснованно" не прибавлять — молодежь нынче амбициозная, ее не запугать
Целью введения аттестации может быть расширение каналов обратной связи, т.е. хоть какое-то налаживание коммуникаций между работниками и начальством за пределом непосредственного.
Также целью введения аттестации может быть продвижение нового проекта внутри компании (или, например, привлечение сторонней организации, которая заработает немаленькие деньги на реализации процесса аттестации — и по удивительному совпадению основным бенефициаром этой самой сторонней организации будет жена того топ-менеджера, который наиболее рьяно продвигает аттестацию).
Не менее важным побочным эффектом может стать устранение бардака в зарплатных ведомостях, когда каждый работник получает свою зарплату, непохожу на других. В бухгалтерии намного удобнее 3-4 типовых зарплаты, чем считать сотню разных. Ведение бюджета также _очень_ сильно упрощается, если подавляющее большинство повышений зарплат будет осуществляться строго 1-2 раза в год.
Все эти эффекты (на взгляд работника — побочные) вполне могут окупить расходы на внедрение аттестации. Говорю же, с кондачка такие вопросы не решаются — все надо посчитать.
M>Аттестация — железный неповоротливый бюрократический механизм, которым в первую очередь раздавит и этих "незаменимых специалистов" и их начальника (который не сможет ничего сделать). M>То, что сотрудники ощущают собственную важность и незаменимость, не обязательно кореллирует с тем, как ощущает верхнее руководство, да и начальник, который методики внедрил или набор критериев разработал — тоже сильно вряд ли захочет публично признавать свою неправоту.
Вы недооцениваете умственный потенциал как "начальника", так и "верхнего руководства". Обычно они не стараются рубить сук, на котором сидят. Если же вдруг такое начинает происходить — значит, компании и так наступает кердык, независимо от аттестации. В моей практике такого не припомню, но, может, коллеги поделятся опытом.
12.08.2011 6:32, ObjectXplorer пишет:
> > Недавно так же "вляпался" — и тоже за 25, точнее даже за 26 И ведь и > сделал все, и о повышении заранее договорились, а год спустя руководство > сделало круглые глаза и со словами "у тебя и так выше среднего по > региону" предложило +3 тысячи рублей максимум. Но с другой стороны оно и > к лучшему, незачем в таких компаниях работать
Ну вообще-то верить словам начальства в русских конторах нельзя по
определению. Я за почти 20 лет работы не видел ни одного русского
начальника, который бы не врал подчиненным.
12.08.2011 3:17, SkyDance пишет:
> А вот высказать что-то под своим > именем — это уже очень серьезно, т.к. если человек решился открыто > высказаться против своего менеджера — значит, уже _РЕАЛЬНО_ наболело и > молчать об это нельзя. Опять же плохой признак для менеджера.
В этой ситуации лучше заявление на стол, а не воевать с ветряными
мельницами.
12.08.2011 8:37, SkyDance пишет:
> > Вы недооцениваете умственный потенциал как "начальника", так и "верхнего > руководства". В моей практике такого не припомню, > но, может, коллеги поделятся опытом.
Значит ты просто мало различных начальников видел.
Здравствуйте, Vzhyk, Вы писали:
>> (новая зона ответственности, новые обязанности, и т.п.) — только тогда >> ему повышают зарплату. V>Я если человек просто четко выполняет свои обязанности и не ИБД, то что V>делаете? Не повышаете?
Я в общем-то бюджетами не распоряжаюсь, но я бы всем таким "застывшим в развитии" просто индексировал зарплату раз в год — на размер инфляции.
В компании где я работаю так и проиходит.
V>Тогда ждите, что выполнять свои обязанности он будет хуже, но ощутите вы V>это через некое длительное время на провалах перед заказчиками.
Это довольно странное предположение. Разработчики с которыми я работаю не просто скрепки на конвеере фигачат. Разработка приложений — довольно увлекательное занятие. В каждом проекте свои оригинальные требования, и реализовывать их можно по-разному. Если есть ощущение, что кому-то надоело заниматься текущим проектом — можно слегка перетасовать команды. Новый проект практически всегда повышает мотивацию сотрудника (не будем рассматривать случаи поддержки адского legacy-кода).
Здравствуйте, SkyDance, Вы писали:
RGB>>Принцип "сначала дайте мне кучу денег, а потом я начну работать" — не работает. Человек сначала должен доказать что он может лучше работать, и потом, когда руководство видит, что он действительно работает лучше (новая зона ответственности, новые обязанности, и т.п.) — только тогда ему повышают зарплату.
SD>К сожалению, этот же принцип "сперва добейся" (С) слишком часто злоупотреблялся (тут вообще лучше английское слово abused, но в русском языке его эквивалент несет чуть-чуть иной смысловой оттенок). Работники теперь тоже не хотят работать за обещания — "вот ты сначала все сделай, а потом мы посмотрим, и, наверное, повысим зарплату". Это прокатывает с недостаточно опытной молодежью (чего греха таить, самого так раза три прокатывали, причем последний раз довольно жестко — и ведь уже за 25 лет мне было).
Тут есть нюанс. Если повысить зарплату одновременно с введением новых обязаностей / ответственности, то не понятно что делать, если человек не справляется с новыми задачами (хороший солдат — это не всегда хороший сержант). Если обратно уменьшить з/п (и убрать новые обязанности) — то человек может уволиться (понижение з/п — чудовищный демотиватор). А я говорю про определенный "испытательный срок". Например — "Вася, раз ты так хочешь — мы назначаем тебя тим-лидом в этой группе. Через месяц мы посмотрим как у тебя получается, и если поймем, что ты справляешься (и сам не передумаешь) повысим тебе з/п на столько-то".
Но, вообще говоря, гораздо более распространена ситуация, когда человек сам берет на себя доп. обязанности / ответственность (например, становится неформальным тим-лидом) — и спустя некоторое время общается с руководством на тему повышения з/п (изменения должности). Это самый выигрышный вариант. Руководство уже видит результаты, и способно дать аргументированный ответ.
12.08.2011 12:45, RGB_Dart пишет:
>> > (новая зона ответственности, новые обязанности, и т.п.) — только тогда >> > ему повышают зарплату.
Меня смутило это предложение.
> V>Я если человек просто четко выполняет свои обязанности и не ИБД, то что > V>делаете? Не повышаете? > Я в общем-то бюджетами не распоряжаюсь, но я бы всем таким "застывшим в > развитии" просто индексировал зарплату раз в год — на размер инфляции. > В компании где я работаю так и проиходит.
Круто. Лично я видел таких компаний 1 на 10 (и все они были не
русскими/белорусскими). Обычно надо идти и начальству "яйца в дверях
зажимать" и то будет долго стрелки друг на друга переводить.
> > V>Тогда ждите, что выполнять свои обязанности он будет хуже, но ощутите вы > V>это через некое длительное время на провалах перед заказчиками. > Это довольно странное предположение. Разработчики с которыми я работаю > не просто скрепки на конвеере фигачат. Разработка приложений — довольно > увлекательное занятие. В каждом проекте свои оригинальные требования, и > реализовывать их можно по-разному. Если есть ощущение, что кому-то > надоело заниматься текущим проектом — можно слегка перетасовать команды. > Новый проект практически всегда повышает мотивацию сотрудника (не будем > рассматривать случаи поддержки адского legacy-кода).
+1
Здравствуйте, vmpire, Вы писали:
V>Или недозагруженный исполнитель, у которого есть на это время
У вас в компании отношение к сотрудникам как к пони в шахтах?! Угля 3 тонны не вытащил — отстрел?
V>Или "мастер брать мало простых задач", быстро их делать и в свободное время заниматься тем, что интересно
У меня в команде никто "не берет" задания. Я раздаю задания. Мне собственно плевать маленькая задача/большая — главное сделать быстро и качественно. Если в результате у меня на руках не только выполненная работа, но еще и инструмент, которым остальные легко могут пользоваться, то для меня это существенный показатель. Быстрота и простота решения зависят не только от того насколько программист хорошо умеет писать и думать, но и насколько у него широкий кругозор, как быстро он осваивает новые инструменты и библиотеки. У меня, например, есть контрагент — кандидат технических наук, неплохой программист, теоретик. Но, блин, любит деать велосипеды. Приносит код — 10000 строк, половина — операции с матрицами, преобразования Фурье, Z и т.п. Ладно бы оптимизировал под процессор или под GPU, ну или что-нить неординарное. Ни фига, делает стандартные вещи, которые найти пачками в сторонних библиотеках. Ну и зачем мне это гора кода, которая еще не факт, что везде правильно работает?
Здравствуйте, itslave, Вы писали:
I>Да, но насколько он хороший исполнитель? Он лучше соседа Васи, за которым тоже почти не надо переделывать? Так уж получается что у всех кто делает работу в срок должна быть одинаковая зп, вне зависимости от обьемов и сложности работы.
Да должна быть одинаковая ЗП. Потому что работники НЕ ДОЛЖНЫ выбирать себе работу. Вы должны им ее давать, а если так то они не виноваты в том, что одинаково сложной работы для всех нет.
I>Ну ка ни крути обьективней чем "делают вовремя что почти переделок не требуется".
А вот нифига. Допустим один написал за день 1000 строк, другой 200 строк. Но первый писал на С++ без использования stl/boost, а второй с использованием stl/boost. В итоге по функциональности 200 строк делают 1000 строк. Или допустим программа первого выполняется в два раза быстрее второго. Что это значит? Да ничего — алгоритмы то разные и функции разные. Один выполняет один запрос к БД, другой 100. Так что... дифференцировать ЗП должна должность. Если вы считаете, что программист дорос до очередной ступени — повышайте в должности.
Здравствуйте, itslave, Вы писали:
I>Основной вопрос в том как оценивать человека, какие метрики собирать. Оно понятно что в идеальном варианте можно внедрить PSP/TSP и в методике умные люди все уже просчиталии все коеффициенты подбили.
В PSP/TSP для особо одаренных явно запрещено использование персональных метрик для подобных целей. Персональные метрики в PSP/TSP являются частными данными, и менеджеру недоступны. Менеджер видит только агрегатные метрики по команде.
Причина в том, что при попытке завязать оценки эффективности на метрики, метрики теряют актуальность, ибо программисты начнут подкручивать метрики, а не писать нормальный код. И все PSP/TSP вместе с метриками сразу пойдет нафиг.
>> высказаться против своего менеджера — значит, уже _РЕАЛЬНО_ наболело и >> молчать об это нельзя. Опять же плохой признак для менеджера. V>В этой ситуации лучше заявление на стол, а не воевать с ветряными V>мельницами.
Иногда, знаете ли, ну очень хочется не бросать проект, в который вложено так много труда и сил. Не знаю, как вы, но лично мне психологически трудно уходить. Оосбенно в околорелизное время.
RGB>Тут есть нюанс. Если повысить зарплату одновременно с введением новых обязаностей / ответственности, то не понятно что делать, если человек не справляется с новыми задачами (хороший солдат — это не всегда хороший сержант). Если обратно уменьшить з/п (и убрать новые обязанности) — то человек может уволиться (понижение з/п — чудовищный демотиватор). А я говорю про определенный "испытательный срок". Например — "Вася, раз ты так хочешь — мы назначаем тебя тим-лидом в этой группе. Через месяц мы посмотрим как у тебя получается, и если поймем, что ты справляешься (и сам не передумаешь) повысим тебе з/п на столько-то".
Видите ли, в вашем варианте ("мы даем тебе новые обязанности, ты с ними справляешься, мы повышаем зарплату") наблюдения показывают следующую картину. Человек с энтузиазмом начинает заниматься работой. И даже добивается некоторых успехов. Заводит речь "так что там насчет денег-то". А денег-то нет... ведь если бы они были, можно было бы ему и без экивоков поднять зарплату. Демотивация вида "обещал и не женился" ничуть не мЕньшая, чем от понижения зарплаты (т.к. чел-то авансом уже поработал, — считай, зарплату ему не просто понизили, а еще и бесплатно на нем поездили).
Возможен вариант этой схемы: "да, у тебя начало получаться, вот твоё повышение, аж на 10%, это вдвое больше среднего индексационного повышения по конторе!"
А инфляция-то 20%.
Далее. Кто будет оценивать, как сотрудник справляется с новыми обязанностями? А как будет оценивать? Формально? Через аттестации? Но формальный подход вообще не дает разрешения человеку "левела 60" заниматься обязанностями "левела 61", т.е. надо СНАЧАЛА повысить в левеле (и в з/п тоже), потом давать доступы и обязанности.
Если оценивать традиционно (т.е. по принципу "начальнику Вася нравится, а Петя нет"), то тут еще проще — Вася все равно не получит достойного повышения. Потому что начальнику нравится Петя.
Вот такая диалектика.
15.08.2011 2:29, SkyDance пишет:
> > Иногда, знаете ли, ну очень хочется не бросать проект, в который вложено > так много труда и сил. Не знаю, как вы, но лично мне психологически > трудно уходить.
Знаю. Поэтому вместо борьбы с ветряными мельницами, лучше заниматься
только тем, что нравиться и не усложнять себе жизнь (бредом на всяких
аттестациях).
Здравствуйте, morm, Вы писали:
V>>Или недозагруженный исполнитель, у которого есть на это время M>У вас в компании отношение к сотрудникам как к пони в шахтах?! Угля 3 тонны не вытащил — отстрел?
Нет, у нас другая проблема. Есть два человека одинаковой (предположим) квалификации. Один загружен на проекте на 100%, другой на 50.
Впторой в свободное время делает полезные вещи для других (что хорошо и правильно).
Но что видно сверху? Первый — просто делает своё дело. Второй — делает своё дело и ещё много полезных вещей.
Угадайте, кому первому повысят зарплату?
V>>Или "мастер брать мало простых задач", быстро их делать и в свободное время заниматься тем, что интересно M>У меня в команде никто "не берет" задания. Я раздаю задания. Мне собственно плевать маленькая задача/большая — главное сделать быстро и качественно. Если в результате у меня на руках не только выполненная работа, но еще и инструмент, которым остальные легко могут пользоваться, то для меня это существенный показатель. Быстрота и простота решения зависят не только от того насколько программист хорошо умеет писать и думать, но и насколько у него широкий кругозор, как быстро он осваивает новые инструменты и библиотеки. У меня, например, есть контрагент — кандидат технических наук, неплохой программист, теоретик. Но, блин, любит деать велосипеды. Приносит код — 10000 строк, половина — операции с матрицами, преобразования Фурье, Z и т.п. Ладно бы оптимизировал под процессор или под GPU, ну или что-нить неординарное. Ни фига, делает стандартные вещи, которые найти пачками в сторонних библиотеках. Ну и зачем мне это гора кода, которая еще не факт, что везде правильно работает?
Я такого тоже видел. Писал стандартные списки под предлогом "я не знаю, как там устроены внутри стандартные, а в моих всё на виду"
SD>Видите ли, в вашем варианте ("мы даем тебе новые обязанности, ты с ними справляешься, мы повышаем зарплату") наблюдения показывают следующую картину. Человек с энтузиазмом начинает заниматься работой. И даже добивается некоторых успехов. Заводит речь "так что там насчет денег-то". А денег-то нет... ведь если бы они были, можно было бы ему и без экивоков поднять зарплату. Демотивация вида "обещал и не женился" ничуть не мЕньшая, чем от понижения зарплаты (т.к. чел-то авансом уже поработал, — считай, зарплату ему не просто понизили, а еще и бесплатно на нем поездили).
На мой взгляд, в вашем примере проблема в отношениях между программистом и начальником. Если руководство "обещает и не женится" — нужно менять себе руководство. Никакими хитрыми правилами / метриками / регламентами вы проблему доверия не решите.
SD>Далее. Кто будет оценивать, как сотрудник справляется с новыми обязанностями? А как будет оценивать? Формально? Через аттестации?
Вы хотите получить математический алгоритм для оценки того как работник справляется с обязанностями? Ну, можно, конечно запариться, но зачем? Ваш руководитель не способен адекватно оценить — кто справляется с работой а кто нет? И вы сами не можете его переубедить? А зачем вы на него работаете тогда?
Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, morm, Вы писали:
V>>>Или недозагруженный исполнитель, у которого есть на это время M>>У вас в компании отношение к сотрудникам как к пони в шахтах?! Угля 3 тонны не вытащил — отстрел? V>Нет, у нас другая проблема. Есть два человека одинаковой (предположим) квалификации. Один загружен на проекте на 100%, другой на 50. V>Впторой в свободное время делает полезные вещи для других (что хорошо и правильно). V>Но что видно сверху? Первый — просто делает своё дело. Второй — делает своё дело и ещё много полезных вещей. V>Угадайте, кому первому повысят зарплату?
Что мешает загруженному на 100% делать так, чтобы попутно создавались инструменты для других?
RGB>На мой взгляд, в вашем примере проблема в отношениях между программистом и начальником. Если руководство "обещает и не женится" — нужно менять себе руководство. Никакими хитрыми правилами / метриками / регламентами вы проблему доверия не решите.
Насколько я понимаю, в первом посте этого треда как раз и обсуждается, удастся ли решить (или хотя бы отодвинуть импичмент начальника ) с помощью введения аттестации. По крайней мере именно такой подтекст прозвучал.
RGB>Вы хотите получить математический алгоритм для оценки того как работник справляется с обязанностями? Ну, можно, конечно запариться, но зачем? Ваш руководитель не способен адекватно оценить — кто справляется с работой а кто нет? И вы сами не можете его переубедить? А зачем вы на него работаете тогда?
Я — нет. Я уже объяснял, как на мой взгляд должна быть введена аттестация. И для чего конкретно: не для решения проблем вида "начальника задалбывают нытьем подчиненные, которым не доплачивают". А для уменьшения бардака в бухгалтерии, и для более простого и точного прогнозирования бюджета. Таки проще, когда з/п меняются не чаще, чем раз в полгода.
Но вот то, что руководители не способы адекватно оценить, кто и как справляется с работой — это я видел в Москве сплошь и рядом. Почти в любой конторе. Были исключения (вспоминаю дважды — одно в Агаве, одно в Касперском).
Re: Аттестация сотрудников
От:
Аноним
Дата:
16.08.11 07:09
Оценка:
Здравствуйте, itslave, Вы писали:
I>Думаем внедрить аттестацию сотрудников(программисты) и пересмотр з/п по результатам аттестации.
Зарплата зависит от соотношения спроса и предложения на рынке труда. У нас капитализм (чахлый, но все же). А вы тут со своим совком.
Если работник по результатам вашей аттестации будет получать меньше, чем ему предложили бы в другом месте, он от вас свалит, и всего делов. Даже если он простой пэхэпэшник и не знает, сколько бит в байте.
Здравствуйте, morm, Вы писали:
V>>>>Или недозагруженный исполнитель, у которого есть на это время M>>>У вас в компании отношение к сотрудникам как к пони в шахтах?! Угля 3 тонны не вытащил — отстрел? V>>Нет, у нас другая проблема. Есть два человека одинаковой (предположим) квалификации. Один загружен на проекте на 100%, другой на 50. V>>Впторой в свободное время делает полезные вещи для других (что хорошо и правильно). V>>Но что видно сверху? Первый — просто делает своё дело. Второй — делает своё дело и ещё много полезных вещей. V>>Угадайте, кому первому повысят зарплату?
M>Что мешает загруженному на 100% делать так, чтобы попутно создавались инструменты для других?
Отсутствие на это времени. Он же не враг себе, чтобы загружаться на 150% из за бескорыстной любви к другим.
Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, morm, Вы писали:
V>>>>>Или недозагруженный исполнитель, у которого есть на это время M>>>>У вас в компании отношение к сотрудникам как к пони в шахтах?! Угля 3 тонны не вытащил — отстрел? V>>>Нет, у нас другая проблема. Есть два человека одинаковой (предположим) квалификации. Один загружен на проекте на 100%, другой на 50. V>>>Впторой в свободное время делает полезные вещи для других (что хорошо и правильно). V>>>Но что видно сверху? Первый — просто делает своё дело. Второй — делает своё дело и ещё много полезных вещей. V>>>Угадайте, кому первому повысят зарплату?
M>>Что мешает загруженному на 100% делать так, чтобы попутно создавались инструменты для других? V>Отсутствие на это времени. Он же не враг себе, чтобы загружаться на 150% из за бескорыстной любви к другим.
У меня стиль работы такой: я сначала пишу для себя инструмент, тестирую, потом задача решается за 5 минут. Своих сотрудников я ориентирую делать также. Плюсы исключительно для всех — через какое-то время багаж инструментов позволяет решать широкий круг задач и аврала я уже не помню последние года 3. А насчет 150% — чего вдруг? Это обычная работа, решай задачу через правильное проектирование, через разделение логики, представления, хранения данных и т.п. и все получится, а в конце работы ты будешь удивлен как легко и просто все получается.
M>>>Что мешает загруженному на 100% делать так, чтобы попутно создавались инструменты для других? V>>Отсутствие на это времени. Он же не враг себе, чтобы загружаться на 150% из за бескорыстной любви к другим.
M>У меня стиль работы такой: я сначала пишу для себя инструмент, тестирую, потом задача решается за 5 минут. Своих сотрудников я ориентирую делать также.
Какой инструмент вы напишете, к примеру, для задачи "создать новый репорт" или "сделать новую форму в приложении"? Свой генератор форм репортов или генератор приложения? А чтобы уточнить спецификацию напишете "уточнятор спецификаций"?
M>Плюсы исключительно для всех — через какое-то время багаж инструментов позволяет решать широкий круг задач и аврала я уже не помню последние года 3.
100% — это не аврал, это нормальная работа. Я про аврал ничего не говорил. Что это — оговорка по Фрейду?
M>А насчет 150% — чего вдруг? Это обычная работа, решай задачу через правильное проектирование, через разделение логики, представления, хранения данных и т.п. и все получится, а в конце работы ты будешь удивлен как легко и просто все получается.
"делай хорошо и будет хорошо". С этим никто и не спорит
Здравствуйте, Undying, Вы писали:
V>>Какой инструмент вы напишете, к примеру, для задачи "создать новый репорт" или "сделать новую форму в приложении"?
U>Отчет/формочка данные откуда берет? Преобразования данных где выполняются? В отчете/формочке?
Берёт из базы, преобразования, если есть, обычно в слое бизнеса. Доступ к данным и фреймворк для типовых формочек давно написан, задача в том, чтобы сделать с использованием этого всего конкретную форму
Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, Undying, Вы писали:
V>>>Какой инструмент вы напишете, к примеру, для задачи "создать новый репорт" или "сделать новую форму в приложении"?
U>>Отчет/формочка данные откуда берет? Преобразования данных где выполняются? В отчете/формочке? V>Берёт из базы, преобразования, если есть, обычно в слое бизнеса. Доступ к данным и фреймворк для типовых формочек давно написан, задача в том, чтобы сделать с использованием этого всего конкретную форму
Здравствуйте, morm, Вы писали:
V>>>>Какой инструмент вы напишете, к примеру, для задачи "создать новый репорт" или "сделать новую форму в приложении"?
U>>>Отчет/формочка данные откуда берет? Преобразования данных где выполняются? В отчете/формочке? V>>Берёт из базы, преобразования, если есть, обычно в слое бизнеса. Доступ к данным и фреймворк для типовых формочек давно написан, задача в том, чтобы сделать с использованием этого всего конкретную форму
M>Вы сами ответили на свой вопрос
Вы что-то путаете, я вопрос не задавал. То, что процитировано из моего поста выше — был вопрос риторический.
Всё, что я писал, это то, что если человек загружен на проекте полностью, то ему уже некогда заниматься общественной деятельностью, которая ценится руководством.
V>Всё, что я писал, это то, что если человек загружен на проекте полностью, то ему уже некогда заниматься общественной деятельностью, которая ценится руководством.
Мне кажется мы друг друга не понимаем и поэтому ходим по кругу Я не очень понимаю формулировку "загружен полностью". Вот сейчас у меня два проекта, за один у меня премии и надбавки к зарплате, за второй денег почти нет, зато за невыполнение штрафы и порицания. Мне приходится и там и там вкалывать, при этом я как бы на обоих загружен на 50%? Или 100% — это когда я только одним проектом занимаюсь?
Когда я говорю про создание инструментов, я имею ввиду, что человек решает любую свою задачу путем создания набора достаточно универсальных инструментов, которые собственно и помогают разработчику выполнить задание. Например, у меня сейчас проект по созданию программно-аппаратного комплекса проверки сложной аппаратуры. По проверяемой аппаратуре есть куча документов, но они часто правятся (для меня загадка почему, но так есть). Фактически я не могу положиться на адреса/подадреса, мнемонику команд и т.д. Выход — написать генератор кода, который разбирает соответствующее ТЗ, строит системные таблицы и проблема решена — теперь мне плевать на разработчиков железа, главное чтобы формат описания в ТЗ не менялся. При этом генератор написан на GPLEX/GPPG, а формирование таблиц через шаблоны документов на C#. Будет другой проект — правлю шаблоны, если понадобится немного правлю файлы парсера и поехали...
Здравствуйте, RGB_Dart, Вы писали:
RGB>Здравствуйте, SkyDance, Вы писали:
RGB>>>Принцип "сначала дайте мне кучу денег, а потом я начну работать" — не работает. Человек сначала должен доказать что он может лучше работать, и потом, когда руководство видит, что он действительно работает лучше (новая зона ответственности, новые обязанности, и т.п.) — только тогда ему повышают зарплату.
SD>>К сожалению, этот же принцип "сперва добейся" (С) слишком часто злоупотреблялся (тут вообще лучше английское слово abused, но в русском языке его эквивалент несет чуть-чуть иной смысловой оттенок). Работники теперь тоже не хотят работать за обещания — "вот ты сначала все сделай, а потом мы посмотрим, и, наверное, повысим зарплату". Это прокатывает с недостаточно опытной молодежью (чего греха таить, самого так раза три прокатывали, причем последний раз довольно жестко — и ведь уже за 25 лет мне было).
RGB>Тут есть нюанс. Если повысить зарплату одновременно с введением новых обязаностей / ответственности, то не понятно что делать, если человек не справляется с новыми задачами
Не хочешь повышать — выдавай премии. Справился, включай деньги в з/п, нет не включай.
