Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Особенности современных проектов 491

тигнет критической точки, после чего начнется спад, поскольку

возрастет количество ошибок и ослабнет концентрация внима-

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

будет демонстрировать «отрицательную» продуктивность, пос-

кольку усилия, затрачиваемые на исправление ошибок и дефек-

тов в программах и их переписывание, будут сводить к нулю всю

выполненную работу Менеджер может относительно безболез-

ненно настаивать на 60-часовой рабочей неделе. При работе от 60

до 80 ч следует четко установить пределы индивидуальных воз-

можностей каждого разработчика; при 80—90-часовой рабочей

неделе менеджер должен отправлять разработчиков домой и зас-

тавлять их отдыхать.

В «безнадежных» проектах очень важны вопросы, связанные

с человеческими ресурсами

—

природа

степень взаимодействия

между менеджером проекта и остальной командой. Идеальная

ситуация - когда у менеджера проекта нет секретов от команды,

и каждый участник команды знает о проекте все. Это означает,

что каждый участник команды располагает актуальной инфор-

мацией относительно состояния проекта, первоочередных прио-

ритетов, рисков, ограничений, политики и т.д.

При таких условиях

команде может быть создана атмосфера

взаимного доверия и доброжелательности. Если участники ко-

манды прилагают экстраординарные усилия к работе над проек-

том и приносят в жертву личную жизнь, для них было бы край-

ним разочарованием обнаружить, что менеджер проекта скрыва-

ет от них важную информацию или играет за их спиной в поли-

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

сы протекают интенсивнее и быстрее, чем в нормальном, выше

вероятность, что участники команды обнаружат утаивание ин-

формации или непристойные политические ифы вокруг них.

Очевидный контраргумент против такой философии заклю-

чатся в том, что менеджер должен оберегать команду от посто-

ронних помех, особенно от каждодневных мелочных политичес-

ких

игр,

которые происходят вокруг проекта.

большинстве слу-

чаев

участники команды

по

достоинству оценивают возможность

освободиться от политики; однако они также нуждаются в уве-

ренности, что в ответ на прямой вопрос менеджер не станет тем-

нить или лгать им. В большинстве проектов, нормальных или

«безнадежных», регулярно проводятся совещания, на которых

говорится о состоянии проекта и поднимаются острые вопросы;

492 Глава?

если участники команды всегда могут узнать о том, что происхо-

дит в проекте, тогда они спокойно смогут на

99%

сконцентриро-

ваться на своей непосредственной работе.

Уровень коммуникации между отдельными участниками ко-

манды весьма важен, особенно если они ранее не работали вмес-

те.

Нужно, чтобы не было постороннего вмешательства во внут-

рикомандное взаимодействие. В этом случае можно будет под-

держивать честный и откровенный обмен информацией. Для

большинства сегодняшних проектов это обязательно подразуме-

вает наличие электронной почты и различных средств групповой

работы.

Открытые и честные взаимоотношения являются важной

составляющей процесса формирования эффективной команды.

Подбор психологически совместимых исполнителей - другая

ключевая составляющая. Крайне важно, чтобы менеджер проек-

та имел свободу действий при выборе участников команды.

Еще одна составляющая заключается в концепции команд-

ных ролей. Многие менеджеры проекта сосредоточиваются на

чисто «технических» ролях, таких, как проектировщики баз дан-

ных, специалисты по сетям, эксперты по пользовательскому ин-

терфейсу и т.д. Все они важны, но нужно подумать и о ролях

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

участников команды. Эти роли присутствуют и в нормальных

проектах, однако в «безнадежных» они приобретают особую важ-

ность. Роб Томсет определил восемь ключевых ролей в проекте

следующим образом.

Председатель (сЬа1фег8оп)

—

выбирает путь, по которому ко-

манда движется вперед к общим целям, обеспечивая наилучшее

использование ее ресурсов; умеет обнаружить сильные и слабые

стороны команды и обеспечить наибольшее применение потен-

циала каждого участника команды. Можно

думать,

что таким че-

ловеком является, как правило, официальный руководитель про-

екта; однако в самоуправляемых командах им может быть любой

человек.

Оформитель (shaper)

—

придает законченную форму действи-

ям команды, направляет внимание и пытается придать опреде-

ленные рамки групповым обсуждениям и результатам совмест-

ной деятельности. Такой человек может иметь официальную

должность «архитектора» или «ведущего проектировщика», но

главное

то,

что эта роль «воображаемая».

безнадежном проекте

Особенности современных проектов 493

