Поиск по сайту
 bit.samag.ru     Web
Рассылка Subscribe.ru
подписаться письмом
Вход в систему
 Запомнить меня
Регистрация
Забыли пароль?
Календарь мероприятий
август    2017
Пн
Вт
Ср
Чт
Пт
Сб
Вс
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

показать все 

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

22.08.2017

Ведущий ИТ-еженедельник PC Week приглашает вас на 5-й ежегодный Russian Enterprise Content Summit 2017 (RECS’2017), который пройдет 19 сентября в Москве, в отеле «Марриотт Аврора».

Читать далее 

22.08.2017

Delta Electronics обеспечила источниками бесперебойного питания «Монди Сыктывкарский ЛПК»

Читать далее 

22.08.2017

Форум ПРОSTOR, крупнейшее в Восточной Европе событие, посвященное технологиям СХД, проходит в Москве

Читать далее 

17.08.2017

29 сентября Санкт-Петербург во второй раз примет Fresh Russian Communications Conference 2017

Читать далее 

17.08.2017

Антон Мелехов расскажет о работе с ретаргетингом в e-commerce на RACE 2017

Читать далее 

17.08.2017

Эксперты обсудят блокчейн, криптовалюты и ICO на Blockchain & Bitcoin Conference Almaty

Читать далее 

17.08.2017

Конференция «Цифровая трансформация ЖКХ в рамках программы Развития цифровой экономики в России – Digital Housing & Utilites 2017»

Читать далее 

показать все 

Статьи

22.06.2017

Опрос. Уроки WannaCry

Читать далее 

22.06.2017

Что такое кастомизация, или Прежде, чем продать что-нибудь ненужное, нужно сначала это ненужное создать!

Читать далее 

22.06.2017

Хорошая ли сделка?

Читать далее 

17.05.2017

Корпоративная мобильность в России, или О чем свидетельствуют цифры?

Читать далее 

17.05.2017

Зачем вести переговоры с коллегами?

Читать далее 

21.04.2017

Язык цифр или внутренний голос?

Читать далее 

16.04.2017

Планы – ничто, планирование – все. Только 22% компаний довольны своими инструментами для бизнес-планирования

Читать далее 

16.04.2017

Цифровизация экономики

Читать далее 

23.03.2017

Сервисная компания – фея или Золушка?

Читать далее 

17.02.2017

Информационные технологии-2017

Читать далее 

показать все 

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

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

В начало⇑

 

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

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

Выпуск №06 (69) 2017г.
Выпуск №06 (69) 2017г. Выпуск №05 (68) 2017г. Выпуск №04 (67) 2017г. Выпуск №03 (66) 2017г. Выпуск №02 (65) 2017г. Выпуск №01 (64) 2017г.

Телеканал «Про Бизнес», программы «Технологии в ритейле»

           

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

 

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

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