ЭПИЦЕНТРЫ
Питер Коффи
Член совета директоров Lockheed Martin и бывший президент этой компании Норман Августин широко известен своими остроумными изречениями, получившими название законов Августина. Один из самых популярных его выводов гласит, что производительность труда во всех сферах распределяется на удивление однообразно. И полицейские аресты, и футбольные голы, и полученные патенты, как выяснил Августин, подчиняются общему правилу. Согласно ему, половину работы в любой группе выполняет одна пятая часть коллектива, тогда как на его худшую половину приходится одна пятая часть сделанного. В связи с этим, как мне кажется, сопоставление средней производительности разных групп теряет всякий смысл. Когда собираешься создать команду экстра-класса, очень важно разобраться и в том, какими могут оказаться самые слабые ее звенья.
Разительные примеры разрыва между лучшими и худшими демонстрирует, например, разработка ПО. Это очень точно подметил еще в 1981 г. Барри Боэм в своей нашумевшей книге "Software Engineering Economics" ("Экономика программного инжиниринга"): "При прочих равных условиях 90-я процентиль команды аналитиков и программистов будет работать примерно в 4 раза производительнее 15-й ее процентили". Другими словами, работодателю выгодно нанимать только самых лучших специалистов остальные же дают только видимость экономии. Даже если классному специалисту нужно платить втрое больше, это все равно может оказаться оправданным.
При создании ПО производительность трудно не только измерить. Порой возникают проблемы даже с определением этого понятия. Чтобы ограничиться меньшим количеством строк, приходится дольше работать. К тому же такая оптимизация чревата неуловимыми ошибками. Августин честно предупреждает: "На последние 10% прироста скорости приходится треть общей цены и две трети проблем". Тем не менее пользователи зачастую настаивают на том, что без этого им не обойтись.
| Когда собираешься создать команду экстра-класса, очень важно разобраться и в том, какими могут оказаться самые слабые ее звенья. |
К сожалению, представляя итоги исследования MIT Center for eBusiness, я попался в обе ловушки. Во-первых, я начал сравнивать общие показатели, а во-вторых, не стал разграничивать разные задачи. За прошедшее с тех пор время выяснилось, что в полученных исследователями результатах данные неправомерно занижены, и я чувствую себя просто обязанным представить на суд читателя обновленные цифры.
В исходном докладе содержится серьезная ошибка: отсутствие ответа здесь представлено нулевым значением, чего, конечно, делать ни в коем случае нельзя. После выявления этой погрешности исследователи либо заполнили соответствующие графы реальными цифрами, либо исключили такие проекты из выборки.
Окончательные результаты анализа 104 проведенных по всему миру проектов были опубликованы в IEEE Software за ноябрь декабрь 2003 г. В соответствии с ними, в течение первых 12 месяцев после появления нового продукта отмечалось в среднем 15 ошибок на 100 тыс. строк исходного текста. С сожалением должен отметить, что это в 5 раз больше той цифры, которую я привел на основании более ранних итогов исследования, опубликованных в прошлом году. Следует также иметь в виду, что в докладе используются срединные, а не средние значения это позволило нейтрализовать влияние изолированных экстремальных величин, которые могут сильно сказаться при анализе сравнительно небольших статистических выборок.
По регионам различия оказались еще больше. В 27 японских проектах срединное значение составило всего две ошибки на 100 тыс. строк, т. е. половина имела больше, а другая половина меньше. В категории "Европа и прочие" 22 проекта распределились поровну, и на 100 тыс. строк приходилось чуть меньше 23 ошибок. В Индии, где было проанализировано 24 проекта, ошибок оказалось несколько больше 26.
В 31 американском проекте нашлось в среднем по 40 ошибок на 100 тыс. строк. М-да... Правда, программисты США опережали своих индийских коллег по производительности: каждый из них пишет по 270 строк кода в месяц, а индийцы по 209. Но те и другие сильно уступают и японским (469), и остальному миру (436).
Авторы доклада торопятся предупредить (что, кстати, и мне стоило бы четче сформулировать в предыдущей колонке): "Отклонения в производительности труда между отдельными регионами могут быть частично связаны с различиями в характере проектов, используемых аппаратных платформах, стиле программирования, категориях потребителей и требованиях к надежности. Вследствие этого приводимые цифры справедливы только для данной выборки и основой для планирования производительности труда в том или ином регионе служить не могут". Что ж, замечание вполне уместное.
Измерять показатели, сопоставлять цифры и продумывать грядущие решения еще до начала сбора данных очень нужно. И мне даже страшно подумать: вдруг кто-то публично уличит меня, что я сам не всегда следую этой рекомендации. 4 С редактором eWeek Питером Коффи можно связаться по адресу: peter_coffee@ziffdavis.com.
