Моя бывшая коллега, Марина Коледа (одна из самых больших потерь Интервэйла в 2014-м), на LinkedIn дала ссылку на еще одну статью про KPI для разработчиков софта: KPIs are for the Lazy. Статья на английском, не очень большая, читается легко. Для себя ничего нового я там не нашел, но в качестве еще одного аргумента против внедрения KPI для программистов вполне сойдет.
Однако, читая эту статью про KPI, я подумал об еще одной проблеме KPI, и не только KPI, но и вообще систем формальных показателей, важность которой я осознал только читая книги Генри Минцберга о менеджменте. А именно: любые результаты анализа или оценки формальных показателей могут показать вам уже случившиеся проблемы. И, зачастую, это уже слишком поздно. Грубо говоря, когда руководитель компании видит катастрофическое падение прибыли по итогам квартала (полугодия, года), то времени на исправление уже может и не быть (тут в тему мой недавний пост про Рона Джонсона в JC Penney).
Еще раз: результаты оценки каких-то формальных показателей за определенный, но уже прошедший, интервал времени показывают вам случившиеся последствия принятых ранее решений.
Соответственно, чем больше времени прошло с момента принятия решения до получения "объективных доказательств" сейчас, тем меньше возможностей для исправления уже возникших проблем. Этот фактор "лага по времени" прекрасно осознается теми, кто внедряет KPI. Но устраняют его последствия они очевидным, простым, но неправильным способом: уменьшением лага, а не поиском других средств и способов диагностирования и устранения проблем на самой ранней стадии.
Т.е., руководство прекрасно понимает, что если оно будет снимать показатели успешности работы программистов раз в квартал, то это плохо, слишком много проблем может накопиться за это время. Поэтом естественным шагом для них является уменьшение интервала для сбора показателей: раз в месяц, раз в неделю, каждый день. Если кому-то кажется, что я утрирую, то это не так. Бывают случаи, когда от разработчика требуется отчет по всем активностям за день, с точностью до 15 минут.
При этом, преследуя цель достижения максимальной прозрачности, и получая подробные отчеты за каждый день работы каждого программиста, руководство, на самом-то деле, оказывается еще дальше от реальной картины происходящего. Поскольку в буквальном смысле "за деревьями леса не видно": информации о деятельности каждого сотрудника настолько много, что в ее объеме тяжело ориентироваться.
Да, становится возможным узнать, что некий Вася Иванов перестал крутить гайку №6 ключом на 16 в середине дня в среду. После чего два дня откручивал гайку №7 ключом на 15 и потратил на это на час больше, чем планировалось. Именно такая информация становится важной. Хотя акцент нужно было бы делать совсем на других вещах. Например, а почему гайку №6 крутил Вася Иванов, а не Ваня Федоров? И почему гайку №7 начали откручивать только после того, как закрутили гайку №6? И зачем вообще потребовалось крутить эти гайки?
Т.е. внедряя подробные KPI и имея возможность "по щелчку" видеть "актуальные отчеты о текущем положении дел" руководство начинает пребывать в уверенности, что обладает хорошим диагностическим инструментом. Который, действительно, хорошо выражает тяжесть случившейся проблемы в количественном выражении. Но на самом-то деле, нужна возможность определять симптоматику на самых-самых ранних стадиях. В общем, как в каком-то голливудском фильме: "Вы дали ему то, что он просил. Я же дал ему то, что ему было нужно".
Если кто-то из читателей считает, что вещи, которые я противопоставляю, на самом деле не противоречат друг другу, и можно в разработке ПО отдельно разруливать смысл работы (т.е. нужно ли вообще крутить гайку №6) и ее эффективность* то прошу поделиться опытом, где и как такого удалось достичь и как долго сие благолепие продолжалось. Мне же почему-то вспоминается один специалист по управлению проектами, выходец из большой компании с отлаженными рабочими процессами, просравшей при этом все что можно было просрать и переставшей в итоге существовать, который с большим удивлением у меня спросил: "Как, а вы разве в конце рабочего дня не прашиваете своих разработчиков о том, что они успели сделать за день?" К сожалению, я был тогда настолько шокирован этим вопросом, что не смог ответить, что мы до тех пор все делали качественно и в срок, пока у нас не стали спрашивать, а что же мы успели сделать за день :(
Ну и, вспоминая о том, что к теме KPI для программистов я возвращаюсь в блоге регулярно, не могу не прорекламировать еще раз свою недавнюю серию "Вновь KPI: подмена понятий и погоня за краткосрочным эффектом". Отбросив не нужную на данный момент скромность могу сказать, что это чуть ли не лучшее, что я видел написанного на русском языке на тему KPI для программистов ;)
Комментариев нет:
Отправить комментарий