Небольшая даже не замечание, а фантазия по поводу mySleep - надо понимать, что точность её будет крайне сильно зависеть от того, в каком порядке будут шедулиться нити и насколько хорошо они избавлены от блокирующих вызовов.
В примере шедулер перебирает нити последовательно. Можно пофантазировать и реализовать mySleep с выставлением времени оставшегося ожидания в описатель нити. И например обрабатывать это ожидание на уровне самого шедулера, а не после переключения в контекст нити. Вообще на неё не переключаться например. Или запускать её с большим приоритетом по истечении таймаута.
Хотя понятно, что в любом случае многозадачность тут кооперативная и зависшая нить не позволит шедулиться никому.
По годовой статистике не совсем согласен. Это зависит от проекта, может у вас и правда так. Но часто видел, что на сложных проектах разные части системы поддерживаются разными разработчиками. И, соответственно, и баги у них отличаются по сложности этих частей. Если система однородная, то, может, и выровняется.
Про ручной труд - у меня сложилось впечатление, что в предложенном подходе его не сильно меньше, чем при обычной оценке по дейликам и списанному времени. А где ручной труд, там и субъективизм. Просто тут он более "гранулярный", что ли.
В конечном то счете смысл всех оценок должен быть в оценке импакта на бизнес, а не на количество кода или строк документации.
Короче - время покажет. Наверняка же вы дорабатывать и корректировать что-то будете в этой схеме. Интересно, к чему придёте.
"если человек приходит на работу, значит он скорее всего что-то делает"
Это утверждение не просто спорное, оно ложное. То что человек приходит на работу значит только то что он сидит на стуле на территории работодателя. Больше ничего.
"вряд ли работа одного и того же разработчика будет состоять только из фикса багов повышенной сложности"
Если ваш коллектив не состоит из одинаковых клонированных сотрудников - перекос по сложности решаемых багов будет обязательно.
"В данном случае можно периодически проводить ревью созданных страниц"
"Ответ – не пропускать такие mr на ревью."
То есть система, предназначенная для упрощения и автоматизации оценки производительности сотрудников требует ручной работы и микроменеджмента.
Выглядит так, что это все применимо только на эталонной галере в вакууме с обезличенными сотрудниками. Откуда там мотивация у сотрудников "не пропускать на ревью" такие мр-ы - не понятно.
У меня сложилось впечатление, что у автора либо очень узкий опыт по типам компаний, либо малый опыт управления командой. Обычно такое и приводит к поиску "волшебной спасительной формулы". Может, вам стоит посмотреть в сторону разбиения команды на подгруппы с ответственными за эти подгруппы, а не пытаться охватить в одного всё с использованием сомнительных формул?
Спасибо за отличную статью!
Небольшая даже не замечание, а фантазия по поводу mySleep - надо понимать, что точность её будет крайне сильно зависеть от того, в каком порядке будут шедулиться нити и насколько хорошо они избавлены от блокирующих вызовов.
В примере шедулер перебирает нити последовательно. Можно пофантазировать и реализовать mySleep с выставлением времени оставшегося ожидания в описатель нити. И например обрабатывать это ожидание на уровне самого шедулера, а не после переключения в контекст нити. Вообще на неё не переключаться например. Или запускать её с большим приоритетом по истечении таймаута.
Хотя понятно, что в любом случае многозадачность тут кооперативная и зависшая нить не позволит шедулиться никому.
По годовой статистике не совсем согласен. Это зависит от проекта, может у вас и правда так. Но часто видел, что на сложных проектах разные части системы поддерживаются разными разработчиками. И, соответственно, и баги у них отличаются по сложности этих частей. Если система однородная, то, может, и выровняется.
Про ручной труд - у меня сложилось впечатление, что в предложенном подходе его не сильно меньше, чем при обычной оценке по дейликам и списанному времени. А где ручной труд, там и субъективизм. Просто тут он более "гранулярный", что ли.
В конечном то счете смысл всех оценок должен быть в оценке импакта на бизнес, а не на количество кода или строк документации.
Короче - время покажет. Наверняка же вы дорабатывать и корректировать что-то будете в этой схеме. Интересно, к чему придёте.
"если человек приходит на работу, значит он скорее всего что-то делает"
Это утверждение не просто спорное, оно ложное. То что человек приходит на работу значит только то что он сидит на стуле на территории работодателя. Больше ничего.
"вряд ли работа одного и того же разработчика будет состоять только из фикса багов повышенной сложности"
Если ваш коллектив не состоит из одинаковых клонированных сотрудников - перекос по сложности решаемых багов будет обязательно.
"В данном случае можно периодически проводить ревью созданных страниц"
"Ответ – не пропускать такие mr на ревью."
То есть система, предназначенная для упрощения и автоматизации оценки производительности сотрудников требует ручной работы и микроменеджмента.
Выглядит так, что это все применимо только на эталонной галере в вакууме с обезличенными сотрудниками. Откуда там мотивация у сотрудников "не пропускать на ревью" такие мр-ы - не понятно.
У меня сложилось впечатление, что у автора либо очень узкий опыт по типам компаний, либо малый опыт управления командой. Обычно такое и приводит к поиску "волшебной спасительной формулы". Может, вам стоит посмотреть в сторону разбиения команды на подгруппы с ответственными за эти подгруппы, а не пытаться охватить в одного всё с использованием сомнительных формул?