Руководитель проекта и методологии управления
Дата статьи
17 октября 2025г.
Автор статьи
Ольга Всеволодова
Время на прочтение
2 минуты
Всем привет)
Продолжим наше общение. В третьей статье я хочу поговорить про методологии проектного управления. Как и каждый производственный процесс, в результате которого создается какой- либо продукт, проектное управление тоже имеет свою методологию, по сути, технологию взаимодействия с результатом в виде целевого продукта.
На текущий момент, все проектные методологии можно разделить на: традиционные (Waterfall), классические (PMBOK), гибкие (Agile, Scrum, Kanban) и процессные (Lean, Lean Six Sigma, Prince2). Но так как все мои статьи посвящены теме РП в ИТ, то и акцентировать внимание я буду именно на этом направлении.
И так, с чего же всё начинается и чем отличается проектное управление в ИТ, какие у него основные аспекты.
Мы живем в эпоху начала пятой технологической революции (Индустрия 5.0), когда роботизация и ИИ тесно входят в обычную жизнь человека и сроки создания ИТ продуктов максимально сократились, но остаются основные этапы, через которые происходит создание любого ИТ продукта:
Игнорирование любого из перечисленных этапов, приводит к хаосу и бардаку, отсутствию результата и постепенному выгоранию проектной команды, поэтому, как бы ни критиковали традиционный каскадный подход (Waterfall), но именно эти шаги надо пройти, чтобы достигнуть нужной цели, и все гибкие методологии — это по сути тот же Waterfall, только с большим количеством повторяющихся сокращенных циклов тех же самых этапов. И опять же, когда принижают каскадный подход за длительность этапов, любой опытный руководитель, доводивший проекты до нужного результата, скажет, что длительность и негибкость на каждом из этапов – это непозволительная роскошь, и чтобы достичь нужного результата, постоянно сверяешься с заказчиком, показывая, что сделали, и устраняешь замечания, быстро реагируешь на изменения, понимая и помня о главной цели проекта.
То есть, в целом, проектное управление в ИТ в успешном проекте – это каскадный подход (Waterfall) с большим количеством повторяющихся циклов с активным участием заказчика и пользователей (Agile).
Я постоянно подчеркиваю, что говорю про успешность проекта, т.к. исхожу из того, что проекты стартуют для достижения своих целей, и в моей практике только такие проекты, но есть и другие результаты, когда перечисленные мною условия успешности не соблюдаются и проекты приносят разочарование и убытки. Поэтому мои статьи – это статьи «… опыт, сын ошибок трудных….», как сказал наш великий классик, выжимки и сливки опыта, когда на практике остается только то, что реально работает.
Продолжим наше общение. В третьей статье я хочу поговорить про методологии проектного управления. Как и каждый производственный процесс, в результате которого создается какой- либо продукт, проектное управление тоже имеет свою методологию, по сути, технологию взаимодействия с результатом в виде целевого продукта.
На текущий момент, все проектные методологии можно разделить на: традиционные (Waterfall), классические (PMBOK), гибкие (Agile, Scrum, Kanban) и процессные (Lean, Lean Six Sigma, Prince2). Но так как все мои статьи посвящены теме РП в ИТ, то и акцентировать внимание я буду именно на этом направлении.
И так, с чего же всё начинается и чем отличается проектное управление в ИТ, какие у него основные аспекты.
Мы живем в эпоху начала пятой технологической революции (Индустрия 5.0), когда роботизация и ИИ тесно входят в обычную жизнь человека и сроки создания ИТ продуктов максимально сократились, но остаются основные этапы, через которые происходит создание любого ИТ продукта:
- Инициация – всё начинается с какой-либо идеи или потребности;
- Определение – формируется видение будущего продукта;
- Проектирование – определяется технология создания продукта (как, где, на чем);
- Разработка – делаем, что определили;
- Тестирование – проверяем, что сделали;
- ОПЭ – привлекаем пользователей в тестирование;
- ПЭ – старт эксплуатации продукта пользователями;
- Сервисная поддержка продукта.
Игнорирование любого из перечисленных этапов, приводит к хаосу и бардаку, отсутствию результата и постепенному выгоранию проектной команды, поэтому, как бы ни критиковали традиционный каскадный подход (Waterfall), но именно эти шаги надо пройти, чтобы достигнуть нужной цели, и все гибкие методологии — это по сути тот же Waterfall, только с большим количеством повторяющихся сокращенных циклов тех же самых этапов. И опять же, когда принижают каскадный подход за длительность этапов, любой опытный руководитель, доводивший проекты до нужного результата, скажет, что длительность и негибкость на каждом из этапов – это непозволительная роскошь, и чтобы достичь нужного результата, постоянно сверяешься с заказчиком, показывая, что сделали, и устраняешь замечания, быстро реагируешь на изменения, понимая и помня о главной цели проекта.
То есть, в целом, проектное управление в ИТ в успешном проекте – это каскадный подход (Waterfall) с большим количеством повторяющихся циклов с активным участием заказчика и пользователей (Agile).
Я постоянно подчеркиваю, что говорю про успешность проекта, т.к. исхожу из того, что проекты стартуют для достижения своих целей, и в моей практике только такие проекты, но есть и другие результаты, когда перечисленные мною условия успешности не соблюдаются и проекты приносят разочарование и убытки. Поэтому мои статьи – это статьи «… опыт, сын ошибок трудных….», как сказал наш великий классик, выжимки и сливки опыта, когда на практике остается только то, что реально работает.