Метрики при разработке софта

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

Долгое время мир делился на теоретиков-апологетов метрик и практиков. Апологеты гордо и самоуверенно вещали: "Ну, мы же инженеры или не инженеры? Инженеры должны мерять! И ваще, процесс!" В качестве положительных примеров приводились случаи, когда тот или иной процесс применялся и продукт таки удавалось создать и шипнуть!

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

Инженеры меряют, но что?

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

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

Вот и с "созданием софта" так же история. Одно дело склепать типичный вебсайт типа брошюры или там, каталога с покупательской корзинкой. Это как завинчивать гайки на конвейере, меряй – не хочу. Вот только сайты создают не совсем инженеры, там работа ближе к индустриальному рабочему, потому и мерять такую работу легко, и проекты управляемые, если, конечно, заказчик не полный идиот и не меняет требования на лету каждый день, но тут уж не ваших рабоников надо мерять.

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

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

Много ли толку от метрик?

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

Допустим, у вас есть два проекта, которые по смете каждый стоит миллион. Проект А, после реализации, принесет фирме 100 миллионов, а проект Б только 2 миллиона.

Теперь скажите сами, для какого проекта важнее контролировать его стоимость? Проект Б, верно? Если вы ошибетесь с оценкой стоимости проекта в два раза, то проект А принесет 98 миллионов вместо 99, разница около одного процента, а вот проект Б окажется полностью бесприбыльным и безполезным.

Видите что получается? Чем более бесполезен проект, тем более важны метрики.

Этот вывод имеет еще одно интересное следствие: Чем более менеджмент озабочен метриками, тем более он неспособен находить или выбирать прибыльные проекты, на которых значение метрик менее значительно. По сути это значит, что чем более менеджмент озабочен метриками, тем более он, менеджмент, бесполезен для фирмы.

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

Баланс между риском и шампанским, или любовь – зла...

Я уже приводил этот пример в статье про экономику открытий, но рискну повторить его. Очень уж хорошо он описывает суть дела.

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

Во-первых, "открытый поиск" не входит в планы королевства, так что требуется спецификация. Спецификация, как обычно, включает задачу минимум и задачу максимум. В качестве задачи максимум записываются смутные воспоминания принца о его видении или там сновидении, а в задачу минимум вставляется упомянутое выше описание короля. Дальше начинается планирование work items – промежуточных задач, и milestones – этапов проекта для достижения результата.

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

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

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

К сожалению, драконов никто из менеджеров в глаза не видел, а допустить плохо определенный термин при планировании просто недопустимо. В результате задача второго этапа формулируется как "Добраться до места, указанного Бабой-Ягой. Сразить мечом животное, на которое укажет Баба-Яга." Правда, "место, указанное Бабой-Ягой" звучит несколько неопределенно, так что в задачу принцу так же ставится добиться, чтобы "указанное место" было в пределах X дней пути. По поводу величины X разворачивается длительная дискуссия, приводящая к тому, что после времени затраченного на дискуссию, на X остается не более одного дня.

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

В результате такого планирования получается техническое задание для принца:

Этап 1. Добраться до избушки Бабы-Яги.

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

Этап 3. Жениться на особе женского пола, которую охраняло сраженное животное и привезти ее обратно в королевство.

В общем, вы уже поняли, что женится наш принц на внучке Бабы-Яги, сразив козла, которого та пасла на лужайке огородом.

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

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

Что я пытаюсь сказать в этой статье, это то, что используя мудреные процессы для снижения риска (предсказуемое время) вы всего-навсего частично переводите процесс отрезания функциональности в начало проекта, и когда функциональности оказыватся так мало, что ее действительно можно запланировать – менеджмент рапортует о победе. Вот и получаются проекты, где "сразили животное и женились на особе женского пола, которую оно охраняло." И хорошо, если это – внучка Бабы-Яги, а не она сама, или там, коза, которая паслась рядом. Кстати, не оттуда ли взялась сказка о царевне-лягушке?

