Когда возникает вопрос: на какие методы мы опираемся в управлении проектами - гибкие методы или (классические) методы водопада? Сторонники этих двух подходов часто непримиримы, поскольку существуют аргументы за и против.
И какой подход в конечном итоге выбирается, часто зависит в первую очередь от культуры в компании и расстановки сил в ней, а не от того, какой подход целесообразен.
Картинная галерея
СОВЕТ ПО СЕМИНАРУ На семинаре «Agile Leadership» участники узнают о гибких ценностях, методах работы и методах применения в интерактивных упражнениях, семинарах, основных выступлениях и дискуссиях с опытными коллегами.
Следующая информация
Исследование: около половины всех проектов провалились
По этой причине в процессе формирования мнений и принятия решений обычно есть проигравшие, люди или области, которые воспринимают себя как таковые. И это часто приводит к постоянному конфликту, который часто приводит к провалу проекта. По крайней мере, это то, что предлагает исследование исследовательской компании Forrester. По ее словам, около половины всех (изменяющихся) проектов в компаниях терпят неудачу, и «организационное столкновение» методов не несет за это значительной ответственности.
Классическое управление проектами на основе модели водопада
Согласно модели водопада, проект состоит из четко определенных последовательных этапов; это также имеет место с V-Modell, дальнейшим развитием модели водопада. Основными этапами модели водопада, например, в разработке программного обеспечения, являются:
- 1. Анализ
- 2. Дизайн
- 3. Реализация
- 4. Тест и
- 5. Операция
Этап проекта 1: создание спецификаций и спецификаций
На этапе 1 «Анализ» требования сначала полностью документируются для разработки спецификации или спецификации. Только после этого составляется план проекта и определяются возможные расходы. Большие задачи делятся на маленькие подзадачи в процессе планирования проекта, и все задачи связаны с течением времени и результатами.
От концепции решения до конечного продукта
На этапе проектирования (этап 2) разрабатывается концепция решения. В программных проектах это архитектура и дизайн системы. Фаза реализации (фаза 3) охватывает все программирование требований на основе спецификации и в рамках плана проекта. Результатом этапа внедрения является программный продукт, который впервые тестируется как общий продукт на следующем этапе тестирования (этап 4) (альфа-тестирование). Обычно это делают сами разработчики.
Совет: встреча пользователей для проектирования машины. Доступность и производительность, гибкость, адаптивность - по сей день дизайнеры и разработчики достигают этих целей, используя классические технологии и методы. Однако, учитывая растущую цифровизацию и сетевое взаимодействие машин и систем, возникает вопрос: где доступны новые концепции машин, где проверенные технологии продемонстрируют свои сильные стороны в будущем? Встреча пользователей машиностроения хочет прояснить эти вопросы и показать конкретные решения.
Регистрация: встреча пользователей машиностроения
Затем программное обеспечение передается выбранным конечным пользователям в виде бета-версии, и только здесь можно увидеть, соответствует ли продукт ранее определенным требованиям и ожиданиям пользователей. После успешного завершения фазы тестирования программное обеспечение запускается для работы или создается выпуск. Использование программного обеспечения и пятый и последний этап модели (операции) начинаются с момента выпуска. Любые возникающие ошибки исправляются и вносятся необходимые улучшения и дополнения.
Минимизировать риски проекта с точки зрения затрат и сроков
Теоретически, водопад или V-Modell должны избегать проектных рисков с точки зрения затрат и сроков. Поэтому его использование целесообразно для проектов, в которых ничего не меняется в будущем и в которых почти нет изменений. Проекты, которые повторяются по структуре и задаче и занимают управляемый период времени, являются идеальными. Это часто регулируемые проекты
- где важно соблюдать законы и правила, и
- где требуется обширная документация, например, в фармацевтической промышленности или медицинской технике.
Agile методы
Разработка программного обеспечения и технологии транспортных средств: спринты соответствуют уровням интеграции
Риски водопадного метода
Однако опыт показывает, что, например, только несколько программных проектов подпадают под эти параметры. Вот почему метод водопада таит в себе много рисков при разработке программного обеспечения. Ситуация аналогична почти для всех крупных проектов изменений и преобразований в компаниях, в том числе потому, что в большинстве случаев необходимо также разработать и / или внедрить подходящее поддерживающее программное решение. Это одна из причин, почему многие компании ищут другие подходы к управлению проектами.
Другое: Сложность требований и существующие взаимодействия в системе мешают многим проектам планировать четкие фазы проекта. Кроме того, существует быстро меняющаяся среда с новыми взглядами и влияниями, которые нельзя планировать. Незапланированные процессы, новая информация и сложные структуры в классическом управлении проектами часто приводят к тому, что проекты должны быть остановлены и перестроены. Это приводит к резким изменениям сроков и затрат.
Гибкое управление проектами: ответ на повышенную сложность
Гибкое управление проектами - например, в разработке программного обеспечения - в основном использует модель Scrum. Это в отличие от водопада или V модели. Основное различие заключается в том, что (разработка) проекта не планируется от начала до конца, а процедура следует видению. Это исключает подробные требования и спецификации требований. Кроме того, процедура
- постепенно, то есть небольшими пошаговыми шагами, и
- итеративный, то есть он имеет место в циклах отражения и повторения.
СОВЕТ ПО СЕМИНАРУ Семинар «Обучение по ТРИЗ 1-го уровня: систематический поиск идей и решение проблем» в академии строительной практики позволяет проектировщикам и инженерам использовать инструменты ТРИЗ для быстрого и более эффективного решения своих проблем строительства и разработки, а также для того, чтобы делать больше и лучше придумывать новые идеи.
Информация и регистрация: www.b2bseminare.de/konstruction/triz-training-level-1
Проект Scrum имеет три основных элемента:
- отставание продукта,
- отставание спринта и
- приращение продукта.
Однако основное внимание уделяется заинтересованным сторонам (клиентам / пользователям) и пользовательским историям. Пользовательские истории описывают требования к конечному продукту или решению проблем с точки зрения пользователя. Они обычно пишутся владельцем продукта - человеком, который в конечном счете отвечает за работу команды разработчиков и качество конечного продукта - с заинтересованными сторонами. Пользовательские истории определяются параллельно с развитием в текущем процессе.
Прозрачность и общение в команде разработчиков
В гибком управлении проектом сам проект не делится на фазы, а представляет собой последовательность из трех-четырехнедельных спринтов. В них пользовательские истории назначаются командам разработчиков, каждая из которых может себе позволить команда за это время. Ежедневные короткие встречи, называемые ежедневными газетами, служат прозрачности и общению внутри Scrum и команд разработчиков. Проблемы решаются там и, при необходимости, решаются немедленно. Когда спринт заканчивается, приращения разработанного продукта доступны команде Scrum и заинтересованным сторонам, например, в виде исполняемого программного обеспечения. Следующий спринт может быть начат.
Agile действий не является гарантией успеха
Модель Scrum возникла из знания, что многие программные и ИТ-проекты сегодня очень сложны и подвержены постоянным изменениям в ходе проекта. Кроме того, требования и требования часто неясны в начале. Однако гибкий подход не является гарантией успеха. Многочисленные проекты показывают это. Основным недостатком Scrum-проектов является оценка историй разработчиками. Они часто слишком оптимистичны. Поэтому цели спринтов не достигнуты. Это затрудняет планирование и планирование проекта на более длительный период. Определенная степень безопасности планирования обычно существует только за один или максимум два спринтерских цикла.
Фактор успеха: зрелость и однородность команды разработчиков
Ключевым фактором успеха в гибких проектах является зрелость и однородность команды разработчиков. На практике это требование часто едва учитывается; По крайней мере, в организациях, которые переходят от традиционного планирования к гибкому. Они часто недооценивают связанные культурные и организационные проблемы.
Компании с переходной экономикой в управлении проектами
Сегодня большинство компаний не являются ни гибкими, ни гибкими. Потому что они годами сталкиваются с повышенной сложностью и ищут способы более гибко реагировать на новые вызовы. Привлечение сотрудников в основном рассматривается как ключ к большей гибкости и повышению эффективности. А гибкие подходы «опробованы» в надежде на более качественные и индивидуальные решения.
Параллельные миры в управлении проектами
По этой причине в компаниях часто возникают «гермафродиты» в управлении проектами: на работу приходят новые сотрудники с обещанием гибкого, самоопределенного способа работы. В то же время, однако, старые структуры и классическое управление проектами «живут» в организации: в управлении проектами существуют, так сказать, параллельные миры. Это нормально на переходном этапе и требует управления. Это особенно верно, если лица, принимающие решения в области ИТ или управления, достаточно критичны или ждут гибкого управления проектами.
Задача: управлять параллельными мирами
Четкая связь параллельных миров является основой, на которую компании должны полагаться в переходной фазе, потому что ясно одно: невозможно переключить знаменитый переключатель, чтобы перейти от классического управления к гибкому управлению проектами. И если бы дело было в том, что с исключительно гибким управлением проектами все проблемы были устранены, то компании допустили бы большие ошибки на протяжении десятилетий. У проворных проектов тоже есть проблемы, но есть и другие. Поэтому важно четко указать, какие проекты выполняются в соответствии с какими правилами, и это также требует знания различных типов проектов, таких как рутина, инновационные проекты, принятие и изменение или изменение проектов.
Видимые промежуточные результаты для клиентов и пользователей
Гибкое управление проектами направлено на непосредственное вовлечение клиентов и пользователей в процесс разработки или решения проблем и быстрого достижения видимых промежуточных результатов; Классическое управление проектами, с другой стороны, фокусируется на комплексном планировании и документировании до начала проекта. Раздражение происходит в компаниях, когда, например, новых сотрудников привлекают «на борт» с обещанием гибкости, но затем они сталкиваются с классическим подходом к управлению проектами. Эти раздражения снижают производительность.
Когда какое управление проектом подходит?
Поскольку оба подхода оправданы, возникает вопрос: когда один, а когда другой? Чтобы ответить на этот вопрос, необходимо четкое общение; Кроме того, понимание «и того, и другого» должно быть достигнуто на уровне управления. В любом случае, опытные менеджеры проектов играют в обоих сегментах. Практика показывает, что если обе стороны - то есть «сторонники» и «противники» различных подходов к управлению проектами - мало понимают друг друга и, следовательно, появляется очевидная гибкость, это худший путь. Поэтому важно, чтобы заинтересованные стороны и участники проекта получили необходимое понимание двух подходов: тогда может быть недогматичным и ориентированным на успех решать, какой принцип применим к какому проекту.
Управление гибридными проектами: объединение лучшего из двух миров
Гибридное управление проектами направлено на создание оптимальной рабочей среды для команд - без догм. Вот почему методы и инструменты из обоих миров используются в гибридных проектах.
В начале гибридного управления проектом есть фаза анализа: но не в целом по проекту, а в довольно грубой грануляции. Этот этап сопровождается общим проектированием системы. Теперь грубая грануляция разделена на этапы проекта, и с этого момента гибкие методы используются, и анализ, проектирование, реализация, тестирование и альфа-операции выполняются параллельно. Регулярные ежедневные газеты гарантируют, что все участники могут синхронизироваться.
Классический водопад как спринт
В гибридном управлении проектами фазы водопада делятся на итерации, то есть спринты. Все этапы классической модели водопада могут происходить в спринте. Например, анализ может быть детализирован как часть спринта, как и дизайн системы. Это создает пользовательские истории для следующего спринта в текущем спринте. Точно так же в спринте разработка, тестирование и в конце спринта также ввод в эксплуатацию альфа-версии результата спринта. Тем не менее, все методы гибкого подхода заложены в принципах водопада.
Обзор и ретроспектива заменяет статус встречи
Вместо статусной встречи спринт заканчивается обзором и ретроспективой до начала следующего спринта. Весь полученный опыт ставится на стол и сравнивается со всем последующим проектом. Это может означать, что сроки должны быть отложены, ресурсы скорректированы, а ожидания изменены. Но здесь важно то, что риски проекта уменьшаются с каждой итерацией и не становятся очевидными до конца проекта.
Управление изменениями является одним из них
Из того, что было написано, следует, что взаимодействие гибких и традиционных методов проектов представляет собой естественный шаг развития в усилиях по повышению гибкости компаний и сопровождается изменением культуры и структуры в организации. По этой причине этот процесс должен контролироваться сознательно, целенаправленно и спланировано профессиональным управлением изменениями. Задача управления состоит в том, чтобы обеспечить сосуществование новых и традиционных способов работы в проектах и создать необходимую основу для этого. Это также включает в себя информирование о различных ролях, которые играют в различных проектах, и обеспечение максимально возможной прозрачности.
Открытость и беспристрастность как основа
Для многих «последователей» гибкого метода или классического управления проектами стало вопросом веры, какой подход заслуживает приоритета в проектах. Культура открытости и беспристрастности является здесь преимуществом. Важно создать межведомственные, функциональные и иерархические структуры в компании.
* Райнер Маркварт - старший консультант и специалист по разработке программного обеспечения в отделе управления, д-р. Краус и Партнер, Брухзаль (www.kraus-und-partner.de); Александр Пифчик - старший консультант и партнер Dr. Kraus und Partner с акцентом на изменения и управление проектами.