Добавлен: 06.07.2023
Просмотров: 66
Скачиваний: 1
Введение
В конце 50-х годов в США для осуществления программы исследовательских и конструкторских работ по созданию ракеты “Поларис” впервые был использован метод планирования и управления, основанный на идее определения, оценки вероятных сроков и контроля так называемого “критического пути” всего комплекса работ.
Результаты превзошли все ожидания: во-первых, заметно уменьшилось число сбоев в работе из-за несогласованности используемых ресурсов, резко сократилась общая продолжительность выполнения всего комплекса работ, получен огромный эффект из-за снижения суммарной потребности в ресурсах и, соответственно, уменьшения общей стоимости программы.
Вскоре после того, как результаты выполнения программы “Поларис” стали достоянием общественности, весь мир заговорил о методе PERT (Project Evaluation and Review Technique) как о новом подходе к организации управления.
За прошедшее с тех пор время метод “критического пути” не только получил широкое применение в повседневной практике управления, но и обусловил появление специальной научно-прикладной дисциплины – управление проектами.
Предмет дисциплины - вопросы планирования, организации, контроля и регулирования хода выполнения проектов, организации материально-технического, финансового и кадрового обеспечения проектов, оценки инвестиционной привлекательности различных вариантов реализации проектов.
В современной деловой среде актуальность проектного управления как метода организации и управления производством значительно возросла. Это обусловлено объективными тенденциями в глобальной реструктуризации бизнеса.
Принцип концентрации производственно-экономического потенциала уступил место принципу сосредоточения на развитии собственного потенциала организации.
Объект проектного управления. Термин проект, как известно, происходит от латинского слова projectus, что в буквальном переводе означает “брошенный вперед”.
Таким образом, сразу становится ясно, объект управления, который можно представить в виде проекта, отличает возможность его перспективного развертывания, т.е. возможность предусмотреть его состояния в будущем.
Хотя различные официальные источники трактуют понятие проекта по-разному, во всех определениях четко просматриваются особенности проекта как объекта управления, обусловленные комплексностью задачи работ, четкой ориентацией этого комплекса на достижение определенных целей и ограничениями по времени, бюджету, материальным и трудовым ресурсам.
Однако, любая деятельность, в том числе и та, которую никто не собирается называть проектом, выполняется в течение определенного периода времени и связана с затратами определенных финансовых, материальных и трудовых ресурсов.
Кроме того, любая разумная деятельность, как правило, целесообразна, т.е. направлена на достижение определенного результата.
И, тем не менее, в одних случаях к управлению деятельностью подходят как к управлению проектом, а в других случаях – нет.
Деятельность как объект управления рассматривается в виде проекта тогда, когда • она объективно имеет комплексных характер и для ее эффективного управления, важное значение имеет анализ внутренней структуры всего комплекса работ (операций, процедур и т.п.);
• переходы от одной работы к другой определяют основное содержание всей деятельности;
• достижение целей деятельности связано с последовательно-параллельным выполнением всех элементов этой деятельности;
• ограничения по времени, финансовым, материальным и трудовым ресурсам имеют особое значение в процессе выполнения комплекса работ;
• продолжительность и стоимость деятельности явно зависит от организации всего комплекса работ.
Поэтому, объектом проектного управления принято считать особым образом организованный комплекс работ, направленный на решение определенной задачи или достижение определенной цели, выполнение которого ограничено во времени, а также связано с потреблением конкретных финансовых, материальных и трудовых ресурсов.
При этом под “работой” понимается элементарная, неделимая часть данного комплекса действий. Элементарность работы – понятие условное и относительное.
То, что нецелесообразно делить в одной системе действий, полезно разукрупнять в другой. Например, если за элемент комплекса работ по сборке автомобиля принимается технологическая операция, то одной из “работ” может считаться установка сборщиком фары.
Эта “работа” в данном случае неделима, так как остаются неизменными ее факторы – исполнитель, предмет и объект действия. Но, как только мы начинаем рассматривать исполнение этой работы как отдельную задачу, она сама превращается в комплекс.
Управление проектом – искусство руководства и координации людских и материальных ресурсов на протяжении жизненного цикла проекта для достижения определенных в проекте результатов по составу и объему работ, стоимости, времени, качеству и удовлетворению участников проекта.
Успешное выполнение проекта определяется выполнением ряда установленных критериев: сроки завершения проекта, стоимость и бюджет проекта, качество выполненных работ и спецификации требований к результатам, степень удовлетворения заказчиков.
Работа по управлению проектом включает ряд относительно независимых процессов: - процессы инициации (разработка концепции, ТЭО, утверждение проекта), - процессы планирования (определение целей и критериев успеха, разработка рабочих схем, планов, алгоритмов и т.д.), - процессы выполнения (организация и реализация процессов выполнения плана проекта), - процессы контроля и анализа, - процессы завершения.
Осуществление любой части проекта требует реализации определенных функций управления. Выделяют базовые и интегрирующие функции. К базовым функциям относятся:
1. Управление предметной областью проекта, или содержательной сущностью. Осуществляется через процессы определения целей и заключается в разработке концепции, планировании, учете, контроле выполнения проекта.
2. Управление качеством. Охватывает весь жизненный цикл проекта и включает оценку результатов работы всех участников проекта, начиная с качества управленческих решений и заканчивая качеством и соответствием конечной продукции проекта существующим стандартам.
3. Управление временными ресурсами – определение сроков начала и завершения проекта и его частей, оптимизация использования бюджет времени. Здесь используются методы календарного планирования, контроля графиков выполнения работ.
4. Управление стоимостью – оценка расходов, составление сметы расходов, определение источников финансирования и контроль за соблюдением финансового и материального бюджета.
К интегрирующим функциям относятся:
1. Управление персоналом проекта – подбор, привлечение и подготовка (переподготовка) специалистов.
2. Управление коммуникациями (взаимодействиями и информационными связями). Необходимо для организации мониторинга и контроля над ходом выполнения проекта, интерпретации полученной информации и прогнозирования.
3. Управление контрактами – определение состава привлекаемых к контракту субъектов, выбор контрагентов и поставщиков, заключение контрактов и контроль над ходом их выполнения.
4. Управление риском. Заключается в прогнозировании неопределенности, предупреждении негативных воздействий возмущающих событий (страхование, диверсификация, хеджирование), а также оценке ущербов и устранении последствий при их возникновении. Для успешной реализации данных функций в управлении проектами используют ряд методов.
Наиболее распространенными являются сетевые методы планирования. Сетевой график – информационно-динамическая модель, связывающая различные работы, необходимые для достижения целей проекта.
Основными элементами сетевого графика являются работы и события. Сетевые графики используются для решения задач управления, связанных с управлением временем и различными ресурсами.
При этом используются следующие методы: -метод критического пути (определение продолжительности критического пути, критических работ, а также резервов времени некритических работ и событий), - PERT-анализ – в дополнение к вышеперечисленным задачам, реализуя вероятностные методы, позволяет определить также оценку возможных отклонений от результатов, полученных по методу критического пути, вероятность того, что проект завершится не позднее установленного срока и т.д.
AGILE – гибкая система управления проектами
Приходилось ли вам когда-нибудь заниматься проектами или хотя бы принимать участие в проектной работе? Если да, то наверняка вы заметили, что наладить работу команды может быть достаточно сложно. И даже если она налажена, есть риск, что все усилия окажутся напрасными, ведь требования к необходимому результату часто меняются.
Однако существенно упростить работу над проектом и научиться им управлять, тем самым повысив эффективность команды, можно при помощи системы гибкого управления проектами под названием Agile («Аджайл» или «Эджайл»).
Метод Agile: определение и краткая история
Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.
Вместо того чтобы ждать, пока будут поочередно завершены все этапы (фазы), Ройс предложил применять фазовый подход. Суть его в том, что изначально собираются все требования, необходимые для проекта, после чего завершается вся архитектура, создается дизайн, записывается код и т.д.
На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:
- В 1991 году появился метод быстрой разработки приложений RAD
- В 1994 году появился метод разработки динамических систем DSDM
- В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
- В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
- В 1997 году появилась итеративная методология разработки ПО FDD
Все вместе эти методы объединились под общим названием гибких методов разработки ПО.
Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.
Манифест Agile
Манифест, созданный программистами, включает в себя 4 базовых идеи и 12 принципов эффективного управления проектами. Любая из систем управления проектами на основе Эджайл (о системах мы поговорим позже) опирается именно на эти идеи и принципы, хотя и использует их в разных вариациях.
Идеи Agile:
- Люди и их взаимодействие важнее, чем процессы и инструменты
- Рабочее ПО важнее, чем документация
- Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
- Готовность к внесению изменений важнее, чем первоначальный план
Принципы Agile:
- Удовлетворять клиентов, заблаговременно и постоянно поставляя ПО (клиенты довольны, когда рабочее ПО поступает к ним регулярно и через одинаковые промежутки времени)
- Изменять требования к конечному продукту в течение всего цикла его разработки
- Поставлять рабочее ПО как можно чаще (раз в неделю, в две недели, в месяц и т.д.)
- Поддерживать сотрудничество между разработчиками и заказчиком в течение всего цикла разработки
- Поддерживать и мотивировать всех, кто вовлечен в проект (если команда мотивирована, она намного лучше справляется со своими задачами, нежели команда, члены которой условиями труда недовольны)
- Обеспечивать непосредственное взаимодействие между разработчиками (возможность прямого контакта способствует более успешной коммуникации)
- Измерять прогресс только посредством рабочего ПО (клиенты должны получать только функциональное и рабочее программное обеспечение)
- Поддерживать непрерывный темп работы (команда должна выработать оптимальную и поддерживаемую скорость работы)
- Уделять внимание дизайну и техническим деталям (благодаря эффективным навыкам и хорошему дизайну команда проекта получает возможность постоянного совершенствования продукта и работы над его улучшением)
- Стараться сделать рабочий процесс максимально простым, а ПО – простым и понятным
- Позволять членам команды самостоятельно принимать решения (если разработчики могут сами принимать решения, самоорганизовываться и общаться с другими членами коллектива, обмениваясь с ними идеями, вероятность создания качественного продукта существенно возрастает)
- Постоянно адаптироваться к меняющейся среде (благодаря этому конченый продукт будет более конкурентоспособен)