Файл: Разработка регламента выполнения процесса «Управление информационными ресурсами».pdf

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ПРЕДПОСЫЛКИ ИССЛЕДОВАНИЯ

1.1. Понятие проектного управления

Управление проектом (Project Management) – это применение знаний, методов и технологий при планировании и выполнении проекта для реализации ожиданий и требований участников проекта. Проект является объектом управления и представляет собой ограниченный по времени, бюджету, трудовым и материальным ресурсам комплекс задач и работ, ориентированный на достижение четко сформулированных целей. Проект – временное предприятие, направленное на создание уникального продукта, услуги или результата. (PMBoK 6, 2017).

В любой организации одновременно выполняется большое количество проектов, которые могут различаться по масштабу, типу и сложности выполнения. Таким образом, управление ресурсами – обязательная составляющая процессов любой компании. В течение многолетней практики проектного управления было сформировано большое количество стандартов управления ресурсами, а также требований к компетенциям менеджера и участников проектной команды. На сегодняшний день в мире используется большое количество нормативных документов, стандартов и рекомендаций, которые позволяют упорядочить и формализовать проектную деятельность. К наиболее крупным международным профессиональным ассоциациям относятся Американский институт управления ресурсами (Project Management Institute, PMI) и Международная организация по стандартизации (International Organization for Standardization, ISO).

Управление ресурсами окончательно сформировалось в качестве отдельной области знаний еще в 1950-х годах. Все началось с появления двух математических метода управления расписанием проектов — метод критического пути СРМ и метод оценки и анализа программ PERT. Несколькими годами позднее (1959) комитетом Андерсона (NASA) был предложен системный подход к управлению проектом по стадиям его жизненного цикла. В 1966 г. появляется система GERT (Graphical Evaluation and Review), Technique), использующая новую генерацию сетевых моделей. В 1981 г. в PMI) началась подготовка документа, содержащего методологические основы управления ресурсами, — «A Guide to the Project Management Body of Knowledge» (PMBОK Guide) или «Руководство к своду знаний по управлению ресурсами», который является актуальным на сегодняшний день и представляет собой руководство для менеджера проектов. В данном документе:

• формализуются и структурируются форматы проектной деятельности,
• описываются подходы к организации управления ресурсами,
• закрепляются понятия,
• определяются методы, которые можно применить в той или иной фазе проекта.

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

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

• ценность для бизнеса,
• срочность,
• сложность,
• число участников.

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

1. интеграция: комплекс мероприятий, направленных на управление ожиданиями заинтересованных сторон:
   1. пути поиска компромисса в случае возникновения конфликта;
   2. эффективное распределение проектных ресурсов;
   3. связи с другими областями знаний;
2. содержание: процессы определения перечня работ, которые необходимо выполнить;
3. сроки: процессы, обеспечивающие завершение работ проекта в указанные сроки:
   1. оценка трудозатрат;
   2. планирование ресурсов.
4. стоимость: процессы, обеспечивающие завершение работ в рамках запланированного и утвержденного бюджета:
   1. оценка стоимости работ;
   2. планирование бюджета.
5. качество: процессы, обеспечивающие соответствие задач проекта потребностям заинтересованных лиц;
6. человеческие ресурсы: процессы управления проектной командой;
7. коммуникации: процессы определения заинтересованных сторон и распространения необходимой информации между ними;
8. риски: процессы идентификации и анализа рисков, а также определения методов реагирования на них;
9. поставки: процессы приобретения необходимых материальных ресурсов у внешних организаций;
10. заинтересованные стороны: налаживание коммуникации между заинтересованными лицами и проектной командой.

В ходе доработки РМВОК (последняя актуальная версия руководства - шестая) его состав изменялся: изменения вносились в описание набора подходов, областей знаний и процессов. Вышедшая в 2017 году шестая версия РМВОК Guide была дополнена отдельным руководством с описанием гибких методологий – Agile Practice Guide, выпущенным совместно институтом PMI и Agile Alliance. Руководство Agile Practice Guide содержит описание всех основных методов и практик гибкого и включает в себя следующие разделы.

