Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения

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

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

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

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

В методологии я обозначаю это термином "невысокая точность" (low precision) [Co98]. Я прихожу к заключению, что большинство проектов вполне можно вести, руководствуясь (верными) не очень точными описаниями: не очень точную документацию по проекту легче читать, приводить в порядок и обсуждать. Архитектуру системы, изображенную с невысокой степенью точности, легче запомнить; в таблицах с не очень точно описанными требованиями легче расставлять приоритеты и легче оценивать масштабы сделанной работы на ранних стадиях проекта. Выполненная не очень точно проектная документация лучше передает "идею" проекта, после чего читатель может начать "ориентироваться в ситуации".

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

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

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

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

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