53
Глава 3. Разработка рекомендаций по совершенствованию
управления рисками на предприятииООО «Айбраш»
3.1 Расчет показателей эффективности инвестиционного проекта
Экономическая оценка проекта занимает одно из ключевых мест в
процессе обоснования вариантов вложения средств. Для того, чтобы оценить
эффективность проекта, в общем смысле, необходимо соотнести затраты на
егореализацию с доходами, которые в перспективе может получить
компания.
Экономический смысл применения Scrum-методологии состоит в том,
что функциональность конечного продукта создается последовательно, а
оплата решения производится заказчиком по частям. Таким образом,
инвестиции разработчика в создание информационной системы окупаются
быстрее, а кроме того, снижаются риски неплатежей со стороны заказчика.
Как было неоднократно отмечено ранее, применение гибкой
методологии управления проектами Скрам целесообразно тем, что уточнение
и демонстрация очередной версии продукта происходит довольно часто,
после окончания очередной итерации. При таком подходе, очевидно, что
возникающие на ранних этапах ошибки могут быть сразу же исправлены (в
отличие от традиционных методологий, где ошибки можно обнаружить
только на этапе тестирования). Кроме того, получаемый в конце проекта
продукт больше соответствует требованиям заказчика. Соответственно,
оперируя данными суждениями, можно отметить, что отклонение по
качеству продукта, полученного с помощью Scrumнамного меньше
отклонения по качеству продукта, полученного с помощью традиционной
организации проектной деятельности. Для заказчика и исполнителя выгода
очевидна: проект внедряется быстрее, качественнее и с меньшими затратами
по сравнению с традиционным методом.
Помимо этого стоит отметить, что компании, сосредотачивающие
внимание на данных принципах и эффективно использующие методологии
54
гибкого управления проектами , добиваются следующих результатов:
- имеют в 2,5 раза больше успешно реализованных проектов;
- и достигают изначальных целей в 3 раза чаще;
- тратят в 13 раз меньше средств на непосредственную реализацию
проектов;
- имеют высокий уровень мотивации и производительности
сотрудников;
- на 15% чаще полностью укладываются в бюджет проекта;
- на 15% чаще реализуют проекты к изначально установленному сроку.
Следовательно, помимо того, что проект в перспективном будущем
способен полностью окупить затраченные средства на него, он также имеет
возможность создать для компании устойчивое конкурентное преимущество,
оказав влияние как на персонал организации, так и на эффективность работы
компании в целом.
Анализируя внедрение Скрам в веб - студии « Айбраш» можно
сформировать основные решение, которые предлагает методология Скрам по
выявленным проблемам в области управления проектами в организации.
Таблица 6
Решение выявленных проблем в проектной деятельности
организации
№
Область
возникновен
и
я
Описание проблемы
Предлагаемое решение
1
Управление
коммуникаци
ями
Низкая частота
коммуникации
Ежедневные митинги
Отсутствие нацеленности на
результат
За счет ежедневных встреч
информация по проекту у
исполнителя будет в целом по
проекту, а не только отдельная
часть
2
Управление
командой
проекта
Отсутствие боевого
командного духа
Совместная работа в рамках
первых спринтов
Проведение тренингов и игр с
целью сплочения команды
Отсутствие целостной
картины по проекту
исполнителей
Организация инспекций по
задачам; Применение практики
коллективного владения кодом.
55
Отсутствие обмена опытом
между частями команды
Работа в скрам - команде
предполагает постоянно
обсуждение
задач и взаимопомощь
3
Управление
сроками и
содержанием
Длительный период
разработки перед первым
показом результата проекта
заказчику
Результаты работ будут
демонстрироваться заказчику
после каждой итерации в течении
1- 2 недель
4
Управление
качеством
проекта
Сложность контроля
качества программного
продукта
Организация инспекций по
задачам
Применение практики
коллективного владения кодом
Проведение обзоров спринтов и
ретроспектив
5
Управление
заинтересова
нными
сторонами
Процесс реализации не
прозрачен для заказчика
После каждого спринта будет
проводиться демонстрация
разработанного функциоанала
заказчику
Низкое взаимодействие с
заказчиком по проекту
Это проблема исчезает за счет
проведение демонстрации по
результатам работ в рамках
итерации
Для оценки экономического эффекта от применения методологии
Скрам рассмотрим реализацию проекта по созданию мобильного
приложения для магазина профессиональной косметики «Каприз». При этом
будет использована традиционная, водопадная модели и параллельно будет
рассматриваться аналогичный проект по разработке мобильного приложения,
заказанный другим клиентом, с некритичным изменением функционала,
реализованный помощью методологии Скрам.
1. Реализация проекта с использованием «водопадной» модели
жизненного цикла.
После того, как менеджером проекта и командой проекта были начаты
работы по проектированию мобильного приложения, оказалось, что сроки
выполнения задач постоянно сдвигаются, причем вслед за задачей,
выполняемой с увеличением базового срока, сдвигается начало выполнения
всех последующих задач. Во время реализации проекта фиксировалась
фактическая длительность каждой задачи, после чего был построен реальный
календарный план. Сравнение запланированных и фактических сроков
56
выполнения проекта в процессе выполнения работ продемонстрировано в
таблице 7.
Таблица 7
Сравнение запланированных и фактических сроков проекта по
разработке мобильного приложения для магазина Каприз
Задачи
Базовое
начало
Базовое
окончани
е
Фактиче
ское
начало
Фактическ
ое
окончание
Базовая
длительн
о
сть, день
Фактическая
Длительност
ь
, дней
Проектирование
01.03.20
20.03.20
01.03.20
29.03.20
14
21
Дизайн
22.03.20
05.03.20
30.03.20
12.03.20
10
14
Написание тех.
задания
заказчиком
06.04.20
13.04.20
12.03.20
03.05.20
5
15
Разработка API
заказчиком
20.04.20
08.05.20
04.05.20
25.05.20
15
25
Разработка МП
09.05.20
09.05.20
25.05.20
20.06.20
20
25
Итого:
64
100
Все задачи имели существенные отклонения по длительности, что
повлекло за собой задержку срока сдачи проекта и увеличение стоимости
проекта. С помощью наблюдения за ходом выполнения проекта были
выявлены и систематизированы причины задержек задач проекта.
Задача «Проектирование мобильного приложения». Базовая
длительность предполагалась равной 14 дням, фактическая составила 21
день. Длительное формирование требований, стремление к минимизации
рисков путем полной аналитики возможных разногласий в будущем привело
к задержке момента согласования финального прототипа и готовности
приступить к следующему этапу. Продолжительное время вносились
корректировки и добавления в прототип, а как следствие, в требования к
мобильному приложению.
Задача «Дизайн мобильного приложения». Базовая длительность
предполагалась равной 10 дням, фактическая составила 14 дней. Во время
57
предыдущего этапа директор компании заказчика не участвовал в
формировании требований к мобильному приложению, но на текущем этапе
он решил внести собственные пожелания. На данном этапе оформлялась
визуализация мобильного приложения, вносились многочисленные
корректировки по желанию заказчика, что повлекло за собой задержку
сроков. Утверждение прототипа, как оказалось, было условным поскольку
визуальное представление прототипов воспринималось иначе и не совсем
удовлетворила первоначальной идеи заказчика.
Задача «Подготовка Технического задания заказчиком». Базовая
длительность предполагалась равной 5 дням, фактическая составила 15 дней.
Задержку на данном этапе спровоцировала неопределенность заказчика в
своих требованиях к конечному продукту, а также непонимание
необходимости данного этапа в целом в процессе работы.
Задача «Разработка APIзаказчиком». Базовая длительность
предполагалась равной 15 дням, фактическая составила 25 дня. На данном
этапе заказчик должен был разработать API(интерфейс взаимодействия
между сервером заказчика и мобильным приложением). Но в виду высокой
загрузки ответственных программистов на других проектах и
неопределенности функционала мобильного приложения на данном этапе
произошла задержка. В виду задержки предоставления заказчиком
работоспособного APIменеджер проекта вынужден был направить
разработчика на выполнение другого проекта сроком на 27 дней.
Задача «Разработка мобильного приложения». Базовая длительность
предполагалась равной 20 дням, фактическая составила 25 дня. На данном
этапе задержка была спровоцирована не готовностью API, а также разным
толкованием технического задания (ТЗ) исполнителем и заказчиком.
Исполнитель считал, что спорные задачи по разработке выполнены
корректно, по крайней мере предмет спора не был описан в ТЗ, в то время
как заказчик посчитал, что такой очевидный пункт не стоило подробно
описывать. Еще одной задержкой на данном этапе послужили явные
58
изменения бизнестребований программного обеспечения, вызванными
корректировками отдела маркетинга заказчика. Многие из нововведений
повлекли за собой изменения в архитектуре приложения. Большое
количество времени ушло на коммуникацию между исполнителем и
заказчиком во время тестирования. Все издержки со стороны заказчика
компенсировались путем заключения дополнительных соглашений к
договору. Сравнение запланированного и фактического бюджета проекта
выполнения проекта в процессе выполнения работ продемонстрировано в
таблице 8.
Таблица 8
Сравнение запланированного и фактического бюджета
проекта по разработке мобильного приложения для магазина
Каприз
Задачи
внутри
компании
Специалист
Стоимость
часа
специалиста,
руб
Базовое
количеств
о часов
Количесв
о часов
Базовы
е
затраты
, руб
Затраты
, руб
Проектирова
ние
Интерфейсол
ог
1200
40
60
48000
72000
Дизайн
Дизайнер
2000
20
40
40000
80000
Разработка
МП
Разработчик
1200
350
450
420000
540000
Управление
проектом
Менеджер
проекта
1000
50
68
50000
68000
Итого:
460
618
558000
760000
Отклонение по времени составляет 36 дней (в базовом плане
предполагалось 64 дней, фактически вышло 100 дней).
В плане предполагалась стоимость проекта равная 558 000 рублям,
фактическая составила 760 000 рублей, из которых 150 700 рублей -
запросы на изменения.
При этом в середине и конце проекта команда разработчиков
находилась в постоянно стрессовом состоянии, так как отсутствие
полноценной коммуникации с другими работниками заказчика повлекло за
собой субъективное понимание технического задания. Ввиду специфики
данной методологии тестирование и отладка программного обеспечения
59
происходит намного позже разработки, что автоматически исключает
возможность обнаружения ошибок на ранних этапах и их дальнейшее
исправление. Поэтому критерий качества в данном случае зависит напрямую
от удовлетворения заказчика от полученного, в конечном счете, продукта.
Таким образом, чтобы действительно достичь желаемого уровня
качества, длительность проекта пришлось увеличить на 56%, а стоимость на
36%. Клиент и менеджер проекта стремились минимизировать возможные,
нежелательные отклонения от требуемого качества (то есть, целевой
результат подразумевает соответствие продукта ожиданиям заказчика),
следовательно, для того, чтобы отклонения по качеству (которое было
выбрано наиболее приоритетным из всех критериев проекта), длительность
проекта и его бюджет пришлось увеличить.
В качестве примера для оценки экономического эффекта от
применения Скрам используется аналогичный проект по разработке
мобильного приложения, заказанный другим клиентом, с некритичным
изменением функционала. Следует отметить, что количество специалистов и
в том и в другом проекте одинаково.
По базовому плану процесс разработки приложения должен был занять
10 итераций, что соответствует 64 рабочим дням, при условии отсутствия
внесения изменений заказчиком.
В конечном итоге весь процесс создания мобильного приложения занял
12 спринтов, что соответствует 75 рабочим дням. Отклонения фактического
плана от базового, построенного по Scrum, представлены в таблице 9.
Таблица 9
Сравнение запланированных и фактических сроков проекта по
разработке мобильного приложения для магазина 24кедр.
Задачи
Базово
е
начало
Базовое
окончание
Начало
Окончан
и
е
Базовая
длитель
ность,
день
Длительност
ь
, дней
Проектирование
05.03.2
0
20.03.20
05.03.20
20.03.20
14
14
60
Дизайн
22.03.2
0
05.03.20
21.03.20
05.03.20
10
11
Написание тех.
задания
заказчиком
06.04.2
0
13.04.20
06.04.20
13.04.20
5
5
Разработка API
заказчиком
20.04.2
0
08.05.20
20.04.20
23.05.20
15
20
Разработка МП
09.05.2
0
09.05.20
23.05.20
15.06.20
20
25
Итого:
64
75
Отклонения по длительности были зафиксированы по задачам
«Разработка API» и «Разработка МП» ввиду задержек на этапах
тестирования. Проанализировав длительности базового и фактических
планов, можно заметить, что отклонение по длительности составило 20%.
Важно отметить, что отклонения по стоимости проекта с
предлагаемойметодологией невелики, так как происходит только доплата за
дни задержек.
Базовая стоимость проекта оценивается в 504 300 рублей, а
фактическая - в 637 000 рублей, таким образом, отклонение по стоимости
равно 26%. Так как проект, реализованный при помощи Скрам, наличие
запросов на изменение не предполагается и следовательно не включается в
конечную стоимость проекта.
Как было неоднократно отмечено ранее, применение итеративной
методологии управления проектами целесообразно тем, что уточнение и
демонстрация очередной версии программного обеспечения происходит
довольно часто, после окончания очередной итерации. При таком подходе,
очевидно, что возникающие на ранних этапах ошибки могут быть сразу же
исправлены. Кроме того, получаемый в конце проекта продукт больше
соответствует требованиям заказчика. Соответственно, оперируя данными
суждениями, можно отметить, что отклонение по качеству продукта,
полученного с помощью Скрам намного меньше отклонения по качеству
продукта, полученного с помощью водопадной модели.
61
Таблица 10
Отклонения фактического плана от базового плана
Модель
Длительность, дн.
Отклоне
ние(%)
Стоимость, руб.
Отклонение
( %)
Базовая
Фактическ
ая
Базова
я
Фактичес
кая
Водопадная
64
100
56%
558 000
760 000
36%
Скрам
64
75
20%
504 300
637 000
26%
Проведенный анализ показывает, что в условиях быстро меняющихся и
нечетко определенных требованиях использование Скрам в управлении
проектами по разработке IT- проектов является наиболее эффективным.
Слаженная работа, которая определяется самими специалистами,
выполняющими ее, намного больше стимулирует исполнителей на
качественное решение задач, нежели постоянные поручения менеджера
проекта и пребывание в вечном стрессе. Для заказчика и исполнителя выгода
очевидна: проект внедряется быстрее, качественнее и с меньшими затратами
по сравнению с традиционным методом.
3.2 Оценка чувствительности и рисков проекта
Для того, чтобы определить изменение каких компонентов оказывает
наибольшее влияние на показатель NPV, рассмотрен еще один подход к
анализу рисков – анализ чувствительности. Он основан на выявлении
возможных изменений в эффективности проекта из-за колебаний какого-либо
изначально указанного параметра.
Алгоритм проведения анализа чувствительности состоит из следующих
этапов:
1. Выбор ключевого показателя эффективности.
2. Выбор неопределенных факторов (цена продукта, объем продаж, и
т.п.).
3. Установление предельных значений для неопределенных факторов.
62
4. Расчет значений ключевого показателя для нескольких значений
неопределенного фактора.
5. Построение графиков зависимости ключевого показателя
эффективности от изменения значений неопределенных факторов.
Рассмотрим анализ чувствительности проекта к изменению объема
продаж и величины постоянных издержек. Для этого необходимо установить
все значения компонентов пессимистического и оптимистического вариантов
в соответствии с базисным сценарием, за исключением изменяемых
показателей. Затем рассчитать денежные потоки (CF) и чистую
дисконтированную стоимость проекта (NPV) для всех вариантов.
Меняя величину объема продаж на 5000 единиц в большую и меньшую
сторону, получаем следующие зависимости (Табл.10).
Таблица 10
Зависимость CF и NPV от изменения объема продаж
Сценарий
Объем продаж
CF
NPV
Базисный
25 000
42 256
82 897,14
Пессимистический
20 000
-41 045
-390 339
Оптимистический
30 000
115 706
459 349,2
Аналогичным образом, меняя величину постоянных издержек,
повторяем анализ (Табл.11).
Таблица 11
Зависимость CF и NPV от изменения величины постоянных
издержек
Сценарий
Постоянные издержки
CF
NPV
Базисный
427 625
42 256
82 897,14