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
Глава 19Часть и целое
Аристотель Кенорос любил вставать рано. И если он собирался нанести визит, то чаще всего это становилось первым событием рабочего дня. Вот и сегодня, когда мистер Томпкинс пришел на работу, миссис Бирцих объявила ему, что Первый программист Моровии уже ждет его в кабинете. Так оно и было. Аристотель сидел на столе, вперив взгляд в таблицу, нарисованную на доске для записей.
— Это отчетная карточка, — пояснил Кенорос. — Я прошелся по всем командам и оценил их успехи в определении архитектуры приложения по пятибалльной шкале. При этом я интересовался не столько качеством их построений, сколько тем, насколько детально они были проработаны. Если вы описали низкоуровневую архитектуру приложения таким образом, что она определяет все модули кода и все взаимодействия между ними — тогда Кенорос поставит вам пятерку. Если ничего такого у вас нет, то единицу. Все прочие получают какой-то промежуточный балл. Вот, посмотри-ка.
Мистер Томпкинс сел за стол и стал рассматривать таблицу, прихлебывая кофе.

— Пожалуйста, скажи еще раз, что значит единица?
— Как правило, это означает, что команда произвела на свет некий политический документ и назвала это «дизайном системы». На самом деле такие тексты не содержат в себе ничего, кроме первоначальных соображений о том, какой в принципе может быть архитектура приложения.
— То есть, по твоей терминологии, это вообще не дизайн.
— Да. Разумеется, потом, в процессе написания кода, дизайн обязательно появится. Но суть в том, что за время, отведенное на продумывание архитектуры, команда не сделала ничего. За это они и получили единицу.
— Хм. А маленькие команды получили пятерки и четверки. В то время как среди больших нашлась только одна, которая получила не единицу, а хотя бы тройку. Отчего же так?
— А вот попробуй догадайся. Эту загадку я специально припас для тебя.
— Прежде всего, если я правильно помню, наша концепция написания кода в последний момент невозможна без отлично проработанного дизайна.
— Очень хорошо. Продолжай!
— И все равно я не понимаю, почему команды А дружно провалили эту фазу. Ведь они не смогут проделать всю работу, которая необходима для того, чтобы перейти к написанию кода.
— Именно. А если еще точнее, то они и не собираются работать по методу кодирования в последнюю минуту. Все шесть команд А уже давным-давно пишут код. Я пытался было убедить их отложить кодирование на последний момент, но у меня ничего не получилось.
— А остальные?
— В разной степени. Впрочем, так или иначе, все они пытаются применить этот подход. Все решили отложить код на последний момент, а до этого постараться как можно точнее описать все внутреннее устройство системы. Некоторые даже отвели на кодирование всего шестую часть времени разработки.
— Но ни одна команда А так поступать не стала?
— Ни одна.
— Ладно. Я сдаюсь. В чем же дело?
Кенорос плюхнулся на стул около мистера Томпкинса. Он широко улыбнулся, но ничего не ответил. Мистер Томпкинс попробовал еще раз:
— Так почему же команды А не захотели заниматься детальной проработкой дизайна?
— Они слишком большие.
— Кто? Что?
— У меня есть теория. Эти команды слишком большие. Когда приходит время заниматься дизайном, команда оказываеся слишком большой. Продумывать архитектуру системы хорошо вдвоем, втроем. Ну, в крайнем случае, можно поручить это четверым или пятерым. Пять человек могут собраться вокруг доски для записей и вместе придумать хорошее решение. Но двадцать человек вокруг доски для записей уже не соберешь.
— И все равно я не понимаю, почему это должно мешать работе. Четверо или пятеро занимаются дизайном, а остальные сосредотачиваются на чем-нибудь другом. Почему бы и нет?
— На чем же еще им сосредоточиться?
— Ну не знаю. На чем-нибудь другом.
— Определение архитектуры приложения — это, по сути, деление целого на части, очень важный этап в разработке программы. Как только вы его прошли, части можно раздавать для выполнения различным людям или командам. Пока вы этого не сделали, у вас нет никаких частей и раздавать вам нечего. Следовательно, вся команда должна работать вместе.
— И все равно это не извиняет отсутствие продуманной архитектуры. Если это должно быть сделано, значит, нужно поручить эту работу четверым или пятерым, а остальные пусть потерпят и подождут. Пусть сидят и ничего не делают, в конце концов, если другого не остается.
- 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