особенно важно иметь единое и четкое представление о пробле-

ме и ее возможном решении.

Генератор идей (plant) - выдвигает новые идеи и стратегии,

уделяя особое внимание главным проблемам, занимается поис-

ком новых подходов к решению проблем, с которыми сталкива-

ется группа. Это человек, который пытается внедрять в команде

радикальные технологии, искать новые решения технических

задач.

Критик (monitor-evaluator)

—

анализирует проблемы с прагма-

тической точки зрения, оценивает идеи и предложения таким об-

разом, чтобы команда могла принять сбалансированные реше-

ния. В большинстве случаев такой человек поступает как скеп-

тик, уравновешивая оптимистические предложения оформителя

и генератора идей. Критик хорошо знает, что новые технологии

отнюдь

не

всегда работают, обещания поставщиков о возможнос-

тях новых средств и языков профаммирования иногда не сбыва-

ются и все может пойти не так, как было задумано.

Рабочая пчелка (company worker)

—

превращает планы и кон-

цепции в практические рабочие процедуры, систематически и

эффективно выполняет принятые обязательства. Другими слова-

ми,

в то время как оформитель придает законченную форму

крупным технологическим решениям, генератор идей предлагает

радикальные новые решения, а критик занимается поиском изъ-

янов и недостатков в этих предложениях, рабочая пчелка

—

это

тот человек, который работает, не привлекая внимания, и выдает

«на гора» тонны кода. Очевидно, любой «безнадежный» проект

нуждается по крайней мере

паре таких человек, но сами по себе

они не способны принести успех проекту, поскольку не обладают

необходимой широтой кругозора.

Опора команды (team worker)

—

поддерживает силу духа в

участниках проекта, оказывает им помощь в трудных положени-

ях, пытается улучшить взаимоотношения между ними и в целом

способствует поднятию командного настроя. Другими словами,

такой человек выполняет в команде роль дипломата. Им может

быть и менеджер проекта, однако им может быть также любой из

участников команды, относящийся более внимательно к своим

коллегам. Эта роль особенно важна в «безнадежных» проектах,

поскольку команда зачастую испытывает сильный стресс.

Добытчик (resource investigator)

—

обнаруживает и сообщает о

новых идеях, разработках и ресурсах, имеющихся за пределами

494 Глава 7

проектной группы, налаживает внешние контакты, которые мо-

гут оказаться полезными для команды, и проводит все последую-

щие переговоры. Он всегда знает, где отыскать бесхозный ПК,

свободный конференц-зал, дополнительный рабочий стол или

любой другой ресурс, в котором нуждается команда. Такие ресур-

сы могут быть добыты по официальным каналам или нет; но да-

же если их можно достать нормальным способом, приходится

ждать выполнения всех бюрократических процедур. «Безнадеж-

ный» проект не может ждать долго и не может позволить, чтобы

вся работа застопорилась из-за того, что какой-то помощник ви-

це-президента не разрешает воспользоваться единственным в ор-

ганизации свободным конференц-залом. Командный добытчик

имеет много друзей и связей в своей организации, с помощью ко-

торых можно выпросить или одолжить необходимые ресурсы.

Завершающий (completer)

—

поддерживает в команде настой-

чивость в достижении цели, активно стремится отыскать работу,

которая требует повышенного внимания, и старается, насколько

возможно, избавить команду от ошибок, связанных как с дея-

тельностью, так и с бездеятельностью. Такой человек играет до-

минирующую роль во время тестирования системы на завершаю-

щей стадии жизненного цикла проекта, однако его роль на более

ранних стадиях тоже важна.

Если процесс формирования такой команды протекает ус-

пешно, это бывает заметно по некоторым внешним признакам. В

преуспевающих командах обычно бывает сильное ощущение

общности интересов и гордости за свою команду, а также чувство,

что они в состоянии хорошо выполнять свою работу и получать

от этого удовольствие. Если организация не в состоянии обеспе-

чить создание такой сплоченной команды, это может привести к

тому, что принимается сознательное или бессознательное реше-

ние плыть по течению и не совершать никаких действий для соз-

дания сплоченной и целостной команды.

Проблемы создания нормальных условий для работы уже

много лет обсуждаются среди разработчиков ПО. Если разработ-

чики работают в достаточно тихом помещении, вероятность по-

явления у них ошибок уменьшается на одну треть по сравнению

с теми, кто работает в шумном офисе и постоянно отвлекается на

посторонние дела. Например, условия работы в Microsoft и в

большинстве других компаний Кремниевой Долины достаточно

