МЕТОДОЛОГИИ УПРАВЛЕНИЯ IT ПРОЕКТАМИ

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

Управление проектом (Project Management) - использование знаний, навыков, методов, средств и технологий при выполнении проекта с целью достижения или превышения ожиданий участников проекта.

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

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

Некоторые походы пригодны не только управлению ИТ проектами, но и проектами вообще.

Методологии в проектном менеджменте, при правильном использовании, снижают неопределенность.

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

Универсальные знания и методы управления проектами позволяют решать такие задачи, как:

• определение целей проекта;

• подготовка обоснования проекта;

• его структурирование (подцели, подпроекты, фазы и т.д.);

• определение финансовых потребностей и источников финансирования;

• подбор поставщиков, подрядчиков и других исполнителей (на основе процедур торгов и конкурсов);

• подготовка и заключение контрактов;

• расчет сметы и бюджета проекта;

• определение сроков выполнения проекта и разработка графика реализации;

• контроль за ходом выполнения проекта и внесения корректив в план реализации;

• управление рисками в проекте;

• обеспечение контроля за ходом выполнения проекта.

Cуществует два вида или уровня методологии управления проектами:

• Project Management Processes – Процессы управления проектом

• Project Life Cycle – Жизненный цикл проекта

Project Management Processes . Сюда относятся стандарты подходящие для любого проекта из любой отрасли – они описывают подход в целом к управлению проектами. Обычно содержат список высокоуровневых процессов, техник и артефактов которые желательны на проекте. К данному виду стандартов относятся PMI PMBOK, IPMA ICB, PRINCE2, SWEBOK и ряд других менее известных. Наиболее распространенный и широко применяемый в мире - PMBOK. По PMBOK есть программа сертификации PMP – наиболее котируемый сертификат в области управления проектами.

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

В отрасли разработки ПО к данному виду стандартов относятся: Waterfall; Agile и его разновидности: SCRUM, Lean, Kanban, XP...; MSF, RUP и другие. Наиболее популярным среди них является SCRUM.

Методология Scrum - одна из самых популярных методологий гибкой разработки. Одна из причин ее популярности - простота.

В методологии Scrum всего три роли:

• Scrum Master

• Product Owner

• Team

Скрам Мастер (Scrum Master) - самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды.

В Agile команда является самоорганизующейся и самоуправлямой.

Основные обязанности Скрам Мастера таковы:

• Создает атмосферу доверия,

• Участвует в митингах в качестве фасилитатора

• Устраняет препятствия

• Делает проблемы и открытые вопросы видимыми

• Отвечает за соблюдение практик и процесса в команде

• Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте.

ScrumMaster может также помогать Product Owner создавать Backlog для команды.

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

Обязанности Product Owner таковы:

• Отвечает за формирование product vision

• Управляет ROI

• Управляет ожиданиями заказчиков и всех заинтересованных лиц

• Координирует и приоритизирует Product backlog

• Предоставляет понятные и тестируемые требования команде

• Взаимодействует с командой и заказчиком

• Отвечает за приемку кода в конце каждой итерации.

Product Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.

Команда (Team). В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды.

Обязанности команды таковы:

• Отвечает за оценку элементов баклога

• Принимает решение по дизайну и имплементации

• Разрабатывает софт и предоставляет его заказчику

• Отслеживает собственный прогресс (вместе со Скрам Мастером).

• Отвечает за результат перед Product Owner

Размер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды - 7 плюс минус 2.

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

Для облегчения коммуникаций команда должна находиться в одном месте (colocated). Предпочтительно размещать команду не в кубиках, а в одной общей комнате для того, чтобы уменьшить препятствия для свободного общения. Команде необходимо предоставить все необходимое для комфортной работы, обеспечить досками и флипчартами, предоставить все необходимые инструменты и среду для работы.

В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней). Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику). Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности. Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов.

Каждый спринт представляет собой маленький "водопад". В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда.

Остановка спринта (Sprint Abnormal Termination)

Остановка спринта производится в исключительных ситуациях. Спринт может быть остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить Product Owner, если необходимость в достижении цели спринта исчезла.

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

Команда демонстрирует инкремент продукта, созданный за последний спринт. Product Owner, менеджмент, заказчики, пользователи, в свою очередь, его оценивают. Команда рассказывает о поставленных задачах, о том как они были решены, какие препятствия были у них на пути, какие были приняты решения, какие проблемы остались нерешенными. На основании ревью принимающая сторона может сделать выводы о том, как должна дальше развиваться система. Участники миитинга делают выводы о том, как шел процесс в команде и предлагает решения по его улучшению.

Скрам Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить адженду и распланировать кто и в какой последовательности что представляет.

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

В условиях роста конкуренции применение методологии управления проектами становится необходимым элементом бизнес-процессов.

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

Литература:

1. Н.М. Светлов, Г.Н. Светлова. Информационные технологии управления проектами: Учебное пособие. М.: ФГОУ ВПО РГАУ–МСХА им. К.А. Тимирязева, 2007.

2. Грекул В. И., Коровкина Н. Л., Куприянов Ю. В. Основы информационных технологий. Методические основы управления ИТ-проектами. Издательство: ИНТУИТ, БИНОМ. Год издания: 2011