Количество итераций по стадиям

Уровень	Начальная стадия	Разработка	Конструирование	Ввод в действие
Низкий
Типичный
Высокий

Таким образом, можно принять в качестве эмпирического правила, что средний итерационный проект включает 6 + 3 итерации.

! Следует запомнить

1. Оценка трудоемкости создания ПО является одним из наиболее важных видов деятельности в процессе создания ПО.

2. Модели и методы оценки трудоемкости необходимы для разработки бюджета проекта, анализа степени риска и выбора компромиссного решения, планирования и управления проектом, анализа затрат на улучшение качества ПО.

3. Большинство моделей для определения трудоемкости разработки ПО могут быть сведены к функции пяти основных параметров: размера конечного, продукта, особенностей процесса, возможностей персонала, среды и требуемого качества продукта.

Основные понятия

Функциональный тип, функциональная точка.

? Вопросы для самоконтроля

1. К каким последствиям могут привести недооценка и переоценка стоимости, времени и ресурсов, требуемых для создания ПО?

2. На какой стадии проекта и с какой точностью может выполняться оценка трудоемкости создания ПО?

3. Охарактеризуйте и сравните методы оценки трудоемкости создания ПО.

4. Что означает хорошая оценка трудоемкости?

5. В каких единицах измеряется размер ПО?

6. Какие факторы наиболее значительно влияют на трудоемкость создания ПО?

ГЛАВА 7

ОСОБЕННОСТИ СОВРЕМЕННЫХ ПРОЕКТОВ

Прочитав эту главу, вы узнаете:

· В каких условиях выполняется большинство современных проектов создания ПО.

· Какую роль играет человеческий фактор в «безнадежных» проектах.

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

В последнее время множество проектов создания ПО выполняется в экстремальных условиях. Независимо от причин такие «смертельные марши» (по определению Эдварда Йордона, одного из ведущих мировых консультантов), или «безнадежные» проекты, предъявляют особые требования к используемым методам управления, технологиям и средствам. Эти требования наиболее полно (и не без юмора) изложены в книге Эдварда Йордона «Death March»[36], выпущенной издательством Prentice-Hall в 1997 г. и в 2003 г. (второе издание).

7.1.

КАТЕГОРИИ «БЕЗНАДЕЖНЫХ» ПРОЕКТОВ

Далеко не все «безнадежные» проекты одинаковы; помимо ограничений в планах, штатах, бюджете и функциональности, они могут иметь различные масштабы, формы и другие особенности.

Наиболее важной отличительной характеристикой «безнадежного» проекта является его масштаб. В зависимости от масштаба можно выделить четыре категории проектов:

· небольшие проекты — проектная команда включает менее 10 человек, работает в исключительно неблагоприятных условиях и должна завершить проект в срок от 3 до 6 месяцев;

· средние проекты - проектная команда включает от 20 до 30 человек, протяженность проекта составляет 1—2 года;

· крупномасштабные проекты - проектная команда включает от 100 до 300 человек, протяженность проекта составляет 3-5 лет;

· гигантские проекты — в проекте участвует армия разработчиков от 1000 до 2000 человек и более (включающая, как правило, консультантов и соисполнителей), протяженность проекта составляет 7—10 лет.

Небольшие проекты являются наиболее распространенной категорией, и шансы на их успешное завершение наиболее высоки. Для средних проектов они заметно ниже, а для крупномасштабных проектов почти равны нулю. В больших проектных командах трудно поддерживать дух сплоченности. Причем решающее значение имеет не только число участников проекта, но и временная протяженность: 80-часовую рабочую неделю в течение 6 месяцев еще можно вытерпеть, но если работать так в течение двух лет, могут возникнуть проблемы.

До сих пор остались без ответа вопросы, почему вполне разумные организации предпринимают подобные проекты и почему разумные менеджеры и технические специалисты соглашаются в них участвовать. Эти вопросы будут рассмотрены ниже.

7.2.

ПРИЧИНЫ, ПОРОЖДАЮЩИЕ

«БЕЗНАДЕЖНЫЕ» ПРОЕКТЫ

Такие проекты порождаются самыми различными причинами:

· высокая конкуренция, вызванная появлением новых компаний на рынке или новых технологий;

