Риск выбора новых средств

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

Два наиболее вероятных риска — технология и обучение. Во многих случаях новое средство даже не является законченным коммерческим продуктом; обычно кто-нибудь из проектной команды переписывает из сети Интернет бета-версию. Или же данное средство невозможно интегрировать с любыми другими средствами, используемыми проектной командой. Поставщик давал на этот счет неопределенные обещания, однако в результате оказалось, что возможности экспорта/импорта изобилуют ошибками. Или средство никем не поддерживается - оно разработано студентом из провинции или (что еще хуже!) создано в домашних условиях одним из разработчиков ПО, не видящим ничего странного в том, что банк разрабатывает свое собственное CASE-средство, а страховая компания - свою СУБД.

Допустим, что средство является достаточно надежным, а его поставщик обладает устойчивой репутацией и обеспечивает поддержку на высоком уровне. В этом случае проблемы будут связаны с освоением, поскольку даже если это средство прежде широко использовалось в организации, никто не воспринимал его как "серебряную пулю", которая сможет чудесным образом спасти проектную команду от гарантированной катастрофы. Иногда можно видеть проектную команду, добивающуюся разрешения использовать какое-либо мощное средство, с которым они уже имели дело в предыдущей работе — однако это достаточно редкое явление. В большинстве случаев никто из участников проектной команды и вообще никто в организации никогда прежде не видел или не использовал это средство.

Как отмечалось раньше, любое нетривиальное средство обычно предъявляет жесткие требования к соответствующим процессам. Таким образом, новое средство обычно подразумевает новый процесс. Хотя такая зависимость должна быть очевидной, тем более поразительно, насколько часто представители поставщика, занимающиеся обучением, "пробегают" пятидневный семинар по использованию средства и только после этого обнаруживают, что сотрудники, обучающиеся на курсах (руководители которых уже впали в панику по поводу пятидневного отставания от плана из-за их обучения), абсолютно ничего не понимают в процессах, поддерживаемых данным средством. Чрезвычайно неприятно, например, провести два дня, объясняя лишенному какого-либо энтузиазма студенту, как рисовать ER-диаграммы, и затем услышать от него вопрос: "Между прочим, а что такое сущность? Поскольку я собираюсь программировать все на C++, зачем мне вся эта чепуха?"

Предположим, однако, что участники команды разбираются в процессах, поддерживаемых (или автоматизируемых) данным средством, и готовы с энтузиазмом использовать его в практической работе; правда, многолетний опыт преподавания структурных и объектно-ориентированных методов говорит о том, что такое предположение наивно и бессмысленно продолжать дальше обсуждение этой проблемы. Итак, если предположить, что не существует технических проблем, связанных с данным средством, и если предположить, что соответствующие процессы также не вызывают никаких проблем, тогда все, что остается, — это обучение и практика, связанные с самим средством.

Как много времени на это потребуется? Очевидно, это зависит от характера и сложности средства, а также от его пользовательского интерфейса, возможностей онлайновой подсказки и др. В лучшем случае разработчики могут самостоятельно разобраться, как использовать средство, без какого-либо формального обучения. В такую возможность ужасно хочется верить менеджеру проекта и разным другим руководителям, поскольку они считают любое обучение потерей времени и отвлечением от "реальной работы" над проектом. Более реалистичная оценка заключается в том, что на освоение средства потребуется час, день или неделя. Независимо от формы (занятия в классе, чтение книги или просто "игры" со средством) на это все равно потребуется какое-то время. Тем не менее в результате обучения мы не получим опытного пользователя, в совершенстве владеющего средством. Обучение не является двоичным феноменом: к концу недельного обучения в классе участники проектной команды не перейдут из состояния полного непонимания в состояние высшего мастерства владения средством. Это должно быть очевидным, однако нарушает планы высшего руководства, которое склонно ворчать и возмущаться: "Хорошо, мы потратили кучу денег на этих высокооплачиваемых преподавателей и напрасно потеряли столько времени в классах, чтобы эти ленивые бездельники-программисты могли научиться кодировать. Теперь мы хотим увидеть реальную отдачу от этого "замечательного" средства, за которое вы так агитировали!" Наверное, в такой наивности высшего руководства нет ничего удивительного, поскольку они сами практически не сталкивались с инструментальными средствами. Однако, к сожалению, приходится наблюдать похожую реакцию со стороны многих менеджеров экстремальных проектов, гораздо лучше разбирающихся в технических вопросах.

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

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

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

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

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

Итак, нужно использовать любые средства, которые окажутся подходящими для экстремального проекта, не обращая внимания на то, какими их считает весь остальной мир: современными или устаревшими. Но следует помнить, что новые средства в экстремальном проекте окажут воздействие и на людей, и на процессы. Как сказал 150 лет назад Генри Дэвид Торо, люди становятся орудиями в руках собственных средств.