Deadline. Роман об управлении проектами - ДеМарко Том - Страница 42

В это время Белинда выбралась из бассейна и стала бодро растираться полотенцем.

— Привет, босс! Ну, что?

— Прекрати брызгаться!

— Извини. Так что у тебя?

— Сочиняю загадки, а потом размышляю над их решением. Присоединяйся.

— С удовольствием, — Белинда положила полотенце на соседний шезлонг, села сверху и набросила на себя свисающий край, как тунику. — Итак, где же загадка дня?

— Думаешь, она одна? Даже не надейся, — улыбнулся мистер Томпкинс, но улыбка получилась несколько мрачноватой. — Для начала возьмем неточную спецификацию. У меня два вопроса. Во-первых, почему ее так написали? И во-вторых, почему этого никто не заметил? Я имею в виду, никто, кроме тебя. Ведь все остальные, и я в том числе, считали, это нормальная спецификация, просто мы недостаточно хорошо знаем предмет, чтобы ее понять!

— Непростой вопрос. Давай я сначала попробую объяснить кое-что попроще, а уже потом отвечу на твою загадку. Почему никто в нашей замечательной команде программистов не забил тревогу и не сказал во всеуслышание: «Это же дерьмо, а не спецификация?» Если бы документ был написан хоть немного лучше, можно было бы подумать, что наши ребята решили додумать недостающие детали самостоятельно. Это нормальный, профессиональный подход любого хорошего разработчика. Но в данном случае спецификация не просто плоха. Она отвратительна. Это выдающийся пример того, как нельзя писать подобные документы. Так почему же они нам об этом не сказали сами?

— Да, почему?

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

— Конкуренцию со спецификацией?

— Да нет же. Между собой. Я считаю, что в каждом из нас, в душе или на уровне подсознания, живет тайный страх: мы боимся показать, что соображаем хуже других. Вся наша раса заражена этим страхом. Каждый готов предположить, что его мыслительные способности ниже средних, поэтому ему надо прикладывать дополнительные усилия, чтобы разобраться в том, в чем другие разбираются с ходу. А теперь возьмем нашу ужасную спецификацию. Ты читаешь ее целый день и обнаруживаешь, что ничего не понимаешь. И тут приходит начальник и спрашивает: «Ну как? Как вам спецификация?» Что сказать? И мы врем! «Все в порядке, босс. То есть я хочу сказать, что документ этот весьма непростой, но дайте нам еще немного времени, и мы во всем разберемся…» И так поступает каждый!

— И поэтому никто не говорит, что спецификация никуда не годится.

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

— А как ты с этим борешься? Разве у тебя нет внутренних сомнений и комплексов?

— Вебстер, и ты задаешь этот вопрос даме, которая по ночам спит в парке под пальмой? Странный ты человек. Конечно, у меня есть внутренние сомнения, как и у любого другого. Но на этом я уже давно обожглась и усвоила урок. Мне хорошо известно, что иногда попадаются спецификации, которые никуда не годятся. У меня даже есть несколько правил, которые помогают мне определить, насколько хорошо написана спецификация программы.

— Расскажи, пожалуйста. Очень хочется узнать, что же это за правила.

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

— То есть получается, что даже если система очень и очень сложная, вся сложность заключается в первой части — правилах.

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

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

— По меньшей мере! Конечно, это автоматически не делает спецификацию прекрасной и полезной, но, по крайней мере, с ней можно работать. В нашей спецификации ничего такого и в помине нет.

Некоторое время мистер Томпкинс молча обдумывал услышанное.

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

— Знаешь, мне так не кажется. Тут дело кое в чем другом. На этот счет у меня тоже есть своя теория, но о ней позже. Для начала я хотела бы еще раз подчеркнуть, что, независимо от сложности системы, ты всегда можешь довольно просто описать входящие и исходящие данные. А теперь представь себе другую спецификацию системы для управления аэропортом. Всего на двадцати страничках, где подробно, последовательно описаны все типы входящей и исходяшей информации, все они поименованы. Чем более важна входящая и исходящая информация для системы, тем более подробным описанием она сопровождается: здесь могут даже описываться сами сигналы и, может быть, уровни напряжения, длительности импульсов и т. п. Допустим, на двадцати страницах такой спецификации описывается двадцать типов входящей информации и тридцать — исходящей. А в первой части стоит всего одна фраза: «Перечисленные ниже типы входящей и исходящей информации каким-то стандартным образом связаны друг с другом». Ну, как тебе такая спецификация?

— Ужасная спецификация. Белинда, это же самая недоделанная и туманная спецификация, какую только можно вообразить!

— Что касается первой части — да. Но зато в ней есть и вторая часть — перечисление данных, с которыми работает система. Другими словами, вторая часть просто превосходная, а вот первая почти отсутствует.

— Ну, и что же ты этим хочешь сказать?

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

Сейчас мистер Томпкинс уже не сомневался в том, что Белинда права. Но ее объяснение только добавило новых вопросов:

— Белинда, но зачем, почему они составили вот такую спецификацию? Кому нужен документ, с которым все равно никто не сможет работать?

— Знаешь, я, кажется, догадалась, — весело рассмеялась Белинда. — Поначалу это было не так уж просто сделать, но теперь, когда я знаю основное правило, частности уже не мешают видеть всю картину.