· сильное воздействие неожиданных правительственных решений;

· неожиданный и (или) незапланированный кризис;

· политические «игры» высшего руководства;

· наивный оптимизм и менталитет первопроходцев у неопытных разработчиков.

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

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

Наиболее распространенные причины, побуждающие разработчиков участвовать в «безнадежных» проектах, можно охарактеризовать следующим образом:

· высокое вознаграждение;

· синдром покорителей Эвереста;

· наивность и оптимизм молодости;

· угроза безработицы;

· возможность будущей карьеры;

· возможность победить бюрократию.

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

Разумеется, самоуверенность участников проекта выручает в ситуациях, когда обычные проектные команды терпят поражение. Тот факт, что наиболее успешные продукты - от Lotus 1-2-3 до Netscape Navigator — были разработаны небольшими командами в условиях, неприемлемых для нормальных людей, уже стал фольклором в индустрии ПО. Такие проекты, заканчиваясь успешно, приносят проектной команде известность и славу; даже когда они проваливаются, то зачастую позволяют всем участникам извлечь для себя важные уроки (хотя для организации в целом последствия могут быть катастрофическими).

Важно отметить, что наивность и оптимизм молодости обычно сочетаются с огромной энергией, целеустремленностью и отсутствием таких помех, как семейные отношения. Гораздо чаще можно встретить 22-летнего программиста, который готов и жаждет участвовать в «безнадежном» проекте со 100-часовой рабочей неделей в течение года или двух, чем 35-летнего женатого программиста с двумя детьми и весьма умеренной склонностью к покорению горных вершин. Молодой программист, желающий участвовать в «безнадежном» проекте, а также относительно молодой менеджер проекта, дающий оптимистические обещания начальству, как бы утверждают: «Разумеется, мы обеспечим успех этого проекта и сокрушим все препятствия на своем пути!»

Индустрия ПО привлекает в основном молодых, и вряд ли ситуация изменится в ближайшие несколько лет, а молодежь утратит оптимизм, энергию и способности сосредоточиваться на решении проблем. Что касается наивности, то эта болезнь проходит только с возрастом.

Технические специалисты и менеджеры проектов часто жалуются, что их корпоративные бюрократы мешают продуктивно работать и задерживают разработки ПО. Чем крупнее организация, тем сильнее бюрократия, особенно в тех организациях, где служба стандартов требует строгого соблюдения требований SEI-СММ или ISO-9000. Аналогично департамент по управлению персоналом может использовать процедуры скрупулезной проверки каждого вновь принимаемого на работу сотрудника или стороннего разработчика, привлекаемого к участию в проекте.

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

Следует отметить, что некоторые аналитики смотрят на проблему оптимистично; они полагают, что количество «безнадежных» проектов в последующие годы будет уменьшаться. Причины такого уменьшения: а) рост корпоративной культуры IT-компаний; б) обучение разработчиков различным методам обеспечения качества в сочетании с «быстрой» разработкой ПО.

7.3.

ПРИЧИНЫ РАЗНОГЛАСИЙ МЕЖДУ

УЧАСТНИКАМИ ПРОЕКТА

Ни один проект не может обойтись без политики; она стоит за каждым взаимоотношением между двумя или более индивидуумами. В лучшем случае она может играть незначительную роль, если участники проекта договорятся между собой и достигнут компромисса или один участник (или группа) одержит верх над всеми остальными, и будет диктовать свои решения.

В условиях «безнадежного» проекта наиболее очевидным источником политических споров и дискуссий являются временные, бюджетные и ресурсные ограничения. Если бы с ресурсами было все в порядке, то не было бы и предмета для обсуждения.

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

Еще более серьезная политическая дискуссия, результаты которой могут оказаться полной неожиданностью для менеджера проекта, связана с вопросом о целесообразности создания новой системы. В некоторых случаях участники проекта действуют пол давлением различных правительственных постановлений, хота это вызывает у них раздражение и возмущение. В других случаях новая система может создаваться под давлением руководителя организации, несмотря на явное несогласие его коллег и подчиненных. Менеджер проекта может оказаться активным участником политических баталий, предшествовавших его официальному утверждению на данную роль, и последствия этого он будет ощущать на себе в течение всего процесса разработки и внедрения системы. А если менеджер проекта не участвовал ни в каких дебатах (например, его наняли на работу уже после того, как были приняты все судьбоносные решения по проекту), то он никак не может понять, почему у него оказалось столько врагов среди основных заинтересованных лиц. Разумеется, простого решения этой проблемы не существует, но, по крайней мере, лучше знать о ней заранее.