1. Введение в Agile.
2. Выбор жизненного цикла.
3. Реализация Agile. Создание среды Agile.
4. Реализация Agile. Поставка в среде Agile.
5. Организационные соображения для гибкости проекта.
6. Призыв к действию.

В практическом руководстве Agile Practice Guide подробно описано, как применять agile-подходы на проектах в различных предметных областях и использовать на практике современные инструменты, методы и фреймворки (Agile Practice Guide, 2017).

Не меньшей популярностью пользуются стандарты международной организации по стандартизации ISO – крупнейшей неправительственной организациии по разработке стандартов. Стандарты ISO, широко известные по всему миру, включают в себя общую терминологию и описание базовых принципов управления ресурсами и используются компаниями, которые реализуют проекты с зарубежными клиентами и партнерами. На сегодняшний день наиболее популярным международным стандартом ISO в области проектного управления является ISO 21500:2012 «Руководство по менеджменту проектов», который входит в новую серию стандартов «Руководство по управлению ресурсами» (Guidance on project management) и является базовым нормативным документом, регламентирующим проектное управление на международном уровне (Зиядуллаев, Фридлянов, 2017).

Развитием стандартов проектного управления в России занимается автономная некоммерческая организация «Центр оценки и развития проектного управления» (АНО «ЦОРПУ»). В ЦОРПУ постоянно проводятся исследования, направленные на расширение набора государственных стандартов (ГОСТов), на данный момент широкое применение в стране получили перечисленные ниже стандарты (АНО «ЦОРПУ», 2020).

1. ГОСТ Р 54869 – 2011 «Проектный менеджмент. Требования к управлению проектом»: устанавливает требования к управлению проекта от его старта до завершения.
2. ГОСТ Р 54871 – 2011 «Проектный менеджмент. Требования к управлению программой»: устанавливает требования к управлению программой на этапах ее формирования и реализации.
3. ГОСТ Р 54870 – 2011 «Проектный менеджмент. Требования к управлению портфелем проектов»: устанавливает требования к управлению портфелем проектов на этапах его формирования и реализации.
4. ГОСТ Р 58305 - 2018 «Система менеджмента проектной деятельности. Проектный офис»: устанавливает цели, задачи, типы и функции проектных офисов.
5. ГОСТ Р 58184 - 2018 «Система менеджмента проектной деятельности. Основные положения»: устанавливает основные положения для систем менеджмента проектной деятельности в организациях.

1.2. Понятие гибких методологий управления ресурсами

Переход к управлению ресурсами с использованием гибких методологий (Agile) является основным трендом в проектном управлении уже на протяжении нескольких лет. Agile – семейство гибких подходов (методологий) к разработке программного обеспечения (Rusbase, 2018). Изначально Agile появился в IT сфере, но позже распространился и в другие сферы, например, машинное обучение и искусственный интеллект. Методики Agile ориентированы на постоянно изменяющиеся условия внешней и внутренней среды, требования заказчиков и потребности конечных пользователей. Согласно этим методологиям, проект необходимо разбивать на отдельные краткосрочные итерации длительностью не более 1 месяца, в конце каждой итерации необходимо получать новую работающую версию продукта, которую можно продемонстрировать заказчику и получить обратную связь. После анализа обратной связи могут быть внесены необходимые правки в продукт. Цель Agile – разработать наиболее эффективный и полезный для бизнеса продукт.

За последний год в компаниях уже практически не осталось проектов, рассчитанных более чем на два года, так как за это время первоначальные требования могут кардинально измениться, и на выходе получится бесполезный продукт.

