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