Организация управления проектами разработки бизнес-приложений платежной системы РУРУ

Мухин А.Н.
выпускник группы ITM-23B
Школа IT-менеджмента
РАНХиГС при Президенте РФ

Универсальная платежная система RURU (ЗАО “НСК”) была создана в июне 2011-го года ОАО “ВымпелКом” (торговая марка “Билайн”) и ОАО “Альфа-Банк”.

Система позволяет осуществлять дистанционные платежи в пользу различных торгово-сервисных предприятий на основе технологий мобильной и электронной коммерции, электронных денег и банковских карт. С помощью RURU возможно оплатить широкий спектр товаров и услуг, выполнять денежные переводы на лицевые счета других абонентов сотовой связи, на электронные кошельки, на банковские карты, а также переводы, которые адресат сможет получить наличными в отделении систем денежных переводов. Оплата услуг производится с помощью сайтов RURU и “Билайн”, через платежные виджеты на сайтах партнеров, мобильные приложения, посредством SMS на короткие номера.

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

Цель работы – организация проектного управления в ЗАО “НСК” для повышения эффективности разработки функционала платежной системы.
Для выполнения поставленной задачи были проведен аудит зрелости бизнес-процессов и проектного управления в компании и намечен план мероприятий по организации процессов разработки с учетом проектной составляющей.
Внедрение первой фазы проектного управление планируется в ноябре 2013-го года.

Специфика работы компании – компания является платежным агрегатором, обеспечивающим оплату услуг электронной коммерции в B2B и B2C сегментах.

Объектом исследования в данной работе  стал процесс разработки программного обеспечения платежной системы RURU.

План действий

1. Проведение аудита зрелости компании.

Прежде чем производить какие-либо изменения требуется определить, в каком состоянии находится объект исследования в настоящий момент. Это важно как для понимания положения, так и для вовлечения в процесс коллег всех подразделений компании. Без ясной картины процессов в компании сложно объяснить необходимость введения изменений.

Процесс разработки исследовался с точки зрения нескольких аспектов:
Первое – это бизнес-архитектура компании. Форма бизнес-архитектуры определяется степенью неопределенности производственных отношений сотрудников компании и конечных результатов производства. Полученные выводы позволяют спрогнозировать необходимый уровень вовлеченности руководства компании и возможность построения проектного управления.

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

Третье – это оценка соответствия состояния процессов уровню 2 CMMi. Оценка CMMi в целом дала невысокие результаты, исключение составляет оценка конфигурационного менеджмента. Компании требуется выстраивание процессов в соответствии с требованиями, предъявляемыми к стандартным моделям.

1. Планирование и исполнение первой стадии организации проектного управления.

Аудит выявил три ключевых проблемы: отсутствие большинства базовых процессов в компании, функциональная организационная структура, и строгая водопадная модель процесса разработки. Устранение недостатков производится согласно следующему плану:

1. Провести первоначальные оценки и планирование.
2. Выполнить аудит текущих проектов и ресурсов.
3. Подготовить и согласовать концепции разработки.
4. Выбрать среду разработки и групповой работы.
5. Создать процедуры управления требованиями.
6. Создать процедуры планирования, контроля и мониторинга.
7. Создать процедуры управления изменениями.
8. Разработать и внедрить политики управления ресурсами.
9. Внедрить согласование бюджетов проектов.
10. Разработать и внедрить политики управления качеством.
11. Разработать и внедрить конфигурационные политики.
12. Разработать систему управления подрядчиками.
13. Выстроить политики коммуникации.
14. Внедрить процедуру сбора метрик и анализа.

Поскольку, в силу указанных выше особенностей, использование жестких методик разработки затруднено, было принято решение воспользоваться OpenUP.

OpenUP – это итеративно-инкрементальный метод разработки. Позиционируется как легкий и гибкий вариант RUP, делит жизненный цикл проекта на четыре фазы: начальная фаза, фаза уточнения, фаза конструирования, фаза передачи. Внутри жизненного цикла проекта создается набор контрольных точек (шлюзов), которые служат для ознакомления с результатами работы и принятия решений о дальнейших действиях. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План каждой итерации определяет, какие изменения должны быть выполнены по окончании, результатом является работоспособная версия продукта. Длительность каждой итерации обычно измеряется неделями и зависит от масштаба проекта. Можно сказать, что итерации в OpenUP – это повторение очень коротких, последовательных, определённых действий в строгом порядке.

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

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

Для отработки новой методики управления была создана “песочница” проектов, куда вошли задачи различных направлений: продуктового, коммерческого, технического.

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

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

Завершение первой стадии планируется в конце ноября 2013-го года. Результаты будут оцениваться с помощью повторной проверки по OPM3 и CMMi. На основании результатов принимается решение о необходимости и направлении дальнейшего развития проектного управления в компании.

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

Заключение
Выпускная квалификационная работа посвящена описанию процесса организации проектного управления в ЗАО “НСК”. В работе изложены теоретические основы, план мероприятий, указана конечная цель и ожидаемые результаты.

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