Шрифт:
— Значит, в спецификации должны быть по меньшей мере данные по входящей и исходящей информации. Причем каждому элементу нужно дать имя и указать, к какой части системы он относится.
— По меньшей мере! Конечно, это автоматически не делает спецификацию прекрасной и полезной, но, по крайней мере, с ней можно работать. В нашей спецификации ничего такого и в помине нет.
Некоторое время мистер Томпкинс молча обдумывал услышанное.
— Ну что ж. Возможно, это объясняет качество нашей спецификации. Допустим, система, которую они пытались описать, была настолько сложной, что писатели просто запутались в ней, исписали три сотни страниц, а про вторую, простую часть, забыли. Можно даже решить, что система такого типа слишком сложна и ее невозможно описать в спецификации.
— Знаешь, мне так не кажется. Тут дело кое в чем другом. На этот счет у меня тоже есть своя теория, но о ней позже. Для начала я хотела бы еще раз подчеркнуть, что, независимо от сложности системы, ты всегда можешь довольно просто описать входящие и исходящие данные. А теперь представь себе другую спецификацию системы для управления аэропортом. Всего на двадцати страничках, где подробно, последовательно описаны все типы входящей и исходяшей информации, все они поименованы. Чем более важна входящая и исходящая информация для системы, тем более подробным описанием она сопровождается: здесь могут даже описываться сами сигналы и, может быть, уровни напряжения, длительности импульсов и т. п. Допустим, на двадцати страницах такой спецификации описывается двадцать типов входящей информации и тридцать — исходящей. А в первой части стоит всего одна фраза: «Перечисленные ниже типы входящей и исходящей информации каким-то стандартным образом связаны друг с другом». Ну, как тебе такая спецификация?
— Ужасная спецификация. Белинда, это же самая недоделанная и туманная спецификация, какую только можно вообразить!
— Что касается первой части — да. Но зато в ней есть и вторая часть — перечисление данных, с которыми работает система. Другими словами, вторая часть просто превосходная, а вот первая почти отсутствует.
— Ну, и что же ты этим хочешь сказать?
— Я хочу сказать, что при всем ее очевидном несовершенстве с такой спецификацией можно было бы начинать работу над системой для аэропорта. Более того, это спасло бы их от провала проекта, от судебной тяжбы и прочих неприятностей. Разработчики прочли бы эти самые двадцать страниц и через какое-то время предложили бы свое видение отсутствующей первой части — логики работы системы. Потом они показали бы результат другим участникам проекта: администраторам и операторам, — чтобы те уточнили детали. Двадцатистраничная спецификация, которую я тебе описала, конечно, ужасна. И все же она гораздо лучше той, которая нам досталась от FAA.
Сейчас мистер Томпкинс уже не сомневался в том, что Белинда права. Но ее объяснение только добавило новых вопросов:
— Белинда, но зачем, почему они составили вот такую спецификацию? Кому нужен документ, с которым все равно никто не сможет работать?
— Знаешь, я, кажется, догадалась, — весело рассмеялась Белинда. — Поначалу это было не так уж просто сделать, но теперь, когда я знаю основное правило, частности уже не мешают видеть всю картину.
— И что же это за «основное правило»?
— Туманность в изложении появляется там, где существует неразрешенный конфликт.
— Конфликт?
— Именно. Программные приложения разрабатываются при участии нескольких групп заинтересованных лиц: собственников компании, пользователей, владельцев акций, разработчиков, операторов, администраторов. А когда речь идет о такой сложной и важной системе, как организация управления аэропортом, заинтересованы будут несколько десятков групп! Часто все они спорят и ссорятся между собой. Возникает конфликт. Смотри, например, одни хотят, чтобы операторам дали возможность вводить данные напрямую. Другие хотят, чтобы эти данные вводились только централизованно.
— Да, такое легко представить. И если они не найдут компромисс, то?…
— То спецификация будет абстрактной и туманной. По ней нельзя будет ничего сказать о системе. Ну как писатель может написать, есть у оператора клавиатура или нет? Если он встанет на сторону одной группы, то его живьем съедят остальные! Безопаснее всего вообще об этом не упоминать.
— То есть они могли бы написать нормальную, хорошую спецификацию, но для этого…
— Для этого им надо было бы ввязаться в драку, защищать ту или другую сторону…
— М-да… а они вместо того, чтобы разрешить конфликт, просто прикрыли его тремястами страницами никому не нужного текста.
— Да, так всегда и происходит. Теперь, когда мне встречается какая-то неточность в спецификации, я сразу иду выведывать, где у них конфликт. И заметь — всегда его нахожу. Кстати, у меня есть твердое убеждение: любую сложную вещь можно описать простыми словами. Если нам это не удается, значит, нужно либо развивать в себе способность четко излагать мысли, либо учиться решать конфликты.
Мистер Томпкинс смотрел вверх — туда, где над холмами в темном вечернем небе уже зажигались первые звезды. Какое-то время они молчали. Потом Белинда спросила:
— Поздно уже. Как насчет ужина, босс?
— Давай. Только ты переоденься сначала. А я встречу тебя в столовой.
Белинда взяла полотенце и направилась в свои апартаменты. Мистер Томпкинс же снова открыл записную книжку.
Туманные спецификации
1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.