6.2 Средства и процессы

Упомянутая выше проблема CASE-средств, вероятно, представляет собой наиболее очевидный пример трюизма: средства и процессы связаны друг с другом достаточно сложным образом. Бессмысленно браться за CASE-средство, поддерживающее структурный анализ, если вы никогда не слышали сокращений DFD и ERD. Использование такого CASE-средства будет не только бесполезным, но и чрезвычайно обременительным, если проектная команда искренне полагает, что DFD и ERD представляют собой лишённые смысла формы бюрократических документов, преследующие единственную цель: чтобы блюстители методологии могли прикрыть свои задницы.
Но ситуация не всегда бывает такой черно-белой. Например, проектная команда может считать, что диаграммы потоков данных полезны, но только как «неформальное» средство моделирования. Таким образом, «гибкое» CASE-средство может рассматриваться как нужное и полезное, в то время как «жёсткое» CASE-средство может быть отвергнуто. Можно провести очевидную аналогию с текстовым процессором: мы все способны оценить достоинства проверки орфографии, но не хотим, чтобы нас заставляли её использовать, и вполне вероятно, что мы её никогда не использовали, поскольку проверка орфографии слишком медленна и неудобна (по крайней мере, именно под таким предлогом я не использую её в Microsoft Word!). Мы будем ещё больше раздражаться, если текстовый процессор будет настойчиво отвергать слово «ain’t» как ошибочное, или требовать, чтобы любые фразы, содержащие утверждения расистского или женоненавистнического характера, утверждались специальным комитетом. Нескольких таких «замечательных» свойств может оказаться достаточно, чтобы вынудить нас вернуться к бумаге и карандашу.
Все это означает, что команда безнадёжного проекта должна в первую очередь нормально воспринимать те процессы и методологии, которым она собирается следовать; кроме того, она должна решить, каким из этих процессов следовать беспрекословно, а каким — следовать духу, но не букве закона. После принятия такого решения можно соответственно выбрать (или отвергнуть!) средства и технологию. Таким же образом менеджер проекта может решить использовать какое-либо средство для усиления процесса, необходимость которого все понимают, но на практике следуют ему достаточно небрежно; хорошие примеры таких процессов — контроль версий и управление конфигурацией.
Один из величайших мифов, касающихся использования инструментальных средств в любых проектах (и особенно опасных в безнадёжных проектах) заключается в отношении к средству как к «серебряной пуле», которая позволит творить чудеса. Разумеется, поиском чудес занимается в основном высшее руководство, однако даже менеджера проекта могут соблазнить рекламные заявления поставщика, уверяющего, что с помощью его гениальных средств можно в десять раз повысить производительность программирования, тестирования или какой-нибудь другой деятельности.
Помимо проблемы, заключающейся в новизне таких средств и в том, что никто не знает, как их использовать (о чем будет говориться ниже), существует более важный момент: средство может стать подобным «серебряной пуле» только в том случае, если оно будет позволять или заставлять разработчиков изменять свои процессы. Например, если я пишу программу, а затем компилирую её, я делаю это в соответствии с определённым процессом. При этом программированию может предшествовать процесс сквозного контроля или тщательного, формального проектирования. Теперь, если вы дадите мне компилятор, который работает на 10% быстрее, чем предыдущий, это облегчит мою работу и сделает её несколько более эффективной; может быть, незначительно возрастёт продуктивность всего проекта в целом. Но мне не придётся менять свой процесс.
С другой стороны, если мне дадут компилятор, который работает в десять раз быстрее, то он изменит мой процесс. Так произошло, когда мы перешли в 70-е годы от ночной пакетной компиляции к онлайновой компиляции, затем к компиляции на собственных ПК и рабочих станциях в 1980-е годы, и затем к различным сочетаниям пошаговой компиляции (а ля Delphi) и интерпретации (а ля Visual Basic). Вследствие этого многие разработчики отказались от тщательного проектирования, предшествующего кодированию, из тех соображений, что они смогут писать программы на ходу и импровизировать в процессе кодирования; во многих проектах отказались также от практики сквозного кодирования, полагая, что программист и так сможет быстро обнаружить и исправить свои ошибки.
Едва ли кто-нибудь станет возражать против использования усовершенствованных технологий, позволяющих избавляться от рутинных и утомительных процессов. Гораздо труднее внедрить новую технологию, требующую введения новых процессов или модификации существующих процессов, к которым мы привыкли. Хорошим примером служит процесс повторного использования и связанная с ним технология библиотек повторно используемых компонент, броузеров и других средств. Проектные команды, использующие эту технологию, могут повысить уровень повторного использования кода приблизительно от 20 процентов (уровень, который я называю «случайным») до 60 процентов и более; разумеется, если технология используется в масштабе всей организации, то уровень повторного использования может достигать 80-90 процентов и более.
Разница между 20-процентным и 80-процентным уровнем повторного использования эквивалентна четырехкратному повышению производительности. Как отмечено в [2], постепенное последовательное повышение уровня повторного использования приносит больше выгод, чем можно было бы ожидать. Если уровень повторного использования возрастает с 80 до 90 процентов, это означает, что вместо разработки «с нуля» 20 процентов кода проектной команде придётся разрабатывать только 10 процентов. Таким образом, их загрузка снизится вдвое.
Все это замечательно — и вполне достойно называться «серебряной пулей» — но совершенно бесполезно, если проектная команда (и в конечном счёте вся организация) окажется неспособной или не пожелает менять свои процессы в соответствиями с требованиями технологии повторного использования. Ирония заключается в том, большинство организаций поставят в вину самой технологии свои собственные провалы: они приобретут дорогостоящую библиотеку классов или поменяют свою старую методологию разработки ПО на объектно-ориентированную методологию, исходя из предположения, что объекты и повторное использование — это одно и то же; когда они в конечном счёте обнаружат, что не добились сколько-нибудь ощутимых результатов, то будут винить во всем объектную технологию, библиотеку классов, поставщика и др. Между тем, все процессы остались в точности такими же, какими были до внедрения новой технологии. Культура такой организации может быть выражена следующей фразой: «Только бездари пользуются чужим кодом; настоящие программисты, черт возьми, пишут свой!»
С точки зрения безнадёжного проекта в этом заключена весьма простая мораль: если внедрение новых средств потребует серьёзного изменения «стандартных» процессов команды, то это значительно увеличит проектный риск и, возможно, будет способствовать провалу проекта. Иногда дополнительные проблемы вносит необходимость обучения и освоения практического использования новых средств (они будут обсуждаться ниже). Однако обычно гораздо более серьёзной проблемой является изменение режима работы, который целиком определяется процессом. Это достаточно трудно сделать и в нормальных условиях, когда у нас достаточно времени, чтобы относительно безболезненно перейти к новому процессу. Для безнадёжного проекта такой переход будет просто катастрофическим.

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

