Однако, потребность в таком обучении изменяется, если безнадёжные проекты становятся частью корпоративной культуры. В этих случаях соответствующие процессы и средства должны быть частью корпоративных стандартов, что исключает необходимость внедрения их в начале каждого проекта как чего-то радикально нового.
В реальности, разумеется, существует некоторый переходный период, когда организация меняет свой режим работы, переходя от прежней формы выполнения проектов к новому стилю. Однако даже во время переходного периода идеальным вариантом было бы проводить обучение не в самом безнадёжном проекте, а в нормальной обстановке; разумеется, такое обучение следует рассматривать как часть переходного процесса. При удачном стечении обстоятельств это позволит сделать процесс обучения более упорядоченным и не загонять его в цейтнот, как это обычно бывает, если обучение проводится в середине безнадёжного проекта.
Соответствующее обучение также должно проводиться для новых сотрудников, принимаемых на работу. Новичкам — например, выпускникам колледжей, которые никогда не занимались полноценной разработкой ПО — нет необходимости объяснять, что новый подход отличается от старого подхода; в самом деле. ведь они даже не слышали такое понятие — «безнадёжный проект». В чем они действительно нуждаются, так это в обучении методам, процессам и средствам, которые организация считает эффективными для применения в безнадёжных проектах. Они, скорее всего, будут сильно отличаться от тех процессов и средств, с которыми новобранцам приходилось иметь дело прежде. (Ирония заключается в том, что как только прежние новобранцы примут участие в своём первом безнадёжном проекте, менеджер велит им «игнорировать все, чему их научили в классе» и усвоить более прагматичный подход к разработке ПО.)
7.4 Концепция «военных игр»
Хотя такие формы обучения выглядят разумными и рациональными, во многих небольших организациях они игнорируются; обучение проводится непосредственно во время работы, разработчикам приходится вникать в тонкости процессов и средств по ходу дела. Ещё хуже дело обстоит для менеджеров — как заметил мой приятель 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 (в приложении к книге приведён полный текст программы). Несколько позже появился ряд средств «визуального» моделирования, большинство из которых достаточно дёшевы. Из коммерческих продуктов я отдаю предпочтение перечисленным ниже средствам:
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.
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
В реальности, разумеется, существует некоторый переходный период, когда организация меняет свой режим работы, переходя от прежней формы выполнения проектов к новому стилю. Однако даже во время переходного периода идеальным вариантом было бы проводить обучение не в самом безнадёжном проекте, а в нормальной обстановке; разумеется, такое обучение следует рассматривать как часть переходного процесса. При удачном стечении обстоятельств это позволит сделать процесс обучения более упорядоченным и не загонять его в цейтнот, как это обычно бывает, если обучение проводится в середине безнадёжного проекта.
Соответствующее обучение также должно проводиться для новых сотрудников, принимаемых на работу. Новичкам — например, выпускникам колледжей, которые никогда не занимались полноценной разработкой ПО — нет необходимости объяснять, что новый подход отличается от старого подхода; в самом деле. ведь они даже не слышали такое понятие — «безнадёжный проект». В чем они действительно нуждаются, так это в обучении методам, процессам и средствам, которые организация считает эффективными для применения в безнадёжных проектах. Они, скорее всего, будут сильно отличаться от тех процессов и средств, с которыми новобранцам приходилось иметь дело прежде. (Ирония заключается в том, что как только прежние новобранцы примут участие в своём первом безнадёжном проекте, менеджер велит им «игнорировать все, чему их научили в классе» и усвоить более прагматичный подход к разработке ПО.)
7.4 Концепция «военных игр»
Хотя такие формы обучения выглядят разумными и рациональными, во многих небольших организациях они игнорируются; обучение проводится непосредственно во время работы, разработчикам приходится вникать в тонкости процессов и средств по ходу дела. Ещё хуже дело обстоит для менеджеров — как заметил мой приятель 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 (в приложении к книге приведён полный текст программы). Несколько позже появился ряд средств «визуального» моделирования, большинство из которых достаточно дёшевы. Из коммерческих продуктов я отдаю предпочтение перечисленным ниже средствам:
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.
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