Динамика процессов

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

Это происходит, несмотря на героические усилия, предпри­нимаемые многими организациями для упорядочения и усовер­шенствования своих процессов, используя RAD, XP, SEI-CMM и т.д. Многие из этих усилий затрачиваются впустую, поскольку не понимается динамика процессов (особенно временные задержки и циклы обратной связи) и игнорируются неформальные процес­сы, играющие главную роль в проектах. По этой причине в пос­ледние несколько лет моделирование и имитация динамики та­ких процессов вызывают особый интерес.

Динамика систем — это не новое понятие, ему уже несколько десятков лет. В США одни из первых работ в этой области выпол­нил в начале 1960-х годов в Массачусетс ком технологическом институте Джей Форрестер. С тех пор многое изменилось: есть ПК, позволяющие работать с имитационной моделью в интерак­тивном режиме, в отличие от пакетных систем с недельным цик­лом обработки; имеются языки визуального моделирования, и применяются общие принципы динамики систем для решения небольших, конкретных задач.

Один из примеров таких конкретных задач — процессы созда­ния ПО. Начиная с первых работ Тарика Абдель-Хамида[37] в Массачусетском технологическом институте в начале 1990-х годов, исследователи и специалисты в области совершенствования про­цессов экспериментируют с динамическими моделями, пытаясь глубже разобраться в процессах создания ПО. Если это поможет менеджеру безнадежного проекта лучше понять, что происходит в его проекте, то вероятность успеха может повыситься.

Многие воспринимают слово «модель» в контексте процессов разработки ПО, как набор графических абстракций ПО — напри­мер, диаграммы UML, блок-схемы, диаграммы «сущность-связь» и др. Однако в реальном мире менеджеры проектов мало что ис­пользуют из всей этой кухни в своей повседневной деятельности. Такие модели используются скорее для планирования и согласо­вания общей стратегии, а для принятия ежедневных оперативных решений используются другие модели, наиболее важными из ко­торых являются мысленные (mental) и табличные (spreadsheet) модели.

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

Представьте себе такую ситуацию: половина проекта позади, утром программисты приходят в офис к менеджеру и хмуро заявляют: «Не знаем, как это случилось, но когда мы проснулись се­годня утром, то обнаружили, что отстаем от графика на полгода!» Простая мысленная модель неопытного менеджера проекта предлагает следующий план действий — немедленно нанять по­больше людей. Почему? — Потому что его мысленная модель го­ворит примерно следующее: «Нам необходимо выполнить боль­ше работы в ограниченное время, поскольку мы не можем отод­винуть срок окончания проекта. Больше людей сделают больше работы, поэтому, чтобы выполнить всю требуемую работу, надо нанять дополнительных сотрудников».

Разумеется, у опытных менеджеров совершенно другая мыс­ленная модель. Она опирается на их собственный опыт и Закон Брукса, который он сформулировал в своей знаменитой книге «Мифический человеко-месяц»: если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше. Поэтому реакция многих менеджеров, особенно в безнадежных проектах, будет иной: «В нашем распоряжении неограниченное и бесплатное сверхурочное время. Если проект отстает от графика, попросим команду «добровольно» поработать сверхурочно неко­торое время, пока проект опять не войдет в график. Если с само­го начала проекта ясно, что график чересчур оптимистичен, то следует заранее объявить, что сверхурочная работа будет обяза­тельной, и довести до сведения каждого, что все продвижения по службе и поощрения будут зависеть от их энтузиазма в выполне­нии своих обязанностей».

Исследования показали, что менеджеры зачастую справляют­ся с проблемами, используя мысленные модели, не учитывающие всех аспектов ситуации. Например, менеджеры с техническим образованием склонны недооценивать влияние социальных фак­торов.

Чем же еще пользуются менеджеры проектов помимо мыс­ленных моделей, основанных на опыте, интуиции и суевериях? Разумеется, многие менеджеры используют сетевые графики PERT (Program Evaluation-and- Review Technique — метод оценки и пересмотра планов) или графики Ганта. Однако не будет преу­величением предположить, что Microsoft Excel — наиболее широ­ко используемое средство управления проектами в 1Т-организа-циях. Табличная модель дает полезную информацию относитель­но процесса, проекта или организации, и большинство менедже­ров с этим согласятся.

Тем не менее таблица статична, она не показывает динамику процессов, во всяком случае, она не наглядна. С таблицами свя­зана еще одна проблема. Поскольку они зачастую связаны с фи­нансовым планированием, их стремятся наполнить только «ося­заемыми» показателями, которые можно измерить — количество сотрудников, денег, рабочих станций, строк кода и т.д. Такой под­ход уводит в сторону от оценки неформальных параметров про­екта — морального состояния, мотивации, качества и уровня по­нимания технологии разработки ПО.

Поскольку такие параметры являются неформальными по своей природе, нужно относиться к ним с некоторой предосто­рожностью и использовать их в основном для качественной оценки порядка изменений и прогнозирования тенденций. Нап­ример, менеджер может задать такой практический вопрос: «Что произойдет с бюджетом и графиком проекта, если я направлю участников проектной команды на учебные курсы, и в результате они потратят вдвое меньше времени на освоение объектно-ори­ентированной технологии?»

