Путь камикадзе

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

* Какими средствами должна быть оснащена сама организация, если каждый

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

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

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

проекта; большинство организаций находит, что вероятность успеха краткосрочных безнадёжных проектов выше. Как отмечает Bill Hamaker:

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

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

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

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

Соответствующее обучение также должно проводиться для новых сотрудников, принимаемых на работу. Новичкам – например, выпускникам колледжей, которые никогда не занимались полноценной разработкой ПО – нет необходимости объяснять, что новый подход отличается от старого подхода; в самом деле. ведь они даже не слышали такое понятие – «безнадёжный проект». В чем они действительно нуждаются, так это в обучении методам, процессам и средствам, которые организация считает эффективными для применения в безнадёжных проектах. Они, скорее всего, будут сильно отличаться от тех процессов и средств, с которыми новобранцам приходилось иметь дело прежде. (Ирония заключается в том, что как только прежние новобранцы примут участие в своём первом безнадёжном проекте, менеджер велит им «игнорировать все, чему их научили в классе» и усвоить более прагматичный подход к разработке ПО.)

7.4 Концепция «военных игр»

Хотя такие формы обучения выглядят разумными и рациональными, во многих небольших организациях они игнорируются; обучение проводится непосредственно во время работы, разработчикам приходится вникать в тонкости процессов и средств по ходу дела. Ещё хуже дело обстоит для менеджеров – как заметил мой приятель Tim Lister, единственное обучение, которое получает большинство менеджеров проектов, заключается в двух словах: «Желаю удачи!»