Deadline. Роман об управлении проектами
Добавить в закладки К обложке
- Предисловие - Страница 1
- Глава 1Широчайшие возможности - Страница 2
- Глава 2Спор с Кэлбсрассом - Страница 6
- Глава 3Силиконовое поле - Страница 8
- Глава 4Завод по изготовлению CD-ROM - Страница 12
- Глава 5Великий Вождь Народов - Страница 15
- Глава 6Лучший в мире руководитель - Страница 19
- Глава 7Подбор персонала - Страница 24
- Глава 8Знаменитый доктор Риццоли - Страница 28
- Глава 9Марков, генерал в отставке - Страница 33
- Глава 10Абдул Джамид - Страница 37
- Глава 11Зловредный министр Бэллок - Страница 44
- Глава 12Человек, который умел считать - Страница 51
- Глава 13QuickerStill - Страница 58
- Глава 14Первый программист Моровии - Страница 63
- Глава 15Думать быстрее! - Страница 70
- Глава 16План работы по подготовке к летним Олимпийским играм - Страница 77
- Глава 17Гений по устранению конфликтов - Страница 83
- Глава 18Маэстро Диеньяр - Страница 87
- Интерлюдия - Страница 92
- Глава 19Часть и целое - Страница 95
- Глава 20Необходимые церемонии - Страница 100
- Глава 21Выход на финишную прямую - Страница 106
- Глава 22Сделка года - Страница 111
- Глава 23Пересадка в Риге по пути домой - Страница 115
— Ужасная спецификация. Белинда, это же самая недоделанная и туманная спецификация, какую только можно вообразить!
— Что касается первой части — да. Но зато в ней есть и вторая часть — перечисление данных, с которыми работает система. Другими словами, вторая часть просто превосходная, а вот первая почти отсутствует.
— Ну, и что же ты этим хочешь сказать?
— Я хочу сказать, что при всем ее очевидном несовершенстве с такой спецификацией можно было бы начинать работу над системой для аэропорта. Более того, это спасло бы их от провала проекта, от судебной тяжбы и прочих неприятностей. Разработчики прочли бы эти самые двадцать страниц и через какое-то время предложили бы свое видение отсутствующей первой части — логики работы системы. Потом они показали бы результат другим участникам проекта: администраторам и операторам, — чтобы те уточнили детали. Двадцатистраничная спецификация, которую я тебе описала, конечно, ужасна. И все же она гораздо лучше той, которая нам досталась от FAA.
Сейчас мистер Томпкинс уже не сомневался в том, что Белинда права. Но ее объяснение только добавило новых вопросов:
— Белинда, но зачем, почему они составили вот такую спецификацию? Кому нужен документ, с которым все равно никто не сможет работать?
— Знаешь, я, кажется, догадалась, — весело рассмеялась Белинда. — Поначалу это было не так уж просто сделать, но теперь, когда я знаю основное правило, частности уже не мешают видеть всю картину.
— И что же это за «основное правило»?
— Туманность в изложении появляется там, где существует неразрешенный конфликт.
— Конфликт?
— Именно. Программные приложения разрабатываются при участии нескольких групп заинтересованных лиц: собственников компании, пользователей, владельцев акций, разработчиков, операторов, администраторов. А когда речь идет о такой сложной и важной системе, как организация управления аэропортом, заинтересованы будут несколько десятков групп! Часто все они спорят и ссорятся между собой. Возникает конфликт. Смотри, например, одни хотят, чтобы операторам дали возможность вводить данные напрямую. Другие хотят, чтобы эти данные вводились только централизованно.
— Да, такое легко представить. И если они не найдут компромисс, то?…
— То спецификация будет абстрактной и туманной. По ней нельзя будет ничего сказать о системе. Ну как писатель может написать, есть у оператора клавиатура или нет? Если он встанет на сторону одной группы, то его живьем съедят остальные! Безопаснее всего вообще об этом не упоминать.
— То есть они могли бы написать нормальную, хорошую спецификацию, но для этого…
— Для этого им надо было бы ввязаться в драку, защищать ту или другую сторону…
— М-да… а они вместо того, чтобы разрешить конфликт, просто прикрыли его тремястами страницами никому не нужного текста.
— Да, так всегда и происходит. Теперь, когда мне встречается какая-то неточность в спецификации, я сразу иду выведывать, где у них конфликт. И заметь — всегда его нахожу. Кстати, у меня есть твердое убеждение: любую сложную вещь можно описать простыми словами. Если нам это не удается, значит, нужно либо развивать в себе способность четко излагать мысли, либо учиться решать конфликты.
Мистер Томпкинс смотрел вверх — туда, где над холмами в темном вечернем небе уже зажигались первые звезды. Какое-то время они молчали. Потом Белинда спросила:
— Поздно уже. Как насчет ужина, босс?
— Давай. Только ты переоденься сначала. А я встречу тебя в столовой.
Белинда взяла полотенце и направилась в свои апартаменты. Мистер Томпкинс же снова открыл записную книжку.
Из записной книжки мистера ТомпкинсаТуманные спецификации
1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118