цивилизованные

—

отдельные помещения с закрытыми дверями,

Особенности современных проектов 495

наличие содовой, сока и других напитков, «постоянный» теле-

фонный номер, который остается за программистом даже в том

случае, если он перебирается

другое помещение.

Многие разработчики ПО работают в банках, страховых ком-

паниях, правительственных учреждениях, промышленных

предприятиях и сотнях других компаний, где до сих пор смотрят

на ПО, как на «накладные» расходы. Поэтому им приходится ра-

ботать не

нормальных офисах, а

отгороженных клетушках, где

практически нет возможности сконцентрировать свои умствен-

ные усилия

на

решении какой-либо проблемы. Звучит музыка, не

прекращаются телефонные звонки, кричат люди и нет никакого

спасения от кого угодно (от курьера до директора), кто может за-

сунуть голову в твою комнату и отвлечь от работы. Пока сотруд-

ники будут тесниться в шумных и неприспособленных помеще-

ниях, нельзя говорить о сколько-нибудь продуктивной работе.

Если менеджер проекта достаточно изобретателен, стоит по-

пытаться обеспечить подходящие условия для работы таким об-

разом, чтобы хозяйственная служба вообще не знала о том, что

происходит. Для этого есть несколько возможностей.

Лобовая атака

—

если у проекта есть защитник

и/или

владе-

лец, которые крайне заинтересованы в его успехе, нужно объяс-

нить им, насколько важно, чтобы проектная команда работала в

хороших условиях. Если защитник проекта является руководите-

лем высокого уровня, то организовать временный переезд коман-

ды в более подходящее помещение будет несложно.

Самовольный захват

—

не спрашивая ни у кого разрешения,

занять какое-нибудь пустое помещение. Такой захват обеспечит

90%

успеха

борьбе за условия работы; пока бюрократы

будут

ру-

гаться, спорить и отправлять в разные стороны гневные посла-

ния, может быть, уже удастся закончить проект и незаметно уда-

литься на прежнее место.

Дистанционный доступ

—

разрешить всем работать дома и ор-

ганизовать еженедельные рабочие совещания в ближайшем

«Макдональдсе» (в 9 часов утра, когда почти нет посетителей).

Пока кто-нибудь обнаружит исчезновение команды, может

пройти не одна неделя. Для дополнительного отвлечения внима-

ния можно посадить чучела за столы, которые обычно занимала

проектная команда; руководству понадобится достаточно много

времени, чтобы отличить их от других сотрудников, сидящих в

офисе.

496 Глава 7

Переход

на

работу

в ночную

смену

—

это более радикальный ва-

риант, однако он может оказаться достаточно эффективным, ес-

ли большая часть работы может выполняться без взаимодействия

с пользователями.

Преграды

заслоны

—

если команда работает в обычном «отк-

рытом» офисе и упомянутые выше стратегии неприменимы, тог-

да надо постараться сделать все возможное, чтобы собрать ко-

манду в смежных помещениях и забаррикадироваться от осталь-

ной толпы в офисе.

Некоторые из этих акций могут спровоцировать более резкую

ответную реакцию корпоративной бюрократии, чем другие; ко-

манда и ее менеджер должны решить, какая стратегия будет наи-

более эффективной. Борьба с бюрократией таким способом

—

не

для робкого десятка; но ведь и сами «безнадежные» проекты тоже

не для робкого десятка. Если менеджер «безнадежного» проекта

не проявляет желания бороться и отстаивать право на нормаль-

ные условия работы, то с какой стати проектная команда должна

идти на экстраординарные жертвы ради организации и менедже-

ра проекта?

Талантливых исполнителей, сплоченной команды и хороших

условий для работы все же недостаточно, чтобы гарантировать

успех «безнадежного» проекта. С другой стороны, их отсутствие

приведет к провалу проекта. Хорошо организованные процессы

разработки и хорошая технология также являются важными сос-

тавляющими успеха; однако самая главная составляющая

—

это

люди.

7.6.

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

В ситуации «безнадежного» проекта применима концепция

приоритетности

—

при нехватке времени и ресурсов команда от-

кажется от тех методов, которые она сочтет бесполезными или

несущественными (например, детальные спецификации в струк-

турном анализе), и примет только подходящие для себя. Распре-

деление дефицитных ресурсов (самым дефицитным из которых

обычно является время) должно осуществляться таким образом,

чтобы извлечь из этого наибольшую выгоду.

Почти во всех «безнадежных» проектах приходится устанав-

