Pull to refresh

Comments 11

(почти оффтопик) Волшебство всё-таки есть. Но не совсем то, что требуется: стоит начать использовать любую из упомянутых вами метрик для оценки разработчиков — и она превратится в тыкву.

Да, согласен, что оценка людей — последнее дело. Она никогда никого до добра не доводила.

Ну, оценивать всё-таки приходится (иначе придётся всем зарплату давать одинаковую или случайную). Главное в процессе не сломать что-то нужное :-)

Моё мнение, что любая оценка людей субъективна и оценивает в первую очередь того, кто эту оценку дает :-)
Особенно хорошо эффективность такой оценки видна в больших компаниях. Вернее, отсутствие какого-либо эффекта.
Я не понял. Судя по тексту, метрика — кол-во закрытых задач за единицу времени. Каким боком здесь участвует «Диаграмма суммарного потока»?
По диаграмме можно определить количество задач и время, за которое они были закрыты

Боже упаси от таких менеджеров, которые вместо управленческих решений смотрят в графики и считают скорость в задачах.
Такое усложнение и сужение взгляда на управление просто верх некомпетентности.
Не мешайте людям работать, смотрите на рузультат. Разработка ПО сильно сложнее чем снятие пары тривиальных метрик.
Меня всегда удивляет, тот факт, что айтишники в основном с техническим образованием. Но при этом менеджеры сложную модель разработки пытаются уложить в 2-3 метрики и на их основе принимать решение, один скрам с велосити чего стоит.
Нерадивые менеджеры отсутствие навыков управления пытаются компенсировать наличием нерелевантных метрик.

Приведите аргументы вместо обвинений.
Почему Вы считаете, что метрика нерелевантная?
Сотрудник А закрыл за сегодня 10 задач на каждую из которых ему понадобилось 5 минут (поменять цвет кнопки, добавить уведомление и т.п.)
Сотрудник Б закрыл за сегодня 1 задачу — добавление нового сложного функционала. И делал он ее 3 дня

По вашей «метрике» первый сотрудник молодец, а второй бездельник.
Я уже писал выше и еще раз повторю, что я категорически против оценки людей и использования метрик для оценки команд.

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

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

Посчитав текущую производительность конвейера и сравним её с целевой Вы сможете это понять, верно?
Ну, или как вариант, можно увеличить скорость работы одного человека

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

В общем то, эта метрика помогает покрыть прогностические нужды, вряд ли можно назвать ее «единственной» и «универсальной». При системном подходе к оценке производительности она все так же остается одной из.
Sign up to leave a comment.

Articles