Все в курсе, что такое WYSIWYG? Наверняка все. А я вот хочу поговорить про WYMIWYG – What You Measure Is What You Get, и почему в большинстве случаев метрики – это совсем не то, что вы хотите в менджменте программными проектами.
Ну, да, кросс-пост с персонального как обычно...
Метрики при разработке софта
Нет, правда, а как иначе? Инженеры мы или не не инженеры? Усё должно меряться. И вот приходит новый менеджер в команду и начинает писать спаслания: «Чего-то я сегодня не заметил, чтобы каждый девелопер, пришедший на работу, исправил бы баг. Нам надо исправлять по крайней мере по два бага на девелопера в день!» Метрика? Еще какая метрика. Осмысленная? Ну, если у вас 300 багов, 10 девелоперов, и две недели, то куда деться? И правда надо чинить по два бага в день. Однако... отгадайте, к чему такая метрика приведет?
Во-первых, люди – не дураки. Им зарплата нужна, а выпендриваться большинству (кроме законченных идиотов вроде меня) – лень. Так что, «командир сказал хорек, и никаких сусликов!» Сказано баги чинить, будем баги чинить. План по валу, вал по плану.
Теперь, о том, что метрика не мерит. Первым результатом в любой команде будет всплеск регрессий. Это когда каждый починенный баг вносит 1-2 новых. Это то, что вы хотели? Вряд ли, правда?
Впрочем, социалистического менеджера такие мелочи не остановят. Он и регрессии может померять. И после того, как он начал мерить все индикаторы, до которых он мог додуматься и увидеть, а люди научатся их имитировать, отгадайте, что происходит следующим?
Ага. Начинают страдать метрики, которые ему и в голову не могли придти. А менеджеру, который пишет такие письма, ясен пень, очень много чего в голову не приходит. Например, количество проблем, которые не видны при разработке, но всплывут как только продукт будет выпущен. Или качество отрываемых багов. Или процент принятия новых фичей, которые совершенно необходимы для успеха продукта, поскольку девы уже в курсе, что их меряют по багам, а не по фичам.
А еще, как думаете, тестеров, что, не меряют? Еще как меряют, и отгадайте как? По количеству открываемых багов. И вот тест начинает открывать тонны багов «Передвинуть кнопку на 2 миллиметра», а девы так же счастливо эти микробаги чинят, метрики и у тех, и у других взлетают под небеса, и вся продуктовая команда превращается в вариант счастливой семьи. И когда продукт выпускают, пользователь тоже начинает себя чувствовать в некотором роде в семье... и требовать развода.
Исторические корни метрик
Сейчас я скажу одну «мыслю», с которой многие не согласятся. Но я ее все-таки скажу. Исторические корни метрик – в социалистическом обществе. Помните, Владимира Ильича? «Социализм – это учет и контроль!» И правда. В социалистическом (индустриальном) общесте метрики работали отлично. Скажем, есть рабочий на заводе, заворачивает винты в правые передние дверцы машин на конвейере. Темп у него задан, так что завинтить он должен одно и то же количество винтов в смену. Зато количество винтов, которые не прошли контроль качества – это отличная метрика, чтобы мерить его производительность. Чем меньше винтов плохо закручено – тем лучше рабоник. Все просто, правда?
Конечно, и тут не все просто, поскольку контроль качества тоже надо мерять, и если их мерять по количеству найденных плохо закрученных винтов, представляете, что за террариум получится? Но тут дирекция сама виновата – надо знать что мерить. Контроль качества должен отвечать за количество гарантийных ремонтов, а не за найденные плохие винты, тогда все будет работать. Социализм, однако, по какую бы сторону океана вы ни находились.
Вы уже заметили проблему? После социализма, в экономике знаний, найти один параметр для измерений практически невозможно. А что самое главное, менеджер обычно не знает, что делают подчиненные. Совершенно не имеет значения, что он сам был девом всю свою жизнь и вот-вот выбился в маленькие начальники. Индустрия развивается умопомрачительно быстро и кластеризована донельзя. Сделайте два шага в сторону – и вы уже не в курсе что действительно важно, а что – ерунда. Дев хоть учиться может, а менеджеру на это времени нет – надо по митингам бегать и щеки надувать, чтоб не сьели.
Это – принцип экономики знаний: менеджер не знает, как действительно его подчиненные достигают результата. Именно это и делает экономику знаний экономикой знаний. Если бы это было не так, ваша фирма была бы обычной социалистической (индустриальной) фабрикой. А теперь сами подумайте, если менеджер реально не знает, как его подчиненные добиваются успеха, как он может мерять это?
Баги? Строки кода? См. выше.
Многие начинающие менджеры (несколько лет в менеджменте) высокомерно посмотрят на это и скажут, «Ну, я-то знаю, как они это делают!» Позвольте не согласиться. Вполне возможно, что вы можете сказать, кто из ваших людей вносит больший вклад в дело, а кто – меньший. Это вы должны быть способны, если вы – толковый менеджер. Так что в этом я с вами согласен. А вот в вашу способность найти магически вычисляемую цифру, по которой вы можете мерить людей – не верю!
Подумайте, Билл Гейтс и Стив Джобс ни использовали формальные метрики при управлении командами, когда они еще занимались этим. Что вам дает основания думать, что вы умнее их?
А чего это я все говорю?
Если вы следите за моими статьями, то вы уже в курсе, что я не из тех, кто плачется публике в передник. У меня обычно какая-то интересная мысль зудит по одной из моих любимых тем – эволюционный марксизм или корпоративные паразиты. Так что, чего это я на эту тему расписался?
Ну, эволюционный марксизм вы и сами увидели – то, что метрики – это тяжелое наследие уходящего социалистического общественного строя. Однако самое интересное не это, а то что... отгадайте, кто любит метрики в экономике знаний? Ага. Они, родимые. Корпоративные паразиты.
Сами посудите. Как только вас начинают мерять линейкой, вы знаете что симулировать. Вы знаете, как утилизовать ваши социальные связи. Вы знаете как использовать свое влияние в группе. Если вы – паразит-подчиненный, вы можете хватать легие баги и подсовывать трудные коллегам. Вы можете использовать свои связи с тест командой, чтобы разбивать баги в облако мелких. А уж если вам все-таки достанется трудный баг, вы знаете, как превратить его в проблему для всей группы, застопорить всю работу, чтобы никто не мог ничего чинить, и довести дело до того, что когда вы его все-таки почините, все вздохнут с облегчением и менеджмент еще долго будет восхищаться вашим подвигом. Если вы – паразит-мендежер, вы знаете как использовать баги, чтобы продвигать тех, кого хотите, и задвигать тех, кого хотите; как презентовать успехи высшему менеджменту который в разработке вообще ни в зуб ногой, поскольку пришел из маркетинга; вы знаете как держать людей в напряжении – не спрашивайте, зачем это нужно менеджерам-паразитам, никогда не мог этого понять, но подозреваю, что это «старый добрый принцип» держиморд «щоб боялись!»
Так что ради чего я пишу это статью – это чтобы напомнить, что корпоративная среда – это эволюционная среда. В эволюционной среде выживает наиболее приспособленный. Наиболее приспособленный – это вовсе необязательно наиболее полезный, в большинстве случаев это отнюдь не более полезный. Каждый раз когда вы меряете что-то, кроме сколько денег заработала фирма в результате усилий работника, вы меряете совсем не то, что вы на самом деле хотите. Измерить сколько денег заработала фирма на усилиях конкретного программиста, пи-эма, тестера, спеца по маркетингу обычно просто физически невозможно. Так что если вы их меряете, вы меряете не то, что хотите. А когда вы меряете не то, что хотите, вы получаете не то, что хотите. WYMIWYG, однако…
