Как разделить программистов на категории (jun/mid/senior)?

Question

[Денис Савицкий]

Суть в том, что есть проект, над ним уже несколько лет работают 8 программистов, их задачи всегда пересекаются (сегодня один фиксит баги в RoR проекте, а завтра он настраивает сеть), причём, пока уровни ЗП и показатель kpi, как таковой, не определен вообще. Как определить, кто какой уровень занимает (из этого уже несложно определить уровни ЗП)?

Answer 1

[Suvo]

У нас в компании совсем недавно мы придумали такую схему:
https://gist.github.com/Houdini/56211da3abb637c73907

Она не окончательная, тем не менее в ней есть несколько важных, на мой взгляд принципов.

1. Поощерять нетривиальные решения на текущем месте работы
2. Поощерять open source
3. Поощерять изучать новые технологии

Answer 2

[Viktor Vsk]

То есть, у вас есть проект, который несколько лет нормально держится на 8 разработчиках и тут вы хотите некоторых из них потерять, некоторым дать повод искать новую работу, а некоторым просто уменьшить желание работать?

Comments

[Денис Савицкий]

Нет, изначально было 3, они все теперь ведущие, из ЗП фиксированная, в конце лета набрали ещё народ. Вот их нужно разделить на категории. Пока они просто "программисты"

[Viktor Vsk]

Повышения\понижения посреди рабочего процесса - это, на мой взгляд, ужасно.
Если их все устраивает, то ждите пока придут за большей ЗП и там ориентируйтесь по ходу дела уже.
Хотите поощрить кого-то - поощрите всех, но меньше

[Денис Савицкий]

Никто не говорит о понижении, просто повышение надо привязать к названию должности, а должность должна иметь определенный круг обязанностей. Как их определить? Не посреди рабочего процесса. Мы каждую неделю подводим глобальные итоги о вкладе каждого участника в развитие компании.

[Viktor Vsk]

@qweewq не думаете, что кто-то из "просто программистов" считает себя мидлом\синьором, а вы ему скажете, что он джуниор?
Просто эти названия должностей - это ужасно

[Viktor Vsk]

Ну а сам вопрос о классификации мидлов\джунов\сиьоров многие, и я в том числе, поднимали здесь же. Единственный адекватный ответ это: "Прошли собеседование на синьора, получаете ЗП как средний синьор - вы синьор."

[Денис Савицкий]

Я уверен, что много, кто считает себя синьором :) Но в том и суть, чтобы они могли это доказать. Если человек синьор, а работает за зп джуниора, то не стоит ли его повысить? И наоборот. Нам нужна эффективность – чтобы деньги были действительно отработаны на 100%.

Answer 3

[Пума Тайланд]

Я думаю не сложно собрать трех программистов ведущих и посидеть с ими 10 минут и раскидать людей по способностям мотивации на ранги.

Comments

[Денис Савицкий]

С тех. лидом посидели уже, оказалось, не самая простая задача. Поэтому и вопрос здесь.

[Пума Тайланд]

задача простая разложите по способностям пять человек, в пирамиду, если простой способ, приходишь к одному человеку озадачиваешь его этим вопросом и отжимаешь ответ в течении 5 минут потом к следующему, получаете три пирамиды людей с рангами, потом смотрите код в гите по каждому прогеру в гите, количество, качество и придерживание стандартов, сложность. Потом на основе этих факторов можно отранжировать людей.

[Денис Савицкий]

А, вы имеете ввиду опросить проггеров мнение друг о друге?

[Пума Тайланд]

Вы уже это делали , и сказали что не простая задача, потому что решили спросить 4 человека с разным мнением однвременно, надо сделать тоже самое по отдельности и потом свести таблицу или пирамиды.

Answer 4

[Валентин]

Наверно, как и во всех других сферах, не только программирование.
Смотрим с высоты полета, кто сделал больший вклад в работу, кто работает в проекте раньше, кто более дисциплинирован, кто старше по возрасту (критерии идут по списку уменьшения важности).
Даем должности программист, старший программист, ведущий программист, руководитель сектора...

Не надо вводить должности jun, mid, sen, если у вас их раньше не использовали. Кому будет приятно работать на должности и получить понижение, хоть и в названии.

Answer 5

[Виктор Маслов]

Размер зарплаты должен быть пропорционален их вкладу в данный проект, а не зависеть от jun/mid/senior -- в конце концов человек может быть в сто раз лучшим программистом, чем другой, по всем параметрам, но для конкретного проекта может оказаться, что полезней тонна говнокода, чем качество.

Comments

[Денис Савицкий]

Да, но он обязан это подтвердить