Ремонт принтеров, сканнеров, факсов и остальной офисной техники


назад Оглавление вперед




[32]

или два.

•Каким образом безнадежные проекты могут повлиять на стиль руководства? Следует ли ожидать, что с самого начала проекта менеджеры будут выжимать из участников команды все соки и затем выбрасывать их за ненадобностью? Или же менеджер проекта будет нести ответственность за хорошее самочувствие участников команды в такой же степени, как за своевременную сдачу работоспособной системы пользователям? Отметим, что если нормальная организация хочет внедрить культуру безнадежных проектов (вместо того, чтобы периодически бороться с такими проектами), она, по-видимому, хочет, чтобы такие проекты завершались успешно; в соответствии с классификацией в главе 1 это означает, что организация сознательно идет на проекты типа «невыполнимая миссия» или «отвратительные». Однако, если дела идут паршиво, а люди «сгорают на работе» и разбегаются к концу проекта, почему бы не воспользоваться услугами консультантов? Sharon Marsh Roberts замечает по этому поводу:

Я считаю, что организации необходимо найти способ обновления своих ресурсов. Одна альтернатива - использование множества консультантов, от которых ожидается работа в стиле «заработай кучу денег и отваливай». Другая альтернатива - иметь «зону безопасности», в которой сотрудники могли бы отсиживаться между безнадежными проектами.

•Какими средствами должна быть оснащена сама организация, если каждый проект будет безнадежным? Если окажется, что главным фактором успеха первого безнадежного проекта стала технология повторного использования с соответствующей библиотекой классов или визуальное средство быстрой разработки приложений, то, возможно, каждый проект должен иметь в распоряжении эти средства.

•Какого типа инфраструктуру должна иметь организация, чтобы поддерживать безнадежные проекты? Она может включать электронную почту в масштабах всей компании или более развитую инфраструктуру рабочих групп, основанную на использовании Lotus Notes. Кроме того, она могла бы также включать серьезные изменения в человеческой инфраструктуре - т.е., сеть администраторов и обслуживающего персонала должна разрастаться, а слой бюрократов - сокращаться.

•Какого рода процессы подходят для культуры безнадежных проектов? Механизм определения приоритетов, формальные процессы и многое другое из того, что обсуждалось в главе 5, должно быть принято на уровне организации, чтобы каждая команда могла получить необходимую ей поддержку, когда она пытается реализовать соответствующие процессы на практике в конкретном безнадежном проекте. Отметим также, что на процессы оказывает влияние (хотя и небольшое) длительность проекта; большинство организаций находит, что вероятность успеха краткосрочных безнадежных проектов выше. Как отмечает Bill Hamaker:

Вместо нескольких крупных безнадежных проектов лучше выполнить побольше небольших проектов. Сконцентрируйтесь на создании такой организации, которая умеет извлекать уроки из результатов каждого безнадежного проекта. Отведите достаточно времени между проектами, чтобы специалисты могли оценить все плюсы и минусы разработки; это время будет для них своего рода отдыхом.

7.3 Обучение участников безнадежных проектов

В главах 6 и 7 я затрагивал вопросы обучения проектной команды новым процесса и средствам. Однако, потребность в таком обучении изменяется, если безнадежные проекты становятся частью корпоративной культуры. В этих случаях соответствующие процессы и средства должны быть частью корпоративных стандартов, что исключает необходимость внедрения их в начале каждого проекта как чего-то радикально нового.


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 (в приложении к книге приведен полный текст программы). Несколько позже появился ряд средств «визуального» моделирования, большинство из которых достаточно дешевы. Из коммерческих продуктов я отдаю предпочтение перечисленным ниже средствам:

•iThink (Macintosh, Windows). High Performance Systems Inc., Hanover, NH. Тел. 603-6439636, факс 603-643-9502.

•VenSim (Windows). Ventana Systems Inc., Belmont, MA. Тел. 617-489-5234, факс 617-4895316.

•Professional DYNAMO (Windows). Pugh-Robert Associates, Cambridge, MA. Тел. 617-8648880, факс 617-864-8884.

•Extend (Macintosh, Windows). Imagine That, Inc., San Jose, CA. Тел. 408-365-0305, факс 408629-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]