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>Вы хотите получить математический алгоритм для оценки того как работник справляется с обязанностями? Ну, можно, конечно запариться, но зачем? Ваш руководитель не способен адекватно оценить — кто справляется с работой а кто нет? И вы сами не можете его переубедить? А зачем вы на него работаете тогда?

Я — нет. Я уже объяснял, как на мой взгляд должна быть введена аттестация. И для чего конкретно: не для решения проблем вида "начальника задалбывают нытьем подчиненные, которым не доплачивают". А для уменьшения бардака в бухгалтерии, и для более простого и точного прогнозирования бюджета. Таки проще, когда з/п меняются не чаще, чем раз в полгода.

Но вот то, что руководители не способы адекватно оценить, кто и как справляется с работой — это я видел в Москве сплошь и рядом. Почти в любой конторе. Были исключения (вспоминаю дважды — одно в Агаве, одно в Касперском).

Здравствуйте, itslave, Вы писали:

I>Думаем внедрить аттестацию сотрудников(программисты) и пересмотр з/п по результатам аттестации.

Зарплата зависит от соотношения спроса и предложения на рынке труда. У нас капитализм (чахлый, но все же). А вы тут со своим совком.

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

Ваш кэп.

Здравствуйте, morm, Вы писали:

V>>>>Или недозагруженный исполнитель, у которого есть на это время
M>>>У вас в компании отношение к сотрудникам как к пони в шахтах?! Угля 3 тонны не вытащил — отстрел?
V>>Нет, у нас другая проблема. Есть два человека одинаковой (предположим) квалификации. Один загружен на проекте на 100%, другой на 50.
V>>Впторой в свободное время делает полезные вещи для других (что хорошо и правильно).
V>>Но что видно сверху? Первый — просто делает своё дело. Второй — делает своё дело и ещё много полезных вещей.
V>>Угадайте, кому первому повысят зарплату?

M>Что мешает загруженному на 100% делать так, чтобы попутно создавались инструменты для других?
Отсутствие на это времени. Он же не враг себе, чтобы загружаться на 150% из за бескорыстной любви к другим.