- •Эдвард Йордан «Смертельный марш» Полное руководство для разработчика программного обеспечения по выживанию в безнадежных проектах
- •Глава 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 Заключение
6.3 Риск выбора новых средств
Как было отмечено выше, некоторые безнадежные проекты хватаются за новые средства и технологии, как за панацею для достижения гораздо более высокой продуктивности работы. Предположим на минуту, что мы нашли способ разрешить культурные и политические проблемы, связанные с изменением процессов. О чем же еще необходимо побеспокоиться?
Два наиболее вероятных риска - технология и обучение. Во многих случаях новое средство даже не является законченным коммерческим продуктом; обычно кто-нибудь из проектной команды переписывает из Internet бета-версию. Или же, данное средство невозможно интегрировать с любыми другими средствами, используемыми проектной командой; поставщик давал на этот счет неопределенные обещания, однако в результате оказалось, что возможности экспорта-импорта изобилуют ошибками. Или, средство никем не поддерживается - оно разработано студентом из Узбекистана или (что еще хуже!) создано в домашних условиях одним из разработчиков ПО, не видящим ничего странного в том, что банк разрабатывает свое собственное CASE-средство, а страховая компания - свою СУБД.
Допустим, что средство является достаточно надежным, а его поставщик обладает устойчивой репутацией и обеспечивает поддержку на высоком уровне. В этом случае проблемы будут связаны с освоением, поскольку даже если это средство прежде широко использовалось в организации, никто не воспринимал его как «серебряную пулю», которая сможет чудесным образом спасти проектную команду от гарантированной катастрофы. Иногда можно видеть проектную команду, добивающуюся разрешения использовать какое-либо мощное средство, с которым они уже имели дело в предыдущей работе - однако, это достаточно редкое явление. В большинстве случаев никто из участников проектной команды и вообще никто в организации никогда прежде не видел или не использовал это средство.
Как отмечалось раньше, любое нетривиальное средство обычно предъявляет жесткие требования к соответствующим процессам; таким образом, новое средство обычно подразумевает новый процесс. Хотя такая зависимость должна быть очевидной, тем более поразительно, насколько часто представители поставщика, занимающиеся обучением, пробегают пятидневный семинар по использованию средства и только после этого обнаруживают, что сотрудники, обучающиеся на курсах (руководители которых уже впали в панику по поводу пятидневного отставания от плана из-за их обучения), абсолютно ничего не понимают в процессах, поддерживаемых данным средством. Чрезвычайно неприятно, например, провести два дня, объясняя лишенному какого-либо энтузиазма студенту, как рисовать ER-диаграммы, и затем услышать от него вопрос: «Между прочим, а что такое сущность? Поскольку я собираюсь программировать все на С++, зачем мне вся эта чепуха?»
Предположим, однако, что участники команды разбираются в процессах, поддерживаемых (или автоматизируемых) данным средством и готовы с энтузиазмом использовать его в практической работе; правда, мой 20-летний опыт преподавания структурных и объектно-ориентированных методов говорит о том, что такое предположение наивно, и бессмысленно продолжать дальше обсуждение этой проблемы. Итак, если мы предположим, что не существует технических проблем, связанных с данным средством, и если предположим, что соответствующие процессы также не вызывают никаких проблем, тогда все, что остается - это обучение и практика, связанные с самим средством.
Как много времени на это потребуется? Очевидно, это зависит от характера и сложности средства, а также от его пользовательского интерфейса, возможностей онлайновой подсказки и др. В лучшем случае разработчики могут самостоятельно разобраться, как использовать средство, без какого-либо формального обучения; в такую возможность ужасно хочется верить менеджеру проекта и разным другим руководителям, поскольку они считают любое обучение потерей времени и отвлечением от «реальной работы» над проектом. Более реалистичная оценка заключается в том, что на освоение средства потребуется час, день или неделя. Независимо от формы (занятия в классе, чтение книги или просто «игры» со средством), на это все равно потребуется какое-то время.
Тем не менее, в результате обучения мы не получим опытного пользователя в совершенстве владеющего средством. Обучение не является двоичным феноменом: к концу недельного обучения в классе участники проектной команды не перейдут из состояния полного непонимания в состояние высшего мастерства владения средством. Это должно быть очевидным, однако нарушает планы высшего руководства, которые склонны ворчать и возмущаться: «Хорошо, мы потратили кучу денег на этих высокооплачиваемых преподавателей и напрасно потеряли столько времени в классах, чтобы эти ленивые бездельники-программисты могли научиться кодировать. Теперь мы хотим увидеть реальную отдачу от этого «замечательного» средства, за которое вы так агитировали!» Наверное, в такой наивности высшего руководства нет ничего удивительного, поскольку они сами практически не сталкивались с инструментальными средствами; однако, к сожалению, мне приходилось наблюдать похожую реакцию со стороны многих менеджеров безнадежных проектов, гораздо лучше разбирающихся в технических вопросах.
В замечательной статье [1] мой коллега Mellir Page-Jones утверждает, что в разработке ПО существует семь ступеней мастерства; его статья сосредоточена в основном на методологиях, но я думаю, что она в такой же степени применима к средствам и технологиям. К списку, приведенному ниже, я добавил свои собственные оценки, касающиеся времени достижения разработчиком средней квалификации различных ступеней мастерства в предположении, что средство или технология обладают средней сложностью:
Таблица 6.1 Семь ступеней мастерства в разработке ПО
1. Наивный новичок |
Никогда не слышал о технологии Х (очевидно, для этого не требуется никакого времени). |
2. Осведомленный разработчик |
Прочел статью о технологии Х (в большинстве случаев разработчику ПО достаточно одного часа, чтобы разобраться в общих чертах и высказать свое мнение о преимуществах и недостатках средства, даже если он никогда его не видел или не использовал). |
3. Начинающий разработчик |
Посетил пятидневный семинар (неделя, возможно, сжатая до двух дней ввиду того прессинга, под которым находится безнадежный проект. Следует отметить, что при этом разработчик, скорее всего, успел всего лишь поработать с компьютерными руководствами, предоставленными поставщиком, или пробежаться по небольшим примерам, иллюстрирующим возможности средства. Ему не пришлось столкнуться с какими-либо проблемами и недостатками средства, у него не было возможности, каким образом можно масштабировать средство (если это вообще возможно) для больших и сложных проектов; он не пытался интегрировать средство с большинством остальных средств в данной среде). |
4. Практикующий разработчик |
Готов использовать технологию Х в реальном проекте (по-видимому, достаточно месяца, чтобы в основном постичь все нюансы использования средства и быть вполне готовым к его использованию в «реальном» проекте). |
5. Квалифицированный разработчик |
Постоянно использует технологию Х в своей работе и очень недоволен, если по какой-то причине лишается этой возможности (для достижения такого уровня обычно требуется 6-12 месяцев, и если средство действительно подобно «серебряной пуле», то разработчик превращается в проповедника и пытается всеми способами убедить каждого, что это средство - самое замечательное в мире). |
6. Мастер |
Усвоил все детали технологии Х; знает, как обходить ее правила (на это требуется два или три года, это также означает, что разработчик прошел через две или три новые реализации продукта, познакомился со всеми пользовательскими сообществами в Internet, знает все отсутствующие в справочниках номера телефонов специалистов по технической поддержке в организации поставщика). |
7. Эксперт |
Пишет книги, выступает с докладами на конференциях, ищет способ распространить технологию Х на другие галактики (Page-Jones в своей статье говорит о методологиях, поэтому не совсем очевидно, что это применимо по отношению к средствам и технологии). |