Комментарии 35
На мой взгляд, очень долгий резкий переход от юниора к специалисту в плане ЗП. Я бы советовал ввести или еще один уровень (до 6 месяцев, скажем с 50% зп), а потом со 100% до 1 года.
правильно, что бонусы за проекты есть, но вырос всего на 75% в ЗП за 3 года — это, на мой взгляд, мало.
Как понимаю, в основном у вас в «среднем» диапазоне находятся люди по данной шкале…
P.S. в таких системах всегда встает вопрос оценивания работников и всегда проблема в людях, которые это делают. В первую очередь, на мой взгляд, надо не критериями брать. а качеством оценки.
P.S.S. Проектов получается за 1 год надо 10 сделать, что выходит около месяца с небольшим на каждый. А не много ли?
правильно, что бонусы за проекты есть, но вырос всего на 75% в ЗП за 3 года — это, на мой взгляд, мало.
Как понимаю, в основном у вас в «среднем» диапазоне находятся люди по данной шкале…
P.S. в таких системах всегда встает вопрос оценивания работников и всегда проблема в людях, которые это делают. В первую очередь, на мой взгляд, надо не критериями брать. а качеством оценки.
P.S.S. Проектов получается за 1 год надо 10 сделать, что выходит около месяца с небольшим на каждый. А не много ли?
Если Вы хотите разработать систему мотивации — то надо вводить более измеримые и понятные параметры.
Вот объясните, зачем вот это нужно «Участие в еженедельных митингах в составе группы разработчиков, оценка задач. Заслуги в тестировании»?
Какова цель этого пункта? Заставить всех участвовать в еженедельных митингах?
Вы программистам за что деньги платите? За митинги или блокноты на столах? )
Скажу честно — меня бы данный документ мотивировал бы разместить резюме на headhuntere.
Совет:
1. Хорошо себе представьте, на что вы мотивируете сотрудников? На что вы хотите их мотивировать и на что их будет мотивировать этот документ.
2. Объясните людям, что Вы от них хотите и за что Вы будете им платить деньги.
Мое личное мнение — не надо привязываться к опыту работы сотрудников и к куче других параметров. Бывают талантливые люди, которые не имеют опыты, имеет инновационное и нестандартное мышления, ненавидит митинги, вне времени и пространства, участвует одновременно только в одном проекте, но делает его за три дня.
PS Почитал всю строчку про time managment — улыбнуло )
Вот объясните, зачем вот это нужно «Участие в еженедельных митингах в составе группы разработчиков, оценка задач. Заслуги в тестировании»?
Какова цель этого пункта? Заставить всех участвовать в еженедельных митингах?
Вы программистам за что деньги платите? За митинги или блокноты на столах? )
Скажу честно — меня бы данный документ мотивировал бы разместить резюме на headhuntere.
Совет:
1. Хорошо себе представьте, на что вы мотивируете сотрудников? На что вы хотите их мотивировать и на что их будет мотивировать этот документ.
2. Объясните людям, что Вы от них хотите и за что Вы будете им платить деньги.
Мое личное мнение — не надо привязываться к опыту работы сотрудников и к куче других параметров. Бывают талантливые люди, которые не имеют опыты, имеет инновационное и нестандартное мышления, ненавидит митинги, вне времени и пространства, участвует одновременно только в одном проекте, но делает его за три дня.
PS Почитал всю строчку про time managment — улыбнуло )
Прошу прощения за русский — сорвалась отправка поста, не успел вычитать
Спасибо за развернутый комментарий. Есть ли у вас система согласно которой вы работаете? Есть ли градации и критерии? В целом Ваше мнение разделяю, но согласно нему никакая система не нужна, глобально к каждому индивидуальный подход. Мне бы хотелось иметь общую систему и локальный подход к каждому в ее рамках.
У меня система простая — я плачу за результат. Если человек быстро и качественно выдает результат — успевает больше сделать — получает больше денег.
Если я знаю, что квалификация у человека хорошая — я ему даю соответствующие по сложности задания.
Если я знаю, что квалификация у человека хорошая — я ему даю соответствующие по сложности задания.
Сложные проекты на этом не сделаешь, тут нужна командная работа. Можно мерить и платить по отработанным часам, а ставку назначать в зависимости от квалификации. Но в этой системе много останавливающих меня моментов + нет опыта
Если Вы хотите платить за потраченное программистами время — меряйте по часам, но это не будет мотивировать на результат.
Мне кажется несправедливо ставку назначать в зависимости от квалификации — это не мотивирует младших работать, потому что за одно и то же они получат меньше, чем старшие.
Вводите командные премии, чтобы мотивировать их работать вместе в команде. Проект закрыли досрочно — «счастья на всех, и чтобы никто не ушел обиженным»
В первую очередь вам надо разобраться со своими целями — за что вы хотите платить программистам, что вы хотите от программистов — и платите именно за это. Все просто. Возможно, кроме просто оплаты можно использовать другие методы мотивации — всякие там публичные награждения, доски почета, соцпакет. Но в любом случае надо определить, что вы хотите от программистов получить, за что вы хотите им платить.
Мне кажется несправедливо ставку назначать в зависимости от квалификации — это не мотивирует младших работать, потому что за одно и то же они получат меньше, чем старшие.
Вводите командные премии, чтобы мотивировать их работать вместе в команде. Проект закрыли досрочно — «счастья на всех, и чтобы никто не ушел обиженным»
В первую очередь вам надо разобраться со своими целями — за что вы хотите платить программистам, что вы хотите от программистов — и платите именно за это. Все просто. Возможно, кроме просто оплаты можно использовать другие методы мотивации — всякие там публичные награждения, доски почета, соцпакет. Но в любом случае надо определить, что вы хотите от программистов получить, за что вы хотите им платить.
Платить за результат — это сделка, предполагающая договоренность с каждым разработчиком о его вознаграждении по окончанию проекта. В работе над сложными командными проектами, эта схема неэффективна, т.к. люди будут просто думать о деньгах, а не о работе. Премии за успешный квартал у меня предусмотрены.
Моя цель, что бы люди качественно работали. Т.е. делали свою работу хорошо, стремились расти. А что бы было понятно куда расти, мы предложили матрицу роста. Ее и обсуждаем. Поправьте меня, если я не правильно смотрю на вещи.
Моя цель, что бы люди качественно работали. Т.е. делали свою работу хорошо, стремились расти. А что бы было понятно куда расти, мы предложили матрицу роста. Ее и обсуждаем. Поправьте меня, если я не правильно смотрю на вещи.
Табличка ради таблички. Очень много субъективного и ненужного.
Имхо надо больше объективных критериев и метрик. «Участие в чем-то» без ощутимой и измеримой пользы — трата рабочего времени.
Имхо надо больше объективных критериев и метрик. «Участие в чем-то» без ощутимой и измеримой пользы — трата рабочего времени.
Приведите примеры или дайте ссылку. Хотелось бы обсуждать более предметно. А лучше пример из своего опыта. Спасибо
Из моего опыта — выделялись только Team Leader, которому ПМ делегировал полномочия в рамках работы команды разработчиков — декомпозиция, сроки, документация, технические риски и так далее. Что отражалось на зарплате существенно.
Но для каждого были свои суммы и градации. За исключением годовых и проектных премий, сотрудник сам должен был начать разговор. Если это случалось, его непосредственный начальник после обсуждения с руководителем команды и hr устанавливал критерии по которым зарплата поднималась. Индивидуально
Но для каждого были свои суммы и градации. За исключением годовых и проектных премий, сотрудник сам должен был начать разговор. Если это случалось, его непосредственный начальник после обсуждения с руководителем команды и hr устанавливал критерии по которым зарплата поднималась. Индивидуально
Не надо оценивать людей по себе. Все люди разные, каждый со своими плюсами и минусами.
Не могу сказать, что говорю это на собственном опыте — нет. К сожалению. Но я верю, что именно это то, о чего надо избавляться руководителю.
А з/п сотрудника зависит только от его способности потребовать повышения з/п.
Не могу сказать, что говорю это на собственном опыте — нет. К сожалению. Но я верю, что именно это то, о чего надо избавляться руководителю.
А з/п сотрудника зависит только от его способности потребовать повышения з/п.
Насчет первого согласен. Есть такое. Поэтому и обращаюсь к сообществу за советом. Насчет второго не согласен. Должна быть система в рамках которой определяется ЗП, иначе возникаем масса мелких споров, конфликтов, которых можно избежать будь система. Команда гораздо более охотно соглашается с правилами, чем с индивидуальными условиями.
Обсуждения зарплат членов команды должно пресекаться.
Ничего хорошего из этого не выйдет. Всегда будут обиженные.
Ничего хорошего из этого не выйдет. Всегда будут обиженные.
Не должно.
Если бы мне руководитель заявил, что я не имею права сообщать кому-то З\П — досвидос. Захочу — напишу хоть в блоге. Никакой тайны в этом нет.
А попытки спрятать то, что лежит на виду наоборот подстегнут попытки выяснить, разузнать и т.д., ибо любопытство людей границ не имеет.
Опять же гарантировано будет мнение «о, он з\п скрывает, наверное ему платят больше, чем мне».
Если бы мне руководитель заявил, что я не имею права сообщать кому-то З\П — досвидос. Захочу — напишу хоть в блоге. Никакой тайны в этом нет.
А попытки спрятать то, что лежит на виду наоборот подстегнут попытки выяснить, разузнать и т.д., ибо любопытство людей границ не имеет.
Опять же гарантировано будет мнение «о, он з\п скрывает, наверное ему платят больше, чем мне».
В большнстве серьёзных и крупных компаний это запрещено или крайне не приветствуется. Но вы можете там не работать, если не хотите.
И «о, он з\п скрывает, наверное ему платят больше, чем мне» нету, потому что не говорит никто.
В кругу близких друзей конечно все известно.
И «о, он з\п скрывает, наверное ему платят больше, чем мне» нету, потому что не говорит никто.
В кругу близких друзей конечно все известно.
Да, именно поэтому и ввожу систему. У Вас в компании индивидуально с каждым ЗП обсуждается или есть градация?
Да, именно поэтому и ввожу систему. У Вас в компании индивидуально с каждым ЗП обсуждается или есть градация?
Действительно, схема ради схемы. На 10+ человек 6 категорий разработчиков и куча абстрактных пунктов типа «вне времени и пространства» и «куратор проектов, учитель, наставник».
Предложение — стереть все это, выбрать любой один параметр (например, число проектов на контроле) и отталкиваться только от него.
Если его не хватит — добавить еще один параметр. Не хватит этих двух — добавить третий — и так, пока схема не начнет устраивать.
Такая схема будет основываться на реальной жизни (в отличие от текущей).
Предложение — стереть все это, выбрать любой один параметр (например, число проектов на контроле) и отталкиваться только от него.
Если его не хватит — добавить еще один параметр. Не хватит этих двух — добавить третий — и так, пока схема не начнет устраивать.
Такая схема будет основываться на реальной жизни (в отличие от текущей).
Градации введены, что бы была понятна перспектива роста. Иначе люди не видят куда можно двигаться. Есть ли у Вас собственный опыт или это на эмоциях?
Обучение сотрудников и ведение своего блога явно никак не относится к профессионализму работника.
Да, но я хочу мерить не только профессионализм и от этого платить зп. Есть факторы, которые показывают отношение человека к работе, интерес к тому, чем он занимается. Конечно блог не является обязательным и его тсутствие может не учитываться при принятии решения о переводе на следующую ступень.
Если не обязательно, то зачем об этом писать? Я не просто так написал про «мерить по себе».
Рассмотрим мои минусы с точки зрения вашей таблицы:
— Не веду своего блога.
— Не люблю обучать людей. Причем не только не люблю, но еще и не умею. Если мне скажут «обучай новичков», я просто уволюсь.
— Я не читаю лекции и не пытаюсь давать знания тем, кто этого не хочет
— Я считаю что митинги — на 90% пустая трата времени.
— У меня есть проблемы с тайм-менеджментом, но я не считаю что он — панацея. Намного важнее, чтобы работа приносила удовольствие, тогда и Т.М. не нужен.
— Я не пытаюсь вносить вклад в атмосферу. Мне все равно будет корпоративное мероприятие или нет
Тем не менее у меня есть большое кол-во плюсов, благодаря которым я работаю не рядовым сотрудником, а тех. диром. Например таких качеств, как честность, прямота и умение признавать свои ошибки у вас нет, а отсутствие этого, имхо, — огромный минус.
Рассмотрим мои минусы с точки зрения вашей таблицы:
— Не веду своего блога.
— Не люблю обучать людей. Причем не только не люблю, но еще и не умею. Если мне скажут «обучай новичков», я просто уволюсь.
— Я не читаю лекции и не пытаюсь давать знания тем, кто этого не хочет
— Я считаю что митинги — на 90% пустая трата времени.
— У меня есть проблемы с тайм-менеджментом, но я не считаю что он — панацея. Намного важнее, чтобы работа приносила удовольствие, тогда и Т.М. не нужен.
— Я не пытаюсь вносить вклад в атмосферу. Мне все равно будет корпоративное мероприятие или нет
Тем не менее у меня есть большое кол-во плюсов, благодаря которым я работаю не рядовым сотрудником, а тех. диром. Например таких качеств, как честность, прямота и умение признавать свои ошибки у вас нет, а отсутствие этого, имхо, — огромный минус.
А какую должность вы сами занимаете?
Судя по вашей градации, перешедший к вам в компанию опытный разработчик будет получать от 15% до 50% базовой ставки в течение года, — этим вы точно не привлечёте к себе специалистов.
Да и 15% для новичка, на мой взгляд, очень мало.
ИМХО, стоит объединить уровни «Новичок» и «Юниор» в «Мало опыта» (т.е. выпускник ВУЗа) и платить 50%, а действительно опытных специалистов (это должно определяться по портфолио и собеседованию) брать сразу на уровень «Специалист».
Также, стоит объединить «Мастер» и «Ведущий разработчик» — принципиальной разницы межде ними не заметно.
Да и 15% для новичка, на мой взгляд, очень мало.
ИМХО, стоит объединить уровни «Новичок» и «Юниор» в «Мало опыта» (т.е. выпускник ВУЗа) и платить 50%, а действительно опытных специалистов (это должно определяться по портфолио и собеседованию) брать сразу на уровень «Специалист».
Также, стоит объединить «Мастер» и «Ведущий разработчик» — принципиальной разницы межде ними не заметно.
Не совсем так. Когда приходит опытный специалист, мы сразу определяем его положение по сетке и назначаем ЗП в соответствии с ней, предполагая что он отвечает всем требованиям. А для того что бы проверить «отвечает или нет» — дается первый месяц (новичок/юниор), по прошествии которого мы, либо оставляем человека у себя, либо прощаемся по причине непрохождения испытательного срока.
Объединять «Мастер» и «Ведущий разработчик» неправильно. Во-первых нужно оставить возможность роста. Во-вторых у них немного отличаются задачи в коллективе. А вообще шли именно к разделению, а не объединению для того, что бы показать возможность роста.
Объединять «Мастер» и «Ведущий разработчик» неправильно. Во-первых нужно оставить возможность роста. Во-вторых у них немного отличаются задачи в коллективе. А вообще шли именно к разделению, а не объединению для того, что бы показать возможность роста.
Рекомендую почитать, как устроена подобная градация у Спольски: www.joelonsoftware.com/articles/Ladder.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обсуждаем градацию разработчиков в веб-студии и смежных структурах