64
Таблица 6
Разграничение прав пользователей
Группы
пользова-
телей
Общая
папка
«ПО»
Общая папка
«Пользовате
ли»
Модуль
«ТЗ»
Модуль
«Проект»
Доступ в
Internet
Менеджер
проектов
Чтение/со
здание
Полный
Полный
Полный
Не
ограниче
н
Менеджер
по
продажам
Чтение/со
здание/уд
аление
Чтение
Чтение
Полный
Ограниче
н
Дизайнер
Чтение
Чтение/созда
ние
Полный
Нет
Нет
Верстальщ
ик
Чтение
Чтение/созда
ние/
удаление
Полный
Чтение
Ограниче
н
Программи
ст
Чтение/со
здание/уд
аление
Чтение/созда
ние/
удаление
Полный
Полный
Не
ограниче
н
2.2. Управление проектом автоматизации
2.2.1 Описание системы принятия управленческих решений
Известным фактом является то, что каждый проект является уникальным
мероприятием, не поддающимся процессам стандартизации. В отличие от самих
проектов, процессы по управлению проектами поддаются стандартизации.
Документы в области стандартизации процессов названы методологиями
управления проектами, некоторые из них применяемы для всех видов проектов,
независимо от области их применения. Также существует ряд методологий,
применяемых для отдельных видов проекта. К примеру, для строительства дорог
применима одна методология, а для разработки ПО другая. Ниже рассмотрены
самые популярные методологии управления проектами [20].
Традиционная (Каскадная) методология управления проектами
Традиционная методология для управления проектами применяется во всех
сферах, но чаще всего в строительстве. Вследствие того, что последовательность
фаз модели подобна потоку, ее также называют водопадной или каскадной. В ней
выделено 7 логических этапов в сфере проектного управления [20]:
1. Определение требований;
2. Проектирование;
3. Реализация;
65
4. Внедрение;
5. Отладка и тестирование;
6. Установка;
7. Эксплуатация и сопровождение.
Переход на следующую фазу возможен только после завершения и
принятия заказчиком предыдущего. Использование методологии возможно в
проектах, конечным продуктом которых будет являться материальный продукт (к
примеру, установка оборудования и т.д.), для создания которого необходима
четкая последовательность при работе. Такие планы в будущем можно применять
для аналогичных проектов [20].
Недостатком каскадной модели управления проектами являются
значительные инвестиции в область планирования. Зачастую две первые фазы
составляют 20-40 % общего времени выполнения проекта согласно данной
методологии. Впоследствии структурированного подхода, изменения списка
работ производится достаточно медленно, при этом делая ее не податливой в
ситуации, когда заказчик не уверен, какой результат он желает получить.
Методология управления проектами PRINCE2
Одной из самых распространенных методологий управления проектами в
Великобритании, как в государственных, так и в бизнес сферах, является
PRINCE2 (Projects in Controlled Environments). Она ориентирована на процессы
верхнего уровня (управление, контроль, организация), и не применима для
процессов низшего уровня (разработка графиков, декомпозиция работ). В
PRINCE2 заложено по 7 типов принципов, тем и процессов. Принципы лежат в
основе методологии: при невыполнении одного из них, проект нельзя считать
выполненным согласно PRINCE2 [20].
Принципы методологии PRINCE2:
1. Поэтапное управление - четкое планирование, мониторинг и контроль на
всех этапах работы над проектом;
2. Управление по отклонениям - четкое обозначение допустимых границ
отклонений от проекта с целью установления ответственности за отклонения;
3. Регулярная оценка экономической обоснованности - мониторинг
экономической выгоды от проекта на всех этапах ЖЦ проекта;
66
4. Обучение на опыте - членам команды проекта необходимо регулярно
изучать опыт создания предыдущих проектов;
5. Фокусирование на продукте - концентрация на определении и
достижении качества конечного продукта;
6. Определение ролевой модели - участники команды проекта должны
обладать четкой организационной структурой, и привлекать подходящий
персонал для решения необходимой задачи;
7. Адаптация к проектной среде - необходимо подобрать процессы и
инструменты администрирования проекта согласно проектной среде, исходя из
масштаба, важности и сложности выполняемых работ, запросов к ним, а также
степени риска.
Аспектами называются направления управления проектом, которые
необходимо контролировать на протяжении всего проекта. Они описаны ниже
[31]
1. Организация - распределение ролей и ответственности в команде проекта
с целью эффективного управления проектом.
2. Обоснование проекта - какая ценность проекта для предприятия?
3. Качество - установление требований и критериев оценки качества, а
также способы его обеспечения.
4. Планы - разработка плана, определение инструментов PRINCE2, которые
необходимо использовать.
5. Прогресс - реализация проекта согласно планам дальнейшего его
развития.
6. Изменение - как руководители проекта оценивают влияние
непредсказуемых ситуаций, изменений и реакцию на них.
7. Риски - каким способом руководители проекта будут решать вопросы
касательно неопределенностей в проекте и внешней среде.
Семь процессов разделяют ЖЦ проекта на фазы, которые имеют свой
перечень рекомендованных действий, конечные продукты и определенные зоны
ответственности. Перечень процессов представлен ниже [31]:
1. Запуск проекта.
2. Руководство проектом.
67
3. Инициация проекта.
4. Контроль этапов проекта.
5. Управление созданием продукта.
6. Управление рамками этапов проекта.
7. Завершение проекта.
В методологии представлены стандартные процедуры для управления
проектом, улучшения деятельности, а также понятия планирования и
мониторинга выполнения проекта, а также план действий в случае невыполнения
проекта. Основным недостатком PRINCE2 является невозможность его
применения для проектов незначительного масштаба, а также для проектов с
большой вероятностью корректировки объема работ, и запросов к ним [20].
Гибкая методология управления проектом (Agile Project Management)
Гибкое администрирование проекта - итеративная и последовательная
методология. Главная особенность заключается в том, что на начальном этапе
разработки неизвестны жизненный цикл и конечные параметры продукта.
Производится разделение итеративных фаз, именуемых «спринтами». Каждый
спринт включает в себя множество задач, имея при этом свой конечный продукт
и результаты. Agile позволяет руководителям после каждой итерации
производить улучшение конечного продукта при помощи получения обратной
связи. Согласно методологии, ответственность за результат несут 3 участника
проекта [20]:
- Владелец продукта: определяет основные цели, создает согласно
заданным параметрам оптимальный график, подстраивает процесс работы к
изменившимся запросам, устанавливает основные характеристики продукта;
- Scrum мастер: определяет первоочередные задачи для команды создателей
проекта; устраняет трудности, возникающие при выполнении поставленных
задач;
- Члены команды - занимаются выполнением поставленных задач,
регулярно выполняют менеджмент и генерацию отчетов о проделанной работе,
следят за качеством продукта.
Преимущество Agile заключается в гибкости: можно элементарно изменить
параметры проекта. Наиболее часто применяется для проектов, ориентированных
68
на сервис (разработка ПО, графический дизайн, пр.). Однако Agile не подходит
для выполнения проектов со строгими требованиями и параметрами [20].
Методология быстрой разработки приложений (Rapid Application
Development — RAD)
Быстрая разработка приложений (RAD) – представляет собой проектную
методологию, чаще всего применяемая в проектах по созданию ПО, главной
целью которых считается качественная и быстрая разработка приложения. Такая
методология по управлению проектами предусматривает 4 этапа проекта [20]:
планирование;
пользовательское проектирование;
быстрое конструирование;
переключение.
С одной стороны, RAD способствует улучшению показателей
результативности проекта и повышения качества риск менеджмента. С другой
стороны, эта методология не подходит для больших IT проектов, способна
повлечь за собой низкое качество кода. При ее реализации в процесс
осуществления всего проекта требуется постоянное вовлечение клиента [20].
Традиционный подход основывается на весьма строгом планировании
проекта перед запуском и наименьшем вмешательствам после. В случае такого
подхода любая последующая фаза берет свое начало после предшествующей:
осуществление после планирования и т.д. При этом возврат к наиболее ранним
фазам не предусмотрен, поэтому данный метод изредка называют водопадным.
Обычный подход сопоставляется с классическим стандартом по управлению
проектами от PMI – PMBoK. А именно хорошо дает описанию процессу
определения управления проектом:
Приложение навыков и знаний, методов и инструментов к работам проекта
с целью удовлетворения требований, которые предъявляются к проекту.
Гибкие методологии, в свой черед, к планированию привязаны меньше и
предусматривают совсем другой жизненный цикл – итерации. Подобный подход
обеспечивает более эффективную работу в условиях стремительно изменяющейся
бизнес-среды. Основное отличие – мнения по поводу изменений на разных этапах
проекта. При обычном подходе изменения на конечных этапах считаются
69
нежелательными и связаны со значительными расходами. Гибкие методологии –
одобряют изменения на всех стадиях. Этот факт делает их наиболее
конкурентоспособными в сегодняшних реалиях.
В настоящее время гибкие методологии являются хорошей альтернативой
традиционному подходу и обширно используются в разнообразных
высокотехнологичных отраслях, в особенности в области ИТ. Причиной
считается тот факт, что традиционным подходом испытываются значительные
затруднения, в случаях, если требования к проекту изменяются почти на любом
этапе, поскольку необходимо реагировать на быстро изменяющуюся среду.
Наиболее сложная ситуация – конечный результат продукта не совсем понятен,
другими словами следует разрабатывать, до конца не зная, что получится. В таких
случаях гибкие методологии становятся более предпочтительными.
Практическим опытом применения методологий также подтверждаются
такие выводы: часть Agile проектов в общей массе неуклонно повышается (с 2%
в 2012г. до 9% в 2016г.), при этом у обычных подходов популярность снижается,
что в особенности заметно в сфере разработки приложений.
Существует управление проектами на различных уровнях иерархии. По
представлению выглядит она таким образом - рисунок 11.
Рисунок 11 Окружение проекта
Первоначально эта схема была ориентирована на проекты по созданию ПО,
но приблизительно в таком же формате она имелась и в остальных проектах в IT.
70
Причем несомненно, что как методологии уровня команды выделяют
определенные Agile методологии, как XP и SCRUM. Впрочем, отдельные
исследователи рассматривают SCRUM как наиболее общую методологию,
которая относится и к уровню менеджера проекта, включая. Некоторые
исследователи также рассматривают Scrum в прочих областях, отличных от IT.
Данной методологией демонстрируются неплохие результаты и в остальных
областях, к примеру, в строительстве.
Поэтому в текущей работе выбрана именно гибкая методология Agile.
Сопоставление фактических и запланированных сроков реализации
проекта при выполнении работ изображено в таблице 7.
Все 5 задач обладали существенными отклонениями по
продолжительности, что привело к задержке срока сдачи проекта и увеличению
стоимости проекта. При помощи наблюдения за выполнением проекта были
обнаружены и систематизированы факторы запозданий задач проекта.
Таблица 7
Сравнение фактических и запланированных сроков проекта по разработке
приложения
Задачи
Базово
е
начало
Базовое
окончани
е
Начал
о
Окончани
е
Базовая
длительност
ь,
день
Длительност
ь,
дней
Проектировани
е
14.07.
2019
08.08.
2019
14.07.
2019
29.08.
2019
20
33
Дизайн
11.08.
2019
22.08.
2019
01.09.
2019
18.09.
2019
10
14
Написание тех.
задания
заказчиком
11.08.
2019
15.08.
2019
01.09.
2019
19.09.
2019
5
15
Разработка API
заказчиком
14.07.
2019
08.08.
2019
14.07.
2019
20.10.
2019
20
92
Разработка МП
18.08.
2019
10.10.
2019
23.09.
2019
05.11.
2019
40
54
ИТОГО:
95
208
Задача «Проектирование приложения». Базовая продолжительность
планировалась 20 дней, фактическая - 33 дня.
Продолжительное составление требований, стремление минимизировать
риски путем глубокой аналитики вероятных расхождений в будущем повлекло
71
задержку времени согласования окончательного прообраза и начала следующего
этапа. Длительное время потрачено на добавления и корректировки прототипа,
следовательно, к запросам к мобильному приложению. Продолжительная
неопределенность заказчика в процессе предоставления своих запросов
менеджеру проекта по предполагаемым функциям мобильного приложения [9].
Задача «Дизайн приложения». Базовая продолжительность планировалась
10 дней, фактическая - 14 дней.
На предыдущем этапе руководитель предприятия заказчика не принимал
участие в формировании запросов к мобильному приложению, но на данном этапе
он принял решение о внесении собственных пожеланий. На этом этапе был
внесены многочисленные исправления по пожеланию заказчика,
визуализировалось мобильное приложение, что привело к задержке сроков.
Задача «Подготовка технического задания заказчиком». Базовая
продолжительность планировалась 5 дней, фактическая - 15 дней. На этом этапе
была спровоцирована задержка из-за неопределенности заказчика в своих
запросах к конечному продукту.
Задача «Разработка API заказчиком». Базовая продолжительность
планировалась 20 дней, фактическая - 92 дня.
На этом этапе заказчик обязан был предоставить API (интерфейс
взаимодействия между мобильным приложением и сервером заказчика). Однако
из-за повышенной загрузки ответственных специалистов на остальных проектах
и неопределенности функционала мобильного приложения на этом этапе
случилась задержка. В связи с тем, что заказчик задержал предоставление
работоспособного API, менеджеру проекта пришлось направить программиста на
реализацию другого проекта на срок в 27 суток.
Задача «Разработка приложения». Базовая продолжительность
планировалась 40 дней, фактическая - 54 дня.
На этом этапе была спровоцирована задержка не подготовленностью API, а
также разной интерпретацией технического задания (ТЗ) заказчиком и
исполнителем. Исполнитель полагал, что конфликтные задачи по разработке
были выполнены правильно, к тому же предмет спора не описывался в ТЗ, а
заказчик предположил, что такой бесспорный пункт не стоит даже детально
72
описывать. Другую задержку на этом этапе спровоцировали очевидные
изменения бизнес - запросов ПО, которые вызваны исправлениями отдела
менеджмента заказчика, многие из которых привели к изменениям в архитектуре
приложения. Много времени потрачено на коммуникацию между заказчиком и
исполнителем и в процессе тестирования. Очень долго заказчик выполнял
тестирование промежуточных и финального результатов. Заключив
дополнительные соглашения к договору, компенсировались все издержки со
стороны заказчика [9].
2.2.2 Формирование команды проекта автоматизации
Соблюдение баланса между работой, временем на ее выполнение и
затратами накладывает огромную ответственность на выполнение проекта.
Одновременно с соблюдением этих трех факторов, также необходимо
максимально удовлетворить потребности заказчика.
Основные цели проекта достигаются за счет функций администрирования.
Все функции администрирования состоят из 5 самостоятельных видов управления
деятельностью [20]:
- Планирование;
- Организация;
- Координация;
- Мотивация;
- Контроль.
Все вышеперечисленные виды напрямую связаны друг с другом, с целью
достижения качественного администрирования.
1. Планирование. Основная миссия - достижение наилучшего результата,
исходя из временных и ресурсных ограничений.
2. Организация. Определяет методы, средства и пути для достижения
заданной цели.
3. Координация. Обеспечивает взаимодействие между участниками
процесса для совместного выполнения работы.
4. Мотивация. Основной целью является получение максимальной
трудоспособности при помощи стимулирования условий труда.
5. Контроль. Основное направление - ликвидация возможных отклонений
73
от работы, а также их предупреждение.
Функции также можно поделить на интегрирующие и базовые. К базовым
можно отнести [20]:
- управление содержанием проекта;
- управление временем: реализовывается при помощи календарного
планирования работы, а также ее корректировки, отслеживания и актуализации;
- управление качеством: выполняется в процессе всего ЖЦ проекта,
реализовывается при помощи установления стандартов и требований к качеству
выполняемого проекта и процесса его реализации;
- управление финансовым и материальным бюджетом: выполняется при
планировании ресурсов, оценки расходов для выполнения проекта, контроля
затрат и денежных поступлений, а также принятия мер при превышении заданных
в смете расходов и прочих отклонениях от бюджета.
К интегрирующим функциям относят:
- управление сотрудниками проекта: направлено на подготовку, подбор и
организацию работы для выполнения работ по проекту;
- управление коммуникациями (отслеживание и прогноз работы и ее
результата): создание, организация и контроль над процессами обмена
информацией с целью удовлетворения нужд сотрудников проекта;
- управление контрактами: контроль над исполнением, закрытием и
оплатой выполненных контрактов; выбор стратегии выполнения работы;
определение сроков и субъектов для выполнения контракта; выбор необходимых
ресурсов для выполнения при помощи тендеров, торгов и пр.; документальная
подготовка контрактов; информационно - рекламная работа и т.д.;
- управление рисками: анализ, оценка и предупреждение возможных
рисков. Разработка мер для уменьшения их воздействия на работу и результаты
проекта, распределение возможного ущерба между участниками проекта.
Применяется в случаях, когда вероятность риска для проекта на высоком уровне.
К участникам относят людей и предприятия, принимающие активное
участие в реализации проекта. Также участниками принято считать тех, чьи
интересы напрямую затронуты результатами выполнения или окончания проекта.
Участники проекта являются его основой, потому что именно они