ливать приоритеты, разделяя все требования к системе на различ-

Особенности современных проектов 497

ные категории

(см.

подразд. 1.5). При этом все акционеры

заин-

тересованные лица должны принять согласованное решение от-

носительно

того,

какие требования следует отнести к категориям

«необходимо», «желательно», «хотелось

бы»

и «хотелось

бы,

но не

в этот раз». Разумеется, если владелец проекта категорически

настаивает на том, чтобы все требования были обязательно вы-

полнены, дальнейшее обсуждение будет пустой тратой времени.

Если акционеры и заинтересованные лица не могут достичь

консенсуса по поводу отнесения требований к той или иной ка-

тегории, то проектная команда, пытаясь удовлетворить

всех,

ре-

зультате окажется парализованной из-за отсутствия необходимых

ресурсов.

К сожалению, в большинстве организаций нет дисциплины,

опыта и политической силы, чтобы определить приоритет требо-

ваний в самом начале проекта. Политические баталии вокруг

«безнадежного» проекта могут сделать почти невозможным дос-

тижение консенсуса по приемлемым для всех приоритетам. Толь-

ко когда станет понятно, что проект «безнадежен», противобор-

ствующие стороны придут к соглашению, которое им надо было

бы достичь в самом начале проекта.

В «безнадежном» проекте необходимо уделить особое внима-

ние такому аспекту жизненного цикла ПО, как управление тре-

бованиями. В самом деле, в экстремальной ситуации проектная

команда даже не будет документировать ни одно из пользова-

тельских

требований.

свое оправдание они говорят, что для до-

кументирования требуется слишком много времени, требования

часто меняются и, кроме

того,

пользователи сами точно не знают,

что им нужно. Таким образом, команда обычно полагается на ме-

тоды и средства прототипирования, с помощью которых можно

наглядно продемонстрировать всю важную проектную работу, а

также выявить реальные требования к системе. С точки зрения

«приоритетности» это порождает невозможность организованно

управлять требованиями.

Чтобы достичь успеха, проектная команда должна прийти к

соглашению, какие процессы будут формализованы (например,

контроль исходного кода, управление изменениями и управле-

ние требованиями) и какие будут неформальными (например,

проектирование пользовательского интерфейса). Бессмысленно

требовать

обязательном порядке выполнения какого-либо про-

цесса, если никто не собирается ему следовать.

498 Глава 7

Менеджер «безнадежного» проекта должен безоговорочно

настаивать на выполнении тех процессов, которые он считает

принципиально важными, например, процесса управления изме-

нениями.

Формальные подходы (типа SEI-CMM, ISO-9000 или внедре-

ние новых технологий анализа и проектирования) должны иметь

место где-нибудь за пределами «безнадежного» проекта. Внедре-

ние таких процессов имеет смысл как

часть

долговременной кор-

поративной стратегии. Оно должно начинаться с выполнения

пилотного проекта (но не «безнадежного»), сопровождаясь орга-

низацией необходимого обучения. Если все это уже сделано, и

другие разработки ПО в организации уже выполняются на треть-

ем уровне SEI-CMM, то официально принятые в организации

процессы следует усовершенствовать, чтобы сделать их пригод-

ными для использования в «безнадежном» проекте.

Существует еще один аспект в разработке ПО, который по-

рождает трудности

«безнадежных» проектах: неявно подразуме-

ваемое требование достижения идеального качества. Обычно оно

выражается в терминах количества дефектов, независимости от

платформы, гибкости и др. Даже в нормальных проектах доста-

точно трудно удовлетворить всем этим требованиям, а в «безна-

дежных» сделать

это

просто невозможно. Вместо этого проектная

команда должна прийти к решению (и по возможности согласо-

вать его с акционерами и заинтересованными лицами) относи-

тельно того, какое качество является достаточно хорошим.

Важность такого решения объясняется тем, что достижение

абсолютного качества съедает все ресурсы проекта, особенно

время. Если нужно разработать сертифицированную, не содер-

жащую ошибок программу

математически доказать ее коррект-

ность, на это потребуется время. Для этого нужны более талант-

ливые и способные специалисты, а их недостаточно в проектной

команде. Кроме того, одному или более участникам команды

придется расходовать дополнительную энергию, следовательно,

они не смогут работать

над

другими задачами. Выполнение таких

требований, как надежность, переносимость и сопровождае-

мость, невозможно без компромиссов, и это необходимо учиты-

вать в процессе определения приоритетов требований.

Эти требования не являются необходимыми, практичными