Послесловие к метрикам при разработке софта и опять об экономика открытий

В заключении к этой статье о метриках при разработке софта, хочу повториться (см. мою предыдущую статью "Экономика открытий") и сказать, что метрики можно использовать, но, как сказал Омар Хайам о вине, надо знать когда, и где, и с кем.

Разработка софта скрывает за собой очень разные виды деятельности. В некоторых случаях, проекты могут быть нивелированы до практически индустриальной эры, когда менеджер знает в точности, что надо делать, а работники просто выполняют его указания. Тут и метрик особенно не нужно, разве что такие простые типа количества закрученных за смену гаек. Иногда это проекты экономики знаний, где менеджер не знает, как конкретно достичь результата, но это знают работники, потому что они обладают знанием предмета. В этом случае обычно метрики можно использовать, хотя и куда сложнее.

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

• Автомобильная индустрия – конкуренция и постоянно меняющиеся требования покупателей. Гонка за экономичностью, безопасностью, маневренностью, комфортом. Три крупнейшие группы производителей – японские, европейские и американские, готовы друг друг глотку перерезать, не говоря уж о конкуренции внутри групп, Тойота проти Хонды и Ниссана, Даймлер против БМВ, Форд против GM и Крайслера... Неудивительно, что производители, оставшиеся в индустриальной эпохе, вроде Лады или Фиата большинству даже в голову не приходят, несмотря на то, что и те, и другие имеют свои наработки – Фиат, например, вроде бы лидер в экономичности, к сожалению, с непримлемой для многих мощностью двигателей.
• Авиастроение – все слыхали историю с Dreamliner от Боинга? Вот, кажется, ярчайший пример компании, застрявшей в экономике знаний, а то и индустриальной. Люди у них грамотные, образованные, а вот методы управления... Это ж насколько надо было плевать на людей, чтобы перевести штаб-квартиру компании из Сиэттла в Чикаго, просто потому что новый CEO с Восточного побережья!
• Тяжелое машиностроение – опять же гонка между японскими, европейскими и американскими производителями. Знаете разницу между экскаватором за полмиллиона и три миллиона? Бортовое ПО, которое знает как его выкрутить в стабильное положение, когда он стоит на крае котлована и его покачнуло к краю.
• Военная техника – вот уж индустрия, где победа в конкурентной борьбе буквально вопрос выживания.

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

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

Хотите два примера? Пример номер один: Россия начала 20-го века. Вся страна была еще по сути феодальной с какой-то степенью капитализма. Социализм нарос только в столицах и нескольких крупных городах, так что конфликт производительных сил и производственных отношений был весьма локализован географически. И все равно жахнуло так, что мало не показалось. Кстати, в феврале, а не октябре. Вся эта кодла Временного правтельства была по сути разношерстной смесью социалистов представляющих уже не капитализм или феодализм, а социализм – индустриальное общество.

Пример номер два? Ага, Россия конца 20-го века. Опять же, экономика знаний нарасла в столицах плюс нескольких крупных центрах. Вся глубинка была индустриальной, с отдельными вкраплениями микрокапитализма, специфического феодализма и даже местами первобытнообщинного строя. Конфликт производства и управления из-за прогресса производства опять весьма локализованный. И тем не менее, опять жахнуло.

По сравнению с Россией Америка имеет громадное преимущество – ее социализм корпоративный, а не государственный, так что она может ломаться и "перестраиваться" по кусочкам, отдельными компаниями или индустриями. Там, отдельно дот-комы, отдельно коммуникации, потом банки... Все равно неприятно, но полегче чем перестройка. Но если экономику открытий в производстве и дальше игнорировать, то выводов Маркса никто так и не отменял, и перестройка в рамках отдельно взятой фирмы тоже будет не мед, если окажешься в ней в этот момент.

Как обычно, кросс-пост с персонального блога.