Общие стандарты управления проектами в применении к ИТ-проектам

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

• Международная ассоциация управления проектами (Швейцария) (англ. International Project Management Association, IPMA), созданная в 1965 году и призванная объединить специалистов в области управления проектами (Project Management), разработавшая модель зрелости организаций в области управления проектами, а также внедрившая собственную четырехступенчатую систему сертификации.
• Project Management Institute (PMI), профессиональная ассоциация по управлению проектами, основана в 1969 году, объединяет более 380 тысяч членов, представлена в более чем 170 странах.

В России IPMA представлена Ассоциацией управления проектами (СОВНЕТ), основанной в 1990 году как некоммерческая организация, осуществляющая научные исследования и разработки, обучение и сертификацию специалистов в области управления проектами. Московское отделение PMI, созданное в 1998-м, объединяет более 500 человек.

Конечно, привилегированное место среди стандартов управления проектами занимает PMBoK, разработанный PMI, который уже давно стал библией руководителей проектов в самых разных областях. PMBoK привлекателен тем, что сложную деятельность по управлению проектами, которую во многих случаях можно отнести к искусству, раскладывает на простые составляющие: процессы, этапы, роли. Таким образом, для руководителя проекта (РП) один сложный объект управления – проект – распадается на множество относительно простых и понятных объектов управления, которых в сложных проектах, правда, бывает очень много.

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

Да, говоря об ИТ-проектах, иногда время или деньги, например, важнее качества результата. Проект должен быть готов в запланированный срок, в частности, при открытии чего-то нового: офиса, сервиса, вывода нового продукта. Если вес ИТ в такой деятельности высок, то она вполне может подпадать под определение ИТ-проекта, данное в предыдущей статье.

Но в огромном количестве случаев важен именно результат проекта: ведь мы не просто так тратили время и ресурсы, а чего-то хотели достичь. ИТ-проекты в этом смысле интересны тем, что их цель довольно часто меняется по мере выполнения проекта и притом весьма существенно. Потому именно для этих проектов определить, достигли ли мы того, что нужно, довольно сложно. А вот посчитать, уложились ли мы в запланированные сроки, сколько потратили денег и человекочасов, намного проще. Так что упомянутый перекос, к сожалению, имеет довольно объективное обоснование. Пятая редакция PMBoK Guide 2012 появилась в 2012 году и была переведена на русский язык в начале 2014-го.

В PMBoK определены основные документы проекта:

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

Жизненный цикл проекта разделяется в PMBoK на пять вполне очевидных этапов, крайние – инициация и закрытие проекта – и циклические, которые могут повторяться не один раз, – планирование, выполнение и контроль (см. рис. 1).

В PMBoK 5 редакции 2012 года перечислены 10 областей знаний и 47 процессов. Следующая, шестая, версия ожидается в 2016 году.

В стандарте выделяются следующие области знаний:

• Управление интеграцией проекта. Под интеграцией проекта понимается объединение усилий различных групп лиц по выполнению проекта, достижение баланса между их подчас противоречивыми требованиями и интересами.
• Управление содержанием проекта. Основу этой области составляет процесс сбора требований и создания иерархической структуры работ (Work Breakdown Structure, WBS).
• Управление сроками проекта. Эта область занимается в основном планированием и разработкой расписаний, в частности, определением критических путей, составлением диаграммы Ганта, формированием диаграмм контрольных событий.
• Управление стоимостью проекта – это процессы управления бюджетом проекта.
• Управление качеством проекта отвечает за обеспечение качества результата проекта.
• Управление человеческими ресурсами проекта – это процессы управления организационной структурой проекта: командой проекта и всеми заинтересованными лицами.
• Управление коммуникациями проекта – важный блок процессов, занимающихся управлением распространения информации о проекте.
• Управление рисками проекта выявляет риски, вырабатывает методы их контроля, избегания и смягчения. В соответствии с PMBoK «Риск – это возможное незапланированное событие».
• Управление поставками проекта относится к специфическим процессам поставок и закупок, необходимых в рамках проекта.
• Управление заинтересованными сторонами проекта (было вычленено в отдельную область в пятой редакции). Охватывает процессы управления ожиданиями заинтересованных лиц.

