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

Автор книги: Драган Милошевич

сообщить о нарушении

Текущая страница: 15 (всего у книги 54 страниц) [доступный отрывок для чтения: 20 страниц]

Описание содержанияЧто такое описание содержания?

Описание содержания[17]17
  В данном случае имеется в виду содержание предметной части проекта. Кроме этого, в любом проекте есть содержание именно управления проектом – части, являющейся приоритетной для непосредственной работы менеджера. – Прим. ред.


[Закрыть] представляет собой письменное изложение целей, этапов и продуктов проекта (рис. 5.5). Описание содержания отвечает на вопрос, имеющий основополагающе значение: «Что мы производим в данном проекте?» Это позволяет оценить желаемый результат и составить базовый план содержания, которому необходимо следовать при выполнении всех работ проекта. В известном смысле базовый план содержания можно сравнить с границами проекта – он говорит о том, что выход за границы не допускается без санкции руководителя и что все, находящееся в этих границах, представляет собой пространство решений, в котором разрешается действовать команде проекта. Хотя существует множество версий описания содержания, формат, представленный ниже, основан на утверждении, что проект – это бизнес-предприятие.

Составление описания содержания

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

Сбор исходной информации. Качество описания содержания во многом зависит от качества исходной информации. В частности, при разработке полноценного описания особенно важны:

• голос заказчика;

• устав проекта;

• SWOT-анализ проекта.

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

Рис. 5.5. Простой пример описания содержания

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

НОВАТОРСКИЕ СПОСОБЫ РАЗРАБОТКИ УСТОЙЧИВОГО К ИЗМЕНЕНИЯМ ОПИСАНИЯ СОДЕРЖАНИЯ

Применение следующих принципов в разработке содержания позволяет определять проекты таким образом, чтобы на стадии выполнения обеспечить их повышенную сопротивляемость изменениям:

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

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

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

Определение бизнес-цели. Давно минули те времена, когда проекты рассматривались исключительно как технические предприятия, цель которых состояла в производстве некоторого продукта или услуги. Сегодня, помимо такого производства, любая фирма должна стремиться к достижению ряда бизнес-целей, к которым относятся желаемая прибыль, доля рынка, накопление знаний, удовлетворение клиентов, определенный уровень производительности и т. д. [19]. Как следствие, разработка содержания начинается с обоснования проекта – с его бизнес-цели. Каких бизнес-целей должен достичь проект? Какие бизнес-планы он будет поддерживать? Для обычного менеджера рассмотрение проекта в терминах бизнеса – дело нелегкое. Но таковы современные проекты. И требования к ним предъявляются соответствующие: быстрее, дешевле и лучше, чем было в прошлом году. Некоторые специалисты полагают, что бизнес-цель проекта должна называться «констатацией предмета страсти проекта» и отвечать на вопрос «Какую уникальную ценность представляет ваш проект для клиента и для бизнеса компании?» Немецкий философ Гегель однажды сказал, что «ничто великое в мире не совершается без страсти».

Определение целей проекта[18]18
  В данной монографии не совсем четко разграничены понятия цели и задачи проекта, поэтому при чтении может возникнуть некоторая путаница. Тем не менее в теории управления проектами есть четкое разделение: цель – это та качественно и/или количественно новая (по продуктам или услугам) точка, в которую надо прийти по завершении проекта. Задачи проекта – это методы и пути, посредством которых достигается цель проекта. – Прим. ред.


[Закрыть]. Сколь бы призывной и вдохновляющей ни была бизнес-цель, она представляет собой лишь общее направление, не содержащее деталей о конкретных целевых установках проекта. Эти установки определяются целями проекта по части сроков (временная цель), стоимости (стоимостная цель) и качества (качественная цель) – см. элемент «цели проекта» на рис. 5.5. Конкретизируя дату завершения проекта (например, 1 мая 2003 г.), вы тем самым устанавливаете свою временную цель. Чтобы достичь ее, необходим конкретный бюджет, который вы должны определить (например, «бюджет проекта модернизации фабрики составляет 400 миллионов долларов»). В отраслях, где бюджеты средств не используются, допускается указание желательного количества часов работы ресурсов (например, «1200 часов работы ресурсов»). В отличие от временных и стоимостных/ресурсных целей, выражение качественной цели конкретным и измеримым образом может представлять собой проблему. Так как под качеством подразумевается удовлетворение или превышение требований заказчика, обычно описываемых какими-либо стандартами, разумно по согласованию с клиентом определить качественную цель проекта путем ссылки на тот или иной стандарт – например, «пользовательское руководство для данного проекта соответствует PMBOK» [5] (см. главу 8).

