Стандарт vs методология: как не перепутать в управлении
Когда руководитель или владелец компании впервые сталкивается с необходимостью систематизировать работу над управлением проектами, он почти неизбежно встречает два термина, которые иногда употребляют как синонимы: «стандарт» и «методология». На деле это совершенно разные вещи, и путаница между ними приводит к ошибочным решениям: либо к избыточной бюрократии, либо к хаосу под видом «гибкости». Понимание разницы помогает выбрать правильный инструмент и не пытаться натянуть на реальный проект то, что ему заведомо не подходит.
Содержание:
- Что такое стандарт в управлении проектами
- Что такое методология
- Ключевая разница в одном предложении
- Ключевая разница по трем основным параметрам
- Главные отличия в таблице для наглядности
- Почему путаница опасна
- Как эффективно сочетать стандарты и методологии
- Вывод
Что такое стандарт в управлении проектами
Стандарты проектного управления, разработанные и принятые сообществом специалистов, – это согласованные своды знаний, терминов, процессов и лучших практик, которые описывают, что вообще должно присутствовать в грамотно управляемом проекте. Самые известные примеры:
- PMBOK (Project Management Body of Knowledge). Американский стандарт, поддерживаемый PMI.
- ICB (IPMA Competence Baseline). Европейский стандарт компетенций, на основе которого построена сертификация IPMA.
- P2M. Японский национальный стандарт для инновационных и государственных проектов.
Также сюда относятся ISO 21500, PRINCE2 (в части, где он выступает именно как база знаний), национальные стандарты ГОСТ Р54869-2011 и другие.
Стандарт не говорит «делай именно так и только так». Он говорит: «вот универсальный язык и карта местности». В PMBOK, например, вы найдете 49 процессов, разложенных по десяти областям знаний и пяти группам процессов. Но сам стандарт честно предупреждает: не все процессы нужны на каждом проекте, выбирайте и адаптируйте. То есть стандарт – это скорее справочник и система координат, а не инструкция по эксплуатации конкретного проекта.
Что такое методология
Методология – это уже конкретный способ вести проект от начала до конца. Это готовый «рецепт», последовательность действий, роли и правила принятия решений. В отличие от стандарта, методология четко отвечает на вопрос «как именно делать».
Классические примеры:
- Waterfall (каскадная модель). Все идет строго по фазам: требования → проектирование → реализация → тестирование → внедрение. Переход на следующую фазу – только после полного завершения предыдущей.
- Agile. Итеративно-инкрементальный подход, где требования и решения развиваются через совместную работу команды и заказчика, продукт поставляется небольшими рабочими порциями. Среди методологий управления проектами, которые руководствуются ценностями и принципами Agile, можно выделить Scrum, Kanban, XP.
- Lean (бережливое производство). Подход, который говорит: «Нещадно избавляйтесь от всего, что не добавляет дополнительной ценности, и делайте исключительно то, в чем есть полная уверенность». Устранение потерь по Lean – это устранение бесполезных совещаний, задач, этапов и документов.
Есть еще Critical Chain, PRINCE2 (в части управляемых этапов), SAFe и десятки других.
Методология управления всегда конкретна, например, если вы действуете по Agile, ваш проект будет развиваться строго по этапам. Если вы выбрали Scrum – у вас будут спринты по 2-4 недели, ежедневные стендапы, роли вроде Product Owner, Scrum Master и команда разработки. Вы не можете сказать «мы делаем Scrum, но без ретроспектив и демо-версии» – это уже будет не Scrum.
Ключевая разница в одном предложении
Резюмируя, стандарт отвечает на вопрос «из каких блоков состоит управление проектами в принципе», а методология – «в какой последовательности и по каким правилам мы будем проходить проект именно сейчас».
Ключевая разница по трем основным параметрам
Если же говорить конкретнее, то разницу между стандартом и методологией следует рассматривать в разрезе трех главных отличий.
Роли
Стандарт не предусматривает выделения ролей, вместо этого – рекомендации, кому и чем лучше заниматься. В методологии, напротив, роли четко выделены (например, Scrum Master) и распределяются перед стартом проекта.
Правила
Стандарт – полезное подспорье в работе: на него опираются, но всем рекомендациям, чтобы достичь результата, следовать не обязательно. Методология, как помним, предполагает противоположный подход: если выбросить один из элементов выбранной стратегии, проект сложится, как карточный домик. Простой пример: когда проект – разработка ПО и при этом используется методология управления Waterfall, исключив этап тестирования, на выходе, скорее всего, получится сырой продукт с целой кучей багов и непригодный для использования.
Последовательность действий
Стандарт – это, как помним, набор рекомендаций, а методология дает четкое понимание, что и за чем необходимо делать. У Waterfall это, собственно, этапы (что оправдывает название «каскадная модель»), у Scrum – короткие итерации (спринты) по 2-4 недели с последующим выпуском рабочей версии, получением обратной связи и внесением изменений.
Главные отличия в таблице для наглядности
| Параметр | Стандарт | Методология |
|---|---|---|
| Что это | Свод знаний и лучших практик | Конкретный способ ведения проекта |
| Обязательность | Рекомендательный характер | Предписывающий характер |
| Гибкость | Высокая, адаптируется под проект | Зависит от методологии (Waterfall – низкая, Agile – высокая) |
| Отвечает на вопрос | «Что должно быть?» | «Как именно делать?» |
| Примеры | PMBOK, ICB, P2M, ISO 21500 | Lean, Scrum, Kanban, Waterfall |
| Можно ли смешивать | Да, берутся процессы из разных стандартов | Как правило, плохо совместимы, но есть гибридные модели вроде Scrumban и Wagile |
Почему путаница опасна
Самая распространенная ошибка – пытаться внедрить стандарт как методологию. Руководитель читает PMBOK, видит 49 процессов и говорит: «С завтрашнего дня делаем все по книжке». В итоге – тонны ненужных документов, бесконечные совещания по управлению рисками на проекте по созданию лендинга и демотивированная команда.
Вторая ошибка – наоборот: объявить «мы теперь Agile» и полностью отказаться от любого планирования и документации, потому что «стандарты – это зло и бюрократия». Через год компания тонет в техническом долге, сроки срываются, а заказчики не понимают, за что платят.
Третья ошибка – путать сертификацию по стандарту с владением методологией. Сертификат PMP подтверждает, что специалист знает содержание PMBOK, но это не значит, что он умеет вести проекты по Scrum или хотя бы по Waterfall.
Как эффективно сочетать стандарты и методологии
Правильная последовательность выглядит так:
- Определите типы проектов в организации (строительство, разработка ПО, маркетинг, НИОКР и т.д.).
- Для каждого типа выберите наиболее подходящую методологию или даже гибрид (Scrumban, Wagile).
- Возьмите один или несколько стандартов как общий глоссарий и источник проверенных практик, которые можно «накладывать» на выбранную методологию.
- Зафиксируйте в корпоративном стандарте только те процессы и документы, которые действительно добавляют ценность именно вашим проектам.
Пример удачного сочетания: компания разрабатывает сложные корпоративные системы. Базовая методология – Scrum, но сверху «надстраивается» ряд процессов из стандартов: управление рисками и заинтересованными сторонами берется почти без изменений из PRINCE2, закупки и контракты – из PMBOK, а оценка компетенций команды осуществляется по ICB 4.0. В итоге получается гибкий, но предсказуемый и управляемый процесс.
Вывод
Стандарт и методология решают разные задачи и прекрасно уживаются, если не путать их роли. Стандарт дает общий язык, карту и набор проверенных инструментов, из которых можно выбирать. Методология – конкретный маршрут и правила движения для данного типа проектов. Попытка превратить стандарт в методологию приводит к бюрократии, а отказ от стандартов под видом «мы гибкие» – к беспорядку и потере управляемости. Оптимальная комбинация – один-два стандарта как фундамент и несколько отточенных методологий под разные задачи.