Products | People | Process

Часто подымается вопрос, как померить программистов или инженеров, ввести метрики или KPI для объективности. Мы экспериментировали с ними с середины 2000х и в целом опыт негативный. Дело в том, что при появлении "метрики" люди склонны оптимизировать "метрику" вместо реального результата, который всегда сложнее. Проблема здесь не в метриках как таковых, а в их неполносте - очень сложно подобрать в разработке такой комплект метрик, который будет действительно полно характеризовать чей-то труд.

Приведу несколько примеров сверх классической копи-пасты в ответ на оценку по числу строк кода:

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

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

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

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

И так далее. Во всех случаях от простой метрики можно легко уйти.
В китае ввели социальный рейтинг по куче метрик - появилось устройство, которое симулирует, что ты много ходишь (и появилась скидка на мед.страховку). SEOшники постоянно пытаются хакнуть метрики поисковиков.

Сложность метрик можно проиллюстрировать таким примером. У вас наполнена водой ванна, но вода вытекает медленно, и чтобы она вытекала быстрее - вы стукаете рукой по воде (стимулируете метрикой). Какой итог? Только брызги. У воды есть куча вариантов куда ей пойти с меньшим трудом, чем заталкиваться в ту дырку. Как это решается в гидравлике? Ну конечно - делается цилиндр, поршень и в шприце, ваше усилие превращается строго в усиление оттока жидкости.

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

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

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

Таким образом, при попытках внедрения метрик важно понимать свою ситуацию, чтобы не оказаться обрызганным водой в ванной. Грубо говоря, важно отследить, что попытки оптимизации отдельных метрик в ущерб реальному результату будут минимизированы через
1) развитый детальный контролль за "взломами"
2) полноту набора метрик и их устойчивость к "взлому"
3) выигрыш от "взлома" метрики не оправдывает необходимых затрат на "взлом" (включая риск спалиться)

www.tg-me.com/us/telegram/com.program_man/23

1.45K viewsMay 8, 2018 at 05:06

Часто подымается вопрос, как померить программистов или инженеров, ввести метрики или KPI для объективности. Мы экспериментировали с ними с середины 2000х и в целом опыт негативный. Дело в том, что при появлении "метрики" люди склонны оптимизировать "метрику" вместо реального результата, который всегда сложнее. Проблема здесь не в метриках как таковых, а в их неполносте - очень сложно подобрать в разработке такой комплект метрик, который будет действительно полно характеризовать чей-то труд.

Приведу несколько примеров сверх классической копи-пасты в ответ на оценку по числу строк кода:

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

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

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

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

И так далее. Во всех случаях от простой метрики можно легко уйти.
В китае ввели социальный рейтинг по куче метрик - появилось устройство, которое симулирует, что ты много ходишь (и появилась скидка на мед.страховку). SEOшники постоянно пытаются хакнуть метрики поисковиков.

Сложность метрик можно проиллюстрировать таким примером. У вас наполнена водой ванна, но вода вытекает медленно, и чтобы она вытекала быстрее - вы стукаете рукой по воде (стимулируете метрикой). Какой итог? Только брызги. У воды есть куча вариантов куда ей пойти с меньшим трудом, чем заталкиваться в ту дырку. Как это решается в гидравлике? Ну конечно - делается цилиндр, поршень и в шприце, ваше усилие превращается строго в усиление оттока жидкости.

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

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

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

Таким образом, при попытках внедрения метрик важно понимать свою ситуацию, чтобы не оказаться обрызганным водой в ванной. Грубо говоря, важно отследить, что попытки оптимизации отдельных метрик в ущерб реальному результату будут минимизированы через
1) развитый детальный контролль за "взломами"
2) полноту набора метрик и их устойчивость к "взлому"
3) выигрыш от "взлома" метрики не оправдывает необходимых затрат на "взлом" (включая риск спалиться)

BY Products | People | Process