Эта концепция обсуждается в моей книге Rise and Resurrection of the American Programmer, и в конце данной главы также приведён ряд ссылок; особенно следует отметить работу Tarek Abdel-Hamid, Stuart Madnick Software Project Dynamics [2], которая описывает полную и детальную имитационную модель для проекта среднего размера.
Имитационная модель может быть в принципе реализована на любом языке программирования, однако для этих целей существуют специализированные языки и средства. Возможно, наиболее известными из них являются SIMSCRIPT, DYNAMO и GPSS; модель, описанная Abdel-Hamid и Madnick, реализована на DYNAMO (в приложении к книге приведён полный текст программы). Несколько позже появился ряд средств «визуального» моделирования, большинство из которых достаточно дёшевы. Из коммерческих продуктов я отдаю предпочтение перечисленным ниже средствам:
11) iThink (Macintosh, Windows). High Performance Systems Inc., Hanover, NH. Тел. 603-643-9636, факс 603-643-9502.
12) VenSim (Windows). Ventana Systems Inc., Belmont, MA. Тел. 617-489-5234, факс 617-489-5316.
13) Professional DYNAMO (Windows). Pugh-Robert Associates, Cambridge, MA. Тел. 617-864-8880, факс 617-864-8884.
14) Extend (Macintosh, Windows). Imagine That, Inc., San Jose, CA. Тел. 408-365-0305, факс 408-629-1251.
Даже при наличии хороших средств и множества опубликованных материалов невозможно отрицать тот факт, что для создания модели, отражающей среду конкретной компании и предоставляющей руководству возможность проигрывать разнообразные сценарии безнадёжных проектов, необходимо серьёзное отношение к делу и немалые инвестиции. Исходя из своего личного опыта участия с начала 90-х годов в ряде подобных проектов по созданию имитаторов и сценариев военных игр, могу сказать, что на построение адекватной и хорошо настаиваемой модели требуется по крайней мере несколько человеко-месяцев; в качестве дополнительной иллюстрации интересно отметить, что модель, опубликованная в [2], была предметом диссертации Abdel-Hamid.
Это означает, что такая работа лежит за пределами возможностей одного-единственного менеджера проекта, если он хочет использовать такой подход в процессе обучения. Ясно, что эти инвестиции носят стратегический характер, и ими должна заниматься корпорация в целом, причём вряд ли они под силу небольшой компании из десяти человек. Однако для организации-разработчика, в штате которой работают сотни и даже тысячи человек, такие инвестиции будут весьма скромными. Напомним, о чем идёт речь: руководство пытается найти способы утвердить процессы и технологии, которые могли бы обеспечить уверенность в выполнимости планов, бюджетов и функциональности, являющихся вдвое или втрое более претенциозными по сравнению с «нормальными» проектами. Планируя такие радикальные изменения, руководство зачастую готово затратить огромные суммы денег — в некоторых случаях буквально миллионы долларов — на оснащение разработчиков новыми рабочими станциями, средствами визуального программирования и объектно-ориентированными методологиями. Ворчать по поводу затрат шести человеко-месяцев на разработку имитатора просто смешно, а лишать свои проектные команды возможности получить опыт на модели безнадёжного проекта перед тем, как рисковать миллионами долларов, просто глупо.
Увы, высшее руководство обычно так не думает. Оно и так негативно относится к затратам времени, усилий и средств на любое обучение, а на затраты, связанные с имитацией безнадёжных проектов, посмотрит ещё более косо. Это одна из главных причин, по которым культура безнадёжных проектов в большинстве крупных организаций никогда не будет успешно внедрена.

7.5 Заключение

Как неоднократно отмечалось на протяжении всей книги, безнадёжные проекты становятся неизбежными для сегодняшнего мира бизнеса с его высокой конкуренцией и хаотичностью. Некоторые организации осознали этот факт и стараются в соответствии с этим разумно спланировать свою деятельность. Тем не менее, история развития индустрии ПО за последние 40 лет говорит о том, что большинство организаций извлекают не слишком много уроков из своего опыта, и склонны воспринимать каждый новый безнадёжный проект как нечто уникальное. Даже тем организациям, которые поняли, что безнадёжные проекты не являются более делом случая, придётся испытать серьёзные трудности, поскольку бюрократия будет продолжать цепляться за старые стандарты, процедуры, методологии и средства, независимо от их непригодности.
Одним приятным исключением из этого правила являются начинающие организации. Таким организациям, по определению, не нужно изменять культуру ввиду её отсутствия, и они, скорее всего, воспримут безнадёжные проекты как нормальное явление — в конце концов, частью мифологии начинающих компаний является убеждение, что каждый должен работать как заведённый, в то время как компания подвергает себя безумному риску, чтобы преуспеть в конкурентной борьбе с крупными корпорациями. И, если начинающая компания приходит к выводу, что её успех полностью обусловлен тактикой её поведения, то она, вероятно, постарается утвердить такую тактику на будущее.
Разумеется, мои утверждения носят достаточно общий характер, и существует множество причин, по которым такой подход может не дать никаких результатов. Интересным, например, является тот факт, что ветераны разработки ПО, покидая большие бюрократические корпорации и создавая новые софтверные фирмы, приносят с собой почти все свои привычки и традиции. С другой стороны, в настоящее время, так же, как и в начале моей карьеры, молодое поколение разработчиков ПО очертя голову бросается в новые проекты, считая 18-часовой рабочий день «отдыхом». Тем не менее, среди всех происшедших драматических изменений я бы особенно выделил характер и темп работы, который народ в Netscape, Microsoft и множестве других организаций называет просто «время Internet».
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