Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: CXCIV Международной научно-практической конференции «Научное сообщество студентов: МЕЖДИСЦИПЛИНАРНЫЕ ИССЛЕДОВАНИЯ» (Россия, г. Новосибирск, 08 августа 2024 г.)

Наука: Экономика

Секция: Менеджмент

Скачать книгу(-и): Сборник статей конференции

Библиографическое описание:
Денежкин В.А. ПОДХОДЫ К УПРАВЛЕНИЮ ПРОЕКТАМИ В РАМКАХ ЦИФРОВЫХ ИННОВАЦИЙ // Научное сообщество студентов: МЕЖДИСЦИПЛИНАРНЫЕ ИССЛЕДОВАНИЯ: сб. ст. по мат. CXCIV междунар. студ. науч.-практ. конф. № 15(193). URL: https://sibac.info/archive/meghdis/15(193).pdf (дата обращения: 24.11.2024)
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

ПОДХОДЫ К УПРАВЛЕНИЮ ПРОЕКТАМИ В РАМКАХ ЦИФРОВЫХ ИННОВАЦИЙ

Денежкин Владимир Александрович

магистрант 1 курса, кафедра менеджмента факультета экономики и информационных технологий, Пермский государственный аграрно-технологический университет имени академика Д.Н. Прянишникова,

РФ, г. Пермь

Черданцев Вадим Петрович

научный руководитель,

д-р экон. наук, проф., Пермский государственный аграрно-технологический университет имени академика Д.Н. Прянишникова,

РФ, г. Пермь

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

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

Большинство авторов сходятся в том, что классический проектный подход («каскадная модель», «водопадная модель») заключается в том, что этапы проекта реализуются последовательно. Например, планирование, разработку, тестирование и поставку результатов работ заказчику. Присутствует вертикаль управления. Руководителю проекта делегированы полномочия. Он управляет командой и ресурсами, отчитывается заказчику и куратору (спонсору) проекта. Руководитель проекта составляет план проекта, который утверждается заказчиком, и команда действует согласно ему. Только в конце проекта готовый продукт (ценность) передается заказчику» [2].

Отцы-основатели каскадного метода управления предлагали использовать некоторые элементы гибкого управления. Так У. Ройс рекомендовал отрабатывать каждую стадию дважды на основе обратной связи от заказчика и дорабатывать результаты блока работ с учетом обновленных требований. На практике, как правило, эта рекомендация не учитывалась, и традиционно сама модель декларировалась как модель «одного прохода» по стадиям, реализуемым в строгой последовательности.

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

В 1987 году положения классического подхода нашли свое воплощение в Своде знаний по управлению проектами (Project Management Body Of Knowledge, PMBOK) глобальной некоммерческой отраслевой организации «Институт управления проектами» (Project Management Institute, PMI) [3].

Благодаря тому, что классический проектный менеджмент жестко регламентирован по времени выполнения задач, для осуществления проектов в рамках данного подхода применяются методы календарно-сетевого планирования как наиболее оптимальные. Самым популярным среди них является диаграмма Ганта. Есть большое количество инструментов для её составления – от стандартных таблиц Excel и Smartsheet до сложных, ориентированных на высокопрофессиональных пользователей программных продуктов таких как Microsoft Project и Primavera.

С 30-х годов XX века исследователи в области менеджмента искали пути повышения эффективности работы и нивелирования потерь. Как решение были разработаны цикл Деминга (PDCA), бережливые методы производства «Тойоты», сформулированы аспекты негативного влияния простоев, перепроизводства, неравномерной работы, перегрузки сотрудников, накопления запасов и др.

В 1990-х годах была сформулирована группа гибких методов создания программного обеспечения в противовес преобладающим жестко регламентированным методам. В соответствии с хронологией это: с 1991 года - RAD (дословно «быстрая разработка приложений»); с 1994 года - метод разработки динамических систем (распространенное обозначение DSDM); с 1995 года - Scrum; с 1996 года, Crystal Clear и экстремальное программирование (XP); с 1997 года - с фокусом на функциях продукта Feature driven development (FDD). Несмотря на то, что они были разработаны и представлены до публикации известного Манифеста инициативной группы Agile Software Development, их относят к гибким методам» [4].