Как было отмечено выше, некоторые безнадёжные проекты хватаются за новые средства и технологии, как за панацею для достижения гораздо более высокой продуктивности работы. Предположим на минуту, что мы нашли способ разрешить культурные и политические проблемы, связанные с изменением процессов. О чем же ещё необходимо побеспокоиться?
Два наиболее вероятных риска — технология и обучение. Во многих случаях новое средство даже не является законченным коммерческим продуктом; обычно кто-нибудь из проектной команды переписывает из Internet бета-версию. Или же, данное средство невозможно интегрировать с любыми другими средствами, используемыми проектной командой; поставщик давал на этот счёт неопределённые обещания, однако в результате оказалось, что возможности экспорта-импорта изобилуют ошибками. Или, средство никем не поддерживается — оно разработано студентом из Узбекистана или (что ещё хуже!) создано в домашних условиях одним из разработчиков ПО, не видящим ничего странного в том, что банк разрабатывает своё собственное CASE-средство, а страховая компания — свою СУБД.
Допустим, что средство является достаточно надёжным, а его поставщик обладает устойчивой репутацией и обеспечивает поддержку на высоком уровне. В этом случае проблемы будут связаны с освоением, поскольку даже если это средство прежде широко использовалось в организации, никто не воспринимал его как «серебряную пулю», которая сможет чудесным образом спасти проектную команду от гарантированной катастрофы. Иногда можно видеть проектную команду, добивающуюся разрешения использовать какое-либо мощное средство, с которым они уже имели дело в предыдущей работе — однако, это достаточно редкое явление. В большинстве случаев никто из участников проектной команды и вообще никто в организации никогда прежде не видел или не использовал это средство.
Как отмечалось раньше, любое нетривиальное средство обычно предъявляет жёсткие требования к соответствующим процессам; таким образом, новое средство обычно подразумевает новый процесс. Хотя такая зависимость должна быть очевидной, тем более поразительно, насколько часто представители поставщика, занимающиеся обучением, пробегают пятидневный семинар по использованию средства и только после этого обнаруживают, что сотрудники, обучающиеся на курсах (руководители которых уже впали в панику по поводу пятидневного отставания от плана из-за их обучения), абсолютно ничего не понимают в процессах, поддерживаемых данным средством. Чрезвычайно неприятно, например, провести два дня, объясняя лишённому какого-либо энтузиазма студенту, как рисовать ER-диаграммы, и затем услышать от него вопрос: «Между прочим, а что такое сущность? Поскольку я собираюсь программировать все на С++, зачем мне вся эта чепуха?»
Предположим, однако, что участники команды разбираются в процессах, поддерживаемых (или автоматизируемых) данным средством и готовы с энтузиазмом использовать его в практической работе; правда, мой 20-летний опыт преподавания структурных и объектно-ориентированных методов говорит о том, что такое предположение наивно, и бессмысленно продолжать дальше обсуждение этой проблемы. Итак, если мы предположим, что не существует технических проблем, связанных с данным средством, и если предположим, что соответствующие процессы также не вызывают никаких проблем, тогда все, что остаётся — это обучение и практика, связанные с самим средством.
Как много времени на это потребуется? Очевидно, это зависит от характера и сложности средства, а также от его пользовательского интерфейса, возможностей онлайновой подсказки и др. В лучшем случае разработчики могут самостоятельно разобраться, как использовать средство, без какого-либо формального обучения; в такую возможность ужасно хочется верить менеджеру проекта и разным другим руководителям, поскольку они считают любое обучение потерей времени и отвлечением от «реальной работы» над проектом. Более реалистичная оценка заключается в том, что на освоение средства потребуется час, день или неделя. Независимо от формы (занятия в классе, чтение книги или просто «игры» со средством), на это все равно потребуется какое-то время.
Тем не менее, в результате обучения мы не получим опытного пользователя в совершенстве владеющего средством. Обучение не является двоичным феноменом: к концу недельного обучения в классе участники проектной команды не перейдут из состояния полного непонимания в состояние высшего мастерства владения средством. Это должно быть очевидным, однако нарушает планы высшего руководства, которые склонны ворчать и возмущаться: «Хорошо, мы потратили кучу денег на этих высокооплачиваемых преподавателей и напрасно потеряли столько времени в классах, чтобы эти ленивые бездельники-программисты могли научиться кодировать. Теперь мы хотим увидеть реальную отдачу от этого «замечательного» средства, за которое вы так агитировали!» Наверное, в такой наивности высшего руководства нет ничего удивительного, поскольку они сами практически не сталкивались с инструментальными средствами; однако, к сожалению, мне приходилось наблюдать похожую реакцию со стороны многих менеджеров безнадёжных проектов, гораздо лучше разбирающихся в технических вопросах.
В замечательной статье [1] мой коллега Mellir Page-Jones утверждает, что в разработке ПО существует семь ступеней мастерства; его статья сосредоточена в основном на методологиях , но я думаю, что она в такой же степени применима к средствам и технологиям. К списку, приведённому ниже, я добавил свои собственные оценки, касающиеся времени достижения разработчиком средней квалификации различных ступеней мастерства в предположении, что средство или технология обладают средней сложностью:

Таблица 6.1 Семь ступеней мастерства в разработке ПО



6.4 Заключение

Означает ли весь пессимизм данной главы, что вообще не следует использовать никакие средства? Может быть, просто выбросить всю эту технологию и вернуться к добрым старым клавишным перфораторам?
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