Концепция арм в управлении «мягкими» проектами

Введение

Актуальность работы. Проблема организации управления современной компанией часто сводится к поиску новых решений по построению внутригрупповой структуры, субординации сотрудников и руководителей, организации работы между группами, управлению внутренними процессами. В современном мире система управления постепенно переходит от строго иерархической к гибко-управляемой системе, в которой не требуются четкие должностные инструкции, а участники взаимодействуют максимально направленно для достижения конкретной цели. Отказ от устоявшихся моделей управления обусловлен стремлением организаций модернизироваться под быстро меняющуюся среду, что способствует производству более качественного продукта.Управление проектами – это управление всеми ресурсами организации для достижения поставленной цели с учетом временного ресурса и бюджета. Примеры включают разработку мобильного приложения, проведение эффективной рекламной кампании и даже запуск ракеты в космос. Управление проектами позволяет выполнять задачи с максимальной ценностью для компании.Поскольку проекты имеют свою специфику, универсальной системы или решения для всех типов проектов в проектной деятельности не существует. Однако за время развития этого направления было придумано немало подходов, методов и стандартов, существенно помогающих менеджерам.Цель работы – рассмотреть концепцию agile project managment (apm) реализации проектов с преобладанием «мягких» факторов.Задачи:1. Охарактеризовать концепцию agile project managment;2. Дать оценку apm при реализации проектов с преобладанием «мягких» факторов.1 Особенности концепции agile project managment (apm)Agile-управление проектами — это итеративный подход к проектам разработки программного обеспечения, который обеспечивает быстрое реагирование на отзывы и возможность внесения соответствующих изменений на каждом этапе спринта или цикла продукта [1].Это позволяет проектным группам применять гибкие методологии управления проектами для быстрой и совместной работы в рамках временных рамок и бюджета проекта.Гибкое управление проектами охватывает множество различных гибких методологий управления проектами, каждая из которых основана на некоторых общих принципах и основных ценностях гибкой разработки.Но единой универсальной «гибкой методологии» не существует. Так откуда они все взялись?Большинство современных гибких методов управления проектами берут свое начало в разработке программного обеспечения. Еще в 1990-х команда разработчиков программного обеспечения обнаружила, что высокоструктурированные «тяжеловесные» традиционные методологии управления проектами (например, Waterfall) просто не подходят, когда дело доходит до того, как им нужно работать.Они обнаружили, что подводные камни этих тяжеловесных методов, такие как отсутствие гибкости, приспособляемости и даже автономии, затрудняли их реакцию на изменения или применение полученных знаний в ходе работы. Поскольку планы проекта были намечены в самом начале, не было места для неожиданностей, а отклонения могли дорого обойтись.Но в отличие от отраслей, где процесс был фиксированным, а результат был надежным и стабильным (подумайте: производственный процесс, который создает один и тот же продукт на сборочной линии), изменения являются фундаментальным компонентом программных проектов.Может быть, требования заинтересованных сторон меняются, или, может быть, тестирование показывает, что что-то работает не так, как должно, когда конечный пользователь получает это в свои руки.Вместо того, чтобы быть в плену плана управления проектом, который они наметили в начале, гибкие методы управления проектами означали, что команды могли учитывать эти изменения для создания наилучшего продукта. Для этого им требовались более короткие циклы разработки (называемые спринтами), более итеративный процесс, а также непрерывная обратная связь и тестирование.Затем, в 2001 году, группа разработчиков программного обеспечения собралась вместе, чтобы обсудить основные принципы Agile и по-настоящему углубиться в лежащую в его основе философию. Они придумали «Манифест гибкой разработки программного обеспечения» — набор ценностей и принципов, которые станут путеводной звездой для команд, задающихся вопросом, как стать гибкими.Если все это кажется очень ориентированным на разработку программного обеспечения, не волнуйтесь. Многие гибкие методологии управления проектами были разработаны с учетом программного обеспечения, но основные ценности и принципы гибкого управления проектами полезны для многих различных типов команд, от групп разработчиков до маркетинговых команд.Знание истории гибкого управления проектами (или, по крайней мере, краткого изложения, изложенного выше) может помочь дать контекст некоторым терминам и процессам, которые до сих пор характеризуют гибкое управление проектами и которые мы рассмотрим более подробно в ближайшее время, когда мы разберем Agile-манифест более подробно.Но если вы просто ищете определение гибкого управления проектами сейчас, а не предысторию того, что было раньше, вот полезное определение гибкого управления проектами.Agile-управление проектами — это совместный итеративный подход к управлению проектами, который включает в себя непрерывное тестирование и реагирование на изменения.Звучит неплохо? Давайте вернемся к Agile-манифесту, чтобы узнать больше об основных ценностях и принципах, которые вы можете использовать для руководства любым agile-проектом.Как упоминалось выше, самые ранние гибкие методы управления проектами были сосредоточены на программном обеспечении, и Agile Manifesto был создан разработчиками программного обеспечения. Таким образом, вы увидите это слово и другие связанные с ним термины, такие как «разработчики» и «клиенты», повсюду [2].Создаете ли вы программное обеспечение или что-то совершенно другое (например, маркетинговую кампанию), есть много выводов, которые вы можете применить, независимо от того, в какой отрасли вы работаете.Первоначальный манифест Agile заявляет, что Agile имеет 4 основных ценности:• Люди и взаимодействия важнее процессов и инструментов.• Рабочее программное обеспечение по исчерпывающей документации.• Сотрудничество с клиентами в ходе переговоров по контракту.• Реагирование на изменение плана.Эти основные ценности лежат в основе всех гибких подходов к управлению проектами, информируя все, от стандартных способов работы до 12 гибких принципов управления проектами.Что становится ясно из основных ценностей, так это то, что гибкие подходы, прежде всего, основаны на сотрудничестве и управлении людьми.Это относится не только к рабочим процессам (прогресс достигается за счет «людей и взаимодействий» и «сотрудничества с клиентами», ставя во главу угла человеческий фактор), но и к готовым продуктам. То есть цель состоит в том, чтобы создать что-то функциональное, что принесет наибольшую пользу конечному пользователю.Согласно Agile Manifesto, существует 12 ключевых принципов гибкого управления проектами. По словам самого манифеста, они таковы:1. Приоритетом номер один является удовлетворение потребностей клиентов за счет раннего и непрерывного предоставления ценного программного обеспечения.2. Приветствуйте меняющиеся разработки, даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.3. Поставляйте работающее ПО часто, от пары недель до пары месяцев, отдавая предпочтение более коротким срокам.4. Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.5. Стройте проекты вокруг мотивированных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.6. Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.7. Работающее программное обеспечение является основным мерилом прогресса.8. Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает гибкость.10. Простота — искусство максимизировать количество невыполненной работы — имеет важное значение.11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.12. Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, затем соответствующим образом настраивает и корректирует свое поведение.Когда дело доходит до этого, говорите ли вы о реальном программном обеспечении или используете его в качестве метафоры для всего, что вы создаете (давайте назовем это «Вещь»), гибкие методы побуждают вас быстро создавать итерации «Вещи». а часто — потому что «Нечто» лучше существовать в ущербной реальности, чем в совершенной теории.Еще одна повторяющаяся тема в этих принципах? Выровняйтесь, оставайтесь в согласии и работайте вместе. Это касается всех участников: вашей собственной команды, «деловых людей», других отделов и заинтересованных сторон. Гибкие методы управления проектами основаны на активном сотрудничестве и прочных межличностных отношениях. Итак, как однажды сказали Билл и/или Тед: будьте добры друг к другу.Agile-управление проектами может показаться просто модной методологией управления проектами, но оказалось, что это больше, чем просто вспышка.Это потому, что результаты говорят сами за себя. Принципы Agile-управления проектами позволили командам всех типов работать более итеративно и гибко, давая им возможность адаптироваться к меняющимся требованиям проекта и быстрее выполнять поставленные задачи.Вот некоторые из наиболее часто упоминаемых преимуществ гибкого управления проектами.Одним из самых больших преимуществ гибких методов является возможность управлять меняющимися приоритетами. Благодаря итеративному подходу Agile и упору на непрерывную обратную связь вы можете получать необходимые данные в процессе разработки, а не после него, что позволяет команде делать более эффективные решения на основе реальных условий, а не только прогнозируемых условий.А благодаря назначенным коротким циклам спринтов, более четкой визуализации проекта и регулярным обновлениям отчетов команды могут повысить предсказуемость проекта и снизить риски.Возможно, вы помните, что сотрудничество с клиентами — это одна из четырех основных ценностей гибкого управления проектами.Что ж, одно из основных преимуществ этого заключается в том, что более тесное сотрудничество с клиентами приводит к большей удовлетворенности клиентов.Гибкие методологии управления проектами выдвигают на первый план клиента и побуждают вас тесно сотрудничать с ним, а также с другими заинтересованными сторонами, чтобы убедиться, что вы создаете что-то, что действительно решает их проблему [3].А поскольку agile-проекты включают в себя регулярное тестирование и обзор в каждом спринте, вы можете получать их реальную обратную связь в режиме реального времени при каждой итерации вашего рабочего продукта.Agile-команды более автономны. То есть им часто предоставляется свобода предлагать новые идеи, вводить новшества и решать проблемы, которых может не хватать в традиционных методологиях управления проектами.С такой ответственностью людям доверяют выполнение работы и поощряют видеть себя неотъемлемыми членами команды, которые могут внести ощутимый вклад в конечный результат проекта.Не только это, но и акцент на сотрудничестве и общении может помочь создать более прозрачные, эффективные, творческие — и, да, более счастливые — команды.Более качественные результаты, более довольные клиенты и пользователи и повышение морального духа команды — это может звучать слишком хорошо, чтобы быть правдой.Но вот в чем дело: agile-управление проектами — это не волшебное лекарство от всех болезней, которое может решить все ваши проблемы с управлением проектами. И он не существует на пустом месте.Чтобы гибкие методы оказали такое преобразующее воздействие, вам нужна поддержка, заинтересованность и несколько действительно выдающихся людей в команде.2 Концепция арм в управлении «мягкими» проектамиОтветом на необходимость эффективного управления «мягкими» проектами стала новая концепция управления проектами APM (Agile Project Management). Этот термин означает, что в условиях высокой неопределенности управление проектом должно быть активным, динамичным и оперативным.ARM возникла в США как подход к управлению проектами в области информационных технологий, разработке новых промышленных продуктов, в том числе компонентов с программным обеспечением, решений в области информационных технологий. Возможность и ценность использования AWS в других проектах быстро стали очевидны.В основе ARM лежит система ценностей. Рассмотрим их. Первое значение — «Ответ (реакция) на изменение вместо строгого следования плану». Каждый проект существует в среде с некоторыми известными и неизвестными, определенными и неопределенными обстоятельствами, а это значит, что он требует баланса между планированием и изменением. Если уровни неопределенности высоки, то возрастает потребность в дополнительных исследованиях, поиске. Классический подход к управлению проектами заключается в предвидении возможных изменений и рисков, но для «мягких» проектов существенные изменения неизбежны, и задача управления — адаптироваться к ранее неизвестной ситуации.Второе значение — «Рабочие продукты вместо исчерпывающей документации». Рабочие варианты продукта демонстрируют (или не демонстрируют) способность проектной команды создавать нечто, имеющее реальную ценность для потребителей, т. е. это своего рода канал обратной связи с рынком. ARM не отрицает ценности документации, однако документация не заменяет эффективное общение между сторонами, участвующими в программе или проекте.Третья ценность — «Сотрудничество с потребителями вместо изматывающих переговоров по условиям контрактов». Реализация крупных проектов предполагает участие многих организаций, зачастую с достаточно размытыми зонами ответственности и особенно целями и содержанием возложенных на них задач. В результате возникают конфликты, стороны пытаются решить свои проблемы за счет других сторон, что приводит к пустой трате времени и сил. ARM предлагает вести открытый диалог между заинтересованными сторонами о том, какая ценность создается и как эта ценность может быть справедливо распределена между участниками в режиме win-win (взаимный выигрыш сторон) [4].Четвертая ценность — «Ставка на людей и их взаимодействие, а не на процессы и традиционные инструменты управления». Ключевая проблема «мягких» проектов — создание возможностей для эффективной познавательной деятельности и новых знаний в коллективной среде. Решающее значение имеет подбор «правильных» людей, способных создать и поддерживать командный дух, атмосферу творчества, использовать синергетический эффект командного взаимодействия. Создание этой ценности для проектов так же важно, как и сложно. Найти в одном человеке эксперта, генератора идей, «душу коллектива», возмутителя спокойствия и признанного лидера кажется почти нереальной задачей. Результатом является отсутствие проектных команд как таковых. Вместо этого они образуют формальные группы с формальным участием в работе. Однако в тех случаях, когда программы инновационного характера действительно увенчались успехом, эти люди были в командах.Помимо ценностей, в основе АРМ лежат две группы принципов. Давайте посмотрим на них. Группа 1 «Создание ценности для клиента с помощью инновационных продуктов» включает следующие три принципа.1. Создайте ценность для клиента. Никакая технология, какой бы сложной или даже изощренной она ни была, экономически бесполезна, пока нет потребителей, готовых платить за новый продукт. Причем заплатить столько, чтобы все усилия по разработке и коммерциализации технологии стали экономически выгодными. Во многих проектах, особенно инновационных, изначально не ясны группы потребителей, для которых новый продукт может представлять ценность. Именно поэтому в ходе проекта необходимо в первую очередь выяснить, для каких групп потребителей создается проектный продукт и какую ценность он будет иметь.2. Используйте итеративный процесс создания ценности, основанный на разъяснении продукта. Изначально могут быть неясны не только предполагаемые группы потребителей, но и характеристики самого товара. Поэтому эти характеристики следует уточнять в ходе проекта. Для решения этой проблемы AWS использует итеративное планирование. Каждая итерация — это небольшой, быстрый и недорогой шаг в проекте. Планирование этих шагов осуществляется таким образом, чтобы быстро и недорого проверить востребованность или невостребованность тех или иных характеристик товара.3. Бороться за техническое совершенство продукта. ARM направляет разработчиков на создание технически совершенных продуктов. Причем это совершенство может быть как внутреннего (саморазвитого), так и внешнего (приобретенного извне) происхождения. При этом нужно помнить первый принцип: техническое совершенство не важно само по себе, оно должно создавать высокую ценность для потребителей [5].Группа 2 «Стиль управления, основанный на лидерстве и сотрудничестве» включает следующие три принципа.1. Поощряйте поиск, исследование. Современные проекты часто реализуются в условиях неопределенности, которую необходимо уменьшить. Движение вперед в условиях неопределенности часто сопровождается ошибками, вероятность и негативные последствия которых необходимо постараться уменьшить. Но если они случились, их нужно принять как данность, извлечь уроки, приобрести новые знания и двигаться дальше. Для этого создается соответствующая культура и среда.2. Создавайте адаптивные команды на основе самоорганизации и самодисциплины. Команды, реализующие софт-проекты, должны уметь адаптироваться к постоянно меняющейся среде. Для этого нужно подобрать «правильных» людей, так как не все чувствуют себя комфортно при изменении ситуации. Общение в таких командах должно быть реализовано максимально эффективно, а взаимодействие между людьми должно поощряться. Все сотрудники должны быть вовлечены в процессы принятия решений. Люди должны обладать самодисциплиной и способностью к самоорганизации.3. Упрощайте. Поскольку «мягкие» проекты продвигаются вперед быстрыми маленькими шагами, все, что используется для планирования, организации, координации, контроля деятельности команд, должно быть очень простым и необременительным. Поэтому ARM предлагает использовать ограниченное количество простых инструментов управления.