47 процессов объединены в пять групп, соответствующих фазам жизненного цикла проекта, которые приведены на рис. 1. Формат статьи не позволяет подробно описать ни 47 процессов, ни структуру документов проекта. Отсылаю вас за этим к самому стандарту или, если переводить ближе к оригиналу, своду знаний.

PMI организовал сертификацию по PMBoK, которая весьма ценится, в частности, для руководителей проектов в области ИТ. Возможно, потому, что это единственная известная широкому кругу лиц сертификация в области управления проектами. В ней существуют различные уровни, необходимо определенное количество прослушанных по предмету учебных часов, некоторый опыт и сдача экзамена компьютеру. Экзамен состоит в выборе правильных ответов на поставленные вопросы.

Чтобы не возвращаться более к сертификации в этой области, хочу привести сомнения одного из основных авторов PMBoK в надежности этой системы сертификации, Билла Дункана. Он говорил, что любой выпускник, обладая небольшим опытом участия в проектах, имея неплохую память и заучив документацию, сможет получить сертификат руководителя проектов. А вот как он будет руководить проектами, это еще большой вопрос. Мне известна его попытка ввести другой принцип сертификации: на основании предоставления доказательств грамотного управления всеми процессами реального проекта в ходе устного экзамена одному из экспертов в этой области, но, насколько я знаю, она не прижилась (хотя у меня такой сертификат есть, экзамен я сдавала Биллу Дункану лично и этим горжусь).

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

Отечественный ГОСТ-Р 54869-2011 «Проектный менеджмент. Требования к управлению проектами» был введен в действие 1.09.2012, текст его был обновлен в 2013-м. Стандарт был разработан российскими экспертами в области управления проектами, объединившимися в Центр стандартизации управления проектами, и представляет собой облегченный вариант PMBoK. Приведу схему из этого стандарта, характеризующую связь между основными ролями проектного управления и их действиями.

Рисунок 2. Основные понятия проектного менеджмента и их взаимосвязь

Хотя стандарт вызвал большие замечания, он ценен уже как первый отечественный стандарт в этой области, в отличие от PMBoK, который в строгом смысле слова стандартом не является, а даже по названию представляет собой свод знаний. В дальнейшем появились также отечественные стандарты по управлению программами проектов – ГОСТ-Р 54871-2011 «Проектный менеджмент. Требования к управлению программой» и портфелями проектов – ГОСТ-Р 54870-2011 «Проектный менеджмент. Требования к управлению портфелем проектов».

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

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

Специализированные стандарты управления ИТ-проектами

Я рассмотрю две группы стандартов: на разработку программных систем и на внедрение крупных корпоративных систем, которые существуют практически у всех значительных вендоров ERP-систем. Обе эти группы опираются на два основополагающих международных стандарта в области создания систем и программных систем: ISO/IEC 15288 и ISO/IEC12207 (российский эквивалент ГОСТ-Р ИСО/МЭК 12207-2010). Хотя первые версии этих стандартов появились в конце прошлого века, они постоянно обновляются и отражают современный уровень развития технологий. Последние версии стандартов относятся к 2008 году. В них так же, как в PMBoK, выделяются группы процессов.

В таблице 1 приведены процессы жизненного цикла ПО из стандарта 12207.

Таблица 1. Процессы жизненного цикла ПО в ГОСТ-Р ИСО/МЭК 12207-2010

Вы можете заметить, что если часть процессов повторяет процессы PMBoK (в основном левая часть рисунка), то другая часть относится именно к ПО, например, группы процессов реализации ПС, поддержки ПС, повторного применения программных средств. Это один из доводов в пользу того, что PMBoK требует дополнения для использования в проектах ИТ, в частности, для разработки ПО.

Стандарты разработки ПО

Кроме вышеупомянутых стандартов ISO/IEC широкого применения, существует ряд популярных методологий разработки ПО, среди которых мне хочется выделить SWEBOK и PRINCE2 как получившие относительно широкое распространение в нашей стране.

Software Engineering Book of Knowledge (SWEBOK) – это свод знаний по программной инженерии, подготовленный в 2004 году IEEE Computer Society и принятый как стандарт ISO/IEC 9579 в 2004-м. Стандарт ISO/IEC 12207:2008 во многом использовал процессы, включенные в SWEBOK. Однако в SWEBOK они описаны намного подробнее. Хорошо то, что есть качественный перевод на русский язык, сделанный несколько лет назад Сергеем Орликом, что немало способствовало распространению этого стандарта в России.