В 2001 году группой энтузиастов, применяющих гибкие методики программирования, была выпущена декларация разработчиков ПО – agile-манифест разработки программного обеспечения, который включает в себя 4 ключевых ценности любой гибкой методологии:

1. Люди и взаимодействие важнее процессов и инструментов
2. Работающий продукт важнее исчерпывающей документации
3. Сотрудничество с заказчиком важнее согласования условий контракта
4. Готовность к изменениям важнее следования первоначальному плану

Манифест содержит важное дополнение к списку ценностей: «То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева» (Agile-манифест, 2001). Это значит, что не стоит пренебрегать такими аспектами, как проектная документация, процессы и инструменты, но основной фокус в гибких методологиях находится не на них.

Согласно гибким методологиям, проекты по разработке ПО состоят из семи «измерений» (Аппело, 2011).

1. Люди: ценность составляют не таланты отдельных людей, а создание кросс-функциональной команды, суммарные компетенции участников которой позволяют качественно реализовать проект.
2. Функциональность: постоянное взаимодействие с заказчиком позволяет постоянно поддерживать функциональные требования в актуальном виде;
3. Качество: контроль качества выполнения задач проводится на всех этапах разработки.
4. Инструменты: повторяющиеся рутинные операции должны быть автоматизированы, чтобы участники команды не тратили на них время.
5. Время: длина итерации и частота релизов определяется участниками команды совместно с заказчиком.
6. Ценность: ценность ПО для клиента определяется наиболее быстрой и качественной реализацией новой функциональности. Функциональность должна быть реализована как можно скорее после того, как была выявлена потребность в ней.
7. Процесс: основные процессы в гибких методологиях – это планирование, ежедневное личное общение участников команды и контроль выполнения задач проекта.

1.3. Обзор существующих гибких методологий

Первая гибкая методология управления ИТ-ресурсами появилась в начале 1990-х. Называлась эта методология «Быстрая разработка приложений» (Rapid Application Development, RAD) и заключалась в сочетании стандартных формализованных подходов методики Waterfall (актуализация технической документации, четкое планирование последовательных стадий проекта) с практикой создания прототипов, версионностью выпускаемого продукта и более тесного общения с заказчиком (Аппело, 2011). Позднее появились и другие гибкие методологии, такие как:

• эволюционное управление разработкой (Evo) (1988): проект разделен на этапы реализации – эволюции, каждая из которых планируется на основании результатов предыдущей эволюции (Habr, 2015);
• Scrum (1995) – фреймворк процесса разработки с участием одной команды; проект реализовывается итерационно, по итогу каждой итерации должна быть представлена новая работоспособная версия продукта (Rusbase, 2017);
• методы разработки динамических систем (DSDM) (1995): заказчик является частью команды и непрерывно участвует в процессе анализа и согласования требований (Аппело, 2011);
• методы Crystal (1997) – семейство методологий, предусматривающих выбор средств обеспечения строгости методологии в зависимости от размера и критичности проекта (Agile Practice Guide, 2017). Основная цель методики – «Кристально чистое» выполнение задач проекта, которое достигается с помощью непрерывной рефлексии по поводу состояния проекта, что в свою очередь позволяет выбрать наиболее правильные и эффективные способы реализации (Winfox, 2014);
• экстремальное программирование (XP) (1999) – методология разработки программного обеспечения, основанная на частом повторении циклов разработки (Agile Practice Guide, 2017). В методологии активно применяются такие практики, как парное программирование, разработка через тестирование (разработчик сначала пишет тесты, а потом код программы), свободный доступ всех разработчиков к коду своих коллег, непрерывная доработка кода (Skillbox, 2018);
• адаптивная разработка ПО (ASD) (2000): основу методологии составляют три нелинейные фазы: обдумывание, сотрудничество и обучение; они относятся к каждому периоду разработки, который завершается выпуском релиза. Отклонения от плана не считаются ошибками, а наоборот, они ведут к новым, более верным решениям (Интуит, 2004).