Добрый день, коллеги.
В компании появилась потребность в разделении программистов на грейды, от начинающего до суперспециалиста. Всего выделили 5 ступеней. На каждом уровне свое премирование и свой KPI. Теперь собственно вопрос, как определить данные критерии для каждого грейда?
Возможно кто то подобное внедрял на своих предприятиях, поделитесь пожалуйста табличкой с компетенциями
В компании появилась потребность в разделении программистов на грейды, от начинающего до суперспециалиста. Всего выделили 5 ступеней. На каждом уровне свое премирование и свой KPI. Теперь собственно вопрос, как определить данные критерии для каждого грейда?
Возможно кто то подобное внедрял на своих предприятиях, поделитесь пожалуйста табличкой с компетенциями
По теме из базы знаний
- 1С:Зарплата и управление персоналом 8 (ЗУП) - ПРОФ, КОРП, купить, цена
- 3% и вы
- "250+ тысяч, в штат и работу пока не ищу": как изменился типичный 1С-ник в 2023 году
- Как самостоятельно составить трек развития в 1С и приступить к нему
- Как мы взяли 100 человек, не знакомых с программированием, и растим их внутри компании
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
по цене, по который они смогут себя продать на рынке.
Оценку каждого сотрудника делайте, сколько бы он стоил на рынка и делите на группы.
Для перехода делайте общую таблицу, требований для перехода, чем одна группа отличается от другой. По сути со всеми надо провести повторное собеседование.
Оценку каждого сотрудника делайте, сколько бы он стоил на рынка и делите на группы.
Для перехода делайте общую таблицу, требований для перехода, чем одна группа отличается от другой. По сути со всеми надо провести повторное собеседование.
Определить исходя из Ваших требований.
У нас была внутренняя сертификация.
Уровень определялся по этим сертификатам и сотрудник знал что ему нужно для перехода на следующий уровень.
Если у Вас только УТ то и сертификаты подгонять под нее. Если все конфы то зависит от того универсальные спецы или узкие - каждый по своей конфе...
У нас была внутренняя сертификация.
Уровень определялся по этим сертификатам и сотрудник знал что ему нужно для перехода на следующий уровень.
Если у Вас только УТ то и сертификаты подгонять под нее. Если все конфы то зависит от того универсальные спецы или узкие - каждый по своей конфе...
В данном случае мы идем не от специалистов, а от грейдов. Т.е. нужно определить четкие критерии в грейде и потом по данному грейду как по чек листу иди на собеседовании. Знаешь это и это, ок мы тебя берем на начинающего 1сника, знаешь еще то то и то то, ты программист 2 грейда, знаешь еще это и это то 3 и т.д.
Поделюсь своим мнением, основанным на работе в 4 франчайзи на роли линейного менеджера и рук. отдела.
Ранжирование и категоризация программистов - в целом, дело не очень благодарное, т.к. шуму создаст много (и сил положит), а практического результата будет мало.
Но если очень хочется, то почему не.
Наименее геморройная система выглядела так: программисты делятся на категории, исходя из ряда параметров, в том числе:
- стаж работы,
- наличие и количество сертификатов с разным весом (1 спец = 3 профа и т.д.)
- количество выработки часов, среднее в месяц
- коэффициент репутации (отзывы vs рекламации)
Для каждого параметра рассчитывался вес. Всего ступеней было три + стажеры.
В высшую лигу попадали те, у кого было много сертификатов, много выработки и т.д. Дорасти до высшей категории можно было месяцев за 6-8 при старании.
Ранжирование и категоризация программистов - в целом, дело не очень благодарное, т.к. шуму создаст много (и сил положит), а практического результата будет мало.
Но если очень хочется, то почему не.
Наименее геморройная система выглядела так: программисты делятся на категории, исходя из ряда параметров, в том числе:
- стаж работы,
- наличие и количество сертификатов с разным весом (1 спец = 3 профа и т.д.)
- количество выработки часов, среднее в месяц
- коэффициент репутации (отзывы vs рекламации)
Для каждого параметра рассчитывался вес. Всего ступеней было три + стажеры.
В высшую лигу попадали те, у кого было много сертификатов, много выработки и т.д. Дорасти до высшей категории можно было месяцев за 6-8 при старании.
(9)Это подходит для компании франчайзи.
У меня внутренний проект внутри компании, свой штат программистов 15 человек. У нас нет задач добавлять звездочек франчу, поэтому на сертификацию людей не гоняем. Люди работают на окладе в белой компании, 40 часовая рабочая неделя. Конфигурации различные используются, один работает с бухой, другой с УТ, третий с очередями обмена типа кафки, и т.д..
Я пишу сюда, так как своих мыслей на эту тему совсем нет. Как причесать такое разнообразие в четкую структуру грейдов??? Но задачу нужно выполнить
У меня внутренний проект внутри компании, свой штат программистов 15 человек. У нас нет задач добавлять звездочек франчу, поэтому на сертификацию людей не гоняем. Люди работают на окладе в белой компании, 40 часовая рабочая неделя. Конфигурации различные используются, один работает с бухой, другой с УТ, третий с очередями обмена типа кафки, и т.д..
Я пишу сюда, так как своих мыслей на эту тему совсем нет. Как причесать такое разнообразие в четкую структуру грейдов??? Но задачу нужно выполнить
(11) давайте идти от простого.
Это формальная вещь или нет? Что стоит за этим проектом (введение грейдов)? Необходимость дифференцировать уже существующее зарплатное неравенство (что нормально) или желание мотивировать сотрудников к развитию? Или вообще просто так HR сказал?
Если вам нужно управлять развитием персонала, то скорее всего у вас есть определенные критерии эффективности - так же, как во франчах ими являются условные сертификаты. Предположу, что это количество закрытых задач*коэффициент масштабности*коэффициент сложности + стаж (да. советский критерий, но для многих работает), + репутация.
Вплоть до того, что вы можете измерять результативность сотрудников, пересчитывая их работы по актуальным рыночным ценникам (Иванов сделал за месяц/годработу, за которую мы отвалили бы подрядчикам 100 000 долл.).
Главное - это соответствие вашей системе грейдирования/премирования целям. А про цели интересно было бы услышать.
Это формальная вещь или нет? Что стоит за этим проектом (введение грейдов)? Необходимость дифференцировать уже существующее зарплатное неравенство (что нормально) или желание мотивировать сотрудников к развитию? Или вообще просто так HR сказал?
Если вам нужно управлять развитием персонала, то скорее всего у вас есть определенные критерии эффективности - так же, как во франчах ими являются условные сертификаты. Предположу, что это количество закрытых задач*коэффициент масштабности*коэффициент сложности + стаж (да. советский критерий, но для многих работает), + репутация.
Вплоть до того, что вы можете измерять результативность сотрудников, пересчитывая их работы по актуальным рыночным ценникам (Иванов сделал за месяц/годработу, за которую мы отвалили бы подрядчикам 100 000 долл.).
Главное - это соответствие вашей системе грейдирования/премирования целям. А про цели интересно было бы услышать.
Холивар. Тема вредная. Только рыночная стоимость спасет. У меня нет ни одного сертификата, и никогда не будет. И в некоторых областях я профан. Но за остальные области мне платят больше рынка, а особенно за создание новых решений, на которые еще не существует сертификатов.
Думаю, по всем приведенным советам - я бы и на грейд-1 не потянул бы. Поэтому я и не работаю в таких компаниях, где есть подобная категоризация и кипиай...
Думаю, по всем приведенным советам - я бы и на грейд-1 не потянул бы. Поэтому я и не работаю в таких компаниях, где есть подобная категоризация и кипиай...
(21)
А если программисты не только умные но и достаточно хитроумные, то будут весьма умело работать не на результат, а на показатели. А поскольку компания "белая", то и платить им прийдеться именно за показатели.
(20)
Точно, вторым пунктом после "корпоративного духа нашей процветающей компании"
в отношении программистов KPI действительно штука плохо работающая и, в случае безголового применения, приводящая к дурной работе ради непонятных и быстро устаревающих показателей.
А если программисты не только умные но и достаточно хитроумные, то будут весьма умело работать не на результат, а на показатели. А поскольку компания "белая", то и платить им прийдеться именно за показатели.
(20)
Вижу в описании вакансии "KPI" прохожу мимо....
Точно, вторым пунктом после "корпоративного духа нашей процветающей компании"
(18)Аналогично - стаж с 1997г. Ни одного сертификата. Но еще до официальной конфы 1С - управление школой уже написал подобную конфу в 10 классе. За 24 года написал около 100 новых конфигураций. Знаю ответы на все вопросы начиная с выбора железа и заканчивая сакральным - "почему 1С тупит". Во фрилансе уже 15 лет.
Пусть кидают тухлые помидоры... Но напишу своё видение с позиции архитектора:
Для начала надо разделить всех прогеров на 2 группы:
1. Я могу программировать в любых конфигурациях
2. Узкие спецы (собственно как и я, мой профиль ЗУП)
Достаточно распространённая ошибка - многие руководители не понимают ценности узких спецов. Для таких сразу напишу: Вы ж простатит не пойдёте лечить к терапевту?!
Т.к. коллега просит 5 уровней... попробуем пофантазировать:
1. Начинающий. практически без опыта работы. Обычно это "я прошёл курсы"... Здесь нужно выяснить что он вынес с курсов своих. Зависит от самих курсов. Если человек запомнил половину материала и способен структурированно рассказывать - значит из него можно вырастить грамотного спеца.
2. Я делал в основном простенькие отчеты и обработки. Т.е. это начинающий, но уже с опытом работы от года. Тут стоит обратить внимание на владение языком запросов, СКД и на знание стандартов разработки. На этом уровне человек уже должен понимать зачем они нужны и какая польза от них. Все кто не соблюдает стандарты для меня это не разработчики, а теплокодеры.
3. Разработчик середнячок. Т.е. ему напишешь качественное ТЗ, он тебе выполнит качественно то, что написано в ТЗ. Достаточно ценная компетенция. Однако на этом уровне не стоит рассчитывать, что разработчик нароет неописанных сценариев в коде и т.д. Должен уже уверенно владеть основными механизмами платформы. На этом уровне решают задачи и по интеграциям и учетные задачи, но всё строго по ТЗ.
4. Опытный разработчик. Здесь уже опыт лет 5 как минимум. Способен решать сложные задачи. Способен проектировать "под присмотром". Такому разработчику можно поручить отдельные куски учета в проектах и особо не париться по поводу них, т.к. человек их точно закроет. Человек способен делать код-ревью для начинашек. Ессно сам строго соблюдает стандарты разработки. Владеет почти всеми механизмами платформы и глубоко знает предметную область. Очень ценная компетенция!
5. Супер профи. Уровень архитектора. Умеют решать любые задачи вне зависимости от уровня сложности. Не требуется грамотная постановка или ТЗ. Всё способен нарыть сам, часто даже не привлекая заказчика. Выстраивает грамотную архитектуру решения, обращает внимание на производительность системы в целом и трудоёмкость ввода данных. Способен реорганизовать бизнес-процессы для исключения лишних операций/звеньев.
Если разработчик работает в одной предметной области, то нужно упор делать на том, на сколько он её хорошо знает и на сколько сложные задачи способен решать. Обратить внимание нужно на степень самостоятельности. Ибо некоторым нужна нянька.
Кстати матрицу компетенций я лично считаю полной чушью, которая никак не показывает ценность разработчика. А те, кто ставит в ней много галочек, чаще всего знают всё очень поверхностно. За 18 лет опыта много раз заполнял её, но ни разу не работал там, где её предлагают заполнить. Потому как я ставлю в ней 2-3 галки, но бестолковому менеджеру никак не объяснишь по этим флажкам глубину знаний каждой из галок. Считаю такой формат подбора людей сильно формальным. Только обсуждение задач из опыта кандидата можно сделать правильны вывод о его компетенциях.
Аналогично отношусь к тестам и тестовым задачам. Полная чушь. абсолютно ничего не показывает.
Для начала надо разделить всех прогеров на 2 группы:
1. Я могу программировать в любых конфигурациях
2. Узкие спецы (собственно как и я, мой профиль ЗУП)
Достаточно распространённая ошибка - многие руководители не понимают ценности узких спецов. Для таких сразу напишу: Вы ж простатит не пойдёте лечить к терапевту?!
Т.к. коллега просит 5 уровней... попробуем пофантазировать:
1. Начинающий. практически без опыта работы. Обычно это "я прошёл курсы"... Здесь нужно выяснить что он вынес с курсов своих. Зависит от самих курсов. Если человек запомнил половину материала и способен структурированно рассказывать - значит из него можно вырастить грамотного спеца.
2. Я делал в основном простенькие отчеты и обработки. Т.е. это начинающий, но уже с опытом работы от года. Тут стоит обратить внимание на владение языком запросов, СКД и на знание стандартов разработки. На этом уровне человек уже должен понимать зачем они нужны и какая польза от них. Все кто не соблюдает стандарты для меня это не разработчики, а теплокодеры.
3. Разработчик середнячок. Т.е. ему напишешь качественное ТЗ, он тебе выполнит качественно то, что написано в ТЗ. Достаточно ценная компетенция. Однако на этом уровне не стоит рассчитывать, что разработчик нароет неописанных сценариев в коде и т.д. Должен уже уверенно владеть основными механизмами платформы. На этом уровне решают задачи и по интеграциям и учетные задачи, но всё строго по ТЗ.
4. Опытный разработчик. Здесь уже опыт лет 5 как минимум. Способен решать сложные задачи. Способен проектировать "под присмотром". Такому разработчику можно поручить отдельные куски учета в проектах и особо не париться по поводу них, т.к. человек их точно закроет. Человек способен делать код-ревью для начинашек. Ессно сам строго соблюдает стандарты разработки. Владеет почти всеми механизмами платформы и глубоко знает предметную область. Очень ценная компетенция!
5. Супер профи. Уровень архитектора. Умеют решать любые задачи вне зависимости от уровня сложности. Не требуется грамотная постановка или ТЗ. Всё способен нарыть сам, часто даже не привлекая заказчика. Выстраивает грамотную архитектуру решения, обращает внимание на производительность системы в целом и трудоёмкость ввода данных. Способен реорганизовать бизнес-процессы для исключения лишних операций/звеньев.
Если разработчик работает в одной предметной области, то нужно упор делать на том, на сколько он её хорошо знает и на сколько сложные задачи способен решать. Обратить внимание нужно на степень самостоятельности. Ибо некоторым нужна нянька.
Кстати матрицу компетенций я лично считаю полной чушью, которая никак не показывает ценность разработчика. А те, кто ставит в ней много галочек, чаще всего знают всё очень поверхностно. За 18 лет опыта много раз заполнял её, но ни разу не работал там, где её предлагают заполнить. Потому как я ставлю в ней 2-3 галки, но бестолковому менеджеру никак не объяснишь по этим флажкам глубину знаний каждой из галок. Считаю такой формат подбора людей сильно формальным. Только обсуждение задач из опыта кандидата можно сделать правильны вывод о его компетенциях.
Аналогично отношусь к тестам и тестовым задачам. Полная чушь. абсолютно ничего не показывает.
Спасибо за ответы и извините за долгое отсутствие.
Цель грейдов перераспределить ФОТ между сотрудниками, по их компетенциям. Набирали программистов при предыдущем ИТ руководстве и часть уже при новом. Те кто пришли позднее, пришли на свободные ставки в штатке(которые в деньгах оцениваются ниже), при этом компетенция у новичков выше. Перераспределить ФОТ хочется не по субъективным причинам, а по вполне измеримым и логичным. Еще проблема в том, что у нас нет новичков, и 5 уровней грейдов нужно распределить между программистами уровня специалист и выше. Стаж у всех сотрудников более 5-7 лет, разбег в зп между 1 грейдом и 5тым более чем в 60 т.р. Так что задача очень не тривиальная.
Цель грейдов перераспределить ФОТ между сотрудниками, по их компетенциям. Набирали программистов при предыдущем ИТ руководстве и часть уже при новом. Те кто пришли позднее, пришли на свободные ставки в штатке(которые в деньгах оцениваются ниже), при этом компетенция у новичков выше. Перераспределить ФОТ хочется не по субъективным причинам, а по вполне измеримым и логичным. Еще проблема в том, что у нас нет новичков, и 5 уровней грейдов нужно распределить между программистами уровня специалист и выше. Стаж у всех сотрудников более 5-7 лет, разбег в зп между 1 грейдом и 5тым более чем в 60 т.р. Так что задача очень не тривиальная.
(29) Автору ясно дали понять, что увеличения ФОТ не будет. Сказали хочешь насыпать денег "новичкам" - отжимай их у "стариков". Если при этом ФОТ еще и уменьшится под соусом грейдов - то премию выпишут :)
(27) Наименее болезненный вариант, сохраняющий видимость справедливости - сначала внедрить какие-то KPI и еженедельно обнародовать результаты оценок, подводя месячные итоги. Пары месяцев должно хватить. Если "старики" откажутся понимать, куда ветер дует и не разбегутся сами - тогда официально утверждать грейды, основанные на этих KPI. Предупредив заранее о грядущем перераспределении плюшек и дав шанс "старикам" вписаться в новые требования.
ЗЫ. Мы делили апельсин, много наших полегло.
(27) Наименее болезненный вариант, сохраняющий видимость справедливости - сначала внедрить какие-то KPI и еженедельно обнародовать результаты оценок, подводя месячные итоги. Пары месяцев должно хватить. Если "старики" откажутся понимать, куда ветер дует и не разбегутся сами - тогда официально утверждать грейды, основанные на этих KPI. Предупредив заранее о грядущем перераспределении плюшек и дав шанс "старикам" вписаться в новые требования.
ЗЫ. Мы делили апельсин, много наших полегло.
(27) возьми за основу то что я написал. 3 грейда тебе точно подойдут. Чтоб придумать ещё 2 посмотри уже на персоналии которые у тебя работают. Проанализируй чем каждый из них занимается. Из этого можно будет понять.
Ну и главное, что надо понимать: возможно у тебя несколько людей будут на одном грейде, а какие-то грейды будут пустыми! Не пытайся заполнить все грейды теми людьми кто есть. Здесь как раз и может получиться, что обидишь кого-то. Собственно как многие коллеги тут и пишут.
Ну и главное, что надо понимать: возможно у тебя несколько людей будут на одном грейде, а какие-то грейды будут пустыми! Не пытайся заполнить все грейды теми людьми кто есть. Здесь как раз и может получиться, что обидишь кого-то. Собственно как многие коллеги тут и пишут.
(27)
У меня прокатывал такой вариант:
Нагрузка по наиболее значимым проектам ложилась на "новичков".
По результатам выбивалось из руководства повышение ФОТ и распределялось в большую сторону на удачно справившихся новичков.
А повышение ФОТ - такая же обязанность руководства, как закрывать задачи у программиста.
И ни каких грейдов, разделяющих команду разрабов, вводить не потребуется. Если есть команда конечно.
проверь себя по шкале, предложенной в (24) - подойти к этой задаче как супер профи и датй заказчику не то, что он хочет, а то, что ему нужно ;)
Цель грейдов перераспределить ФОТ между сотрудниками
У меня прокатывал такой вариант:
Нагрузка по наиболее значимым проектам ложилась на "новичков".
По результатам выбивалось из руководства повышение ФОТ и распределялось в большую сторону на удачно справившихся новичков.
А повышение ФОТ - такая же обязанность руководства, как закрывать задачи у программиста.
И ни каких грейдов, разделяющих команду разрабов, вводить не потребуется. Если есть команда конечно.
проверь себя по шкале, предложенной в (24) - подойти к этой задаче как супер профи и датй заказчику не то, что он хочет, а то, что ему нужно ;)
тут обсуждают, как проранжировать программистов, причем объективно, и не спрашивая мнения последних
если они все готовы пахать с утра до ночи и все претендуют на самый высший уровень, то все вышесказанное в определенной мере справедливо
возможным компромиссом было бы для начала узнать, как они в коллективе оценивают друг друга
я уверен, что часть из них не стала бы претендовать на высший уровень, при этом зная, что нагрузка на них будет поменьше (задачи попроще при одинаковой рабочей неделе)
то есть изначально надо их спросить и таким образом поделить на ПОДгруппы - кто претендует на высший уровень, кто на средний
на низший можно откинуть самых "слабых", если таковые имеются
но для этого у них должны быть задания выполненные в замечаниями, ошибками, и чтоб их еще премии лишили
Тогда задача немного упростится - уже будет 3 подгруппы, самым сложным будет проранжировать вторую (посередке)
Неплохо бы сразу определиться со специалистами самого высокого уровня, тесты не подойдут - кто будет их тестировать? кто знает тонкости лучше их самих?
разве что они сами друг друга - этот вариант не для них
конечно, можно заняться подсчетом их сертификатов
но результативность - все таки наиболее объективный критерий, ради чего они работают?
спросите лучше начальников отделов (или потребителей результатов их работы)
если старички не согласны с перестановкой мест, тогда можно им объявить что самые тяжелые задания будут поступать им и только им
для группы программистов во второй группе (которая между первой и высшей) можно применить и стаж, и количество сертификатов, и тесты (их накидают программисты из определившейся высшей группы)
причем в качестве тестов можно использовать и текущие задачи - кто сделает лучше?
если они все готовы пахать с утра до ночи и все претендуют на самый высший уровень, то все вышесказанное в определенной мере справедливо
возможным компромиссом было бы для начала узнать, как они в коллективе оценивают друг друга
я уверен, что часть из них не стала бы претендовать на высший уровень, при этом зная, что нагрузка на них будет поменьше (задачи попроще при одинаковой рабочей неделе)
то есть изначально надо их спросить и таким образом поделить на ПОДгруппы - кто претендует на высший уровень, кто на средний
на низший можно откинуть самых "слабых", если таковые имеются
но для этого у них должны быть задания выполненные в замечаниями, ошибками, и чтоб их еще премии лишили
Тогда задача немного упростится - уже будет 3 подгруппы, самым сложным будет проранжировать вторую (посередке)
Неплохо бы сразу определиться со специалистами самого высокого уровня, тесты не подойдут - кто будет их тестировать? кто знает тонкости лучше их самих?
разве что они сами друг друга - этот вариант не для них
конечно, можно заняться подсчетом их сертификатов
но результативность - все таки наиболее объективный критерий, ради чего они работают?
спросите лучше начальников отделов (или потребителей результатов их работы)
если старички не согласны с перестановкой мест, тогда можно им объявить что самые тяжелые задания будут поступать им и только им
для группы программистов во второй группе (которая между первой и высшей) можно применить и стаж, и количество сертификатов, и тесты (их накидают программисты из определившейся высшей группы)
причем в качестве тестов можно использовать и текущие задачи - кто сделает лучше?
У Вас на предприятии есть собственные проекты? разработка крупного функционального блока, или разработка собственной конфигурации? Как в случае проектной работы делить программистов по грейдам?
Кто больше разработал тот и больше получает? да но до него предыдущий программист анализировал задачу, детализировал и разобрал от и до, проработал. Когда команда, цель одна - делить программистов по грейдам не получится - узнают что кто то из их же команды получает больше - начнут смотреть на сторону.
Кто больше разработал тот и больше получает? да но до него предыдущий программист анализировал задачу, детализировал и разобрал от и до, проработал. Когда команда, цель одна - делить программистов по грейдам не получится - узнают что кто то из их же команды получает больше - начнут смотреть на сторону.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот