1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

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

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

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

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

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

если участники команды всегда могут узнать о том, что происхо­ дит в проекте, тогда они спокойно смогут на 99% сконцентриро­ ваться на своей непосредственной работе.

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

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

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

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

Оформитель (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, ХР, SEI-CMM и т.д. Многие из этих усилий затрачиваются впустую, поскольку не понимается динамика процессов (особенно временные задержки и циклы обратной связи) и игнорируются неформальные процес­ сы, играющие главную роль в проектах. По этой причине в пос­ ледние несколько лет моделирование и имитация динамики та­ ких процессов вызывают особый интерес.