Кроме этих проблем существует еще один источник политических дебатов: разногласия по поводу статуса проекта, вероятности его успешного завершения и действий, которые необходимо предпринять, если проект выбьется из графика и/или бюджета.

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

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

7.4.

ПЕРЕГОВОРЫ В «БЕЗНАДЕЖНОМ» ПРОЕКТЕ

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

Если контрпредложение со стороны высшего руководства или заказчика содержит только одну «переменную», менеджер проекта может оценить влияние остальных переменных. Например, если первоначальная оценка менеджера проекта заключается в том, что проект потребует 12 месяцев на реализацию, трех разработчиков и бюджет $200 000, вполне вероятно, что первой реакцией руководства будет: «Вздор! Нам нужно, чтобы система была готова и работала через шесть месяцев!» На первый взгляд, очевидный способ сделать это заключается в увеличении штата и/или бюджета (например, увеличить зарплату, чтобы привлечь более продуктивных программистов).

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

Переговоры - это игра, которая имеет место во всех проектах. Переговоры в «безнадежных» проектах характеризуются тем, что ставки гораздо выше, эмоции перехлестывают через край, а запросы противоположной стороны (в терминах плана, бюджета и т.д.) обычно доходят до такой крайности, что могут превысить любой «запас прочности». В обычном проекте самый очевидный запас прочности — это сверхурочная работа. Даже если менеджер проекта оказался вынужден принять под давлением жесткий график й урезанный бюджет, успеха все равно можно будет добиться. Для этого надо уговорить проектную команду работать сверхурочно от 10 до 20 ч. в неделю в течение нескольких заключительных месяцев проекта. Эти дополнительные усилия никак не отражаются в официальной статистике, поскольку программисты ничего не получают за сверхурочную работу, поэтому в конце проекта менеджер выглядит героем.

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

Консультант в области менеджмента Роб Томсет определил общие варианты переговорных игр. Наиболее распространенные из них приведены ниже:

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

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

«Угадай число, которое я задумал» — у пользователя или руководителя высокого уровня есть своя «приемлемая» оценка для сроков, бюджета и/или других аспектов переговоров, но они отказываются четко ее сформулировать. Когда менеджер проекта предлагает свою оценку сроков и бюджета, пользователь или руководитель попросту качает головой и говорит «нет». Такой ответ подразумевает: «Это слишком много — попробуй угадать еще раз». Незадачливый менеджер в конце концов (иногда после полудюжины попыток) приходит с нужной оценкой, но поскольку теперь это его оценка, ему впоследствии и придется отвечать за нее.

«Двойной плевок пустышкой» — «пустышкой» (dummy) называется детская соска, а «выплюнуть пустышку» означает, что ребенок настолько расстроен и рассержен, что выплевывает свою соску. Томсет использует это как метафору, чтобы описать такую ситуацию в процессе переговоров: руководитель высокого уровня впадает в буйное неистовство, когда менеджер проекта в первый раз докладывает свои предложения по плану и бюджету. Дисциплинированный менеджер поспешно удаляется, затем снова возвращается с пересмотренной оценкой, а руководитель снова закатывает истерику. Получается «двойной плевок пустышкой». Идея заключается в следующем: запугать и затерроризировать менеджера до такой степени, чтобы он согласился с чем угодно, лишь бы избежать еще одной вспышки гнева.

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

«Игра на понижение» - часто имеет место в ситуации, когда организация — разработчик ПО проигрывает своим конкурентам борьбу за право разработки системы для организации-клиента. Эта игра очевидна: заказчик (или в некоторых случаях представитель службы маркетинга организации-разработчика) говорит менеджеру проекта, что один из претендентов внес свои предложения о коротком сроке разработки и/или более скромном бюджете. Это вынуждает менеджера проекта не только ответить на вызов конкурента (который может быть вполне реальным, а может, и нет), но и превзойти его, чтобы повысить свои шансы на заключение контракта. Один из вариантов такой игры — клиент дает понять, что он не исключает возможность, что проект вообще не состоится; при этом организация-разработчик, которая во что бы то ни стало стремится заполучить этот проект, постарается выдвинуть такие заманчивые для клиента предложения, от которых он не сможет отказаться.

