Не меняйте проекты, как перчатки. Часть 2::БИТ 04.2015
 
                 
Поиск по сайту
 bit.samag.ru     Web
Рассылка Subscribe.ru
подписаться письмом
Вход в систему
 Запомнить меня
Регистрация
Забыли пароль?

Календарь мероприятий
декабрь    2023
Пн
Вт
Ср
Чт
Пт
Сб
Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

показать все 

Новости партнеров

08.12.2023

Опубликован шорт-лист «Премии Рунета 2023» 

Читать далее 

05.12.2023

Ассоциация «Цифровой транспорт и логистика» предлагает выпустить серию почтовых марок о беспилотном транспорте

Читать далее 

01.12.2023

X Международный конгресс SMART RUSSIA

Читать далее 

27.11.2023

В Москве наградили победителей Международного хакатона по искусственному интеллекту 

Читать далее 

показать все 

Статьи

21.11.2023

Как вы оцениваете развитие инфраструктурного ПО в России?

Читать далее 

22.09.2023

Эпоха российской ориентации на Запад в сфере программного обеспечения завершилась

Читать далее 

22.09.2023

Сладкая жизнь

Читать далее 

22.09.2023

12 бизнес-концепций, которыми должны овладеть ИТ-руководители

Читать далее 

22.09.2023

Проще, чем кажется. Эталонная модель документооборота или краткое руководство по цифровой трансформации

Читать далее 

22.09.2023

Какие hard skills вам нужны?

Читать далее 

22.09.2023

Какие hard skills вам нужны?

Читать далее 

25.07.2023

Как изменится ИТ-мир через 35 лет?

Читать далее 

25.07.2023

Тотальный контроль или разумная опека?

Читать далее 

03.07.2023

Property technologies: тренды и инновации

Читать далее 

показать все 

Не меняйте проекты, как перчатки. Часть 2

Главная / Архив номеров / 2015 / Выпуск №4 (47) / Не меняйте проекты, как перчатки. Часть 2

Рубрика: Управление проектами


Марина Аншинапредседатель Комитета по стандартам, Российский Союз ИТ-директоров

Не меняйте проекты, как перчатки

Часть 2. Ландшафт современных стандартов, связанных с управлением проектами ИТ

Проект ИТ мероприятие не самое простое, что видно хотя бы из статистики их выполнения, которая может либо огорчать, либо удручать, либо и то и другое. По различным оценкам неуспехи ИТ-проектов достигают 60-80%. Поэтому использование стандартов хотя законом и не требуется, но практически обязательно. Слишком тонкая и сложная это материя, чтобы можно было в разумный срок учесть в договоре все нюансы.

 

Начну от печки с определения, что такое стандарт. В соответствии с Федеральным законом РФ о техническом регулировании стандарт это «Документ, в котором в целях добровольного многократного использования устанавливаются характеристики продукции, правила осуществления и характеристики процессов производства, эксплуатации, хранения, перевозки, реализации и утилизации, выполнения работ или оказания услуг. Стандарт также может содержать требования к терминологии, символике, упаковке, маркировке или этикеткам и правилам их нанесения», 27 декабря 2002 года №184-ФЗ.

Обращаю ваше внимание на слово «добровольного». Таким образом, практически все стандарты ИТ, кроме нескольких, к которым, в частности, относится ФЗ-152 Закон о персональных данных, можно использовать, а можно и не использовать. На первый взгляд кажется, что не использовать намного проще.А поскольку всякий разумный человек, не обладающий явной склонностью к мазохизму, будет решать задачу, в данном случае делать проект, максимально простым способом, то многие так и живут без стандартов. Причем некоторым из них кажется, что живут они хорошо.

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

Все стандарты по управлению проектами ИТ можно разделить на две группы:

  • Общие стандарты управления проектами, которые применимы для ИТ-проектов.
  • Стандарты управления группами ИТ-проектов, среди которых выделяются стандарты проектов разработки ПО и стандарты проектов внедрения крупных корпоративных систем.

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

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

  • Международная ассоциация управления проектами (Швейцария) (англ. 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).

Не меняйте проекты, как перчатки

Рисунок 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. Основные понятия проектного менеджмента и их взаимосвязь

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

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

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

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

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

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

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

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

Таблица 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, соответствия которому требовали их заказчики. Анализ показал, что это стандарты, хотя, к счастью, не противоречат друг другу, скорее лежат в разных плоскостях, и согласовать их очень непросто.

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

В начало⇑

 

Комментарии отсутствуют

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

Выпуск №08 (131) 2023г.
Выпуск №08 (131) 2023г. Выпуск №7 (130) 2023г. Выпуск №6 (129) 2023г. Выпуск №5 (128) 2023г. Выпуск №4 (127) 2023г. Выпуск №3 (126) 2023г. Выпуск №2 (125) 2023г. Выпуск №1 (124) 2023г.
Вакансии на сайте Jooble

           

Tel.: (499) 277-12-41  Fax: (499) 277-12-45  E-mail: sa@samag.ru

 

Copyright © Системный администратор

  Яндекс.Метрика