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