«Китайская пытка водой» — данная игра заключается в том, что плохие новости преподносятся заказчику и (или) высшему руководству небольшими порциями. Допустим, разумная оценка срока выполнения проекта, сделанная менеджером, составляет 12 месяцев. По его мнению, при помощи сверхурочной работы и разного рода чудес проект можно выполнить за 6 месяцев, однако руководство настаивает на 4 месяцах. Менеджер нехотя уступает и устанавливает для проекта последовательность «контрольных точек». Например, новая версия прототипа системы должна предъявляться заказчику каждую неделю. Первое предъявление окажется опоздавшим на один день, однако менеджер докажет, что для данной работы задержка может составлять от 14 до 20% (в зависимости от того, сколько дней в неделю работает команда — 5 или 7); отсюда, по его мнению, следует, что срок разработки заключительной версии системы также может быть отодвинут на 14—20%. На такой ранней стадии проекта руководство отказывается пойти На уступки, но когда вторая контрольная точка также окажется сдвинутой на день (что означает общую задержку в два дня в течение двух недель), менеджер вновь повторит свои аргументы. Это похоже на китайскую пытку водой — одной плохой новости недостаточно, но все вместе могут оказаться роковыми.

«Спрятанное качество» — это одна из наиболее хитрых игр. В ней могут участвовать (в конструктивной или деструктивной манере) хорошо информированные менеджеры проектов, менеджеры высокого уровня по информационным технологиям и/или заказчики. Менеджер проекта может предоставить пользователю бесконечно большое число программ за нулевое время, пока их не нужно реально эксплуатировать. Разумеется, было бы глупо предлагать такой экстремальный сценарий. Однако суть заключается в том, что качество ПО (выражаемое в количестве ошибок, переносимости, сопровождаемое™ и т.д.) — это одно из «измерений» проекта, которое нужно учитывать во время переговоров по срокам, затратам, персоналу и другим ресурсам. Некоторые заказчики слишком неопытны, чтобы понимать это, а другие не собираются принимать в расчет длительную перспективу. В самом лучшем варианте такая «игра» отражает стратегию «достаточно хорошего» (good-enough) ПО, которая описана ниже. В худшем виде она носит такой же жульнический характер, как и некоторые другие упомянутые выше политические игры.

Самый важный совет Томсета - не попасть в ловушку «скоропалительных» оценок проекта. Наихудшую разновидность такой ловушки представляет собой игра «испанская инквизиция». Однако существуют и не такие заметные ловушки. Преднамеренно или нет, но менеджера проекта часто ставят в положение, когда от него требуется быстро дать «грубую оценку» времени и количеству персонала, требуемым для реализации каких-либо частей проекта, и эти оценки могут превратиться в жесткие, не подлежащие изменению требования. В подобной ситуации, когда имеется некоторое время на выполнение формальной оценки, очень важно выразить оценки в терминах «уровней достоверности» или в некотором диапазоне «плюс-минус». Если абсолютно отсутствуют данные для детальной оценки и если в «безнадежном» проекте используется совершенно новая технология и участвует персонал неизвестной квалификации, то будет благоразумным сказать: «Проект, вероятно, потребует от трех до шести месяцев» или «Я думаю, что мы закончим проект через шесть месяцев плюс-минус 50%».

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

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

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

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

7.5.

ЧЕЛОВЕЧЕСКИЙ ФАКТОР

В «БЕЗНАДЕЖНЫХ» ПРОЕКТАХ

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

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

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

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

Первая отличительная особенность «безнадежного проекта» - умение правильно сформировать проектную команду. Существуют четыре наиболее распространенных стратегии формирования команды «безнадежного проекта»:

· нанять суперпрограммистов и предоставить им свободу действий;

· настаивать на привлечении команды, которая готова к «невыполнимой миссии» и имеет опыт совместной работы;

· набрать команду из «простых смертных», но при условии, что они будут знать, на что идут;

