1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom
.pdfОсобенности современных проектов |
501 |
ляют: «Не знаем, как это случилось, но когда мы проснулись се годня утром, то обнаружили, что отстаем от графика на полгода!» Простая мысленная модель неопытного менеджера проекта предлагает следующий план действий — немедленно нанять по больше людей. Почему? — Потому что его мысленная модель го ворит примерно следующее: «Нам необходимо выполнить боль ше работы в офаниченное время, поскольку мы не можем отод винуть срок окончания проекта. Больше людей сделают больше работы, поэтому, чтобы выполнить всю требуемую работу, надо нанять дополнительных сотрудников».
Разумеется, у опытных менеджеров совершенно другая мыс ленная модель. Она опирается на их собственный опыт и Закон Брукса, который он сформулировал в своей знаменитой книге «Мифический человеко-месяц»: если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше. Поэтому реакция многих менеджеров, особенно в безнадежных проектах, будет иной: «В нашем распоряжении неофаниченное и бесплатное сверхурочное время. Если проект отстает от фафика, попросим команду «добровольно» поработать сверхурочно неко торое время, пока проект опять не войдет в фафик. Если с само го начала проекта ясно, что фафик чересчур оптимистичен, то следует заранее объявить, что сверхурочная работа будет обяза тельной, и довести до сведения каждого, что все продвижения по службе и поощрения будут зависеть от их энтузиазма в выполне нии своих обязанностей».
Исследования показали, что менеджеры зачастую справляют ся с проблемами, используя мысленные модели, не учитывающие всех аспектов ситуации. Например, менеджеры с техническим образованием склонны недооценивать влияние социальных фак торов.
Чем же еще пользуются менеджеры проектов помимо мыс ленных моделей, основанных на опыте, интуиции и суевериях? Разумеется, многие менеджеры используют сетевые фафики PERT (Program Evaluation-and-Review Technique — метод оценки и пересмотра планов) или фафики Ганта. Однако не будет преу величением предположить, что Microsoft Excel — наиболее широ ко используемое средство управления проектами в 1Т-организа- циях. Табличная модель дает полезную информацию относитель но процесса, проекта или организации, и большинство менедже ров с этим согласятся.
502 |
Глава 7 |
Тем не менее таблица статична, она не показывает динамику процессов, во всяком случае, она не наглядна. С таблицами свя зана еще одна проблема. Поскольку они зачастую связаны с фи нансовым планированием, их стремятся наполнить только «ося заемыми» показателями, которые можно измерить - количество сотрудников, денег, рабочих станций, строк кода и т.д. Такой под ход уводит в сторону от оценки неформальных'параметров про екта - морального состояния, мотивации, качества и уровня по нимания технологии разработки ПО.
Поскольку такие параметры являются неформальными по своей природе, нужно относиться к ним с некоторой предосто рожностью и использовать их в основном для качественной оценки порядка изменений и прогнозирования тенденций. Нап ример, менеджер может задать такой практический вопрос: «Что произойдет с бюджетом и фафиком проекта, если я направлю участников проектной команды на учебные курсы, и в результате они потратят вдвое меньше времени на освоение объектно-ори ентированной технологии?»
Большое значение имеет также природа взаимодействий между различными компонентами процесса. Если изменить ка кой-либо компонент процесса, то это, вероятно, скажется на ка ком-нибудь другом. Кроме того, при взаимодействии могут иметь место временные задержки и циклы обратной связи. Эти взаимодействия можно отразить в табличной модели, но они не будут видны постороннему наблюдателю. Взаимодействия выра жаются в виде связей между ячейками Таблицы за счет использо вания различных математических формул, встроенных в ячейки. Если пользоваться табличным процессором, то можно видеть эти формулы, но если просто смотреть на таблицу, то не видно ника ких связей между ее ячейками.
Сочетание нескольких взаимодействующих компонентов мо жет привести к появлению «волнового эффекта» в организации. Допустим, организация-разработчик делает существенные ин вестиции в CASE-средства, но с каждым кварталом тратит все меньше и меньше денег на обучение. Если работа с CASE-сред- ствами требует использования формальных и строгих методов, а персонал не освоил их в достаточной степени, не удивительно, что продуктивность разработки в начальном периоде снижается. Вместе с падением продуктивности и разочарованием в новых CASE-средствах ухудшается и моральное состояние команды, от
Особенности современных проектов |
503 |
которого невозможно отмахнуться. Если оно ухудшается, растет текучесть кадров, и в первую очередь уходят самые продуктив ные. Во-первых, у них самые лучшие приглашения на работу от других организаций и, во-вторых, они испытывают наибольшее разочарование в нынешней ситуации. В результате их ухода сред няя продуктивность организации падает еще больше, что вызы вает дальнейшее ухудшение морального состояния ... которое по вышает текучесть кадров ... которая заставляет увольняться ос тавшихся продуктивных сотрудников ... и так до тех пор, пока в организации не останется ни одного нормального специалиста.
Если этот пример выглядит слишком надуманным (хотя эта ситуация вполне реальна), можно рассмотреть более приземлен ную ситуацию. При оценке различных параметров проекта почти все менеджеры учитывают фактор «безопасности» (известный также, как фактор случайности, подгона под нужный результат, и под другими красивыми названиями), и они это делают без учета какой-либо динамики. Различные факторы безопасности порож дают различные проекты. Если проектная команда знает, что ее менеджер опубликовал официальный график проекта с нулевым запасом прочности, участники проекта немедленно скорректиру ют свое поведение, исключив любую деятельность, которую они считают несущественной. В зависимости от характера проекта это может означать отказ от документирования, тестирования, обеспечения качества, присутствия на еженедельных совещаниях или ответов на сообщения электронной почты. И наоборот, если график проекта составлен с большим запасом, то начинает действовать Закон Паркинсона: работа занимает все отведенное для нее время.
Некоторые организации, достигшие третьего, четвертого или пятого уровней СММ, осознали важность проблем, связанных с динамикой процессов. Даже если исключить неформальные фак торы, временные задержки и циклы обратной связи все равно мо гут оказать значительное воздействие на успех проекта. В качест ве простого примера рассмотрим влияние дефектов проектирова ния, допущенных на стадии анализа в классическом «каскадном» процессе и обнаруженных только в начале стадии программиро вания или тестирования. В формальном, строгом процессе разра ботки это означает, что нужно снова вернуться на стадию анали за для исправления ошибок и затем провести все изменения че рез проектирование и кодирование, пока не дойти снова до тес-
504 |
Глава 7 |
тирования. Разумеется, возможно, что в процессе исправления ошибок что-то сделано не так, и тестирование выявит новые ошибки. В итоге может потребоваться несколько циклов исправ лений, пока тестирование не даст удовлетворительных результа тов. Все это может существенно повлиять на общее время про цесса, который организация пытается усовершенствовать.
Если динамика процесса разработки ПО настолько важна, то каким образом в ней можно разобраться? Таблицы для этого не очень подходят, поскольку они не отражают взаимозависимости и обратные связи между компонентами процесса. Напротив, ви зуальные модели лучше подходят для иллюстрации «целостной» природы процесса, такие модели вызывают дискуссии и критику.
Здесь имеется только одна проблема: фафические модели ста тичны. За небольшим исключением они были изобретены до по явления современных CASE-средств, поэтому их привыкли рисо вать на бумаге или отображать на пассивном дисплее. Если пост роить диафамму потоков данных с помощью типичного CASEсредства, то она не «движется», не показывает динамику модели руемого процесса. Для этого требуется анимация, которой боль шинство поставщиков CASE-средств никогда не занималось.
В результате организации-разработчики, пытающиеся дос тичь более глубокого понимания своих процессов, обращаются к средствам имитационного моделирования, которые могут отоб разить динамику системы. Одна из наиболее известных динами ческих моделей процесса создания FIQ была разработана Тариком Абдель-Хамидом. Она отражает виды работ в процессе уп равления проектом среднего размера, использующего традици онные средства разработки и классическую «каскадную» модель процесса разработки. Хотя она не учитывает особенности сегод няшних проектов, использующих быстрое прототипирование, средства визуальной разработки, библиотеки повторно использу емых компонентов и т.д., тем не менее, она может служить в ка честве отправной точки для организаций, желающих более глубо ко разобраться во взаимодействиях между различными компо нентами их процесса разработки ПО.
В идеальной ситуации менеджеру «безнадежного» проекта желательно располагать временем, финансами, настойчивостью и техническими ресурсами для создания динамической модели своего проекта. Основная причина для построения такой модели заключается в том, что ее можно использовать для ответов на
Особенности современных проектов |
505 |
вопросы типа «что-если», анализируя «нелинейные» аспекты ди намики проекта. Например, может оказаться, что существенное увеличение некоторого параметра (такого, как количество новых сотрудников, нанимаемых за месяц) окажет совершенно незна чительное воздействие на какой-либо из основных параметров, например, на «ожидаемую дату завершения проекта». В других случаях небольшое изменение незначительного, на первый взгляд, параметра (например, «частоты ухода» профессионалов) может оказать на проект такое существенное воздействие, кото рого никто не ожидал. Такое происходит из-за наличия множест ва взаимодействующих факторов, взаимное влияние которых друг на друга достаточно сложно количественно оценить.
К сожалению, в реальном мире очень немногие менеджеры «безнадежных» проектов располагают временем или ресурсами для создания моделей. Однако даже у менеджеров, находящихся в самых стрессовых ситуациях, все же есть некоторое время и ре сурсы, и если они потратят хотя бы час или два на анализ времен ных задержек и обратных связей, то уже и это сможет существен но повлиять на динамику проекта.
7.8. КОНТРОЛЬ ЗА ПРОДВИЖЕНИЕМ ПРОЕКТА
Безусловно, очень важно в самом начале проекта договорить ся с требовательными заказчиками относительно реалистичных сроков и бюджета, сформировать проектную команду, опреде лить необходимые рабочие процессы и процедуры. К сожалению, некоторые менеджеры проектов полагают, что это самая трудная часть работы и после того, как она сделана, все пойдет гораздо легче. На самом деле контроль за продвижением (иначе говоря — прогрессом) безнадежного проекта — это срочная и важная рабо та, отнимающая много времени; ее нельзя игнорировать или за ниматься ею от случая к случаю. Именно это самая важная обя занность менеджера проекта после завершения всех тяжелых пе реговоров в начале проекта.
Чтобы преуспеть в этой деятельности, менеджер проекта дол жен уметь отличать реальный прогресс от «кажущегося» прогрес са. Многие менеджеры проектов давно усвоили, что синдром «выполнено на 90%» является опасной иллюзией, и они знают, что в безнадежном проекте не менее опасно утверждать «мы вы-
506 Глава 7
полнили анализ и проектирование на 100%, но еще не закончили написание кода и не тестировали его». Практичной и эффектив ной альтернативой это дилемме является принцип «ежедневной сборки» («daily build»).
Неявно подразумевается, что очередные результаты, получае мые проектной командой, появляются через интервалы, измеря емые месяцами или неделями. К этому приучает опыт нормаль ных проектов, и это согласуется с обычным темпом деловой жиз ни — например еженедельными совещаниями персонала, ежеме сячными отчетами о состоянии работ, ежеквартальными презен тациями для высшего руководства и т.д.
Однако безнадежные проекты нуждаются в другом подходе. Когда проект приходит к прототипированию и пошаговой разра ботке, работу над ним надо организовать на основе принципа «ежедневной сборки». Под этим подразумевается следующее: компиляция, сборка, установка и тестирование всей совокупнос ти разработанного командой кода должны выполняться каждый день, как если бы этот день был последним перед завершением проекта, и на следующее утро было бы необходимо сдать закон ченную систему пользователям.
Разумеется, с первого дня невозможно приступить к ежеднев ной сборке. Правда, уже на второй день работы можно написать подпрограмму типа «Hello, World», и трудно сегодня удивить ко го-то совершенно новыми технологиями. Однако существуют определенные требования, которым должна удовлетворять вер сия прототипа системы при первой «официальной» демонстра ции: помимо того, что она включает необходимую совокупность компонентов, процедур или модулей и несколько сотен, а может быть и тысяч строк кода, она должна выполнять реальный ввод данных, производить реальную обработку или вычисления и формировать реальный выход. Именно с этого момента следует начинать ежедневную сборку и формировать каждый день новую (желательно улучшенную) версию системы.
Для менеджера проекта подобная стратегия может быть при оритетом номер один. Если в течение недели никто не сможет сообщить менеджеру проекта, что разрабатываемое приложение не хочет правильно взаимодействовать с новой объектно-ориен тированной базой данных, то в результате проект может безна дежно отстать от графика. До тех пор, пока менеджер судит о сос тоянии проекта по устным отчетам, запискам или диаграммам
Особенности современных проектов |
5 0 7 |
потоков данных, будет слишком легко перепутать движение с прогрессом и усилия с результатами. Однако, если менеджер про екта настаивает на ежедневной физической демонстрации ре зультатов, будет нелегко скрыть возникающие трудности, кото рые в конечном счете могут способствовать провалу проекта.
В то время как вряд ли кто-нибудь вправе претендовать на «изобретение» данного подхода, известно, что он впервые стал популярным во время разработки операционной системы Windows NT. Можно также отметить, что при разработке Windows 95 использовался принцип «ежедневной сборки»; заключитель ная бета-версия перед выпуском конечного продукта была реали зована в августе 1995 г. и называлась «Проект 951».
Важно осознавать, что подобный подход становится неотъем лемой составляющей процесса разработки системы, которому следует проектная команда. Кроме того, процесс ежедневного за вершения работы над проектом должен быть автоматизирован ным и выполняться ночью без участия программистов, тогда он будет эффективным. Такой подход подразумевает наличие авто матизированного управления конфигурацией ПО и механизмов управления исходными кодами, а также разнообразных «сцена риев» для выполнения компиляции и сборки приложений. Но что еще более важно, он подразумевает наличие системы автома тизированного тестирования, которая может работать всю ночь, выполняя множество тестов для проверки работоспособности системы. Таким образом, чтобы реализовать на практике прин цип «ежедневной сборки», необходимо иметь в своем распоряже нии адекватный набор средств и технологий.
Хотя ежедневная сборка весьма эффективна с точки зрения мониторинга продвижения безнадежного проекта, она не слиш ком помогает справиться со многими серьезными проблемами. Важно понимать семантическое различие между тем, что некото рые менеджеры называют «issue» (вопрос, незначительная проб лема), и рисками. В ходе работы над проектом ситуация может выйти из-под контроля. Это происходит потому, что управление рисками строится в основном на эмоциях и инстинктах, а не на формальных процессах, и менеджер в процессе работы зачастую может вовремя не заметить появление новых рисков. В лучшем случае риски, очевидные в самом начале проекта, будут устра няться. В нормальной ситуации они являются поводом для бес покойства в течение всей работы над проектом (например, риск
508 |
Глава 7 |
ухода ключевого разработчика). Однако неожиданно могут воз никнуть совершенно новые риски, которые окажутся убийствен ными для проекта.
Проектная команда должна различать оценку риска, управле ние риском и ликвидацию риска. В худшем случае проектная ко манда реагирует на риск только по мере его возникновения — например, вьщеляет дополнительные ресурсы для проведения очередного тестирования, чтобы смягчить последствия ошибки. В этом случае проблеме уделяется внимание только после ее про явления. При подобном подходе работа строится в стиле «туше ния пожара». Для проектной команды такая ситуация может быть катастрофой. Гораздо лучше предупреждать риск заранее. Это оз начает, что команда согласна соблюдать выполнение формаль ных процессов оценки и управления с целью предотвращения потенциальных рисков.
Профилактическое управление рисками направлено на уст ранение самих причин, приводящих к неудачам. Оно нередко яв ляется центральным звеном всех начинаний, связанных с управ лением качеством в организации. При таком подходе проявляет ся тенденция к значительному расширению границ оценки рис ков и появлению возможности их предотвращения. Это может привести к весьма агрессивному стилю управления, основанному на полном контроле над степенью риска в соответствии с его до пустимостью для организации. Эта проблема в большей степени стратегическая, она должна обсуждаться и реализовываться за пределами «безнадежного» проекта. Команда «безнадежного» проекта преследует в основном тактические цели; она пытается не изменить культуру организации, а всего лишь выжить и нор мально закончить проект.
Оценка риска выполняется обычно путем оценок сложности разрабатываемой системы или продукта, а также клиентской сре ды и среды проектной команды. Сложность продукта можно оце нить в терминах объема (например, количества функциональных точек), ограничений производительности, технической сложнос ти и т.д. Риск, связанный с клиентской средой, определяется в ос новном такими факторами, как число пользователей, вовлечен ных в проект, их уровень квалификации, значение разработки для пользовательского бизнеса, вероятность того, что внедрение новой системы (если оно произойдет) приведет к реорганизации, и т.д. Наконец, риск, связанный со средой проектной команды.
Особенности современных проектов |
509 |
зависит от ее способностей, опыта, морального состояния и фи зического/эмоционального здоровья.
Как правило, достаточно полная модель риска может включать сто или более факторов риска. Некоторые из рисков можно оце нить количественно, например требования к производительности (скорости реакции системы) или объем системы, выраженный в количестве функциональных точек. Другие факторы (например, степень расположенности или враждебности пользователей) мо гут быть оценены только качественно. Такие факторы принято ха рактеризовать значениями «высокий», «низкий» или «средний».
После того как риски подверглись идентификации и оценке, менеджер и команда могут выбрать подходящую стратегию ми нимизации или исключения по возможности большего числа рисков. Эта деятельность носит, конечно, общий характер. Одна ко не следует забывать: сама природа «безнадежного» проекта та кова, что количество рисков превышает обычное, они более серь езны, и от них нельзя просто так избавиться. С другой стороны, если риски являются экстраординарными, то и решения должны быть адекватными: в то время как проектная команда нормаль ного проекта может никогда не набраться смелости, чтобы обра титься к исполнительному директору или первому вице-прези денту с просьбой уменьшить риск путем существенного увеличе ния бюджета или снятия серьезных бюрократических ограниче ний, участникам безнадежного проекта будет вполне разумно об ратиться с такой просьбой.
В любом случае, если существуют серьезные факторы риска, воздействие которых исключить невозможно (а в «безнадежных» проектах почти всегда так оно и есть), их следует зафиксировать в специальном документе, идентифицировав для каждого риска возможные последствия и разработав план действий в непредви денных ситуациях. Документирование рисков является важной практической деятельностью, подталкивающей пользователей и руководство к пониманию того, что они предпочитали не заме чать и игнорировать.
Менеджеры проектов традиционно использовали сетевые графики и графики Ганта для планирования продвижения своих проектов. Они пытались разбить весь проект на набольшие зада чи с «двоичным» результатом (т.е. либо «выполнено», либо «не выполнено») и контролем качества на выходе, который позволял убедиться, что результаты выполненных задач можно включить в разрабатываемую систему. В такой подход очень хорошо вписы-