Известная фраза “Нельзя управлять тем, что не измеряешь” приписывается разным уважаемым управленцам: Джеку Уэлчу из GE, Эдварду Демингу, отцу QA, возможно ещё кому-то. Некоторые считают, что это народная пословица – общеизвестная истина, сформулированная кратко и ёмко. Действительно, выстраивая систему управления неплохо бы сделать так, чтобы принимаемые решения опирались на объективные данные, а не мнение отдельных участников о состоянии дел. В этом случае решения могут быть более взвешенными, а потому – более результативными.

Занимаясь организацией процессов управления, скажем, в ITSM, современный консультант не забудет про KPI и метрики. Разрабатывая для заказчика регламент какого-либо процесса, управления инцидентами, проблемами, конфигурациями, изменениями, уровнем услуг… – любого процесса, консультант добавит в этот регламент необходимые слова про точки измерения, выполнение оценки, принятие решений. Более того, не просто добавит слова, а приложит все усилия, чтобы практика измерения у заказчика появилась, прижилась, дала результаты.

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

Некоторые команды ничего не измеряют вовсе. Они объективно не знают про свой процесс ни-че-го. Люди просто ходят на работу и что-то делают, а на совещаниях и прочих контрольных мероприятиях пространно рассуждают, а то и дают невыполнимые обещания.

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

Некоторые команды разработки ПО всё ещё (в 2019-м!) исповедуют проектное управление, а потому имеют и менеджера проекта, и календарный график, и полный набор заблуждений относительно проектного управления как способа получения результата.

То есть – исходная ситуация схожа с той, что мы наблюдали лет 15 назад в области ИТ-эксплуатации.

Теперь предположим, что есть попытка навести порядок и в процессе разработки, и в измерении этого процесса. Такая попытка встретит большое сопротивление. Сопротивление может иметь разную форму.

Одни вам скажут, что метрики неизвестно как собирать и верить данным нельзя (враки, конечно).

Другие посетуют, что ничего не понятно (несмотря на состоявшиеся обучения и разъяснения).

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

Четвёртые будут всё же регистрировать события, на основе которых формируется измерение, но таким образом, что в полный рост невооружённым глазом виден принцип “garbage in – garbage out”.

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

Активно или пассивно, осознанно или бессознательно, но сопротивление измерению в разработке ПО присутствует и мешает. Мешает в первую очередь тем, что замедляет любую трансформацию – то, что можно было сделать за месяц-два, получается сделать наполовину за год. Простите, это никуда не годится.

К сообществу нашего портала у меня два вопроса:

1. Почему так? Чем принципиально отличается область разработки ПО от области эксплуатации?
2. Что с этим делать? Действовать убеждением, или жёстко? Как не потратить на вопрос измерения (всего лишь один из вопросов трансформации!) месяцы и кварталы?

Буду рад услышать ваши соображения и ваш опыт.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Построение системы KPI для ИТ

Как обеспечить управление процессами, проектами, услугами, персоналом