- •Эдвард Йордан «Смертельный марш» Полное руководство для разработчика программного обеспечения по выживанию в безнадежных проектах
- •Глава 1. Введение 6
- •Глава 2. Политика 29
- •Глава 1. Введение
- •1.1 Определение безнадежного проекта
- •1.2 Категории безнадежных проектов
- •1.3 Почему существуют безнадежные проекты ?
- •1.3.1 Политика, политика, политика
- •1.3.2 Наивные представления маркетинговых служб, высшего руководства, менеджеров проекта и др.
- •1.3.3 Наивный оптимизм юности: «Мы сможем сделать это за выходные!»
- •1.3.4 Менталитет первопроходцев у неопытных предпринимателей
- •1.3.5 Менталитет «Морского Корпуса»(Marine Corps):Настоящиепрограммисты не нуждаются в сне!
- •1.3.6 Высокая конкуренция, порожденная глобализацией рынков
- •1.3.7 Высокая конкуренция, вызванная появлением новых технологий
- •1.3.8 Сильное воздействие неожиданных правительственных решений
- •1.3.9 Неожиданный и/или незапланированный кризис
- •1.4 Почему люди участвуют в безнадежных проектах?
- •1.4.1 Риск высок, но вознаграждение тоже
- •1.4.2 Синдром покорителей Эвереста
- •1.4.3 Наивность и оптимизм молодости
- •1.4.4 Альтернатива - безработица
- •1.4.5 Возможность будущей карьеры
- •1.4.6 Альтернатива - банкротство или прочие разные бедствия
- •1.4.7 Возможность победить бюрократию
- •1.4.8 Месть
- •1.5 Заключение
- •Глава 2. Политика
- •2.1 Идентификация «игроков», вовлеченных в проект
- •2.1.1 Владелец
- •2.1.2 Заказчики
- •2.1.3 Акционеры
- •2.1.4 Заинтересованные лица
- •2.1.5 Защитники
- •2.2 Определение сущности проекта
- •2.3 Отношение участников к проекту
- •2.4 Заключение
- •Глава 3. Переговоры
- •3.1 Нормальные переговоры
- •3.2 Допустимые компромиссы
- •3.3 Переговорные игры
- •3.4 Стратегии переговоров
- •3.5 Что делать в случае провала переговоров
- •Глава 4. Человеческий фактор в безнадежных проектах
- •4.1 Кадровые вопросы
- •4.2 Лояльность, отношение, мотивация и вознаграждения
- •4.2.1 Стимулирование участников проекта
- •4.2.2 Сверхурочная работа
- •4.3 Значение коммуникации
- •4.4 Проблемы формирования проектной команды
- •4.5 Условия работы
- •4.6 Заключение
- •Глава 5. Процессы
- •5.1 Концепция «triage»
- •5.2 Важность управления требованиями
- •5.3Sei, iso-9000. Формальные процессы против неформальных
- •5.4 «Достаточно хорошее» программное обеспечение
- •5.5 Наилучшая практика и наихудшая практика
- •5.6 Принцип «ежедневной сборки проекта»
- •5.7 Управление рисками
- •5.8 Заключение
- •Глава 6. Технология и средства
- •6.1 Минимально необходимый набор средств
- •6.2 Средства и процессы
- •6.3 Риск выбора новых средств
- •6.4 Заключение
- •Глава 7. Безнадежные проекты как образ жизни
- •7.1 Почему безнадежные проекты становятся нормой
- •7.2 Учреждение «культуры» безнадежных проектов
- •7.3 Обучение участников безнадежных проектов
- •7.4 Концепция «военных игр»
- •7.5 Заключение
1.3.2 Наивные представления маркетинговых служб, высшего руководства, менеджеров проекта и др.
Наивность часто связана с неопытностью, поэтому не удивительно, когда люди, не имеющие представления о трудоемкости и длительности создания нужной им системы, принимают нереалистичные решения. В самом худшем варианте это может привести к тому, что мой коллега Том ДеМарко называет «истерическим оптимизмом», когда все поголовно в организации бездумно верят, что сложный проект, ничего подобного которому они никогда не делали, можно как-нибудь сделать за девять месяцев, хотя реалистичная оценка его продолжительности - три года.
Наивность и оптимизм, как мы видим, присущи также и техническим специалистам. Однако, вообразим на минуту, что именно ваши менеджер, отдел маркетинга или конечный пользователь несут ответственность за чересчур оптимистичный план или бюджет. Как они отреагируют, когда в конечном счете поймут чрезмерную оптимистичность первоначальных оценок? Захотят ли они продлить срок разработки, увеличить бюджет и спокойно согласиться с тем, что все не так просто, как они себе представляли? Скажут ли они вам и вашим коллегам спасибо за героические усилия? Если это так, то самым важным для вас может оказаться заменить классическую каскадную модель жизненного цикла ПО на подход RAD, чтобы сразу после реализации первой версии прототипа системы можно было получить реалистичную оценку плана, бюджета и ресурсов.
Тем не менее, в большинстве безнадежных проектов такого рода рациональная коррекция курса в середине проекта невозможна. Так может случиться, например, если главный менеджер наивно пообещал что-либо заказчику и считает, что дело чести - выполнять свое обязательство, несмотря ни на что. Самое худшее - когда человек, принимающий на себя обязательства, вполне осознает происходящее (в особенности такие дела всплывают наружу, когда после празднования по поводу заключения нового контракта с очередным доверчивым пользователем менеджер по маркетингу признается менеджеру проекта за кружкой пива: «Послушай, мы никогда бы не заключили этот контракт, если бы сказали клиенту, сколько времени потребует проект на самом деле; в конце концов, мы знали, что наши конкуренты тоже придут с заманчивыми предложениями. И, кроме всего прочего, твои ребята всегда раздувают планы и бюджеты, не так ли?»).
На последнее замечание особенно трудно возразить, если оно исходит от вашего босса или менеджера, который выше вас на два или три уровня. Предполагается, что вся оценка планов и бюджета является предметом переговоров (которые будут детально обсуждаться в главе 3). В то же время ваш менеджер ведет себя в некоторой степени наивно, если он, будучи недовольным «раздуванием» плана и бюджета, полагает, что вы сможете завершить проект в смехотворно короткий срок, принятый без вашего ведома. Такой срок может быть установлен и под влиянием менталитета «Морского Корпуса», который обсуждается в подразд. 1.3.5. Наконец, принятие отделом маркетинга смехотворного плана и бюджета может быть результатом политических игр, о которых говорилось ранее; менеджера по маркетингу вряд ли особенно волнует реалистичность предлагаемого им плана и бюджета, поскольку его основная цель - получить комиссионное вознаграждение или доставить удовольствие своему боссу.
Представим себе, что наш безнадежный проект - это результат «наивности в чистом виде», свободной от политики или каких-либо других злонамеренных воздействий. Главный вопрос заключается в следующем: что делать? Как было отмечено выше, определяющим фактором является вероятность того, что лица, принимающие решения, пересмотрят свои бюджеты и планы, когда станет очевидной невыполнимость взятых на себя первоначально обязательств. Трудно предсказать заранее, произойдет это или нет, однако небесполезно было бы оглядеться вокруг себя и посмотреть, что же происходит в подобной ситуации с другими безнадежными проектами. (Если это первый такой проект, который когда-либо осуществлялся в вашей компании, значит, вы в самом деле - белое пятно на карте!)
Если у вас есть твердая уверенность, основанная на вашем политическом чутье или опыте предыдущих проектов вашей организации, что руководство, отрицая очевидные факты, будет настаивать на первоначальном бюджете и плане, значит, придется принимать гораздо более серьезное решение относительно дальнейшего продолжения работы. При этом имеет существенное значение степень вашего влияния на другие аспекты проекта - например, на состав привлекаемых технических специалистов - что будет обсуждаться в главе 2.