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

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

Белинда обернулась к остальным участникам собрания:

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

Кто-то хмыкнул. Кто-то пожал плечами.

— Хороший вопрос, — сказал Гулливер.

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

— Вебстер, подумай еще раз: о чем я тебя спросила. Если мы создаем многопроцессорную систему, которая включает в себя и «железо», и программное обеспечение, базу данных с сотнями возможностей настроек конфигурации…

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

— Но откуда же они возьмутся, все эти данные?

— Что?

— Я говорю, как они попадут в нашу систему?

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

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

— Ничего такого, — кивнул Гулливер. — Она абсолютно права, Вебстер. Вся эта спецификация на самом деле ничего не описывает. Это три сотни страниц каких-то смутных догадок и общих фраз.

Мистеру Томпкинсу захотелось записать что-то по поводу «догадок вместо спецификаций», но что? На всякий случай он заново перечитал спецификацию (на это ушел целый час). Ему так хотелось думать, что Белинда ошиблась и что дело не так уж плохо. Однако, как спецификация, документ никуда не годился. Каким-то образом авторам удалось вообще избежать конкретных описаний конструируемой системы. Но зачем они так ее написали? Неужели написать нормальную спецификацию было так уж сложно? И почему никто, кроме Белинды, включая комиссию Американской FAA, не увидел, что это всего лишь триста страниц откровенной белиберды? Ведь те люди тоже должны были строить по ней настоящую систему для настоящего аэродрома, принимать самолеты с пассажирами… Почему же так происходит? Ему и раньше случалось видеть спецификации, которые никак не объясняли, что именно предстоит создавать программистам. Каждый раз создание такого документа являлось неизменной частью процесса подготовки к написанию продукта, и каждый раз такой проект заканчивался провалом. Так зачем же их пишут, принимают, и почему никто не критикует авторов за подобные «творения»? Загадка какая-то. Тайна абстрактных спецификаций.

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

Сердитый начальник

1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.

2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?

3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

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

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

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

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

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

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

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

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

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