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

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

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

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

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

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

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

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

— И что же это за «основное правило»?

— Туманность в изложении появляется там, где существует неразрешенный конфликт.

— Конфликт?

— Именно. Программные приложения разрабатываются при участии нескольких групп заинтересованных лиц: собственников компании, пользователей, владельцев акций, разработчиков, операторов, администраторов. А когда речь идет о такой сложной и важной системе, как организация управления аэропортом, заинтересованы будут несколько десятков групп! Часто все они спорят и ссорятся между собой. Возникает конфликт. Смотри, например, одни хотят, чтобы операторам дали возможность вводить данные напрямую. Другие хотят, чтобы эти данные вводились только централизованно.

— Да, такое легко представить. И если они не найдут компромисс, то?…

— То спецификация будет абстрактной и туманной. По ней нельзя будет ничего сказать о системе. Ну как писатель может написать, есть у оператора клавиатура или нет? Если он встанет на сторону одной группы, то его живьем съедят остальные! Безопаснее всего вообще об этом не упоминать.

— То есть они могли бы написать нормальную, хорошую спецификацию, но для этого…

— Для этого им надо было бы ввязаться в драку, защищать ту или другую сторону…

— М-да… а они вместо того, чтобы разрешить конфликт, просто прикрыли его тремястами страницами никому не нужного текста.

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

Мистер Томпкинс смотрел вверх — туда, где над холмами в темном вечернем небе уже зажигались первые звезды. Какое-то время они молчали. Потом Белинда спросила:

— Поздно уже. Как насчет ужина, босс?

— Давай. Только ты переоденься сначала. А я встречу тебя в столовой.

Белинда взяла полотенце и направилась в свои апартаменты. Мистер Томпкинс же снова открыл записную книжку.

Туманные спецификации

1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.

2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.

3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.

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