Знаковым событием стала встреча в феврале 2001 года семнадцати разработчиков-программистов в штате Юта. Предметом обсуждения стали эффективные методы разработки. Результатом встречи стала публикация Манифеста о гибкой разработке программного обеспечения Agile. С этим фактом связывают признание гибкого подхода к управлению проектами [2].

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

Для сопоставления гибкого подхода с классическим, авторы иногда разделяют его на несколько стадий, соответствующих традиционным этапам жизненного цикла проекта. Так Хайсмит сформулировал три нелинейные пересекающиеся фазы: обдумывание (определение календарных рамок проекта, необходимого количества циклов и временных границ каждого из них, составление списка задач по всему проекту); сотрудничество (анализ результатов, сложившегося положения дел и поведения команды в целях корректировки, если будет такая необходимость); обучение (оценка достигнутых результатов по завершению каждого из блоков разработки: удовлетворенность продуктом заказчика, уровень технической реализации продукта, взаимодействие в команде и сложившиеся практики)» [3].

Общими для методов гибкого управления проектами будут следующие базовые элементы [1]:

  • визуальный контроль. Команда в повседневной деятельности использует карточки разных цветов и видов, которые демонстрируют, какое свойство итогового продукта уже реализована или спланировано и т.д. Посредством этого разработчики имеют визуализированную информацию о текущем положении дел. Это обеспечивает синхронизацию видения проекта каждым в команде. К участникам проекта относят и клиента;
  • адаптируемое управление. Гибкое управление проповедует обслуживающее лидерство. Руководитель проекта – не уполномоченный раздавать указания сотрудник, а мотивирующий лидер, помогающий установить командные правила сотрудничества и работы;
  • совместная работа. Исполнители, руководитель проекта и заказчик работают совместно, что позволяет исключить возможные потери информации и разницы в непонимании целей. Прозрачность потока задач и работ позволяет моментально реагировать на выявленные проблемы и находить оптимальные решения;
  • работа, основанная на распределении всего объема работ по проекту на составные части. Данный подход позволяет снизить сложность проекта и фокусироваться на каждой части в отдельности.
  • работа над ошибками. При отработке цикла команда получает новые навыки и анализирует встретившиеся ошибки, что позволяет исключить их в работе во время следующего цикла;
  • спринты и ежедневные краткосрочные совещания. Спринты – временные периоды, за которые команды прорабатывает определённый ряд задач. Их внедрение позволяет объективно оценивать результаты работы. Ежедневные встречи длительностью, не превышающей 15 минут, помогают каждому участнику проекта ответить прежде всего для самого себя на три вопроса: «что я делал вчера», «что я буду делать сегодня», «что мне мешает выполнять работу»?».

Таким образом, «внедрение в проектную деятельность гибкого метода Agile возможно при соблюдении следующих условий [2]:

  • цель проекта точно обозначена;
  • заказчик активно взаимодействует с командой по ходу всего проекта;
  • допустимо пошаговая реализация общего объема работ по проекту;
  • итоговый результат работ оценивается выше, чем документация;
  • ключевая рабочая группа разработчиков имеет в составе не более 7-9 человек».

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

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

 

Список литературы:

  1. Антонец, В. А. Инновационный менеджмент: учебник и практикум для среднего профессионального образования./ В. А. Антонец. – 2-е изд., испр. и доп. – М.: Юрайт, 2022. –303 с.
  2. Локтионов, Д. А. Критерии применения Agile методологии для управления проектом / Д. А. Локтионов, В. П. Масловский. // Креативная экономика. – 2018. – Том 12. – № 6. – С. 839-854
  3. Проектные методологии управления. Agile и Scrum [Электронный ресурс] Электрон. текстовые данные. – М.: Аспект Пресс, 2018. – 160 c. – URL: http://www.iprbookshop.ru/86125.html
  4. Редькин, А. В. Гибридный метод управления проектами / А. В. Редькин, М. Р. Демидов // Научно-методический журнал «Журнал технических исследований». – 2019. – №2. – С. 14-18 – URL: https://naukaru.ru/ru/nauka/article/29006/view
Удалить статью(вывести сообщение вместо статьи): 
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

Оставить комментарий

Форма обратной связи о взаимодействии с сайтом
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.