· взять любых сотрудников, которых дают, и сделать из них команду «невыполнимой миссии».

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

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

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

Последней стратегии следует избегать при любых затратах. Если проект превращается в «свалку» для сотрудников, которых не хотят брать ни в какие другие проекты, он почти наверняка будет самоубийственным.

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

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

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

Эта оценка достаточно точно характеризует нормальные проекты. В большинстве «безнадежных» проектов деньги все же играют важную роль. Многие начинающие компании предпринимают безумные и бесперспективные проекты в надежде на то, что им удастся разработать какое-нибудь совершенно новое приложение для нового технического устройства и продать миллион его копий на рынке. Если участники проектной команды являются акционерами и собираются участвовать в распределении прибыли, то денежное вознаграждение, очевидно, составляет весьма существенную часть мотивации их участия в проекте. Действительно, многие компании намеренно придерживают зарплату на 20—30% ниже преобладающего на рынке уровня, заинтересовывая своих специалистов возможностью серьезного участия в акционировании и других формах распределения будущей прибыли. Эта стратегия направлена не только на повышение мотивации, но и на снижение расхода наличности, поскольку зарплаты сотрудников зачастую составляют единственные самые крупные затраты начинающей компании.

Если «безнадежный» проект достаточно важен для предприятия, оно найдет способы зарезервировать значительный премиальный фонд для поощрения проектной команды при условии удачного завершения проекта в срок. Допуская возможность такого вознаграждения, не следует забывать, что 20%-ное повышение зарплаты имеет гораздо большее значение для молодого программиста, чем для опытного и квалифицированного программиста.

Размер премии напрямую не связан с количеством времени, затрачиваемым проектной командой на выполнение проекта. В некоторых организациях высшее руководство пытается соблазнить проектную команду двойной премией (при отставании проекта от графика), поскольку руководство, очевидно, верит, что это заставит людей работать вдвое больше. Однако, если участники команды уже работают по 18 часов в день, законы физики не позволят работать вдвое больше даже самым рьяным из них.

Что касается проектов, за выполнение которых невозможно получить большие премии, менеджеру проекта важно не забывать о том, что существуют разнообразные виды нематериального вознаграждения (дополнительный отпуск, свобода действий, создание полностью оснащенной домашней компьютерной системы и др.), и с их помощью можно стимулировать участников проекта. Это также справедливо и для нормальных проектов, но для «безнадежных» особенно важно.

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

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

Независимо от того, получают участники команды компенсацию за сверхурочную работу или нет, большой ошибкой будет отсутствие учета этого времени. Даже если с точки зрения бухгалтерии именно так оно и есть, менеджер не должен рассматривать сверхурочное время как свободное. Даже если участники команды способны всю жизнь без устали работать по 18 часов в день, для менеджера важно фиксировать, сколько таких сверхурочных часов затрачивается в течение работы над проектом. Это единственный способ точно измерить производительность команды и вероятность своевременного достижения каждой промежуточной контрольной точки в графике проекта.

Каждому известно, что люди не в состоянии работать всю жизнь по 18 часов в день; даже если они будут очень стараться, все равно скоро устанут. А когда они устают, то становятся раздражительными и вспыльчивыми, работают менее продуктивно и делают гораздо больше ошибок. Это может отрицательно повлиять на работу над проектом. Поэтому менеджер должен четко понимать, когда следует попросить команду поработать сверхурочно, а когда не следует этого делать.

Одна из опасностей, которые менеджер проекта должен предвидеть — это чрезмерная добровольная сверхурочная работа той части молодых энтузиастов, которые не представляют пределов своих собственных возможностей и не задумываются о побочных эффектах работы до изнеможения. Производительность труда действительно может расти в первые 20 часов сверхурочной работы (благодаря повышенному содержанию адреналина в крови, концентрации внимания и т.д.). Но рано или поздно каждый достигнет критической точки, после чего начнется спад, поскольку возрастет количество ошибок и ослабнет концентрация внимания. Таким образом, наступит момент, когда участник команды будет демонстрировать «отрицательную» продуктивность, поскольку усилия, затрачиваемые на исправление ошибок и дефектов в программах и их переписывание, будут сводить к нулю всю выполненную работу. Менеджер может относительно безболезненно настаивать на 60-часовой рабочей неделе. При работе от 60 до 80 ч следует четко установить пределы индивидуальных возможностей каждого разработчика; при 80—90-часовой рабочей неделе менеджер должен отправлять разработчиков домой и заставлять их отдыхать.

