Этот раздел открывают, когда проблема уже не в одном навыке и не в одном инструменте, а в самом рабочем подходе. Команда что-то делает, но непонятно, по какой логике живёт поток поставки, как устроены роли, какие ритуалы действительно нужны, где заканчивается полезный фреймворк и начинается тяжёлая процессная декорация.
Методологии и фреймворки не дают магического контроля над проектом. Но они помогают PM не собирать управление заново каждый раз с нуля: дают язык для ролей, ритмов, качества, приоритизации, релиза и принятия решений. Сильный уровень здесь не в том, чтобы «знать Scrum» или «читать PMBOK», а в том, чтобы выбирать и адаптировать подход под реальный контекст проекта.
Структура раздела
4.1. Фреймворки проектного управления
4.2. Методологии поставки
4.3. Ритуалы поставки и командные ритмы
- Ритуалы поставки и командные ритмы
- Дейли
- Планирование
- Рефайнмент / grooming
- Ревью / демо
- Ретро
- Еженедельная синхронизация
- Ежемесячная синхронизация
4.4. Фреймворки и потоки поставки ПО
- Фреймворки и потоки поставки ПО
- SDLC
- Поток релиза
- Поток инцидентов / hotfix
- Разделение discovery / delivery
- Поток поддержки / сопровождения
4.5. Фреймворки организации работы и ответственности
- Фреймворки организации работы и ответственности
- RACI
- RAID log
- Карта стейкхолдеров
- Карта зависимостей
- Реестр рисков
- Процесс обработки change request
4.6. Фреймворки требований и качества
4.7. Фреймворки планирования и приоритизации
- Фреймворки планирования и приоритизации
- Планирование дорожной карты
- Планирование по вехам
- Планирование загрузки
- Модели приоритизации
- Сценарное планирование
4.8. Фреймворки релиза и приёмки
- Фреймворки релиза и приёмки
- UAT
- Чеклист релиза
- Практика подготовки release notes
- Коммуникация rollout / deployment
- Процесс финального согласования
Что важно помнить
Подход полезен только тогда, когда помогает реальному проекту:
- даёт понятные правила для принятия решений, а не добавляет ритуалы ради ритуалов;
- усиливает hard skills PM, а не подменяет их названиями фреймворков;
- поддерживает soft skills PM, а не маскирует слабую коммуникацию за процессной терминологией;
- учитывает размер команды, зрелость среды, тип проекта и реальную цену внедрения.
Поэтому страницы этого раздела будут не про догматичное «как правильно по учебнику», а про практический выбор: когда подход помогает, когда мешает, что из него реально брать PM и чем его можно заменить в более простом контуре.
Куда идти дальше
Если нужен общий каркас управления проектом, начинайте с фреймворков проектного управления. Если вопрос больше в том, как команда реально поставляет результат, идите в методологии поставки.