Большое значение имеет также природа взаимодействий между различными компонентами процесса. Если изменить ка­кой-либо компонент процесса, то это, вероятно, скажется на ка­ком-нибудь другом. Кроме того, при взаимодействии могут иметь место временные задержки и циклы обратной связи. Эти взаимодействия можно отразить в табличной модели, но они не будут видны постороннему наблюдателю. Взаимодействия выра­жаются в виде связей между ячейками таблицы за счет использо­вания различных математических формул, встроенных в ячейки. Если пользоваться табличным процессором, то можно видеть эти формулы, но если просто смотреть на таблицу, то не видно ника­ких связей между ее ячейками.

Сочетание нескольких взаимодействующих компонентов мо­жет привести к появлению «волнового эффекта» в организации. Допустим, организация-разработчик делает существенные ин­вестиции в CASE-средства, но с каждым кварталом тратит все меньше и меньше денег на обучение. Если работа с CASE-средствами требует использования формальных и строгих методов, а персонал не освоил их в достаточной степени, не удивительно, что продуктивность разработки в начальном периоде снижается. Вместе с падением продуктивности и разочарованием в новых CASE-средствах ухудшается и моральное состояние команды, от которого невозможно отмахнуться. Если оно ухудшается, растет текучесть кадров, и в первую очередь уходят самые продуктив­ные. Во-первых, у них самые лучшие приглашения на работу от других организаций и, во-вторых, они испытывают наибольшее разочарование в нынешней ситуации. В результате их ухода сред­няя продуктивность организации падает еще больше, что вызы­вает дальнейшее ухудшение морального состояния... которое по­вышает текучесть кадров... которая заставляет увольняться ос­тавшихся продуктивных сотрудников... и так до тех пор, пока в организации не останется ни одного нормального специалиста.

Если этот пример выглядит слишком надуманным (хотя эта ситуация вполне реальна), можно рассмотреть более приземлен­ную ситуацию. При оценке различных параметров проекта почти все менеджеры учитывают фактор «безопасности» (известный также, как фактор случайности, подгона под нужный результат, и под другими красивыми названиями), и они это делают без учета какой-либо динамики. Различные факторы безопасности порож­дают различные проекты. Если проектная команда знает, что ее менеджер опубликовал официальный график проекта с нулевым запасом прочности, участники проекта немедленно скорректиру­ют свое поведение, исключив любую деятельность, которую они считают несущественной. В зависимости от характера проекта это может означать отказ от документирования, тестирования, обеспечения качества, присутствия на еженедельных совещаниях или ответов на сообщения электронной почты. И наоборот, если график проекта составлен с большим запасом, то начинает действовать Закон Паркинсона: работа занимает все отведенное для нее время.

Некоторые организации, достигшие третьего, четвертого или пятого уровней СММ, осознали важность проблем, связанных с динамикой процессов. Даже если исключить неформальные фак­торы, временные задержки и циклы обратной связи все равно мо­гут оказать значительное воздействие на успех проекта. В качест­ве простого примера рассмотрим влияние дефектов проектирова­ния, допущенных на стадии анализа в классическом «каскадном» процессе и обнаруженных только в начале стадии программиро­вания или тестирования. В формальном, строгом процессе разра­ботки это означает, что нужно снова вернуться на стадию анали­за для исправления ошибок и затем провести все изменения че­рез проектирование и кодирование, пока не дойти снова до тестирования. Разумеется, возможно, что в процессе исправления ошибок что-то сделано не так, и тестирование выявит новые ошибки. В итоге может потребоваться несколько циклов исправ­лений, пока тестирование не даст удовлетворительных результа­тов. Все это может существенно повлиять на общее время про­цесса, который организация пытается усовершенствовать.

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

Здесь имеется только одна проблема: графические модели ста­тичны. За небольшим исключением они были изобретены до по­явления современных CASE-средств, поэтому их привыкли рисо­вать на бумаге или отображать на пассивном дисплее. Если пост­роить диаграмму потоков данных с помощью типичного CASE-средства, то она не «движется», не показывает динамику модели­руемого процесса. Для этого требуется анимация, которой боль­шинство поставщиков CASE-средств никогда не занималось.

В результате организации-разработчики, пытающиеся дос­тичь более глубокого понимания своих процессов, обращаются к средствам имитационного моделирования, которые могут отоб­разить динамику системы. Одна из наиболее известных динами­ческих моделей процесса создания ПО была разработана Тариком Абдель-Хамидом. Она отражает виды работ в процессе уп­равления проектом среднего размера, использующего традици­онные средства разработки и классическую «каскадную» модель процесса разработки. Хотя она не учитывает особенности сегод­няшних проектов, использующих быстрое прототипирование, средства визуальной разработки, библиотеки повторно использу­емых компонентов и т.д., тем не менее, она может служить в ка­честве отправной точки для организаций, желающих более глубо­ко разобраться во взаимодействиях между различными компо­нентами их процесса разработки ПО.

В идеальной ситуации менеджеру «безнадежного» проекта желательно располагать временем, финансами, настойчивостью и техническими ресурсами для создания динамической модели своего проекта. Основная причина для построения такой модели заключается в том, что ее можно использовать для ответов на вопросы типа «что-если», анализируя «нелинейные» аспекты ди­намики проекта. Например, может оказаться, что существенное увеличение некоторого параметра (такого, как количество новых сотрудников, нанимаемых за месяц) окажет совершенно незна­чительное воздействие на какой-либо из основных параметров, например, на «ожидаемую дату завершения проекта». В других случаях небольшое изменение незначительного, на первый взгляд, параметра (например, «частоты ухода» профессионалов) может оказать на проект такое существенное воздействие, кото­рого никто не ожидал. Такое происходит из-за наличия множест­ва взаимодействующих факторов, взаимное влияние которых друг на друга достаточно сложно количественно оценить.

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

7.8.