CC BY
3
EDN: ZQFXAL
А.Ю. Тарасова - магистрант факультета Высшая школа управления, Финансовый университет при Правительстве Российской Федерации, Москва, Россия, [email protected],
A.Y. Tarasova - master's degree student of the Faculty of Higher School of Management, Financial University under the Government of the Russian Federation, Moscow, Russia;
Научный руководитель: И.В. Трифонов - д.т.н., доцент, профессор Департамента менеджмента, Финансовый университет при Правительстве Российской Федерации, Москва, Россия, [email protected],
Scientific supervisor: I.V. Trifonov - Doctor of Technical Sciences, Associate Professor, Professor of the Department of Management, Financial University under the Government of the Russian Federation, Moscow, Russia.
ОСОБЕННОСТИ РЕАЛИЗАЦИИ ПРОЕКТОВ В ГИБКИХ МЕТОДОЛОГИЯХ FEATURES OF PROJECT IMPLEMENTATION IN FLEXIBLE METHODOLOGIES
Аннотация. В данной статье приводится обзор семейства гибких методологий управления проектами в лице Scrum, Kanban и Lean, функционирующих на базе Agile-философии. Путем анализа каскадной модели или «Waterfall» как применяемой изначально и фундаментальной методологии управления проектами в работе выявлена причина популяризации на сегодняшний день именно гибких подходов к управлению проектами. В рамках каждого указанного метода гибких методологий приводится краткий обзор основных процессов, особенностей реализации проектной деятельности и используемого инструментария. Предметом данного исследования являются преимущества и недостатки указанных методологий с практической точки зрения при управлении проектом. По итогам работы составлена сводная таблица, резюмирующая результаты исследования, и позволяющая сделать общий вывод об эффективности использования конкретного метода гибкого управления проектами в рамках определенного проекта. Результаты работы могут быть применены для дальнейшего изучения вопроса выбора оптимального метода управления проектами в зависимости от основных характеристик самого проекта и отрасли его реализации через составление расширенной модели, учитывающей указанные параметры проекта как входные.
Abstract. This article provides an overview of the family of flexible project management methodologies represented by Scrum, Kanban and Lean, operating on the basis of the Agile philosophy. By analyzing the cascade model or "Waterfall" as an initially applied and fundamental project management methodology, the reason for the popularization of flexible approaches to project management today is revealed. Within the framework of each specified method of flexible methodologies, a brief overview of the main processes, features of the implementation of project activities and the tools used is provided. The subject of this study is the advantages and disadvantages of these methodologies from a practical point of view in project management. Based on the results of the work, a summary table has been compiled summarizing the results of the study and allowing us to draw a general conclusion about the effectiveness of using a specific method of flexible project management within a specific project. The results of the work can be applied to further study the issue of choosing the optimal project management method, depending on the main characteristics of the project itself and the industry of its implementation through the preparation of an extended model that takes into account the specified project parameters as input.
Ключевые слова: управление проектами, каскадная модель управления проектами, Agile-философия, гибкие методологии, Скрам, Канбан, Бережливое производство.
Keywords: project management, cascading project management model, Agile philosophy, Agile methodologies, Scrum, Kanban, Lean Manufacturing.
Введение
Зародившийся в середине XX века проектный подход сейчас является актуальным инструментом управленческой деятельности, применяемым повсеместно: от малого бизнеса до органов государственной власти. Такая высокая распространённость неслучайна, ведь управление проектами позволяет решать широкий круг вопросов, связанных со стратегическим развитием организации, внедрением инноваций, совершенствованием процесса оказания услуг или разработки продукции и многое другое. [7] В связи с этим целью данного исследования является желание разобраться в вопросе выбора наиболее результативного метода управления проектом с учетом его особенностей (размер проектной команды, масштаб реализации проекта, требования к рабочей группе) и отрасли экономики, в рамках которой происходит его реализация.
В ходе исследования были использованы научные методы анализа, сравнения и классификации.
Основная часть
Изначально основой проектного управления выступал метод каскадной разработки продуктов или «Waterfall», состоящий в жёстком следовании заданным стадиям разработки продукта: анализ, проектирование, разработка, тестирование, эксплуатация и поддержка (рисунок 1).
Начало --
проекта 1
Программирование и тестирование
Одобрение заказчика и ввод в эксплуатацию
Рисунок 1 - Каскадная модель управления проектами [8]
Однако со временем стали видны существенные недостатки концепции, главными среди которых стали невозможность управляющей системы своевременно реагировать на изменения внешней среды, чрезмерная зарегла-ментированность процессов и бюрократизм [6]. В условиях повышенной неопределённости, расплывчатости и
Исследование и диагностика
1
динамичности требований заказчиков, а также при постоянном росте числа событий типа «чёрный лебедь» стало очевидно, что необходимы новые концепции управления проектами, более адаптивные по сравнению с методом «водопада». Так, в конце 1970-х годов появились первые гибкие методологии управления проектами. Изначально, гибкие методологии управления проектами использовались только для разработки программного обеспечения. Однако создание «Agile Manifesto» в 2001 году изменило отношение к данной группе инструментов проектного управления и вывело их на качественно новый уровень использования. Схематично группу гибких методов управления проектами можно представить следующим образом (рисунок 2).
Рисунок 2 - Методы гибкого управления проектами [14]
Рисунок 2 демонстрирует существование отдельной философии управления - Agile, в рамках которой выделяются методы управления проектами с присущими им особенностями.
Agile или Agile software development подразумевает под собой семейство методов управления, в которых проект разделяется не на последовательные этапы, а на меньшие по масштабу подпроекты, объединяемые в итоге в единое целое - готовый продукт, что видно на рисунке 3.
Рисунок 3 - Схема работы Agile [11]
При этом процесс инициации работы и первоначального планирования осуществляются для всего проекта, а последующие стадии работы: разработка, тестирование реализуются самостоятельно для каждого мини-проекта. В итоге происходит более быстрая передача инкрементов - результатов подпроектов, что даёт возможность проектной команде скорее приступить к новому мини-проекту или итерации. При этом, в отличие от традиционного подхода к проектному управлению (метод «Waterfall»), Agile акцентирует внимание на отношениях между людьми, а не на регламентах работ - гибкие методы управления ориентируются на командный подход к работе - над проектом работают и сторона заказчика, и сторона исполнителя.
В связи с этим главные ценности Agile можно представить следующим образом:
1. Люди и взаимодействие важнее процессов и инструментов - говорит о том, что в Agile акцент делается на человеческих ресурсах, как ведущем факторе реализации успешного проекта, так как только замотивирован-ная команда способна работать эффективно. Данный принцип подчеркивает значимость человеческих коммуникаций при реализации проекта, а не опоры на регламенты и инструкции, что порождает бюрократию.
2. Работающий продукт важнее исчерпывающей документации - на первый план выходит вопрос скорости готовности продукта к эксплуатации, в то время как подготовка технической документации находится не в приоритете.
3. Сотрудничество с заказчиком важнее согласований условий контракта - подразумевает непрерывный диалог с клиентом по поводу происходящих в проекте изменений. При этом стоит отметить, что перемены могут произойти даже при условии заранее прописанных в договоре условий и требований.
4. Готовность к изменениям важнее следования первоначальному плану - предполагает поощрение перемен в рамках каждой итерации, что с одной стороны делает процесс внесения изменений в проект более экономичным, а с другой - может существенно увеличить время его разработки и привести к непредсказуемым результатам [5,12].
При этом согласно «Agile Manifesto» указанная ценностная совокупность способна действовать только в высокомотивированном и профессиональном коллективе. Именно это позволит коллективу избавиться от ненужных формальностей и сосредоточиться на главном - создать в сжатые сроки и при более эффективном взаимодействии продукт, пригодный для использования. Таким образом, к основным достоинствам Agile можно отнести:
- удешевление процедуры внесения изменений в проект за счет деления работы на итерации;
- адаптивность, которая позволяет подстраиваться под постоянно меняющуюся внешнюю среду и нечёткие требования заказчика.
Однако также имеются и недостатки Agile философии, в числе которых:
- отсутствие технической документации, которое негативным образом может сказаться на конечном ре-
зультате проекта;
- ускоренное планирование, часто не соотносящееся с масштабом готовящегося продукта, что может стимулировать ошибки в разработке [1];
- необходимость каждой проектной команды самостоятельно разрабатывать систему управления, так как Agile - набор ценностей, которые не являются готовым инструментом управления.
Однако считается, что с данным недостатком призваны справиться отдельные методы гибкого управления, разработанные на основе Agile-подхода и представленные на рисунке 2. Рассмотрим их более подробно.
Понятие Scrum впервые было использовано в 80-х годах XX века в трудах Икуджиро Нонаки и Хиротаки Такеучи для описания организационных команд, работающих без жёсткой специализации. Японские учёные сравнили данный термин со схваткой в регби - ситуацией, когда после нарушения или остановки игры судьёй назначается её возобновление. В итоге команда проекта, так же, как и спортивная команда, должна суметь самостоятельно организоваться для успешного достижения цели, учитывая свои прошлые ошибки.[15] Говоря об истории термина «Scrum», стоит заметить, что развил данный метод управления и популяризировал его американский программист, Джефф Сазерленд, к 2001 году.
Суть организации проектного управления в Scrum сводится к выстраиванию 3 блоков: роли, практики и артефакты или документы. Рассмотрим каждую часть по отдельности. В Scrum принято выделять 3 роли:
1. Владелец продукта (Product Owner) - ответственен за его разработку и является официальным представителем или доверенным лицом клиента. К числу его основных обязанностей в проекте обычно относят: подготовку бизнес-плана, формирование списка требований к готовому продукту, управление ожиданиями заказчика, осуществление контроля по подготовке конечного продукта, непрерывное взаимодействие с проектной командой и приём результатов по окончании каждой итерации. Важно заметить, что роль владельца продукта всегда выполняет один человек, а не группа лиц, так как именно Product Owner принимает итоговые решения по проектам.
2. Scrum-мастер (Scrum master) - призван обеспечить инициативность членов команды проекта и выстраивание между ними грамотной коммуникации, отвечает за формирование командного духа и решение вопросов и проблем, возникающих в ходе выполнения работ. Поэтому, чтобы обеспечить высокоэффективный рабочий процесс, Scrum-мастером должен быть человек, уже являющийся частью команды.
3. Команда разработчиков (Delivery Team) - мини-группа из 5-9 самостоятельных, инициативных и многофункциональных членов команды, которые ставят перед собой достижимые и оригинальные цели, воплощают их в жизнь в условиях ограниченности времени и заданных параметров качества. Важной функцией является элемент самоконтроля участников команды разработчиков, так как они самостоятельно занимаются отслеживанием прогресса в работе, а затем предоставляют результат владельцу продукта.
Именно Delivery Team занимается реализацией Scrum-практик управления проектами, которые так же, как и роли, включают в себя 3 категории:
1. Ежедневные Scrum-встречи (Daily Scrum Meeting) - проводятся Scrum-мастером утром перед началом работы для формирования у команды продукта представлений о своих обязанностях. Каждому члену команды задаётся 3 вопроса: «что ты сделал вчера?», «что ты сделаешь сегодня?» и «с какими проблемами ты столкнулся?». Максимальная длительность каждой такой встречи равняется 15 минутам.
2. Встречи по обзору спринта (Sprint Review Meeting) - организуются по окончании каждого спринта проекта для анализа результатов проделанной итерации. Условно их можно разделить на 2 части. В первой -команда разработчиков демонстрирует владельцу продукта его рабочую версию или результаты спринта. В свою очередь Product Owner оценивает соответствие продукта требованиям, прописанным в журнале спринта, и обсуждает со стороной исполнителя задачи на следующий спринт. По личному усмотрению владелец продукта может также пригласить других заинтересованных лиц для рассмотрения итогов работ. Вторая часть встречи по обзору спринта состоит в обсуждении итогов работы со Scrum-мастером и определении степени эффективности реализованной части проекта. Оптимальной считается четырёхчасовая продолжительность каждой такой встречи.
3. Аварийная остановка спринта (Sprint Abnormal Termination) - происходит только в крайних случаях, например, когда команда осознаёт, что не сможет добиться поставленных перед собой целей к указанному дед-лайну. После остановки спринта участники встречаются для обсуждения причин неудачи и формирования плана дальнейших действий. Затем наступает подготовка очередного спринта.
Несмотря на отсутствие в Scrum проектной документации в её классическом представлении, данный метод всё-таки предполагает наличие 3 документов:
1. Журнал продукта (Product Backlog) - подготавливается на начальной стадии работы над проектом владельцем продукта с внесением доработок и дополнений проектной командой исполнителей. Отображает совокупность требований к продукту, расставленных в порядке приоритетности с детализацией наиболее значимых пунктов.
2. Журнал спринта (Sprint Backlog) - составляется на основе подготовленного Product Backlog и показывает выбранные владельцем продукта функции, которые затем разбиваются на задачи так, чтобы на реализацию каждой требовалось не более 2 дней. Роль журнала спринта крайне высока в проекте, потому что именно правильная декомпозиция позволяет грамотно планировать итерацию и своевременно достигать поставленных целей. Также важно следить, чтобы содержание журнала спринта и журнала продукта не расходились друг с другом, в противном случае необходимо будет проводить изменения в документации и пересматривать сроки реализации мероприятий.
3. График спринта (Bumdown Chart) - позволяет отслеживать ежедневные изменения общего объема работ, оставшиеся до завершения очередного спринта. Это ключевой инструмент управления сроками и изменениями в проекте. Также, график позволяет владельцу продукта отслеживать прогресс итерации и своевременно регулировать командную работу.
Схематично процесс работы Scrum как метода управления проектами может быть изображен следующим образом (рисунок 4).
Рисунок 4 - Общая схема реализации Scrum в проектном управлении [7]
Таким образом, реализация проекта по Scrum предполагает действия в рамках спринтов (итераций проекта), каждый из которых длится от 1 недели до 1 месяца. Причём в конце каждого спринта владельцу должен быть предоставлен работающий продукт с усовершенствованным функционалом. Подготовка к первому спринту происходит после подготовки владельцем продукта бэклога. Затем, приступая к каждому последующему спринту, команда проекта обращается к бэклогу и выбирает те задачи, которые способна выполнить к определенному дедлайну в рамках очередного спринта, причём начинает с выполнения приоритетных задач для получения скелета готового продукта. Параллельно происходит непрерывная оценка промежуточных результатов работы с возможностью корректировки предыдущих этапов подготовки проекта при участии Product Owner.
В связи со всем вышесказанным преимуществами Scrum как методики управления проектами являются:
- быстрый запуск проекта с функциями, находящимися в приоритете благодаря правильной разбивке на короткие спринты;
- непрерывный контроль за выполнением работ;
- высокая вероятность удовлетворения итоговой потребности клиента из-за частых совещаний с ним;
- возможность внесения корректировок по ходу реализации проекта без высоких финансовых потерь, что даёт возможность «быстро ошибаться» и подстраиваться под изменения.
Однако также существуют и недостатки данного метода управления проектами:
- сложность подбора кросс-функциональной, высокомотивированной команды проекта;
- большое количество совещаний;
- юридические сложности, связанные с заключением контрактов по разработке проектов, из-за отсутствия фиксированных бюджета и технического задания в методике Scrum [2].
В связи со всем вышесказанным Scrum отлично подходит в проектах, где необходимо применение творческого подхода и происходит внедрение инноваций, например, в стартапах. Компаниям, занимающимся серийным производством продукции, данная модель управления может помешать в реализации поставленных целей [4].
Следующим рассмотрим метод гибкого управления Kanban (с японского «кан» - визуальный, «бан» - доска), разработанный в 1953 году инженером компании Toyota Тайичи Оно. Суть подготовленной им системы состояла в формировании для цехов завода совокупности разноцветных карточек, обеспечивающих своевременную разработку автомобилей. Данный метод менее строгий по сравнению со Scrum, так как в нём:
- отсутствуют роли помимо Product Owner, являющегося менеджером запросов. Также добавляется позиция менеджера потока, контролирующего все процессы, связанные с карточками на Kanban-досках;
- время итераций не ограничено;
- сотрудники команды способны вести несколько задач одновременно;
- отсутствует регламентация встреч по обсуждению статуса проекта.
Kanban направлен на выравнивание нагрузки исполнителей. С практической точки зрения методика реализуется через Kanban-доски, в основе которых лежит идея выделения в проекте отдельных стадий или этапов для каждого потока операций, например, планирование, разработка, тестирование и завершение. Данные этапы
являются столбцами, состоящими из 3 граф - «надо сделать», «в работе» и «готово», в каждую из которых направляются свои разноцветные карточки - детально прописанные задачи, требующие воплощения на разных стадиях. Важно заметить, что задачи:
- попадают в столбцы из Backlog в порядке своей приоритетности, что позволяет обеспечивать непрерывность деятельности;
- количественно распределяются по возможности их выполнения производственными отделами в рамках заданного временного лимита;
- имеют цветовую сортировку, представленную на рисунке 5, по карточкам в соответствие с назначением задачи, например, жёлтый цвет - конкретные планы, голубой - технические вопросы, розовый - проблемы выполнения задачи, из-за чего приходится приостанавливать задачу и «вешать» на неё блокер с описанием причины невозможности выполнить работу. Максимально допустимый срок действия блокера - 5 дней, после чего нужно комплексно рассматривать сложившуюся проблему. Дополнением к карточкам задач могут выступать маленькие квадраты - карточки количества ресурсов, которые планируем потратить на реализацию задачи до наступления следующего рабочего дня [13].
Планирование
Разработка
Тестирование
Завершение
Надо сделать в работе Готово
га ш [Ш
га
Надо сделать
ш
и
Надо сделать в работе Готово
2 И ш
3
На.ш сделать
га
Рисунок 5 - Схема работы доски Kanban [14]
По мере выполнения поставленных задач происходит перемещение карточек вперёд по этапам, хотя возможен и перевод в обратном направлении, до чего желательно не доводить. С каждым передвижением процент выполнения работы должен повышаться согласно принципу постоянного улучшения или kaizen. Вместе с этим осуществляется непрерывный анализ производственных процессов и поиск путей повышения эффективности. Если задача проходит весь цикл в сжатые сроки, командная работа была слаженной, в противном случае необходимо искать проблемные области и оптимизировать производственные процессы. В итоге после полного прохождения карточками всех этапов получается готовый для представления заказчику продукт [14].
Таким образом, методика Kanban позволяет:
- оптимизировать работы благодаря принципу kaizen;
- сделать производственный процесс наглядным из-за визуализации;
- сочетать подход с другими гибкими методами управления проектами почти в любой отрасли экономики без необходимости перестраивания организационной системы и излишнего расходования бюджетных средств на внедрение.
К недостаткам Kanban можно отнести то, что метод:
- плох для проектов с жёсткими сроками и слишком большим рабочим коллективом, превышающим 5 человек;
- не предназначен для длительного горизонта планирования производственных мероприятий;
- не позволяет оценивать эффективность работы отдельного сотрудника команды.
Также, как и Kanban, методика Lean возникла в Японии в компании Toyota. Однако закрепление термина «бережливое производство» произошло только в 1988 году Джоном Крафчиком - генеральным директором компании Waymo, специализирующейся на разработке автономных автомобилей.
Lean больше напоминает философию управления проектами и часто применяется в комплексе с другими гибкими инструментами управления проектами. На практике бережливое производство схоже со Scrum тем, что позволяет разбивать производственный процесс на подзадачи, но в Lean они реализуются независимо друг от друга, и отсутствуют чёткие границы этапов реализации работ по типу спринта (рисунок 6). Несмотря на это, бережливое производство предполагает, что каждая работа выполняется параллельно остальным, пока задача не будет выполнена в соответствие с заявленными требованиями.
Рисунок 6 - Общая схема работы по Lean [14]
Основная цель и вместе с тем достоинство Lean - достижение максимально оптимального использования ресурсов и получение качественного результата на каждом этапе работы над проектом. Добиться этого можно при следовании 2 основным принципам бережливого производства:
1) предоставление на всех этапах работы над продуктом его ценности клиенту. В итоге сформированная ценность принесёт прибыль самой компании;
2) выявление только необходимых производственных процессов и устранение всех видов потерь - то есть усилий и ресурсов, потраченных в пустую. Причем потери в бережливом производстве классифицируются по группам: defect - дефекты, overproduction - перепроизводство, waiting - потери на ожидание, not using employees creativity - невозможность использовать таланты сотрудников для достижения компанией поставленных целей, transport - информационные и материальные потоки, inventory - затраты на хранение и учет, motion - оптимизация, extra processing - совокупность реакций на достижение конкурентного преимущества [10].
Распространёнными инструментами бережливого производства в рамках гибкого управления проектами являются:
1. Andon - визуальная система, часто выражающаяся в звуковом оповещении или вывешивании специально подготовленной таблички, позволяющая каждому сотруднику своевременно оповещать о любой возникшей по ходу реализации проекта проблеме для её устранения в кратчайшие сроки и недопущения возникновения потерь [9].
2. Рассмотренный ранее принцип kaizen.
3. «Вытягивание» продукта, подразумевающее производство ровно того объёма продукции, который сможет полностью удовлетворить потребности клиента без формирования складских запасов или товарного дефицита.
4. Правило 5S (5 Sigma) - система организации рабочего пространства, позволяющая минимизировать процент брака на производстве. Включает в себя: «сортировку» - разделение предметов на нужные и ненужные с последующим устранением вторых; «соблюдение порядка» - организацию хранения вещей, нужных в процессе деятельности; «содержание в чистоте»; «стандартизацию» - закрепление на уровне регламентов и инструкций правил для первых трёх сигм и «совершенствование» - точное соблюдение прописанных правил и стремление к развитию и получению новых знаний.
5. Метод Poka - yoke или принцип нулевой ошибки (с японского «poka» - «ошибка» и «yokeru» - «избегать») - направлен на минимизацию ошибок, вызванных человеческим фактором, и подразумевает предоставление единственного шанса выполнить работу без дефектов через внедрение в рабочий процесс различных механизмов немедленного выявления ошибок.
Всё это позволит одинаково качественно выполнять каждую из итераций проекта согласно концепции бережливого производства. В связи с этим данный метод подходит организациям, работающим в сфере логистики, строительства или, например, медицины [3]. Однако к числу минусов Lean можно отнести:
- чрезмерно детальную проработку всех процессов, что совсем не подходит крупному или неоднородному проекту, где далеко не каждый процесс должен детализироваться с целью устранения потерь;
- отсутствие чёткого рабочего процесса для воплощения в жизнь отдельных частей проекта, что способно растянуть сроки его реализации при отсутствии должного уровня компетенций руководителя.[14]
Представленный обзор семейства гибких методов управления проектами может быть кратко представлен в таблице 1.
Таблица 1 - Сравнительная характеристика гибких методов управления проектами [10]
Критерий Название гибкого метода управления проектами
Scrum Kanban Lean
1 2 3 4
¡.Количество участников проекта 3-8 человек Неограниченное, но большая эффективность достигается с группой до 5 человек Неограниченное
2.Требования к рабочей группе Высокие требования. Универсальная и высокомотивированная команда Средние требования. Группа может обладать разным уровнем навыков, но желательна взаимозаменяемость Средние требования. Группа может обладать разным уровнем навыков
З.Используемые инструменты 1. Scrum-доска 2. Scrum-практики УП (встречи) 1. Kanban-доска 2. Карточки 3. Принцип kaizen 1. Andon 2. Принцип kaizen 3. Правило 5S 4. «Вытягивание» продукта 5. Метод Poka-yoke
4.Область применения 1. Проекты, где необходимо применение творческого подхода 2. Внедрение инноваций 3. Стартапы 1. Наукоёмкое производство; 2. Логистика Любая отрасль, где необходима жёсткая регламентация устранения потерь: логистика, строительство, медицина...
5.Достоинства 1. Быстрый запуск проекта с функциями, находящимися в приоритете благодаря правильной разбивке на короткие спринты; 2. Непрерывный контроль за выполнением работ; 3. Высокая вероятность удовлетворения итоговой потребности клиента из-за частых совещаний с ним; 4. Возможность внесения корректировок по ходу реализации проекта без высоких финансовых потерь, что даёт возможность «быстро ошибаться» и подстраиваться под изменения 1. Оптимизация работы благодаря принципу kaizen 2. Наглядность производственного процесса из-за визуализации 3. Сочетание подхода с другими гибкими методами УП без лишних финансовых затрат 1. Одинаково качественное выполнение всех итераций проекта 2. Сочетание с другими методиками гибкого УП
Продолжение таблицы
1 2 3 4
6.Недостатки 1. Сложность подбора кросс-функциональной, высокомотивированной команды проекта 2. Большое количество совещаний 3. Юридические сложности, связанные с заключением контрактов по разработке проектов, из-за отсутствия фиксированных бюджета и технического задания в методике Scrum 1. Плох для проектов с жёсткими сроками и слишком большим рабочим коллективом, превышающем 5 человек 2. Не предназначен для длительного горизонта планирования производственных мероприятий 3. Не позволяет оценивать эффективность работы отдельного сотрудника команды 1. Чрезмерно детальная проработка всех процессов, что не всегда нужно проекту и «тормозит» сроки; 2. Отсутствие чёткого рабочего процесса для воплощения в жизнь отдельных частей проекта, что способно растянуть сроки его реализации при отсутствии должного уровня компетенций руководителя
Заключение
Таким образом, на основание рассмотренной информации можно сделать общий вывод: в условиях постоянно меняющейся внешней среды и непостоянства требований заказчиков, для проектного менеджера на первый план всё чаще и чаще выходят гибкие методы управления проектами, позволяющие справиться с недостатками традиционной системы. Однако, также нельзя сказать, что Agile-философия универсальна и подходит любой организации - каждый гибкий метод управления проектами имеет свои особенности, достоинства и недостатки. Чтобы правильно выбрать инструмент реализации проекта, помимо общего понимания механизма его работы, необходимо иметь ясное представление об отрасли деятельности и специфике предстоящих работ.
Источники:
1. Большаков Н. Agile: что это такое и где используется, принципы и методология. [Электронный ресурс] // 2022 год. 19 января. URL: https://www.calltouch.ru/blog/agile-chto-eto-takoe-i-gde-ispolzuetsya-princzipy-i-metodologiya/
2. Горбунова К. Kanban/Agile/Scrum/Lean - гибкие методологии разработки. [Электронный ресурс] // 2021 год. 09 мая. URL: https://vc.ru/u/752307-karina -gorbunova/218436 -kanban-agile- scrum- lean-gibkie -meto dologii -razrabotki
3. Грачёв М. Что такое бережливое производство и зачем его внедрять. [Электронный ресурс] // 2021 год. 13 июля. URL: https://rb.ru/opinion/lean-manufacturing/
4. Завертайлов В. Scrum в деталях. От теории до практики. [Электронный ресурс] // URL: https://blog.sibirix.ru/scrum-in-details/
5. Зуйкова А. Что такое Agile и подойдёт ли он вашей компании. [Электронный ресурс] // РБК. 2022 год. 23 марта. URL: https://trends.rbc.ru/trends/education/6023fc369a79476e47b19ef0
6. Кочешков А. Agile. Методологии управления проектами. [Электронный ресурс] // 2019. 31 июля. URL: https://upr.ru/article/agile/
7. Найдис И.О. Метод Agile в управлении проектами: реализация метода, компетенции команды и руководителя проекта. [Электронный ресурс] // Вестник АГТУ Экономика. 2020. N 4. - стр. 15-24. URL: https://cyberleninka.ru/article/n/metod-agile-v-upravlenii-proektami-realizatsiya-metoda-kompetentsii-komandy-i-rukovoditelya-proekta/viewer
8. Сазерлен Д. Scrum. Революционный метод управления проектами. - М.: Манн, Иванов и Фердер, 2017 - 186 с.
9. Система Андон. [Электронный ресурс] // Leanbase. Практика внедрения бережливого производства. URL: https://leanbase.ru/knowledgebase/sistema-andon/
10. Терентьева З.С., Хализова И.А. Гибкие методы управления проектами, анализ и сравнение. // Азимут научных исследований: экономика и управление. 2019. Т. 8. № 1(26).
11. Что такое Agile, зачем и где используется, разница Scrum и Kanban. [Электронный ресурс] // URL: https://www.bigdataschool.ru/wiki/agile
12. Agile - манифест разработки программного обеспечения. [Электронный ресурс] // URL: https://agilemanifesto.org/iso/ru/manifesto.html
13. Kanban - как жить но цветным бумажкам. [Электронный ресурс] // URL: https://qahacking.ru/blog/kanban-kak-zhit-po-tsvetnym-bumazhkam
14. Pell A. Agile vs. Scrum vs. Kanban: What's the difference? [Электронный ресурс] // 2022 год. 31 мая. URL: Agile vs. Scrum vs. Kanban: what's the difference? | Zapier
15. Scrum - эффективный метод управления проектами. [Электронный ресурс] // 4brain. URL: https://4brain.ru/blog/scrum/
EDN: POSADM
М.В. Тодика -к.э.н., доцент кафедры общего стратегического информационного менеджмента и бизнес-процессов, Кубанский государственный университет, Краснодар, Россия, [email protected],
M.V. Todika -candidate of economic sciences, associate professor of the Department of General Strategic Information Management and Business Processes, Kuban State University, Krasnodar, Russia;
О.Н. Овсянникова - обучающаяся факультета управления и психологии, Кубанский государственный университет, Краснодар, Россия, [email protected],
O.N. Ovsyannikova-students of the Faculty of Management and Psychologists, Kuban State University, Krasnodar, Russia;
А.Г. Вербец - обучающаяся факультета управления и психологии, Кубанский государственный университет, Краснодар, Россия, [email protected],
A.G. Verbets - students of the Faculty of Management and Psychologists, Kuban State University, Krasnodar, Russia.
ОЦЕНКА ЭФФЕКТИВНОСТИ РАБОТЫ С ОБРАЩЕНИЯМИ ГРАЖДАН В ОРГАНЕ ИСПОЛНИТЕЛЬНОЙ ВЛАСТИ СУБЪЕКТА РФ ASSESSMENT OF THE EFFECTIVENESS OF WORK WITH CITIZENS' APPEALS IN THE EXECUTIVE AUTHORITY OF THE SUBJECT OF THE RUSSIAN FEDERATION
Аннотация. В данной статье описан анализ взаимодействия государственной системы с населением в рамках обработки обращений граждан и предоставления государственных и муниципальных услуг потребителям. Как ключевой орган исполнительной власти взят МФЦ, который на данный момент является одним из популярных среди населения пунктом обращения для получения необходимой информации, документации или услуги. Как итог проведенного анализа можно привести вывод о том, что в настоящих условиях МФЦ теряет свою актуальность среди населения и несет в себе неоправданные затраты государства на его обслуживание. Различные государственные цифровые платформы, наиболее успешным из которых является портал «Госуслуги», с каждым годом все больше набирают популярность и доверие среди населения. Они ориентированы на полное сопровождение разных обращений населения.
Absrtract. This article describes the analysis of the interaction of the state system with the population in the framework of processing citizens' appeals and providing state and municipal services to the population. The IFC has been taken as a key executive authority, which is currently one of the most popular points of contact among the population for obtaining the necessary information, documentation or services. As a result of the analysis, it can be concluded that in the present conditions, the MFC is losing its relevance among the population and carries unjustified government costs for its maintenance. Various government digital platforms, the most successful of which is "Public Services", are gaining popularity and trust among the population every year and are focused on full support of various appeals from the population.
Ключевые слова: исполнительна власть, многофункциональные центры, население, цифровая экономика.
Keywords: executive branch, multifunctional centers, population, digital economy.
