8 проверенных критериев выбора методологии управления проектами

1. Критерий 1 - Знание решения
2. Критерий 2 - Размер проекта
3. Критерий 3 - Стабильность требований
4. Критерий 4 - Доступность для клиентов
5. Критерий 5 - Допуск на изменения в бюджете и сфере действия
6. Критерий 6 - Время доставки
7. Критерий 7 - Команда
8. Критерий 8 - Интеграция с внешними системами
9. Критерий 9 - предпочтения клиента
10. Автор записи

Вероятно, каждый из читателей познакомился с концепцией методологии - то есть набор общих принципов управления проектами. Разработанных методологий в настоящее время очень много. Поэтому выбрать правильный вариант нелегко. Каким критериям нужно следовать при выборе? Нужно ли руководствоваться при выборе методологии (см. Популярные маркетинговые лозунги) Мы проворные «У нас есть Scrum в крови»)? Вы уверены, что все проекты могут быть реализованы с помощью гибких методологий? Я постараюсь ответить на вопросы в дальнейшей части статьи.

Критерий 1 - Знание решения

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

Критерий 2 - Размер проекта

Рекомендуется использовать классические методологии для больших и очень больших проектов. В этом случае трудно представить, что многомиллионные проекты будут реализованы без известной цели и решения. Гибкие методологии лучше подходят для небольших проектов . Ничто, однако, не препятствует тому, чтобы весь проект управлялся классическим способом, создавая гибкие модули. Это называется гибридная модель. В этом случае весь проект делится на подпроекты, каждый из которых может управляться с использованием другой методологии.

Различия и сходства между традиционными, гибкими и гибридными моделями

Критерий 3 - Стабильность требований

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

Критерий 4 - Доступность для клиентов

Теоретически, в случае традиционных методологий, клиент может быть доступен команде проекта только во время приемочных и приемочных испытаний. На практике, однако, участие клиента требуется, по крайней мере, на этапе анализа требований (см. Термины, часто встречающиеся в Спецификации основных условий заказа, утверждение «следующий пункт будет подробно описан на этапе анализа»). В то время как в классических методологиях нет необходимости связываться с клиентом на протяжении всей жизни проекта, в гибких методологиях клиент является неотъемлемой частью команды проекта и постоянно поддерживает разработчиков. Поэтому его доступность является ключевым фактором при выборе методологии. Однако мне лично известны случаи, когда сотрудники подрядчика выступают в роли владельца продукта. Однако это очень редкие случаи, требующие большого доверия между клиентом и внешней компанией.

Критерий 5 - Допуск на изменения в бюджете и сфере действия

Проекты, реализованные в классических методологиях, всегда имеют строго определенный объем и стоимость - они выполняются по фиксированной цене. В случае гибких методологий из-за меняющихся требований и приоритетов сложно оценить общую стоимость проекта. Поэтому, если бюджет клиента постоянен и не может быть увеличен, функции с наивысшим приоритетом предоставляются в конце проекта. Другими словами, объем работ может быть изменен / уменьшен. Осведомленность клиента в этом отношении имеет решающее значение, и отсутствие понимания этого вопроса всегда вызывает проблемы.

Критерий 6 - Время доставки

Основное предположение классических методологий - предоставить клиенту готовое решение только в конце проекта. В случае гибких методологий полное, рабочее решение является конечным результатом каждой итерации. Поскольку итерации длятся от 1 до 4 недель, существует возможность быстрого внедрения новых функций.

Критерий 7 - Команда

Компетенции проектной команды являются одним из наиболее важных факторов при выборе методологии. В идеальном мире каждая команда состоит из компетентных и опытных людей, но в эпоху постоянных проблем с ресурсами это не так очевидно. Если вы выбираете методологию, зная, что в вашем распоряжении более слабая команда, выберите классическую методологию. В гибких методологиях команда называется «Самоорганизующийся организм», должен быть опытным, долго знать, уметь оценивать задачи, иметь хорошие коммуникативные навыки. В случае классических методологий нехватка команды может быть уравновешена руководящей командой менеджеров. Они могут внести изменения в распределение задач в команде, что, в свою очередь, не должно происходить в командах, работающих над проектами, реализованными с использованием гибких методологий.

Критерий 8 - Интеграция с внешними системами

Этот момент может показаться неразборчивым, поскольку большинство систем теперь интегрируются с другими системами. Однако для крупных проектов, где много приложений создаются одновременно и которые должны взаимодействовать друг с другом, например, с использованием шины данных, лучшим выбором является использование классической методологии. Благодаря этому у нас всегда будут определенные способы общения, и команда сможет выполнить соответствующие макеты . В случае гибких методологий существует очень высокий риск блокирования работы команды из-за недостатков со стороны других модулей. Здесь стоит упомянуть, что часто модули / приложения создаются разными компаниями, что облегчает синхронизацию работы.

Критерий 9 - предпочтения клиента

Знание методологий клиентом является ключом к успеху проекта. Реализация проекта по неизвестной клиенту методологии вызовет хаос и раздражение. Поэтому из-за сложностей с изменением осведомленности клиентов (обучение не всегда возможно, команда проекта часто составляет десяток человек), стоит адаптировать его к своим предпочтениям. Много раз у нас тоже нет выбора - методология навязывается непосредственно требованиям клиента.

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

Автор записи

Томаш Крупа

Руководитель проекта

Он отвечает за реализацию польских и зарубежных проектов, управляя проектным циклом от ценообразования, анализа, реализации и технического обслуживания. Он является предметом специалистов, специализирующихся как на веб-технологиях (ASP.NET MVC), так и на мобильных устройствах (Windows Phone), услугах (веб-API, WCF, веб-службы) и занимающихся настройкой решений Microsoft (CRM, SharePoint, Biztalk).