Комментарии 2
Оценка нечто сферического в вакууме, с нулевой устойчивостью. Если нет базиса, на которую может опереться система, то система будет не устойчива, как следствие будет легко и естественно «взламываться».
В статье не увидел толком ничего по процессу оценки.
В самой «физической» части навыков нет конкретики. Конечно, знания можно оценивать бесконечно, но для большей части задач не надо уметь собираться синхрофазотрон из клавиатуры. Т.е. везде личное мнение, да ещё с относительной оценкой, вроде: «решает задачи, которые 90% других не могут».
Получше с AoE. Но по процессу ничего нет) Обучить сколько новичков нужно? Кто стоит со свечкой? А кто оценивает качество обучения?
А вот как наладить оценку, чтобы не было злоупотреблений? Как избежать случая, что в компании в момент все оказались в верхнем тире, и им нечего платить?(что естественная реакция на появление такой системы) Или то же самое, но уже потому, что бегут с низких тиров? Ну и где статистика, как без неё понять эффективность?
Сама система без инструментов внедрения бесполезна, если, конечно, нет желания спустить бюджет на поиски)
В статье не увидел толком ничего по процессу оценки.
В самой «физической» части навыков нет конкретики. Конечно, знания можно оценивать бесконечно, но для большей части задач не надо уметь собираться синхрофазотрон из клавиатуры. Т.е. везде личное мнение, да ещё с относительной оценкой, вроде: «решает задачи, которые 90% других не могут».
Получше с AoE. Но по процессу ничего нет) Обучить сколько новичков нужно? Кто стоит со свечкой? А кто оценивает качество обучения?
А вот как наладить оценку, чтобы не было злоупотреблений? Как избежать случая, что в компании в момент все оказались в верхнем тире, и им нечего платить?(что естественная реакция на появление такой системы) Или то же самое, но уже потому, что бегут с низких тиров? Ну и где статистика, как без неё понять эффективность?
Сама система без инструментов внедрения бесполезна, если, конечно, нет желания спустить бюджет на поиски)
Здравствуйте. Я, если что, автор доклада.
Во-первых, вы правы, и некоторые темы действительно не раскрыты. Уточню, что формат доклада — 35-40 минут, а тут — лишь его конспект. И я уместил в этот интервал доклада то, что показалось мне наиболее важным.
Дальше постараюсь поделиться опытом, как делаем мы — в разрезе ваших вопросов.
В целом, мы стараемся рассматривать команду в первую очередь как коллектив людей, а не как сложный механизм с приборами и метриками. Поэтому жестких критериев в оценке людей мы в принципе не используем.
Также подход карьерных уровней полагает на то, что компания неплохо работала и без них, это очевидно не must-have практика в каждой инженерной организации со старта. Поэтому зачастую есть очевидные и неочевидные зависимости и предположения.
> Обучить сколько новичков нужно? Кто стоит со свечкой? А кто оценивает качество обучения?
Обучение новичков есть и с карьерными уровнями и без них. Есть ожидания по времени выхода на 80% эффективности сотрудников разных уровней, например для P7 это 2-3 месяца, для P5 — полгода, для P4 — год и т.п. Отвечает за оценку качества обучения руководитель, тимлид. Для этого тимлид вовлекает часть своей команды и иногда соседних, в зависимости от уровня новичка. Тут предполагается, что в команде в целом есть какой-то метод оценки эффективности работы, вроде классического перф. ревью. Достаточно обучить двух новичков на уровне компетенций 2, так как тут AoE — команда.
> А вот как наладить оценку, чтобы не было злоупотреблений?
Кратко — делать калибровку нужным кругом людей, в зависимости от уровня. Чтобы выставить кому-то P4, тимлиду команды придется пройти калибровку у своего руководителя, который вовлечет пару своих пиров или пиров тимлида. Система без жестких метрик хороша тем, что для злоупотребления инженеру P5, претендующему на P4, пришлось бы обмануть своего руководителя, руководителя своего руководителя и пару их пиров. Не представляю, как на практике такое возможно.
> Как избежать случая, что в компании в момент все оказались в верхнем тире, и им нечего платить?
Не уверен, что понял, что конкретно вы называете «верхним тиром». Предположу, что вы имеете ввиду ситуацию вроде «как избежать ситуации, когда в команде из 5-ти человек в сумме с тимлидом все остальные четверо — P4». В таком случае. Во-первых, именно такое не произойдет, потому что им будет тесно и они уйдут раньше — так что давайте рассматривать вариант, когда там например два P4. Во-вторых, по мере развития команды заботливый руководитель подсказывает сотрудникам внешние по отношению в команде возможности, чтобы они не унывали в тесноте — так он преследует интересы более крупной команды чем своя, ведь он сам часть этой команды вместе с другими тимлидами. В-третьих, в процессе формирования команды безусловно нет смысла нанимать людей так, чтобы им через год стало тесно — в противном случае это ошибка найма, и тимлиду её и исправлять. В-четвертых, на коротком интервале времени до года, если так вышло, что команда более скилованная чем бюджет команды — это по сути эскалация из команды, поэтому тимлид этого тимлида может дать ему добро на временное завышение бюджета, если в целом хочет сохранить P4 на уровне своей более большой команды, поэтому тимлид тимлида будет искать для них возможности перевода между командами. Я могу написать еще с десяток правил, но пока не буду, т.к. не уверен, что правильно вас понял.
> Или то же самое, но уже потому, что бегут с низких тиров?
А почему люди должны бежать с нижних пиров? Можете пояснить, пожалуйста? У нас не было ни таких опасений ни таких кейсов, чтобы люди по итогам оценки на уровень P7 убегали куда-то.
> Ну и где статистика, как без неё понять эффективность?
В момент доклада у меня не было красивой статистики. Кратко, через год после окончания внедрения, она такая: 1) более 50% сотрудников находят такой подход полезным и развивающим их карьеру; 2) текучка кадров между 2018 и 2020 в юните где были полностью внедрены карьерные уровни снизилась в три раза.
Если я что-то пропустил из того — дайте знать, с радостью продолжу логн-рид. :)
Во-первых, вы правы, и некоторые темы действительно не раскрыты. Уточню, что формат доклада — 35-40 минут, а тут — лишь его конспект. И я уместил в этот интервал доклада то, что показалось мне наиболее важным.
Дальше постараюсь поделиться опытом, как делаем мы — в разрезе ваших вопросов.
В целом, мы стараемся рассматривать команду в первую очередь как коллектив людей, а не как сложный механизм с приборами и метриками. Поэтому жестких критериев в оценке людей мы в принципе не используем.
Также подход карьерных уровней полагает на то, что компания неплохо работала и без них, это очевидно не must-have практика в каждой инженерной организации со старта. Поэтому зачастую есть очевидные и неочевидные зависимости и предположения.
> Обучить сколько новичков нужно? Кто стоит со свечкой? А кто оценивает качество обучения?
Обучение новичков есть и с карьерными уровнями и без них. Есть ожидания по времени выхода на 80% эффективности сотрудников разных уровней, например для P7 это 2-3 месяца, для P5 — полгода, для P4 — год и т.п. Отвечает за оценку качества обучения руководитель, тимлид. Для этого тимлид вовлекает часть своей команды и иногда соседних, в зависимости от уровня новичка. Тут предполагается, что в команде в целом есть какой-то метод оценки эффективности работы, вроде классического перф. ревью. Достаточно обучить двух новичков на уровне компетенций 2, так как тут AoE — команда.
> А вот как наладить оценку, чтобы не было злоупотреблений?
Кратко — делать калибровку нужным кругом людей, в зависимости от уровня. Чтобы выставить кому-то P4, тимлиду команды придется пройти калибровку у своего руководителя, который вовлечет пару своих пиров или пиров тимлида. Система без жестких метрик хороша тем, что для злоупотребления инженеру P5, претендующему на P4, пришлось бы обмануть своего руководителя, руководителя своего руководителя и пару их пиров. Не представляю, как на практике такое возможно.
> Как избежать случая, что в компании в момент все оказались в верхнем тире, и им нечего платить?
Не уверен, что понял, что конкретно вы называете «верхним тиром». Предположу, что вы имеете ввиду ситуацию вроде «как избежать ситуации, когда в команде из 5-ти человек в сумме с тимлидом все остальные четверо — P4». В таком случае. Во-первых, именно такое не произойдет, потому что им будет тесно и они уйдут раньше — так что давайте рассматривать вариант, когда там например два P4. Во-вторых, по мере развития команды заботливый руководитель подсказывает сотрудникам внешние по отношению в команде возможности, чтобы они не унывали в тесноте — так он преследует интересы более крупной команды чем своя, ведь он сам часть этой команды вместе с другими тимлидами. В-третьих, в процессе формирования команды безусловно нет смысла нанимать людей так, чтобы им через год стало тесно — в противном случае это ошибка найма, и тимлиду её и исправлять. В-четвертых, на коротком интервале времени до года, если так вышло, что команда более скилованная чем бюджет команды — это по сути эскалация из команды, поэтому тимлид этого тимлида может дать ему добро на временное завышение бюджета, если в целом хочет сохранить P4 на уровне своей более большой команды, поэтому тимлид тимлида будет искать для них возможности перевода между командами. Я могу написать еще с десяток правил, но пока не буду, т.к. не уверен, что правильно вас понял.
> Или то же самое, но уже потому, что бегут с низких тиров?
А почему люди должны бежать с нижних пиров? Можете пояснить, пожалуйста? У нас не было ни таких опасений ни таких кейсов, чтобы люди по итогам оценки на уровень P7 убегали куда-то.
> Ну и где статистика, как без неё понять эффективность?
В момент доклада у меня не было красивой статистики. Кратко, через год после окончания внедрения, она такая: 1) более 50% сотрудников находят такой подход полезным и развивающим их карьеру; 2) текучка кадров между 2018 и 2020 в юните где были полностью внедрены карьерные уровни снизилась в три раза.
Если я что-то пропустил из того — дайте знать, с радостью продолжу логн-рид. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Карьерные уровни в компании