Как было отмечено выше, некоторые безнадёжные проекты хватаются за новые средства и технологии, как за панацею для достижения гораздо более высокой продуктивности работы. Предположим на минуту, что мы нашли способ разрешить культурные и политические проблемы, связанные с изменением процессов. О чем же ещё необходимо побеспокоиться?
Два наиболее вероятных риска – технология и обучение. Во многих случаях новое средство даже не является законченным коммерческим продуктом; обычно кто-нибудь из проектной команды переписывает из Internet бета-версию. Или же, данное средство невозможно интегрировать с любыми другими средствами, используемыми проектной командой; поставщик давал на этот счёт неопределённые обещания, однако в результате оказалось, что возможности экспорта-импорта изобилуют ошибками. Или, средство никем не поддерживается – оно разработано студентом из Узбекистана или (что ещё хуже!) создано в домашних условиях одним из разработчиков ПО, не видящим ничего странного в том, что банк разрабатывает своё собственное CASE-средство, а страховая компания – свою СУБД.
Допустим, что средство является достаточно надёжным, а его поставщик обладает устойчивой репутацией и обеспечивает поддержку на высоком уровне. В этом случае проблемы будут связаны с освоением, поскольку даже если это средство прежде широко использовалось в организации, никто не воспринимал его как «серебряную пулю», которая сможет чудесным образом спасти проектную команду от гарантированной катастрофы. Иногда можно видеть проектную команду, добивающуюся разрешения использовать какое-либо мощное средство, с которым они уже имели дело в предыдущей работе – однако, это достаточно редкое явление. В большинстве случаев никто из участников проектной команды и вообще никто в организации никогда прежде не видел или не использовал это средство.
Как отмечалось раньше, любое нетривиальное средство обычно предъявляет жёсткие требования к соответствующим процессам; таким образом, новое средство обычно подразумевает новый процесс. Хотя такая зависимость должна быть очевидной, тем более поразительно, насколько часто представители поставщика, занимающиеся обучением, пробегают пятидневный семинар по использованию средства и только после этого обнаруживают, что сотрудники, обучающиеся на курсах (руководители которых уже впали в панику по поводу пятидневного отставания от плана из-за их обучения), абсолютно ничего не понимают в процессах, поддерживаемых данным средством. Чрезвычайно неприятно, например, провести два дня, объясняя лишённому какого-либо энтузиазма студенту, как рисовать ER-диаграммы, и затем услышать от него вопрос: «Между прочим, а что такое сущность? Поскольку я собираюсь программировать все на С++, зачем мне вся эта чепуха?»
Предположим, однако, что участники команды разбираются в процессах, поддерживаемых (или автоматизируемых) данным средством и готовы с энтузиазмом использовать его в практической работе; правда, мой 20-летний опыт преподавания структурных и объектно-ориентированных методов говорит о том, что такое предположение наивно, и бессмысленно продолжать дальше обсуждение этой проблемы. Итак, если мы предположим, что не существует технических проблем, связанных с данным средством, и если предположим, что соответствующие процессы также не вызывают никаких проблем, тогда все, что остаётся – это обучение и практика, связанные с самим средством.
Как много времени на это потребуется? Очевидно, это зависит от характера и сложности средства, а также от его пользовательского интерфейса, возможностей онлайновой подсказки и др. В лучшем случае разработчики могут самостоятельно разобраться, как использовать средство, без какого-либо формального обучения; в такую возможность ужасно хочется верить менеджеру проекта и разным другим руководителям, поскольку они считают любое обучение потерей времени и отвлечением от «реальной работы» над проектом. Более реалистичная оценка заключается в том, что на освоение средства потребуется час, день или неделя. Независимо от формы (занятия в классе, чтение книги или просто «игры» со средством), на это все равно потребуется какое-то время.
Тем не менее, в результате обучения мы не получим опытного пользователя в совершенстве владеющего средством. Обучение не является двоичным феноменом: к концу недельного обучения в классе участники проектной команды не перейдут из состояния полного непонимания в состояние высшего мастерства владения средством. Это должно быть очевидным, однако нарушает планы высшего руководства, которые склонны ворчать и возмущаться: «Хорошо, мы потратили кучу денег на этих высокооплачиваемых преподавателей и напрасно потеряли столько времени в классах, чтобы эти ленивые бездельники-программисты могли научиться кодировать. Теперь мы хотим увидеть реальную отдачу от этого «замечательного» средства, за которое вы так агитировали!» Наверное, в такой наивности высшего руководства нет ничего удивительного, поскольку они сами практически не сталкивались с инструментальными средствами; однако, к сожалению, мне приходилось наблюдать похожую реакцию со стороны многих менеджеров безнадёжных проектов, гораздо лучше разбирающихся в технических вопросах.
В замечательной статье [1] мой коллега Mellir Page-Jones утверждает, что в разработке ПО существует семь ступеней мастерства; его статья сосредоточена в основном на методологиях, но я думаю, что она в такой же степени применима к средствам и технологиям. К списку, приведённому ниже, я добавил свои собственные оценки, касающиеся времени достижения разработчиком средней квалификации различных ступеней мастерства в предположении, что средство или технология обладают средней сложностью:
Таблица 6.1 Семь ступеней мастерства в разработке ПО
Заключение
Означает ли весь пессимизм данной главы, что вообще не следует использовать никакие средства? Может быть, просто выбросить всю эту технологию и вернуться к добрым старым клавишным перфораторам? Значит ли это, что технология в принципе не способна сослужить нам какую-либо добрую службу?
Риторический характер этих вопросов преследует цель напомнить, что во всех подобных дискуссиях на первом месте должен стоять здравый смысл. Когда звезды и планеты выстроятся в одну линию, может быть, технология действительно станет палочкой-выручалочкой по крайней мере для одного или двух безнадёжных проектов. Определённо, следует использовать преимущества самых передовых технологий, поскольку они способны усилить наш интеллект и освободить от решения рутинных задач, связанных с разработкой ПО.
В лучшем из всех миров разработчики ПО будут иметь возможность изучать, экспериментировать и практиковаться в работе с мощными средствами без какого-либо риска; естественно, в лучшем случае эти средства уже развёрнуты во всей организации и являются частью её культуры и инфраструктуры. В этом случае нет необходимости затевать какие-либо дискуссии по поводу средств и технологий вообще; остаётся только взять средства – и вперёд в безнадёжный проект.
Причина обсуждения в данной главе – и причина того, что все это имеет самое непосредственное отношение к большинству безнадёжных проектов – заключается в том, что организация использует заурядные средства, или кто-либо верит, что совершенно новая с виду технология, с восторгом объявленная только на прошлой неделе начинающим поставщиком, может каким-то образом спасти дело. Первый сценарий приводит в уныние, однако он достаточно распространён; второй сценарий тоже достаточно распространён по той простой причине, что технологии в нашей области распространяются быстро и неумолимо.
Если бы внедрение новой технологии не оказывало никакого влияния на наши процессы, и не требовало специального обучения и практики, то мы могли бы принять решение, основываясь всего лишь на сопоставлении затрат и выгод. Поскольку природный инстинкт многих руководителей высокого уровня подсказывает им, что любую проблему можно решить с помощью простого финансового вливания, я заметил, что существует тенденция к гораздо большему использованию совершенно новых технологий в безнадёжных проектах, чем в «нормальных». Как я пытался объяснить в данной главе, ирония заключается в том, что новое средство может оказаться последней каплей, переполнившей чашу терпения; таким образом, именно на средство будет возложена ответственность за неудачу проекта.
Итак, используйте любые средства, которые вы сочтёте подходящими для вашего безнадёжного проекта, не обращая внимания на то, какими их считает весь остальной мир: современными или устаревшими. Но не забывайте, что новые средства в безнадёжном проекте окажут воздействие и на людей, и на процессы. Как сказал 150 лет назад Генри Дэвид Торо, люди становятся орудиями в руках собственных средств.
Литература к главе:
1) Mellir Page-Jones.The Seven Stages in Software Engineering. American Programmer, July-August 1990.
2) Paul G. Basset. Framing Software Reuse: Lessons from the Real World. Upper Saddle River, NJ: Prentice Hall, 1996.
Дополнительная литература:
1) Michael Schrage. No More Teams! Mastering the Dynamics of Creative Collaboration. New York: Doubleday-Dell Publishing Company, 1995.
ГЛАВА 7.