В «безнадежных» проектах очень важны вопросы, связанные с человеческими ресурсами — природа и степень взаимодействия между менеджером проекта и остальной командой. Идеальная ситуация — когда у менеджера проекта нет секретов от команды, и каждый участник команды знает о проекте все. Это означает, что каждый участник команды располагает актуальной информацией относительно состояния проекта, первоочередных приоритетов, рисков, ограничений, политики и т.д.

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

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

Уровень коммуникации между отдельными участниками команды весьма важен, особенно если они ранее не работали вместе. Нужно, чтобы не было постороннего вмешательства во внутрикомандное взаимодействие. В этом случае можно будет поддерживать честный и откровенный обмен информацией. Для большинства сегодняшних проектов это обязательно подразумевает наличие электронной почты и различных средств групповой работы.

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

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

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

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

Генератор идей (plant) — выдвигает новые идеи и стратегии, уделяя особое внимание главным проблемам, занимается поиском новых подходов к решению проблем, с которыми сталкивается группа. Это человек, который пытается внедрять в команде радикальные технологии, искать новые решения технических задач.

Критик (monitor-evaluator) — анализирует проблемы с прагматической точки зрения, оценивает идеи и предложения таким образом, чтобы команда могла принять сбалансированные решения. В большинстве случаев такой человек поступает как скептик, уравновешивая оптимистические предложения оформителя и генератора идей. Критик хорошо знает, что новые технологии отнюдь не всегда работают, обещания поставщиков о возможностях новых средств и языков программирования иногда не сбываются и все может пойти не так, как было задумано.

Рабочая пчелка (company worker) — превращает планы и концепции в практические рабочие процедуры, систематически и эффективно выполняет принятые обязательства. Другими словами, в то время как оформитель придает законченную форму крупным технологическим решениям, генератор идей предлагает радикальные новые решения, а критик занимается поиском изъянов и недостатков в этих предложениях, рабочая пчелка — это тот человек, который работает, не привлекая внимания, и выдает «на гора» тонны кода. Очевидно, любой «безнадежный» проект нуждается по крайней мере в паре таких человек, но сами по себе они не способны принести успех проекту, поскольку не обладают необходимой широтой кругозора.

Опора команды (team worker) — поддерживает силу духа в участниках проекта, оказывает им помощь в трудных положениях, пытается улучшить взаимоотношения между ними и в целом способствует поднятию командного настроя. Другими словами, такой человек выполняет в команде роль дипломата. Им может быть и менеджер проекта, однако им может быть также любой из участников команды, относящийся более внимательно к своим коллегам. Эта роль особенно важна в «безнадежных» проектах, поскольку команда зачастую испытывает сильный стресс.

Добытчик (resource investigator) — обнаруживает и сообщает о новых идеях, разработках и ресурсах, имеющихся за пределами проектной группы, налаживает внешние контакты, которые могут оказаться полезными для команды, и проводит все последующие переговоры. Он всегда знает, где отыскать бесхозный ПК, свободный конференц-зал, дополнительный рабочий стол или любой другой ресурс, в котором нуждается команда. Такие ресурсы могут быть добыты по официальным каналам или нет; но даже если их можно достать нормальным способом, приходится ждать выполнения всех бюрократических процедур. «Безнадежный» проект не может ждать долго и не может позволить, чтобы вся работа застопорилась из-за того, что какой-то помощник вице-президента не разрешает воспользоваться единственным в организации свободным конференц-залом. Командный добытчик имеет много друзей и связей в своей организации, с помощью которых можно выпросить или одолжить необходимые ресурсы.

Завершающий (completer) — поддерживает в команде настойчивость в достижении цели, активно стремится отыскать работу, которая требует повышенного внимания, и старается, насколько возможно, избавить команду от ошибок, связанных как с деятельностью, так и с бездеятельностью. Такой человек играет доминирующую роль во время тестирования системы на завершающей стадии жизненного цикла проекта, однако его роль на более ранних стадиях тоже важна.

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

