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