Книга: Deadline
Назад: Глава 15. Думать быстрее!
Дальше: Глава 17. Гений по устранению конфликтов

Глава 16

План работы по подготовке к летним Олимпийским играм

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

— Знаю, знаю, Сардинка. Я тоже очень по ней соскучился. И я тоже понятия не имею, когда она вернется…

Впрочем, в этот день ему таки посчастливилось получить кое-какие новости о Лаксе, хотя и косвенного характера. Утром у себя в кабинете мистер Томпкинс обнаружил кипу документации в виде блокнотов с отрывными листами. К ним была приложена записка на бланке Министерства внутренних дел, нацарапанная корявым, почти неразборчивым почерком: «Велел Хулигэн выкрасть эти бумаги в Соединенных Штатах. С таким подспорьем вы просто не сможете опоздать с выпуском системы для Олимпийских игр». Внизу стояла размашистая подпись с замысловатыми завитушками — Бэллок.

Кроме того, в кабинете его поджидал Аристотель Кенорос. На коленях он держал раскрытый блокнот. Увидев мистера Томпкинса, Аристотель улыбнулся:

— Это спецификации контрактов FAA NASPlan, — весело сказал он.

— О-о-о, — простонал мистер Томпкинс, — только не американские спецификации NASPlan! Все эти проекты окончились судебными процессами.

— Именно! Более того, на всех этих документах стоит печать судебного пристава.

— Если бы Бэллок действительно хотел нам помочь, он украл бы спецификации французской или испанской системы… по крайней мере, там были хоть какие-то положительные результаты. А эти…

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

— Ну, это маловероятно…

— Конечно. Один шанс на миллион, но вдруг?

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

— Всегда рад помочь. Кстати, проект обещает быть весьма интересным — жонглировать самолетами, управлять взлетами и посадками… подумать только. Превосходный проект, если ты не удавлен сроками.

— Это не наш случай. Мы знаем свой срок и изменить его не можем.

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

— Зато у нас будет прекрасная команда разработчиков. Стоило мне упомянуть о «системе для аэропорта» в разговоре с Гэбриелом, как он тут же нашел мне семь человек, которые принимали участие в разработке испанской системы такого же типа.

Я поговорил с ними и сразу взял в проект. Это действительно замечательные ребята.

— Здорово. Хорошая новость для меня. А у меня для вас, к сожалению, плохая: у нас есть проблема с одним из основных проектов.

— Скажите лучше, где их нет.

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

Проектом РМill-А руководил Осмун Грэдиш, приятный, мягкий молодой человек. Было просто невозможно представить, что он может грубо себя вести.

— Ладно, сегодня я поговорю с ним, — сказал мистер Томпкинс. — А пока не поможешь ли мне с этими книжками? Нужно снести их вниз, к ребятам из «аэродромного» проекта. Надеюсь, от этих спецификаций будет толк. Если этого не случится, то лето 2012 года ознаменуется для нас грандиозным провалом.

Даже вдвоем они едва могли унести огромную кипу спецификаций. Сначала мистер Томпкинс передал охапку книжек в черном переплете в руки Аристотелю, потом сгреб оставшиеся.

— Зачем мы все это делаем? — обратился он к Кеноросу. — Зачем мы вешаем на себя новую работу, если и ту, что есть, мы едва успеваем сделать в срок?

— Мы много на себя берем, потому что мало чего боимся, — пропыхтел в ответ Кенорос, и они отправились вниз по лестнице.

Внешне Осмун Грэдиш почти не изменился: все тот же мягкий голос и приятная улыбка. Однако присмотревшись, можно было заметить, что в уголках его губ залегли складки, а взгляд стал мрачным и усталым. Мистер Томпкинс решил пойти на еженедельное собрание проекта PMill-A. Тут же он встретил и руководителя всех трех команд PMill — Мелиссу Альбер. После собрания мистер Томпкинс пригласил ее выпить кофе. Вскоре они уже сидели во дворике напротив Айдриволи-1, потягивая крепкий моровийский кофе.

— Так что же все-таки происходит с командой А? — начал мистер Томпкинс.

— Ох, Вебстер. С ними у нас большие проблемы. Осмун не выдержал нагрузки.

— Я его не виню, — печально покачал головой мистер Томпкинс. — Мы с самого начала знали, что все команды А будут переполнены, к тому же на них постоянно давят: и объем работы, и сроки практически нереальны. Именно поэтому мы и создали команды Б и В. Когда мне становится совсем невмоготу, я иду в Айдриволи-7 и навещаю Nolate-B, или PShop-B, или любую другую из этих команд.

— Я тоже.

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

— Да, что-то вроде того.

— Так расскажи мне, как у них дела. Неужели все действительно так плохо?

