Трюгве Реенскауг рассказал мне как-то еще одну историю. Однажды он предложил систему автоматического проектирования инженеру, который занимался разработкой морских нефтедобывающих платформ. Трюгве предложил, чтобы система автоматически отслеживала все виды работ, которые проводились на любой части платформы, и указывала их показатели. Однако в ответ услышал: "Достаточно будет, чтобы в системе хранились только номера телефонов. Я сам позвоню и узнаю, что было сделано".
В методологии я обозначаю это термином "невысокая точность" (low precision) [Co98]. Я прихожу к заключению, что большинство проектов вполне можно вести, руководствуясь (верными) не очень точными описаниями: не очень точную документацию по проекту легче читать, приводить в порядок и обсуждать. Архитектуру системы, изображенную с невысокой степенью точности, легче запомнить; в таблицах с не очень точно описанными требованиями легче расставлять приоритеты и легче оценивать масштабы сделанной работы на ранних стадиях проекта. Выполненная не очень точно проектная документация лучше передает "идею" проекта, после чего читатель может начать "ориентироваться в ситуации".
Создание артефактов с низкой степенью точности позволяет снизить стоимость работ за счет сильных качеств человеческой натуры. Для этого нужно делать особый упор на таких свойствах, как "хорошая ориентация" и непосредственная межличностная коммуникация, и стараться не обращать внимания на то, что обновления происходят не так часто, как нужно. Я использую эти принципы с 1994 года, и могу смело рекомендовать их как главный методологический элемент.
Одни люди любят составлять списки, а другие - нет. Одни предпочитают работать ночью, другие - днем. Одним нравится устанавливать дэдлайны, другим - нет. Точно так же разнятся и группы людей. В одних культурах всячески приветствуется публичная критика, в других самолюбие людей защищено лучше, и т.д.
Методологии, как правило, представляют собой набор правил для координирования работы группы людей, и то, что подходит одному человеку или группе, категорически не подойдет другому. То, что годится для работы в группе, принимающей решения сообща, не годится для культуры, где принято ждать решения босса.
Возвращаясь к приведенному выше перечню проектов, хочу отметить, что два примера успешного применения "высокодисциплинированной" методологии наблюдались в проекте для федерального сектора IBM и для Военно-воздушных сил. В области коммерческих разработок я такого не видел. Из этого можно сделать такое предварительное заключение: в государственном и военном секторе экономики есть некие дополнительные факторы, которые обеспечивают успешное применение тяжеловесной методологии. Те немногие опросы, которые я проводил в этих областях, пестрят фразами: "нам бы хотелось работать в более легкой и эффективной манере, но..". далее следуют ссылки либо на стандарты производства ПО для военной индустрии, либо на трудности в контролировании работы субподрядчиков. Интересно было бы узнать, являются ли такие факторы внутренне присущими этим областям или же военная и государственная культуры просто "предпочитают" тяжеловесность в разработках.
