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

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

 

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

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