Заключение

Основное применение метода – при разработке новых и инновационных производств и продуктов, когда высока доля неопределенности, основные идеи для достижения цели приходят в момент разработки продукта. На этапе планирования нет четкой структуры и понимания того, как получить конечный продукт.Подходы Agile неоднократно подвергались критике, потому что Agile не предусматривает планирования и соблюдения жестких требований, что может привести к снижению качества конечного продукта. Это просто набор принципов и ценностей, которыми могут руководствоваться сотрудники и менеджеры проектов. Применение таких подходов может потребовать от организации значительной реструктуризации системы организации, от межличностного взаимодействия до бюджетной и финансовой дисциплины.Наибольший интерес представляет обращение органов госсектора к agile-методологии. В Австралии подход встроен в национальную методологию в рамках управления проектами в государственном секторе, а значит, можно будет проследить развитие этого подхода в других странах, в том числе и в Российской Федерации.

Список использованной литературы

Кон, М. Agile: оценка и планирование проектов / М. Кон; пер. с англ. - Москва : Альпина Паблишер, 2018.Agile: Tools for Preparing Your Team for the Future by Harvard Business Review, Darrell K. Rigby, Jeff Sutherland, Peter Cappelli, Phil Simon.Кузнецова, Е. В. Управление портфелем проектов как инструмент реализации корпоративной стратегии : учебник для вузов / Е. В. Кузнецова. – 2-е изд., перераб. и доп. – Москва : Издательство Юрайт, 2020. – 177 с. Макарова, Н. В. Отличительные особенности стандартов по управлению проектами / Н. В. Макарова, В. В. Балясников // Актуальные проблемы экономики и управления. – 2020. – № 1(25). – С. 94-99.Малахова, А. И. Исследование содержания проблемы управления инновационными проектами в процессах стратегического планирования и развития производственно-экономических систем / А. И. Малахова, Н. О. Никулина, Л. Р. Черняховская // Информационные технологии. – 2020. – Т. 26. – № 4. – С. 239-251.