или желательными

большинстве «безнадежных» проектов. Дос-

тичь такого

совершенства невозможно

даже в

нормальных проек-

Особенности современных проектов 499

тах, хотя в них нет таких жестких ограничений на время, бюджет

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

пользователям в действительности нужна система, которая дос-

таточно дешева, достаточно производительна, обладает необхо-

димыми возможностями, достаточно устойчива и будет готова

достаточно скоро

—

вот в чем заключается их определение «дос-

таточно хорошего» ПО.

Однако отсутствие стандартов и технологии само по себе мо-

жет превратить проект в «безнадежный». Не следует восприни-

мать сказанное выше как предлог для отказа от каких-либо про-

цессов или методов вообще. Проблема заключается в том, чтобы

отыскать те процессы, которые действительно работают и кото-

рым команда будет следовать естественным образом и бессозна-

тельно. Последнее особенно важно: команда испытывает такой

стресс

давление, что должна многое делать чисто инстинктив-

но.

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

—

приоритетность.

7.7.

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

Во многих «безнадежных» проектах наиболее серьезные

проблемы носят не столько технический характер, сколько поли-

тический, социальный, культурный и человеческий. И хотя су-

ществует ряд хороших подходов, ориентированных на учет чело-

веческого фактора (набор лучших специалистов, их мотивация и

организация продуктивных коллективов), проблема в том, что

все это должно работать в рамках некоторой реальной организа-

ции, которая может оказаться настолько сложной, что непонят-

но,

как она вообще

работает.

На самом

деле,

зачастую она

и не

ра-

ботает, при этом деятельность проектной команды оказывается

парализованной из-за непонятных и неожиданных.решений и

политики руководства.

Это происходит, несмотря на героические усилия, предпри-

нимаемые многими организациями для упорядочения и усовер-

шенствования своих процессов, используя RAD,

ХР,

SEI-CMM и

т.д.

Многие из этих усилий затрачиваются впустую, поскольку не

понимается динамика процессов (особенно временные задержки

и циклы обратной связи) и игнорируются неформальные процес-

сы,

играющие главную роль в проектах. По этой причине в пос-

ледние несколько лет моделирование и имитация динамики та-

ких процессов вызывают особый интерес.

500 Глава 7

Динамика систем

—

это не новое понятие, ему

уже

несколько

десятков

лет.

США

одни

из первых работ

этой области выпол-

нил в начале 1960-х годов в Массачусетском технологическом

институте Джей Форрестер. С тех пор многое изменилось: есть

ПК, позволяющие работать с имитационной моделью в интерак-

тивном режиме, в отличие от пакетных систем с недельным цик-

лом обработки; имеются языки визуального моделирования, и

применяются общие принципы динамики систем для решения

небольших, конкретных задач.

Один из примеров таких конкретных задач

—

процессы созда-

ния ПО. Начиная с первых работ Тарика Абдель-Хамида^ в Мас-

сачусетском технологическом институте в начале 1990-х годов,

исследователи и специалисты

области совершенствования про-

цессов экспериментируют с динамическими моделями, пытаясь

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

менеджеру безнадежного проекта лучше понять, что происходит

в его проекте, то вероятность успеха может повыситься.

Многие воспринимают слово «модель»

контексте процессов

разработки ПО, как набор графических абстракций ПО - напри-

мер,

диафаммы UML, блок-схемы, диаграммы «сущность-связь»

др.

Однако в реальном мире менеджеры проектов мало что ис-

пользуют из всей этой кухни

своей повседневной деятельности.

Такие модели используются скорее для планирования и согласо-

вания общей стратегии,

а для

принятия ежедневных оперативных

решений используются другие модели, наиболее важными из ко-

торых являются мысленные (mental) и табличные (spreadsheet)

модели.

Мысленную модель следует буквально понимать как модель,

которая существует только в голове. Она может основываться на

опыте или интуиции или на мифах

легендах, на нее оказывают

влияние политика и весь спектр человеческих эмоций. Однако

главная особенность мысленной модели заключается в том, что

ее невозможно выразить

письменной форме; во многих случаях

ее даже невозможно озвучить, это глубоко личная практика ме-

неджера, которой он руководствуется в своей работе.

Представьте себе такую ситуацию: половина проекта позади,

утром программисты приходят

офис к менеджеру и хмуро заяв-

^ Тагек

Abdel-Hamid,

Stuart Е. Madnick. Software Project Dynamics: An

Integrated Approach. Englewood ClilTs, NJ: Prentice Hall, 1991.