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