Файл: Управление проектом внедрения специализированного программного обеспечения в Банк.docx

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

1. 
   Главным критерием успешности проекта являлось качество. Под качеством будет подразумеваться возможность выявления и исправления ошибок на ранних этапах проекта, а также полное соответствие результатов проекта требованиям заказчика. Так как внедряемое программное обеспечение в будущем должно автоматически оценивать клиентов банка, при внедрении проекта было необходимо минимизировать операционные риски, которые могли бы возникнуть в дальнейшем. Как результат, длительность и бюджет проекта автоматически увеличивались из-за постоянных доработок программного обеспечения. Это означает, что для заказчика качество было ключевым моментом, ради которого он готов был пожертвовать длительностью и бюджетом;
   
2. 
   В середине и конце проекта команда разработчиков находилась в постоянно стрессовом состоянии, так как отсутствие коммуникации с другими работниками повлекло за собой субъективное понимание технического задания. В результате менеджером проекта было решено назначить им дополнительный объем работу за счет Банка, но, несмотря на это, производительность работников была ниже предполагаемой из-за человеческого фактора;
   
3. 
   Отклонение по времени составляет 88,5 дней (в базовом плане предполагалось 102,5 дней, фактически вышло 191 день);
   
4. 
   В плане предполагалась стоимость проекта равная 937 600 рублям, фактическая составила 1 465 600 рублей, из которых 323 200 рублей – запросы на изменения, соответственно, стоимость проекта для Банка равняется 1 260 800 рублям (рисунок 20):
   
   

Рис. 20 Сравнение затрат

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

---

Таким образом, чтобы действительно достичь более или менее желаемый уровень качества, длительность проекта пришлось увеличить на 86,3%, а стоимость на 34,5%.

Введем следующие обозначения:

,


.

Банк и менеджер проекта внедрения (представитель компании-Исполнителя) стремятся минимизировать возможные, нежелательные отклонения от требуемого качества (то есть, целевой результат подразумевает соответствие продукта ожиданиям заказчика), следовательно, для того, чтобы минимизировать отклонения по качеству (которое было выбрано наиболее приоритетным из всех критериев проекта), длительность проекта и его бюджет пришлось увеличить:

---

3.3. Моделирование и анализ внедрения проекта с помощью «гибкой» методологии «скрам»

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

Процесс моделирования можно описать следующим образом:

(1) Вводятся предпосылки, уравновешивающие проектируемую модель с реальной ситуацией:

1. 
   Производительности команд при использовании методологии «скрам» и водопадной модели равны;
   
2. 
   Количество специалистов той или иной области в двух проектах одинаково, и оно приведено на рисунке 21:
   
   
   

Рис. 21 Ресурсы

3. 
   Время выполнения задач при использовании методологии «скрам» включает время проведения командой совещаний, что является тоже оплачиваемым заказчиком;
   
4. 
   Сбор новых требований не занимает дополнительного времени, а происходит в течение «спринта»;
   
5. 
   Внедрение программы происходит непосредственно в офисе банка, то есть для качественного применения методологии «скрам» лучше избегать удаленной работы.
   

(2) Описывается хронология ведения проекта и формализация действий:

Перед официальным началом проекта организовывается встреча представителя со стороны заказчика (Владельца продукта), которым является сотрудник отдела рисков, Скрам-мастера и Скрам-команды для обсуждения общего видения проекта. Обсуждается программа, которая будет внедряться, Скрам-командой происходит осознание базовых моментов, которые желает наблюдать заказчик. Заказчик, в свою очередь, пытается понять специфику программного обеспечения и принципы работы Скрам-команды. В течение этого времени (7-ми дней) происходит обмен общими договоренностями и обещаниями (например, участники проекта приходят к выводу о документировании каких-либо справочных значений).

«Скрам»-проект будет проходить следующим образом:

• 
  Владелец Продукта подготавливает к каждому спринту журнал продукта, отсортированный по приоритету;
  
• 
  Каждый спринт начинается с его планирования, т.е. команда определяет количество времени, которое необходимо каждому участнику для выполнения заданий из журнала продукта;
  
• 
  Выбранные задания из журнала продукта переносятся в журнал спринта и, если надо, детализируются разработчиками;
  
• 
  Во время планирования спринта участники команды обсуждают общую идею выполнения задач, их коррелированность с другими специалистами и прочее;
  
• 
  В течение спринта команда выполняет задания, каждый день отчитываясь друг другу о выполненной работе во время ежедневного совещания;
  
• 
  Выполнение сроков совещаний, а также поддержание атмосферы в команде обеспечивает Скрам-мастер;
  
• 
  В конце спринта команда демонстрирует настроенный функционал Скрам-мастеру, Владельцу продукта и любым желающим со стороны заказчика (например, топ-менеджменту Банка);
  
• 
  Если Скрам-команда не успевает сделать задание за один спринт, то, в случае мелких недочетов, спринт может задержаться на пару дней, а в случае крупных недоработок это же задание выносится снова в журнал продукта;
  
• 
  В течение спринта у Владельца продукта могут появиться новые требования к программному обеспечению, которые он должен записывать в журнал продукта, после чего он дожидается встречи по планированию нового спринта для того, чтобы внести изменения в работу.
  

---

(3) Оценка базовой длительности задач, описанных с помощью методологии «скрам»:

Согласно методологии «скрам» команда разработчиков сама оценивает время, которое им может потребоваться для выполнения задач. Для моделирования проекта был проведен экспертный опрос разработчиков рассматриваемого IT-проекта для выявления предполагаемой длительности и максимально возможных отклонений. Им была объяснена идея внедрения программного обеспечения по итерациям с помощью методологии «скрам» и был продемонстрирован пример журнала продукта с базовыми требованиями от заказчика, отсортированный по убыванию важности для бизнеса на момент составления:

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

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

При проведении опроса разработчики были предупреждены, что каждая итерация длится 14-30 дней, на что они впоследствии делали упор при моделировании. Таким образом, на самую первую итерацию (то есть, в журнал спринта) разработчики назначили первую задачу из журнала продукта и часть второй (рисунок 22). План проекта строился с помощью дополнения к программному обеспечению

---

Microsoft Office Project 2010, которое называется Scrum Tool, которое просто помогает формализовать процесс.



Рис. 22 Моделирование первого спринта

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

С учетом важных изменений в требованиях, которые были описаны при рассмотрении плана проекта, построенного с помощью водопадной модели, был смоделирован финальный журнал продукта (после завершения проекта) (рисунок 23):



Рис. 23 Состояние журнала продукта в конце проекта

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

Важно отметить, что журнал продукта представляет собой требования заказчика, написанные понятным ему языком, («функциональность проверки внешней кредитной истории клиента», «добавить влияние наличия дополнительных кредитных услуг при проверки необходимости пересмотра заявки»), в отличие от этапов водопадной модели, составленных менеджером проекта, который больше ориентировался на понимание этапов своей командой («разработка схемы XSD модели данных», «программирование стратегии в ИС»). Подробное описание бизнес-требований снижает риск отклонения от желаемого заказчиком качества, когда речь идет о соответствии его требованиям (т. е. ).

Таким образом, смоделированный полноценный проект приведен на рисунке 24 (проект с детализацией задач приведен в Приложении 1):

---