не являются противоречивыми или несовместимыми. Можно потратить время и силы как на одно, так и на другое; если команда безнадёжного проекта считает, что для лучшего понимания требований к системе полезно построить объектно-ориентированную модель, у меня нет никаких возражений. Я только хотел бы предостеречь проектную команду, чтобы она делала то, что именно она сама считает важным и полезным, а не то, что считают «правильным» блюстители чистоты методологии (здесь частично затрагиваются вопросы «наилучшей» практики, которые будут обсуждаться ниже).
Мой опыт говорит о том, что в большинстве безнадёжных проектов не используются формальные методы моделирования, такие, как SA/SD или OOA/OOD. Отчасти это из-за того, что эти методологии кажутся проектной команде слишком громоздкими и бюрократическими; отчасти из-за того, что CASE-средства, поддерживающие эти методологии, кажутся слишком неудобными для использования; и, как правило, из-за того, что они не видят, каким образом можно преобразовать полученные в результате анализа модели в работающий код — единственное , что в конечном счёте нужно пользователю. (В «нормальном» проекте, наоборот, SA/OOA-модели сами по себе воспринимаются, как весьма полезные. Пользователи и специалисты, определяющие бизнес-политику организации, будут толпиться вокруг диаграмм потоков данных и тихо бормотать друг другу: «Так вот в чем заключается наш бизнес! Может быть, имеет смысл провести реинжиниринг бизнес-процессов и изменить все это перед тем, как создавать новую автоматизированную систему».)
В самом деле, в экстремальной ситуации проектная команда даже не будет документировать ни одно из пользовательских требований; в своё оправдание (которое наверняка слышал каждый менеджер проекта!) они говорят, что это требует слишком много времени, требования слишком часто меняются и, кроме того, пользователи сами не знают, что им нужно. Таким образом, команда обычно полагается на методы и средства прототипирования, с помощью которых можно наглядно продемонстрировать всю важную проектную работу, а также выявить реальные требования к системе.
С точки зрения «приоритетности», о которой шла речь в разд. 5.1, все это порождает одну главную проблему: невозможность сколько-нибудь организованным способом управлять требованиями. Как можно в любой момент времени сказать, какие требования «необходимо выполнить», какие «следует выполнить» и какие «можно выполнить»? Интересно отметить, что методологии SA/SD и OOA/OOD также не дают ответа на этот вопрос. Можно, конечно, определять приоритеты, раскрашивая кружочки на диаграммах потоков данных, но они изначально предназначены вовсе не для этого. Методологии SA/SD и OOA/OOD предназначены в первую очередь для понимания и объяснения требований, а не для управления ими в динамике.
Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудности. Если бы вам в самом начале проекта удалось убедить всех акционеров и заинтересованных лиц согласиться с приоритетностью требований, и если бы эти приоритеты никогда не менялись в течение проекта … ну что ж, если вы в самом деле в это верите, то вы, наверное, также верите в фей и колдунов. В реальных же безнадёжных проектах обычно возникают в различных вариантах следующие дилеммы:
3) Акционеры и заинтересованные лица не могут полностью согласиться с предложенными приоритетами. Разумеется, если они совсем не согласны, проект будет просто парализован; однако, нередко можно встретиться с такой ситуацией, когда для 80 процентов требований устанавливаются приоритеты и начинается работа над проектом, в то время как политиканы продолжают спорить относительно оставшихся 20 процентов. В результате этих споров требования с высоким приоритетом иногда появляются в самый последний момент. Это ставит перед проектной командой трудную задачу, однако вряд ли возможно этого избежать.
4) Во время проекта изменяется ситуация в команде. Например, в одно прекрасное утро менеджер проекта приходит в офис и обнаруживает, что два его лучших программиста, Матильда и Эзекиель, решили создать реггей-бэнд и только что уехали в Нэшвил в поисках контракта для записи диска. Никто не предполагал, что такое может случиться, однако это случилось. Первые три вопроса, которые вынужден выяснить менеджер, заключаются в следующем: «Над какими обязательными требованиями работали эти мерзавцы, каков статус этих требований и кому я могу их перепоручить?»
5) Изменяются обстоятельства вовне проектной команды. В зависимости от финансовых успехов компании увеличивается или уменьшается бюджет. Срок окончания проекта отодвигается или приближается (и даже очень сильно) в зависимости от того, насколько департамент маркетинга осведомлён относительно изменения конкурентной ситуации на рынке. Меняются решения правительства, меняются технологии (не всегда в лучшую сторону!), поставщики приходят и уходят, и т.д., и т.п. Каждое из этих внешних событий может оказать некоторое воздействие на решения, принятые в отношении приоритетов требований.
6) Нередко наступает «момент истины», когда пользователи, высшее руководство и участники проектной команды вынуждены признать, что система не будет готова в срок. Разумеется, если в начале проекта была проделана достаточно квалифицированная работа по определению приоритетов требований, такой кризис может и не наступить вообще. Но что если команда вынуждена признать, что она не может выполнить в срок даже все необходимые требования? Как было отмечено выше, менеджеру проекта обычно «снимают голову» и заменяют на другого; при этом, если новому менеджеру удаётся отодвинуть конечный срок, то приоритеты могут быть оставлены без изменения. Однако в этот момент все же, как правило, ранее принятые решения подвергаются серьёзному пересмотру. Конечный срок уже маячит впереди на расстоянии нескольких недель, и пользователи могут волей-неволей согласиться с тем, что некоторые требования, считавшиеся ранее абсолютно необходимыми, вообще перестают быть таковыми.
Этот перечень можно продолжать дальше, но думаю, что вывод ясен: управление приоритетом требований является критически важной частью «процесса» безнадёжных проектов. Конечно, если безнадёжный проект содержит всего дюжину требований, то управлять ими будет совсем несложно; можно нацарапать их на бумажной салфетке и просто пересматривать по мере необходимости. Однако, большинство проектов включает сотни требований, а многие — даже тысячи; проект самолёта Боинг-777 (который вполне можно считать мешком программ с крыльями) включал, по слухам, 300.000 требований. Но это ещё не все, ведь требования обычно не являются независимыми; некоторые требования зависят от других требований, а некоторые в свою очередь порождают другие требования.
Все это подразумевает необходимость в методах, процессах и средствах для описания зависимостей между требованиями и управления большим количеством таких зависимостей. В решении данной проблемы могут, конечно, помочь такие известные методы, как структурный анализ и объектно-ориентированный анализ, но, к сожалению, до сих пор эти методы традиционно игнорировали атрибуты требований, такие, как приоритет, стоимость, риск, план, владелец и разработчик, который занимается его реализацией. В результате проектным командам, испытывающим потребность в управлении требованиями, приходилось использовать доморощенные средства, базирующиеся на электронных таблицах, текстовых процессорах или наспех созданных приложениях, чтобы обеспечить хотя бы некоторую степень автоматизированной поддержки.
К счастью, в настоящее время появилось новое поколение средств, обеспечивающих более комплексную и сложную поддержку управления требованиями. Вот некоторые из доступных на сегодняшний день средств: Requisite (Requisite, Inc.), DOORS (Zycad Corp.), RTM (Marconi Systems). Поскольку данная глава посвящена в основном процессам, а не средствам, я не буду вдаваться в детали этих трех продуктов; но поскольку средства влияют на процессы, важно знать хотя бы о их существовании (ветераны-разработчики ПО вспомнят старую поговорку: «Если единственным вашим инструментом является молоток, то все ваши проблемы выглядят как гвозди»).
Существует один аспект в комбинации процессов и средств, который следует особо отметить. Как было сказано выше, многие команды безнадёжных проектов отказываются от использования формальных методологий SA/SD или OOA/OOD, поскольку они выглядят слишком громоздкими и бюрократическими. Что интересно, акционеры и заинтересованные лица рассуждают точно так же. Если предоставить им выбор, то они предпочли бы, чтобы их не заставляли изучать, как читать диаграммы потоков данных; в самом деле, руководители и конечные пользователи высокого уровня иерархии жалуются, что они ничего не понимают во всех этих «технических» диаграммах. У них также не хватает терпения продираться сквозь сотни страниц с диаграммами и мелкими деталями описаний элементов данных или спецификаций процессов. Конечно, если времени и терпения достаточно, то проектная команда в состоянии преодолеть сопротивление и убедить конечных пользователей в том, что тщательно разработанные модели на самом деле приносят большую пользу — однако в безнадёжных проектах вечно не хватает ни времени, ни терпения.
Что пользователи в состоянии понимать — так это их собственный родной язык, например, английский для большинства североамериканских проектов. И что большинство из них предпочитают читать — это небольшой документ из 10-20 страниц, суммирующий все требования к системе. Требования в таком документе могут называться «характеристиками», а сам документ в целом — «Требования к системе» («Product Requirements Document» — PRD) или «спецификация высокого уровня» или ещё какой-нибудь подходящей фразой. Главное, что этот документ небольшой и на английском языке. Он не должен содержать рекламной «шелухи», а также непонятной терминологии или обозначений, заставляющих пользователей задумываться, что бы это значило. В идеальном случае каждый абзац или даже каждое отдельное предложение должны соответствовать конкретному требованию, чтобы и пользователи, и участники проектной команды могли использовать их в качестве отправной точки для своей дальнейшей работы.
Во всем этом есть один интересный момент — он заключается в том, что у нас уже одно знакомое всем средство для создания таких документов; оно называется «текстовый процессор». В самом деле, начальная версия такого документа обычно исходит от пользователей — например, в виде записки от вице-президента по маркетингу к исполнительному директору по поводу возникшей потребности в новом замечательном продукте со свойствами X, Y и Z, который мог бы соперничать с продуктом конкурента — даже когда департамент информационных технологий ещё ничего об этом не знает. На этой ранней стадии пользователи рассматривают текстовый процессор как своё средство, а записку службы маркетинга — как свой документ; в результате они проявляют гораздо большую готовность участвовать в последующих дискуссиях по поводу приоритетности требований, если при этом продолжают использоваться аналогичные средства и документы. Таким образом, мы наблюдаем тенденцию, ведущую к документо-центричному управлению требованиями, когда средства, используемые специалистами по ИТ (например, Requisite, DOORS или RTM), тесно интегрируются с текстовыми процессорами и документами, в которых пользователи хорошо разбираются (я должен честно признаться, что это в какой-то степени рекламный трюк, поскольку такая интеграция является одним из основных свойств Requisite, и я был одним из членов правления компании Requisite, когда писал эту книгу. Но поскольку я играю роль объективного автора, я искренне рекомендую вам познакомиться со всеми тремя перечисленными здесь продуктами.)
Ещё одно последнее соображение: очень важно, чтобы все акционеры и заинтересованные лица участвовали в процессе выработки начальных требований, их документирования и определения приоритетов. Разумеется, это касается любых проектов, однако нехватка времени и политические баталии, присущие безнадёжным проектам, нередко соблазняют менеджера проекта рассуждать следующим образом: «Ладно, мы будем двигаться дальше и обойдёмся без этого идиота Мелвина из департамента маркетинга; все, на что он способен — это не соглашаться никогда и ни с чем». При этом может возникнуть следующая проблема: Мелвин, получив серьёзную «политическую» пощёчину и чувствуя, что его игнорируют (и что менеджер проекта считает его идиотом!), скорее всего найдёт способ саботировать проект.
Теоретически каждый понимает и соглашается с такой точкой зрения, однако на практике просто удивительно наблюдать, как безнадёжные проекты потихоньку обрастают все новыми и новыми требованиями. Дополнительные требования, модификации существующих требований и недвусмысленные предложения игнорировать некоторые требования — все это сваливается на проектную команду в виде телефонных звонков, посланий по электронной почте и разговоров с глазу на глаз с менеджером проекта. Многие из этих предложений предваряются такими успокаивающими фразами, как «извини, что я забыл об этом сказать на нашем последнем совещании, но … » или «я рассчитывал, что у нашей группы управления будет время справиться с этой проблемой, но … ».
Существует ли у менеджера проекта такая формальная группа управления — т.е., группа, состоящая из акционеров и заинтересованных лиц, которая оценивает полученные в проекте результаты и принимает определённые решения относительно приоритетности требований — или нет, в данном случае не имеет значения; это зависит от того стиля управления и организации проектов, который сложился в каждой организации. Но что действительно имеет значение для успешного завершения безнадёжного проекта — это тщательное документирование каждой модификации, вносимой в исходные требования, и извещение о ней всех акционеров и заинтересованных лиц. Если вице-президент по финансам хочет потихоньку вставить в проект ещё одно приоритетное требование, это замечательно; однако при этом менеджер проекта должен позаботиться, чтобы об этом узнали вице-президент по маркетингу и исполнительный директор.
5.3 SEI, ISO-9000. Формальные процессы против неформальных
Некоторые менеджеры, прочтя предыдущий раздел данной главы, могут высказать недовольство: «Вот здорово! Это выглядит гораздо более формальным, чем все, что мы когда-либо делали!» Когда мне приходилось сталкиваться с такой реакцией в некоторых консалтинговых проектах, это просто ставило меня в тупик. С одной стороны, я уверен, что документирование, определение приоритетов и управление требованиями просто необходимы (независимо от того, какие средства и методы для этого используются) ; с другой стороны, я опасаюсь следующего: когда проектной команде, и без того заваленной работой выше головы, навязывается совершенно новый и незнакомый процесс, то этот процесс — например, управление требованиями — может оказаться последней каплей, переполнившей чашу терпения.
В самом деле, у меня нет для этой дилеммы другого решения, кроме как надеяться, что проектная команда все же сможет справиться с одной новой идеей среди прочих своих средств и процессов. Однако, меня охватывает гораздо большее беспокойство, когда я вижу команды, которые предпринимают свой первый безнадёжный проект с решением (или, что более вероятно, с указанием, навязанным им блюстителями методологии), обязывающим их использовать формальные процессы, например, те, которые регламентируются SEI-CMM или ISO-9000. Формальные процессы — это великая вещь, если вы хорошо знаете, что делаете, и если вы уже использовали их прежде. Однако, реальность такова, что такие формальные процессы, как правило, ранее вообще не использовались в организации, и безнадёжный проект представляет собой пилотный проект для апробации структурного анализа или ISO-9000.
Какое безумие! Это действительно последняя капля, которая переполнит чашу терпения; в конце концов типичный безнадёжный проект пытается выполнить то, что раньше никогда не делалось, и (несмотря на мои предостережения в главе 4) команда нередко состоит из людей, которые никогда раньше не работали вместе. Так мало того, они ещё вынуждены осваивать использование незнакомой методологии или процесса, не будучи уверенными в том, что это им необходимо в первую очередь, и, напротив, будучи убеждёнными, что это только затормозит их работу. Чему же тогда удивляются блюстители методологии, когда они в подобных обстоятельствах сталкиваются с сопротивлением?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Мой опыт говорит о том, что в большинстве безнадёжных проектов не используются формальные методы моделирования, такие, как SA/SD или OOA/OOD. Отчасти это из-за того, что эти методологии кажутся проектной команде слишком громоздкими и бюрократическими; отчасти из-за того, что CASE-средства, поддерживающие эти методологии, кажутся слишком неудобными для использования; и, как правило, из-за того, что они не видят, каким образом можно преобразовать полученные в результате анализа модели в работающий код — единственное , что в конечном счёте нужно пользователю. (В «нормальном» проекте, наоборот, SA/OOA-модели сами по себе воспринимаются, как весьма полезные. Пользователи и специалисты, определяющие бизнес-политику организации, будут толпиться вокруг диаграмм потоков данных и тихо бормотать друг другу: «Так вот в чем заключается наш бизнес! Может быть, имеет смысл провести реинжиниринг бизнес-процессов и изменить все это перед тем, как создавать новую автоматизированную систему».)
В самом деле, в экстремальной ситуации проектная команда даже не будет документировать ни одно из пользовательских требований; в своё оправдание (которое наверняка слышал каждый менеджер проекта!) они говорят, что это требует слишком много времени, требования слишком часто меняются и, кроме того, пользователи сами не знают, что им нужно. Таким образом, команда обычно полагается на методы и средства прототипирования, с помощью которых можно наглядно продемонстрировать всю важную проектную работу, а также выявить реальные требования к системе.
С точки зрения «приоритетности», о которой шла речь в разд. 5.1, все это порождает одну главную проблему: невозможность сколько-нибудь организованным способом управлять требованиями. Как можно в любой момент времени сказать, какие требования «необходимо выполнить», какие «следует выполнить» и какие «можно выполнить»? Интересно отметить, что методологии SA/SD и OOA/OOD также не дают ответа на этот вопрос. Можно, конечно, определять приоритеты, раскрашивая кружочки на диаграммах потоков данных, но они изначально предназначены вовсе не для этого. Методологии SA/SD и OOA/OOD предназначены в первую очередь для понимания и объяснения требований, а не для управления ими в динамике.
Именно динамическая составляющая управления требованиями обычно вызывает наибольшие трудности. Если бы вам в самом начале проекта удалось убедить всех акционеров и заинтересованных лиц согласиться с приоритетностью требований, и если бы эти приоритеты никогда не менялись в течение проекта … ну что ж, если вы в самом деле в это верите, то вы, наверное, также верите в фей и колдунов. В реальных же безнадёжных проектах обычно возникают в различных вариантах следующие дилеммы:
3) Акционеры и заинтересованные лица не могут полностью согласиться с предложенными приоритетами. Разумеется, если они совсем не согласны, проект будет просто парализован; однако, нередко можно встретиться с такой ситуацией, когда для 80 процентов требований устанавливаются приоритеты и начинается работа над проектом, в то время как политиканы продолжают спорить относительно оставшихся 20 процентов. В результате этих споров требования с высоким приоритетом иногда появляются в самый последний момент. Это ставит перед проектной командой трудную задачу, однако вряд ли возможно этого избежать.
4) Во время проекта изменяется ситуация в команде. Например, в одно прекрасное утро менеджер проекта приходит в офис и обнаруживает, что два его лучших программиста, Матильда и Эзекиель, решили создать реггей-бэнд и только что уехали в Нэшвил в поисках контракта для записи диска. Никто не предполагал, что такое может случиться, однако это случилось. Первые три вопроса, которые вынужден выяснить менеджер, заключаются в следующем: «Над какими обязательными требованиями работали эти мерзавцы, каков статус этих требований и кому я могу их перепоручить?»
5) Изменяются обстоятельства вовне проектной команды. В зависимости от финансовых успехов компании увеличивается или уменьшается бюджет. Срок окончания проекта отодвигается или приближается (и даже очень сильно) в зависимости от того, насколько департамент маркетинга осведомлён относительно изменения конкурентной ситуации на рынке. Меняются решения правительства, меняются технологии (не всегда в лучшую сторону!), поставщики приходят и уходят, и т.д., и т.п. Каждое из этих внешних событий может оказать некоторое воздействие на решения, принятые в отношении приоритетов требований.
6) Нередко наступает «момент истины», когда пользователи, высшее руководство и участники проектной команды вынуждены признать, что система не будет готова в срок. Разумеется, если в начале проекта была проделана достаточно квалифицированная работа по определению приоритетов требований, такой кризис может и не наступить вообще. Но что если команда вынуждена признать, что она не может выполнить в срок даже все необходимые требования? Как было отмечено выше, менеджеру проекта обычно «снимают голову» и заменяют на другого; при этом, если новому менеджеру удаётся отодвинуть конечный срок, то приоритеты могут быть оставлены без изменения. Однако в этот момент все же, как правило, ранее принятые решения подвергаются серьёзному пересмотру. Конечный срок уже маячит впереди на расстоянии нескольких недель, и пользователи могут волей-неволей согласиться с тем, что некоторые требования, считавшиеся ранее абсолютно необходимыми, вообще перестают быть таковыми.
Этот перечень можно продолжать дальше, но думаю, что вывод ясен: управление приоритетом требований является критически важной частью «процесса» безнадёжных проектов. Конечно, если безнадёжный проект содержит всего дюжину требований, то управлять ими будет совсем несложно; можно нацарапать их на бумажной салфетке и просто пересматривать по мере необходимости. Однако, большинство проектов включает сотни требований, а многие — даже тысячи; проект самолёта Боинг-777 (который вполне можно считать мешком программ с крыльями) включал, по слухам, 300.000 требований. Но это ещё не все, ведь требования обычно не являются независимыми; некоторые требования зависят от других требований, а некоторые в свою очередь порождают другие требования.
Все это подразумевает необходимость в методах, процессах и средствах для описания зависимостей между требованиями и управления большим количеством таких зависимостей. В решении данной проблемы могут, конечно, помочь такие известные методы, как структурный анализ и объектно-ориентированный анализ, но, к сожалению, до сих пор эти методы традиционно игнорировали атрибуты требований, такие, как приоритет, стоимость, риск, план, владелец и разработчик, который занимается его реализацией. В результате проектным командам, испытывающим потребность в управлении требованиями, приходилось использовать доморощенные средства, базирующиеся на электронных таблицах, текстовых процессорах или наспех созданных приложениях, чтобы обеспечить хотя бы некоторую степень автоматизированной поддержки.
К счастью, в настоящее время появилось новое поколение средств, обеспечивающих более комплексную и сложную поддержку управления требованиями. Вот некоторые из доступных на сегодняшний день средств: Requisite (Requisite, Inc.), DOORS (Zycad Corp.), RTM (Marconi Systems). Поскольку данная глава посвящена в основном процессам, а не средствам, я не буду вдаваться в детали этих трех продуктов; но поскольку средства влияют на процессы, важно знать хотя бы о их существовании (ветераны-разработчики ПО вспомнят старую поговорку: «Если единственным вашим инструментом является молоток, то все ваши проблемы выглядят как гвозди»).
Существует один аспект в комбинации процессов и средств, который следует особо отметить. Как было сказано выше, многие команды безнадёжных проектов отказываются от использования формальных методологий SA/SD или OOA/OOD, поскольку они выглядят слишком громоздкими и бюрократическими. Что интересно, акционеры и заинтересованные лица рассуждают точно так же. Если предоставить им выбор, то они предпочли бы, чтобы их не заставляли изучать, как читать диаграммы потоков данных; в самом деле, руководители и конечные пользователи высокого уровня иерархии жалуются, что они ничего не понимают во всех этих «технических» диаграммах. У них также не хватает терпения продираться сквозь сотни страниц с диаграммами и мелкими деталями описаний элементов данных или спецификаций процессов. Конечно, если времени и терпения достаточно, то проектная команда в состоянии преодолеть сопротивление и убедить конечных пользователей в том, что тщательно разработанные модели на самом деле приносят большую пользу — однако в безнадёжных проектах вечно не хватает ни времени, ни терпения.
Что пользователи в состоянии понимать — так это их собственный родной язык, например, английский для большинства североамериканских проектов. И что большинство из них предпочитают читать — это небольшой документ из 10-20 страниц, суммирующий все требования к системе. Требования в таком документе могут называться «характеристиками», а сам документ в целом — «Требования к системе» («Product Requirements Document» — PRD) или «спецификация высокого уровня» или ещё какой-нибудь подходящей фразой. Главное, что этот документ небольшой и на английском языке. Он не должен содержать рекламной «шелухи», а также непонятной терминологии или обозначений, заставляющих пользователей задумываться, что бы это значило. В идеальном случае каждый абзац или даже каждое отдельное предложение должны соответствовать конкретному требованию, чтобы и пользователи, и участники проектной команды могли использовать их в качестве отправной точки для своей дальнейшей работы.
Во всем этом есть один интересный момент — он заключается в том, что у нас уже одно знакомое всем средство для создания таких документов; оно называется «текстовый процессор». В самом деле, начальная версия такого документа обычно исходит от пользователей — например, в виде записки от вице-президента по маркетингу к исполнительному директору по поводу возникшей потребности в новом замечательном продукте со свойствами X, Y и Z, который мог бы соперничать с продуктом конкурента — даже когда департамент информационных технологий ещё ничего об этом не знает. На этой ранней стадии пользователи рассматривают текстовый процессор как своё средство, а записку службы маркетинга — как свой документ; в результате они проявляют гораздо большую готовность участвовать в последующих дискуссиях по поводу приоритетности требований, если при этом продолжают использоваться аналогичные средства и документы. Таким образом, мы наблюдаем тенденцию, ведущую к документо-центричному управлению требованиями, когда средства, используемые специалистами по ИТ (например, Requisite, DOORS или RTM), тесно интегрируются с текстовыми процессорами и документами, в которых пользователи хорошо разбираются (я должен честно признаться, что это в какой-то степени рекламный трюк, поскольку такая интеграция является одним из основных свойств Requisite, и я был одним из членов правления компании Requisite, когда писал эту книгу. Но поскольку я играю роль объективного автора, я искренне рекомендую вам познакомиться со всеми тремя перечисленными здесь продуктами.)
Ещё одно последнее соображение: очень важно, чтобы все акционеры и заинтересованные лица участвовали в процессе выработки начальных требований, их документирования и определения приоритетов. Разумеется, это касается любых проектов, однако нехватка времени и политические баталии, присущие безнадёжным проектам, нередко соблазняют менеджера проекта рассуждать следующим образом: «Ладно, мы будем двигаться дальше и обойдёмся без этого идиота Мелвина из департамента маркетинга; все, на что он способен — это не соглашаться никогда и ни с чем». При этом может возникнуть следующая проблема: Мелвин, получив серьёзную «политическую» пощёчину и чувствуя, что его игнорируют (и что менеджер проекта считает его идиотом!), скорее всего найдёт способ саботировать проект.
Теоретически каждый понимает и соглашается с такой точкой зрения, однако на практике просто удивительно наблюдать, как безнадёжные проекты потихоньку обрастают все новыми и новыми требованиями. Дополнительные требования, модификации существующих требований и недвусмысленные предложения игнорировать некоторые требования — все это сваливается на проектную команду в виде телефонных звонков, посланий по электронной почте и разговоров с глазу на глаз с менеджером проекта. Многие из этих предложений предваряются такими успокаивающими фразами, как «извини, что я забыл об этом сказать на нашем последнем совещании, но … » или «я рассчитывал, что у нашей группы управления будет время справиться с этой проблемой, но … ».
Существует ли у менеджера проекта такая формальная группа управления — т.е., группа, состоящая из акционеров и заинтересованных лиц, которая оценивает полученные в проекте результаты и принимает определённые решения относительно приоритетности требований — или нет, в данном случае не имеет значения; это зависит от того стиля управления и организации проектов, который сложился в каждой организации. Но что действительно имеет значение для успешного завершения безнадёжного проекта — это тщательное документирование каждой модификации, вносимой в исходные требования, и извещение о ней всех акционеров и заинтересованных лиц. Если вице-президент по финансам хочет потихоньку вставить в проект ещё одно приоритетное требование, это замечательно; однако при этом менеджер проекта должен позаботиться, чтобы об этом узнали вице-президент по маркетингу и исполнительный директор.
5.3 SEI, ISO-9000. Формальные процессы против неформальных
Некоторые менеджеры, прочтя предыдущий раздел данной главы, могут высказать недовольство: «Вот здорово! Это выглядит гораздо более формальным, чем все, что мы когда-либо делали!» Когда мне приходилось сталкиваться с такой реакцией в некоторых консалтинговых проектах, это просто ставило меня в тупик. С одной стороны, я уверен, что документирование, определение приоритетов и управление требованиями просто необходимы (независимо от того, какие средства и методы для этого используются) ; с другой стороны, я опасаюсь следующего: когда проектной команде, и без того заваленной работой выше головы, навязывается совершенно новый и незнакомый процесс, то этот процесс — например, управление требованиями — может оказаться последней каплей, переполнившей чашу терпения.
В самом деле, у меня нет для этой дилеммы другого решения, кроме как надеяться, что проектная команда все же сможет справиться с одной новой идеей среди прочих своих средств и процессов. Однако, меня охватывает гораздо большее беспокойство, когда я вижу команды, которые предпринимают свой первый безнадёжный проект с решением (или, что более вероятно, с указанием, навязанным им блюстителями методологии), обязывающим их использовать формальные процессы, например, те, которые регламентируются SEI-CMM или ISO-9000. Формальные процессы — это великая вещь, если вы хорошо знаете, что делаете, и если вы уже использовали их прежде. Однако, реальность такова, что такие формальные процессы, как правило, ранее вообще не использовались в организации, и безнадёжный проект представляет собой пилотный проект для апробации структурного анализа или ISO-9000.
Какое безумие! Это действительно последняя капля, которая переполнит чашу терпения; в конце концов типичный безнадёжный проект пытается выполнить то, что раньше никогда не делалось, и (несмотря на мои предостережения в главе 4) команда нередко состоит из людей, которые никогда раньше не работали вместе. Так мало того, они ещё вынуждены осваивать использование незнакомой методологии или процесса, не будучи уверенными в том, что это им необходимо в первую очередь, и, напротив, будучи убеждёнными, что это только затормозит их работу. Чему же тогда удивляются блюстители методологии, когда они в подобных обстоятельствах сталкиваются с сопротивлением?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24