— Иногда он срывается и становится совершенно невыносим, — ответила Мелисса. — Кричит на сотрудников, обзывает их бранными словами в присутствии остальных.

— Думаешь, его что-то беспокоит? Не только сроки и давление сверху?

— Он не хочет говорить со мной на эту тему. Но знаешь, он как-то обмолвился, что вот Quirk-A собирается сдать свой проект вовремя. Он боится, что опоздает только его команда. Наверное, в этом-то все и дело.

— Может, мне с ним поговорить?

— Давай позже. Я бы хотела еще сама с ним поработать.

— Как скажешь.

— Да, кстати, разработчики уже начали просить о переводе на другой проект. Им не хочется работать в команде РMill-A. Даже не знаю, что мне им…

— Дай мне немного времени, чтобы это обдумать, хо­рошо?

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

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

— Так и будет, если только им удастся сплотиться и работать единой командой. Не мне объяснять тебе, что когда разработчики не чувствуют поддержки и признания руководства, они вряд ли способны создать сильную сплоченную команду. И я бы не стала рассчитывать на такую удачу в случае с PMill-A.

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

— Привет, босс! — весело приветствовала его Белинда. Остальные выглядели подавленными. Даже лидер группы Гулливер Менендес — и тот, казалось, утратил свой обычный энтузиазм. Взгляд у него был равнодушный и слегка отупевший.

— Единственный вопрос на повестке дня, Вебстер. Что ты думаешь об этих спецификациях? — спросила Белинда и хитро улыбнулась.

Мистер Томпкинс внутренне напрягся и приготовился к обороне. По правде говоря, он не понял ни слова из того, что читал, притом что потратил на это целых три часа.

— Ну… — начал он, — я читал-то всего пару часов…

— Замечательно. Расскажи нам, что ты думаешь после пары часов чтения.

— Ну, как бы это сказать… в общем, я подчеркиваю — в общем — эта спецификация… она…

— Она что?

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

— Короче говоря, ты ничего не понял, я права?

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

Гулливер мрачно кивнул:

— В общем, примерно так. Я имею в виду свою команду. А вот у Белинды сложилось иное мнение.

— Ага! И каково же мнение Белинды?

— Это полная чушь! — Белинду явно забавлял этот разговор. — Вебстер, это же классическая, стопроцентная чушь, от начала до конца. Все вместе и каждая страница в отдельности.

— Ну ты хватила. Я бы так не сказал. Как можно отзываться так о спецификации, которую написали сведущие в своем деле специалисты?

— О, в специалистах я нисколько не сомневаюсь.

— К тому же спецификация была прочитана и одобрена в FAA.

— Конечно. Авторы написали ерунду, потом эту ерунду прочитали и одобрили в FAA.

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

— Как ты можешь так говорить! В конце концов, это спе­цификация на проект в сто миллионов долларов!

— Сто шестьдесят, если быть точным. Я проверяла.

— Тем более. Кто же будет тратить столько денег на проект с никому не понятной спецификацией?

— Ты думаешь? Ну так ответь мне на простой вопрос. Ты ведь читал этот документ целых два часа?

— Даже три.

— Ну, тогда ты должен был хотя бы один раз прочесть его полностью.

— Скорее, просмотрел. Досмотрел до конца, потом вернулся и просмотрел чуть внимательнее еще раз.

— О’кей. Тогда скажи, пожалуйста: можно ли вводить в эту систему данные с помощью клавиатуры?

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

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

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

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

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

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

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

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

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

— Что?

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

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

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

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

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

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

Из записной книжки мистера Томпкинса

Грозный начальник

  1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать такое поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
  2. Неуважение и злоба, по мнению некоторых руководителей, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но такой «кнут» никогда не подвигнет людей работать лучше.
  3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не того, что у него плохие подчиненные).

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

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

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

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

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

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

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

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

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

— Да, почему?

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

— Со стороны авторов спецификации?

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

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

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

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

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

— Не поделишься? Очень хочется узнать, что же это за правила.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Конфликт?

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

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

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

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

— Для этого им надо было бы занять позицию одной из сторон…

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

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

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

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

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

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

Из записной книжки мистера Томпкинса

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

  1. Неясность изложения материала говорит о том, что между участниками проекта существуют неразрешенные конфликты.
  2. Спецификацию, в которой нет списка типов входящей и исходящей информации, не следует даже принимать к рассмотрению. Это значит, что она попросту ничего не специфицирует.
  3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут подозревать себя в неспособности понять написанное, чем обвинят авторов спецификации в несостоятельности.
Назад: Глава 15. Думать быстрее!
Дальше: Глава 17. Гений по устранению конфликтов