Home

Автор: Джеральд Вайнберг (Gerald Weinberg)

Оригинал статьи: http://secretsofconsulting.blogspot.ru/2016/08/better-estimating-can-lead-to-worse.html

Перевод: Ольга Алифанова.

Эта статья – новая глава моей книги "Хотите стать (хорошим) менеджером?"

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

В те времена Том ДеМарко послал мне бесплатную копию своей книги "Контроль проектов разработки: менеджмент, измерение и оценки". К несчастью, я положил ее в сумку велосипеда вместе с куском барбекю, и произошел казус. Том, щедрой души человек, подарил мне еще одну копию.

Благодаря щедрости Тома я почувствовал себя обязанным прочитать книгу, которая была довольно хороша и без дополнительного соуса. В ней Том осторожно сообщает, что разработка ПО далека от зрелости, и поэтому меня удивил выход его статьи "Разработка ПО: достижение совершеннолетия". Неужели меньше чем за год наша отрасль таки достигла зрелости?

Как оказалось, заголовок был авторской неточностью, если судить по этой цитате:

"Для того, чтобы бизнес разработки ПО достиг зрелости, нам нужно улучшить наши расчеты. В течение последних двух лет были заложены основы внятной дисциплины оценивания…"

Статья была вовсе не про зрелость разработки ПО – это был скорее обзор состояния оценок и метрик в отрасли. Проведя обзор работ Барри Боэма, Виктора Базили, Каперса Джонса и Лоуренса Патнама, ДеМарко сообщает, что эти работы:

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

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

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

Оценки могут стать стандартом

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

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

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

Возьмем, к примеру, метрику "количество дефектов на N строк кода". Каперс Джонс цитирует организации, которые варьируют от 50 до 0.2, согласно этой метрике. Такой разброс соответствует моим собственным наблюдениям. Но я нахожу очень странным, что и компании с метрикой 50, и компании с метрикой 0,2 устанавливают свой уровень в качестве допустимого стандарта.

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

Когда я показал ему, что их проекты объективно сложны, он ответил, что, наверное, их затраты на разработку куда выше.

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

Суть я понимал, и еще как! Проблема была в нем самом. Он был убежден, что точно знает, как разрабатывать софт, и этим он и занимался – за счет больших издержек для собственных пользователей.

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

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

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

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

Грамотное использование оценок

Итак, как же использовать оценки эффективно, если вы хотите стать хорошим менеджером?

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

• Количество используемых языков программирования
• Опытность команды разработки
• Использование формальных код-ревью
• Процент ошибок на функцию
• Многие другие факторы.

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

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

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

Обсудить в форуме