KPI, Грейды и оценки

Существует множество разных систем как оценивать и прогнозировать скорость и качество разработки. Вся сложность в том, что продукт как правило являетая сложной системой, которую можно построить сотней разных способов

Нельзя оценивать всех разработчиков по заранее известным критериям
При разработке сложной системы - теоретически можно разложить все ее составляюзие компоненты и как-то классифицировать сложность каждого из навыков

Если это веб система - наверное всем знакома общая классификация направлений, таких как фронт, бек, веб-дизайнер
Иногда ее делят на более узкие специализации, такие как андройд, иос, администратор базы данных, UX дизайнер
Иногда обобщают в более широкие специализации - фулстек, техлид

(Это всё еще не брало во внимание управленческие компетенции, где всё становится в разы неоднозначней)

Все это разные пути спроектировать модель закрытия потребностей в разработке продута.
Если какая-то из компетенций не закрыта - она обязательно ляжет на кого-то кто ближе всего находится к ее решению.
То есть уже на этом этапе мы знаем только грубые потребности. Но при сборе команды может оказаться что нужных компетенций нету или искать их долго, либо они просят слишком дорого за свой труд. В общем рынок
Если компания уровня FAANG, конечно таких пробелем не возникает и люди подстраиваются под компетенции
А в обычной обыденности - компетенции подстраиваются под людей. И это обязательно нужно брать во внимание

При чем тут KPI

Используя главную мысль, что в окружении (.env) рядовой компании - нет огромного списка желающих покрыть все компетенции, а также иногда и бюджета на это - приходится работать с тем что есть

KPI рассматривается как попытка измерить результат труда каждого специалиста из команды, а также определить ценность этого труда

Если такое можно сделать с менеджерами по продажам, грузчиками, то почему нельзя с разработчиками?
Есть допустим задача. Эту задачу можно +- оценить в деньгах - помножив оценку на стоимость часа разработчика, который ее будет решать. Другое дело, что эта оценка может в 3 раза отличаться от прознозной и это обычное дело. Более того, от специфики задачи сильно зависит сталкивался ли с ней специалист ранее или нет. Понимает он ее природу, или ему нужно будет быстро набраться компетенций (естественно в счет решения задачи).
Отсюда приходит понимание, что заранее разлижть все компетенции специалиста на все направления, а также оценить проект в этих направлениях весьма тяжело и затратно.

По этому в обычном ряде случаев - никто этим не занимается.

• Оценка как правило приравнимается к опыту (хотя опыт может быть и совершенно разным - он все же несет какую-то объективность в себе)
• Второй критерий - рынок. Считаешь что тебя не правильно оценили - найди компанию которая тебя оценит лучше и если такая найдется - будет повод для переоценки.

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

Также следует учесть что любое изменение этих критериев (а продукты иногда меняются) - может привести к понижению по грейдам. А это может сильно демотивировать сильную часть команды.

Часто бывает, что на одном месте сотрудника оценивают как сеньора, а в другом говорят что он еле на мидла тянет. Всё сильно по разному
Можно попробовать использовать общие показатели в грейдах - например если специалист решает узкие задачи - он уступает специалисту, который решает задачи высокого уровня - уровня проект или прдукт, а также вник в продукт на уровне, что может сам сформулировать задачу и критерии ее решения, то есть забрать компетенции продукт менеджера

Такое разделение убьет в компании все узкие специальности в пользу общих - но не приведет к получению продукта лучшего качества за те же деньги (или время). Будут все фулстеки заниматся проработкой задач каждый в своем темпе с посредственным написанием кода, с посредственным дизайном.
Вводя грейды или KPI нужно быть очень осторожным, ошибиться и напортачить легче чем ничего не делать.