Проблемы создания нормальных условий для работы уже много лет обсуждаются среди разработчиков ПО. Если разработчики работают в достаточно тихом помещении, вероятность появления у них ошибок уменьшается на одну треть по сравнению с теми, кто работает в шумном офисе и постоянно отвлекается на посторонние дела. Например, условия работы в Microsoft и в большинстве других компаний Кремниевой Долины достаточно цивилизованные - отдельные помещения с закрытыми дверями, наличие содовой, сока и других напитков, «постоянный» телефонный номер, который остается за программистом даже в том случае, если он перебирается в другое помещение.

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

Если менеджер проекта достаточно изобретателен, стоит попытаться обеспечить подходящие условия для работы таким образом, чтобы хозяйственная служба вообще не знала о том, что происходит. Для этого есть несколько возможностей.

Лобовая атака — если у проекта есть защитник и/или владелец, которые крайне заинтересованы в его успехе, нужно объяснить им, насколько важно, чтобы проектная команда работала в хороших условиях. Если защитник проекта является руководителем высокого уровня, то организовать временный переезд команды в более подходящее помещение будет несложно.

Самовольный захват — не спрашивая ни у кого разрешения, занять, какое-нибудь пустое помещение. Такой захват обеспечит 90% успеха в борьбе за условия работы; пока бюрократы будут ругаться, спорить и отправлять в разные стороны гневные послания, может быть, уже удастся закончить проект и незаметно удалиться на прежнее место.

Дистанционный доступ — разрешить всем работать дома и организовать еженедельные рабочие совещания в ближайшем «Макдональдсе» (в 9 часов утра, когда почти нет посетителей). Пока кто-нибудь обнаружит исчезновение команды, может пройти не одна неделя. Для дополнительного отвлечения внимания можно посадить чучела за столы, которые обычно занимала проектная команда; руководству понадобится достаточно много времени, чтобы отличить их от других сотрудников, сидящих в офисе.

Переход на работу в ночную смену — это более радикальный вариант, однако он может оказаться достаточно эффективным, если большая часть работы может выполняться без взаимодействия с пользователями.

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

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

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

7.6.

ПРОЦЕССЫ В «БЕЗНАДЕЖНЫХ» ПРОЕКТАХ

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

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

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

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

Чтобы достичь успеха, проектная команда должна прийти к соглашению, какие процессы будут формализованы (например, контроль исходного кода, управление изменениями и управление требованиями) и какие будут неформальными (например, проектирование пользовательского интерфейса). Бессмысленно требовать в обязательном порядке выполнения какого-либо процесса, если никто не собирается ему следовать.

Менеджер «безнадежного» проекта должен безоговорочно настаивать на выполнении тех процессов, которые он считает принципиально важными, например, процесса управления изменениями.

Формальные подходы (типа SEI-CMM, ISO-9000 или внедрение новых технологий анализа и проектирования) должны иметь место где-нибудь за пределами «безнадежного» проекта. Внедрение таких процессов имеет смысл как часть долговременной корпоративной стратегии. Оно должно начинаться с выполнения пилотного проекта (но не «безнадежного»), сопровождаясь организацией необходимого обучения. Если все это уже сделано, и другие разработки ПО в организации уже выполняются на третьем уровне SEI-CMM, то официально принятые в организации процессы следует усовершенствовать, чтобы сделать их пригодными для использования в «безнадежном» проекте.

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

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

Эти требования не являются необходимыми, практичными или желательными в большинстве «безнадежных» проектов. Достичь такого совершенства невозможно даже в нормальных проектах, хотя в них нет таких жестких ограничений на время, бюджет и людские ресурсы. Что же касается «безнадежных» проектов, то пользователям в действительности нужна система, которая достаточно дешева, достаточно производительна, обладает необходимыми возможностями, достаточно устойчива и будет готова достаточно скоро — вот в чем заключается их определение «достаточно хорошего» ПО.

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

7.7.

ДИНАМИКА ПРОЦЕССОВ

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

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

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

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

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

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

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

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

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

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

Тем не менее таблица статична, она не показывает динамику процессов, во всяком случае, она не наглядна. С таблицами связана еще одна проб