Поставив цели, мы наверняка столкнемся со ставшим уже притчей во языцех трехсторонним ограничением – удачный способ сформулировать тот факт, что три наши цели конкурируют друг с другом [5]. Если сократить целевое расписание проекта, придется увеличивать бюджет средств. Также изменение целевой установки по качеству может повлиять на стоимостную и временную цели. Очевидно, что эти цели взаимосвязаны и управлять ими – значит находить компромиссы. По названной причине во многих проектах принято расставлять приоритеты целей: наивысший приоритет – сроки, затем – качество, наинизший приоритет – стоимость. Иначе говоря, в ситуации, где требуется компромисс, мы в первую очередь должны стремиться соблюсти сроки, не обращая внимания на цели с более низкими приоритетами. Эта проблема существенно усложняется при разработке новых продуктов, когда необходимо ввести четвертую цель и четвертое ограничение – стоимость продукта [2]. Чтобы принимать решения в условиях четырехстороннего ограничения, нужно очень хорошо понимать тонкие взаимодействия между целями проекта.

Описание содержания работ. Какую конкретно работу потребуется выполнить в данном проекте для получения продукта и выполнения поставленных целей? Способны ли вы ответить сжато, одним-двумя предложениями, сделав акцент на картине проекта в целом? Например, содержание работ, связанных с возведением новой фабрики по производству оптики, может выглядеть так: «Спроектировать фабрику по производству оптики, рассчитать бюджет проекта, построить фабрику, сдать фабрику в эксплуатацию», – а для проекта в области программного обеспечения: «Определить технологические карты выполнения операций (трудовые процессы), сконфигурировать программное обеспечение, разработать план обучения, создать прототип, обучить персонал, выпустить программное обеспечение». И снова идея состоит в том, чтобы идентифицировать основные элементы работ проекта, которые будут рассмотрены более подробно в сопровождающих спецификациях и иной документации. Обратите внимание на способ структурирования описания: глагол (определить), за которым следует существительное (технологические карты), опять глагол (сконфигурировать) и существительное (программное обеспечение). Разумеется, вы можете сформулировать содержание по-другому. Здесь мы стремились ослабить привязку описания содержания работ к операциям и усилить привязку к целям. Говоря более конкретно, в некоторых организациях считается несущественным, выполняет ли проектная команда какую-либо работу (привязка к операциям), главное – добивается ли она результата (привязка к целям). Если вы чувствуете, что наша попытка усилить привязку описания содержания к целям не является действенной применительно к вашему случаю, прочтите следующую часть описания содержания: там речь пойдет о о промежуточных и конечных результатах проекта и контрольных событиях.

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

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

• «отчет о технологических картах выполнения операций готов» – 15 февраля 2002 г.;

• «конфигурирование программного обеспечения завершено» – 28 февраля 2002 г.;

• «план обучения составлен» – 28 февраля 2002 г.;

• «прототип разработан» – 30 марта 2002 г.;

• «персонал обучен» – 16 апреля 2002 г.;

• «программное обеспечение выпущено» – 30 апреля 2002 г.

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

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

Следует заметить также, что все проекты сталкиваются с серьезными ограничениями, которые могут изменить способ представления работ, получения результатов и достижения контрольных событий. Эти ограничения могут быть физическими, техническими, ресурсными или иными. Рассмотрим восхождение на Эверест как проект. Физическое ограничение здесь – климат, следовательно, проект реализуем лишь в определенные месяцы. В другом случае, когда некая консалтинговая компания принимала участие в тендере на выполнение проекта разработки справочника (технического руководства) проекта (17), владелец потребовал, чтобы все консультанты этой компании имели сертификат профессионала по управлению проектами, выдаваемый Институтом управления проектами (PMI). Такое условие вынудило компанию изменить первоначальное описание работ и образовать совместное предприятие с другой консалтинговой компанией, в которой было больше сертифицированных сотрудников. В третьем случае руководство поручило менеджеру проекта выполнить проект разработки программного продукта в режиме быстрого прохода. Однако из-за недостатка ресурсов для оперативного тестирования программы контрольные события пришлось изменить и сдвинуть на несколько месяцев. Мы привели лишь несколько примеров, говорящих об одном: сначала идентифицируйте основные ограничения и только потом разрабатывайте содержание и приступайте к выполнению проекта. В противном случае будьте готовы к тому, что ваш проект потерпит неудачу.

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

Определение исключений. Избавиться от любой привычки весьма сложно. В начале 1990-х годов некий подрядчик, занимающийся внедрением технологии в Африке, включил в содержание своих проектов поставку вычислительных центров в комплекте с офисной мебелью. Владельцам африканской компании потребовалось несколько лет, чтобы осознать, что покупать офисную мебель на месте гораздо дешевле, чем импортировать ее из Европы. Подрядчика попросили вычеркнуть мебель из содержания. Офис подрядчика был надлежащим образом уведомлен, однако мебель продолжала поставляться. Почему? Мебель стала привычной частью содержания, а уведомление не было ни достаточно сильным, ни достаточно заметным. Во избежание подобных ситуаций необходимо использовать исключения: особым образом отмечать то, что часто считается относящимся к проекту, но в данный момент не является частью содержания.

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

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