среда, 23 апреля 2014 г.

[work.thoughts] Вновь KPI: подмена понятий и погоня за краткосрочным эффектом (часть вторая)

Продолжение, первая часть здесь.

Еще одной серьезной проблемой KPI является ограниченный временной интервал, на котором производится "съем параметров". Например, существуют квартальные и годовые показатели эффективности, итоги по которым подводятся в конце квартала и в конце года.

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

Много лет назад мы с другом занимались проведением олимпиады по программированию в местном университете. Среди прочих была несложная задача по поиску оптимального плана дозаправки автомобиля. Автомобиль должен проехать из пункта A в пункт B, одной заправки автомобиля на этот путь может не хватить. Но по дороге расположены автозаправки с разной стоимостью топлива. Нужно найти оптимальный план заправки автомобиля, чтобы стоимость заправок по дороге из A в B оказалась минимальной. Известен объем бака, расход топлива на милю пути, но при этом на заправке можно заполнять бак только до полного объема (т.е. если в бак можно залить 15л топлива, то нужно именно 15л и залить, меньше нельзя).

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

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

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

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

Допустим, компания отметила свой 5-й день рождения. И для сотрудников определяются KPI на 21-й квартал. На двадцать первый! Т.е. этот временной отрезок уже составляет всего лишь 1/20 от времени жизни компании.

А если компании не 5 лет, а 15? Очередной квартал для нее будет всего лишь небольшим отрезком в 1/60 от общей продолжительности ее жизни.

А если не 15, а 30? Не 30, а 60?...

Какой смысл концентрироваться на сборе и оценке показателей эффективности отдельных сотрудников компании на столь коротких отрезках ее жизни? Да еще и учитывая, что происходит концентрация на локальных оптимумах, сумма которых на столь больших интервалах может привести к очень неоптимальному глобальному итогу.

Представьте себе, что компания прожила 10 лет и хочет прожить еще, как минимум, два раза по столько. И для этого ей нужно провести серьезную реорганизацию и снизить темпы своего развития на 1.5-2 года. Два года даже по отношению к уже прожитым 10 годам не так уж много, а по отношению к планируемым 30 годам вообще не критичны. Но, два года -- это восемь кварталов. Восемь кварталов подряд, в течении которых показатели компании будут снижаться, а количество проблем и геморроя -- увеличиваться. Попробуйте представить себе восемь кварталов подряд, в течении которых нормальных KPI вообще не будет.

С другой стороны, допустим, что эти восемь кварталов будут потрачены на поиски локальных оптимумов в каждом из кварталов. Чтобы численные показатели хорошо выглядели здесь и сейчас. И в течении которых для достижения красивых квартальных отчетов по KPI принимаются решения, пагубные в долгосрочной перспективе. Как вы думаете, хватит ли 10-летней компании, столкнувшейся с проблемами роста и необходимостью реорганизации запаса прочности, чтобы пережить эти два года движения не туда?

Так что это еще одна очень большая проблема KPI: концентрация на краткосрочных выгодах вместо долгосрочных.

Возможно, долгосрочные перспективы сейчас никого и не интересуют. Вроде как по статистике, изрядная часть компаний умирает не достигнув и 3-х летнего возраста, а подавляющее большинство живут не более 13-14 лет. Немногие пережившие 15-летний рубеж доживают до 50-60 лет, но все равно исчезают. И лишь считанные единицы продолжают жить после 60-летней отсечки.

Однако, если посмотреть на тот же Microsoft (компания основана в 1975-м, почти 40 лет назад) или Oracle (1977-ой)... Или даже на Google (1998-й) или Facebook (2004). Или основанные на просторах бывшего СССР: 1C (1991-й), EPAM Systems (1993-й), Лаборатория Касперского (1997-й), то окажется, что успешных софтверных компаний с более чем десятилетней историей не так уж мало.

Продолжение следует.

Комментариев нет:

Отправить комментарий