PRINCE2, PRojects IN Controlled Environments 2 – это один из наиболее известных и популярных стандартов ведения ИТ-проектов. Он был разработан в 1989 году Central Computer and Telecommunications Agency (CCTA) Великобритании как стандарт для руководства проектами в области информационных технологий этой страны и является одним из самых первых стандартов в данной области. В настоящее время он широко используется и в других областях и является «de facto» стандартом для руководства проектами в Великобритании. В нем выделены семь принципов управления проектами:

• Постоянная оценка соответствия проекта потребностям бизнеса.
• Учет уроков проекта, «самообучение» проекта.
• Выделение определенных ролей с ответственностью и правами.
• Управление по фазам. Текущая фаза завершается планированием следующей.
• Управление по отклонениям. Каждая роль имеет полномочия на утверждение конкретных отклонений.
• Ориентация на результат. Главное – именно результат, а не процессы его достижения (в отличие, например, от PMBOK).
• Адаптация стандарта под конкретную организацию и внешнюю среду.

На рис. 3 приведены стадии проекта по созданию ПО в соответствии с PRINCE2.

Рисунок 3. Восемь стадий проекта в PRINCE2

Отечественные стандарты разработки ПО – это стандарты ГОСТ серий 19, 24 и 34. Наиболее известны ГОСТы 34, соответствия которым и сегодня требуют государственные структуры от поставщиков ПО. Обычно используются два стандарта этой серии: ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» и ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы», реже – ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем».

Как вы видите из названий, это ГОСТы 90-х годов прошлого века. Хотя качество их очень высокое, методы и средства разработки ПО за это время кардинально изменились: появилось объектно-ориентированное программирование, среды разработки. Так называемые каскадные или водопадные методы разработки, когда вначале собираются требования, создается и согласуется техническое задание, потом ведется разработка, тестирование и сдача ПО заказчику, работают плохо. Поэтому появились методы Agile Programming – гибкой разработки, среди которых наиболее известны Экстремальное программирование (Extreme programming) и Scrum. Эти методы ориентированы на создание ПО в тесном контакте с будущими пользователями, на постепенное наращивание его функционала, с тем, чтобы сократить время от создания до использования ПО. ГОСТы 34 плохо подходят для гибкой разработки, в то время как стандарты 12207 и 15288 учитывают ее особенности.

Стандарты внедрения корпоративных систем

Известно, что корпоративные системы, и прежде всего ERP-системы, трудно внедряются. Поэтому практически все вендоры, предлагающие свои системы, озабочены повышением количества успешных внедрений. Для достижения этой цели вместе с самими системами они предлагают методики внедрения, следование которым призвано упростить проект и повысить шансы на его успех. В частности, компания SAP для внедрения своей ERP-системы предлагает Accelerated SAP (ASAP), а компания ORACLE – Oracle Unified method (OUM). Есть свой метод внедрения 1С:УПП и у компании 1С – Технология быстрого результата, основанная, как видно даже из названия, на гибких методах внедрения.

Все эти методологии основаны на упоминавшихся уже стандартах ISO/IEC 12207 и 15288 и построены по схожему с другими методологиями управления проектами принципу: описываются основные процессы проекта на различных этапах его жизненного цикла. Эти методологии своевременно обновляютcя, в частности, сейчас используется ASAP 8.

Конечно, в рамках статьи трудно описать все многообразие стандартов управления ИТ-проектами, которые вы можете использовать для создания своего корпоративного стандарта. Вы можете выбрать те из них, которые в большей степени соответствуют вашей корпоративной культуре и выработавшейся практике разработки. Однако учтите, что не все из них согласуются между собой. В свое время крупный российский интегратор пригласил меня провести мастер-класс по переложению стандартов ASAP на ГОСТ 34, соответствия которому требовали их заказчики. Анализ показал, что это стандарты, хотя, к счастью, не противоречат друг другу, скорее лежат в разных плоскостях, и согласовать их очень непросто.

В любом случае трудно рассчитывать, что чужой опыт стандартизации будет полностью применим в вашей организации. Любые стандарты требуют анализа и адаптации. Успеха вам на этом пути!