Встретились как-то начинающие проджекты в баре.
Вася: «А что такое scrum?»
Петя: «Ты реально не знаешь? Это же топовая методология».
Семён: «Какой ещё скам?»
Примерно так ощущает себя новичок в управлении проектами, когда сталкивается с десятком терминов на английском языке, с сотней нюансов и ограничений.
Но мало знать определения, нужно понимать, что из этого является методом, что — подходом, а что — фреймворком. Смешивать всё в одну кучу и называть любое понятие методом или инструментом попросту непрофессионально.
Разжевали важное в управлении проектами и принесли тебе на блюдечке с голубой каёмочкой. Материала много — для удобства пользуйся навигатором по разделам справа ➡️
Важная теоретическая часть
Метод (техника) — способ что-то сделать
Методология — набор методов и принципов, подкреплённых теорией
Методика (фреймворк) — готовый алгоритм применения методов для достижения конкретной цели
Подход (философская концепция) — свод общих принципов и ценностей в управлении проектами без чётких решений
А теперь готовься скриншотить.
| Термин | Чем является |
|---|---|
| Waterfall | Подход |
| Agile | Подход, философская концепция |
| Scrum | Методология Agile |
| Kanban | Метод Agile |
| Lean | Философская концепция |
| PRINCE2 | Методика |
| Six Sigma | Методология, но касается управления процессами, а не проектами |
Четыре подхода к управлению проектами
Подход — это база, философия, на которой держится управление проектами. Чёткие принципы и свод правил, которые определяют, как команда взаимодействует с заказчиком и между собой, чтобы получить результат.
Waterfall
Классический подход, его ещё называют каскадным. Ты выполняешь задачи по проекту одну за другой последовательно и не можешь начать новую, пока не закончишь предыдущую.
🌊 Waterfall — «водопад» в переводе с английского, потому что этапы проекта идут чётко друг за другом, как течёт вода. Нельзя плыть против течения. Если захочешь вернуться в предыдущую задачу, чтобы что-то поправить, то держи в уме, что это дорого тебе обойдётся. Таковы правила
Главное преимущество каскадного подхода — предсказуемость. Ещё до начала работы проект расписан до мельчайших деталей. У тебя на руках документы, где чёрным по белому прописаны: структура, этапы, чёткие дедлайны, фиксированный бюджет и договорённости с заказчиком.
Работа над любым проектом по Waterfall чётко разделена по фазам. Схема всегда будет одинаковой.
Преимущества и недостатки
| ✅ Да | ❌ Но |
|---|---|
| Лёгкий в понимании — можно просто идти по чёткой структуре и получить предсказуемый результат | Если в конце реализации обнаружишь ошибки — придётся откатиться назад, всё перепроверять и пересобирать проект заново |
| Все фазы по проекту и общение с заказчиком прописаны в документах. Никто не сможет устроить произвол и вводить новые правила там, где они не нужны | Бумажная волокита становится бюрократией — на составление кипы документов утекают время и силы |
| Сроки и расходы на проект определяют заранее — вся работа будет под контролем | Любое изменение во внешней среде — боль, потому что Waterfall тяжело адаптировать под форс-мажоры |
| Здорово, когда сразу понимаешь, какой должен быть результат, ведь его прописали в документах | Если во время разработки рынок кардинально поменяется, то к моменту выпуска продукт может стать неактуальным |
Agile
Реакция на несгибаемый подход Waterfall и его бесконечную бюрократию. В 2001 году 17 разработчиков в США придумали манифест Agile, который лёг в основу процесса разработки ПО.
Agile — это гибкость. Его основа — быстрая реакция на изменения в процессе работы. Не так важно, что написано в документах, главное — уметь договариваться и быстро реагировать на форс-мажоры
Подход уходит от чётких планов, аргументируя это тем, что куда важнее научиться подстраиваться под изменчивый мир и работать с тем, что есть сейчас
‼️ Важно: Agile — это подход, философия с чёткими принципами, но при этом он не даёт чётких инструкций к работе. Для этого существуют его фреймворки — Scrum и Kanban.
Подход Agile строится на базовых принципах:
- Итеративность — заказчик видит результат после каждого этапа работы. Работающий продукт сейчас ценнее идеального в отдалённом будущем
- Самоорганизация — команда сама решает, как достичь поставленных целей, без микроменеджмента. При этом стратегические приоритеты и цели определяются руководителем продукта (Product Owner), который отвечает за финальный результат
- Функциональность — команда объединяет специалистов разного профиля, которые понимают задачи друг друга. Это позволяет гибко распределять нагрузку, помогать коллегам и избегать «узких мест»
Преимущества и недостатки Agile
| ✅ Да | ❌ Но |
|---|---|
| Можно быстро адаптироваться под изменения рынка и править продукт сразу, а не искать причины ошибки на финальных этапах | Сложнее планировать бюджет и сроки до начала работы над проектом |
| Заказчик сразу видит результат | Если он пропадёт или затянет с обратной связью, то работа встанет |
| Удобно, когда есть тесная связь с заказчиком. Можно обсудить все детали сразу и скорректировать результат | Подход требует колоссальной вовлечённости всех участников процесса и готовности постоянно быть на связи |
Чистый Agile не подходит для больших команд. Для крупняков эффективнее гибридный подход.
Гибрид Waterfall + Agile
Взяли лучшее из подходов и объединили их, чтобы сделать работу ещё эффективнее.
Чёткая структура, фазы и последовательность задач (Waterfall) ➕ Гибкость, готовность менять проект под требования заказчика сразу, итеративный подход и отсутствие долгой цепочки согласований (Agile) 🟰 Wagile
От Waterfall в гибридном подходе заимствовали фазы и чёткое планирование проекта. Помним, что «водопад» не прощает ошибок. Если на первых порах что-то пошло не так, то на стадии разработки будет больно разбирать ошибки.
Есть нюанс: все участники рабочего процесса должны быть готовы к смешанному формату, иначе могут возникнуть недопонимания:
- Если руководитель проекта привык работать по жёсткому Waterfall, то ему будет трудно перестроиться на гибкость и равенство команды.
- Если рабочий коллектив всегда работал только в Agile, то жёсткие ограничения могут его демотивировать.
Итог: конфликт интересов.
Lean (бережливое управление)
🧘 Подход, который можно описать примерно так: меньше усилий → минимум потерь → заказчик в восторге. Впервые появился на производстве японских машин Toyota.
Суть бережливого управления: наладить работу потоковых задач так, чтобы не выдохнуться на полпути, но при этом сделать всё, чтобы заказчик был доволен. Ценность продукта — на первом месте
Как оптимизируют рабочий процесс, чтобы создать ценность продукта:
- Отсекают лишнее — всё, что забирает время, но при этом не несёт пользы. Можно перестать раскидывать задачи в десяти рабочих чатах и перейти в WEEEK. За 10 минут ты распределишь таски по отделам и исполнителям и сможешь отслеживать результаты в одном окне
- Предотвращают ошибки — быстрее выявить проблему на раннем этапе и просчитать все риски, чем потом исправлять последствия
- Создают непрерывный поток — систему, в которой работа начинается только по запросу следующего этапа. Это исключает простои и перегрузки, обеспечивает плавное движение задач
- Визуализируют процессы — для этого используют канбан-доски. Рабочая область разделена на три колонки: К работе, В работе и Готово. Задачи переходят из одной колонки в другую в зависимости от её статуса. Так проще ориентироваться в потоке и понимать, как идут дела и что можно улучшить
- Непрерывно развиваются — бережливое производство работает по концепции Kaizen — постоянное улучшение рабочего процесса
Суть подхода — свести потери к минимуму и научиться работать с потоком задач. Планирование в основном краткосрочное и основано на вытягивающем производстве (Pull System).
Объясняем: система вытягивания направлена на то, чтобы искоренить многозадачность. Схема проста: ты берёшь задачу в работу только тогда, когда можешь её выполнить.
Lean активно используют в производстве, в том числе и IT-продуктов, потому что подход действительно рабочий. Но помни: не получится внедрить его просто так, без регистрации и СМС.
Команда должна постепенно адаптироваться и осознанно подойти к работе, иначе весь процесс окажется бесполезным. Например, бездумно перетаскивать карточки с задачами на Kanban-доске противоречит сути подхода.
Сравниваем подходы
Сводная таблица в помощь, чтобы запомнить важное о подходах в управлении проектами.
| Waterfall | Agile | Wagile | Lean | |
|---|---|---|---|---|
| 🧭 Фокус | На жёстком планировании, последовательности задач | На гибкости процессов — меньше ограничений, никаких согласований | Гибрид: планирование и последовательность, но без жёстких ограничений и согласований по каждому шагу | На процессе производства. Меньше потерь, но больше эффективности |
| ⏰ Сроки, задачи, бюджеты | Строго задокументированы, все риски просчитаны до начала работы по проекту | Зависят от изменений рынка или планов заказчика | Прописаны в документах, но при этом значения можно адаптировать | Вместо конкретных значений — вероятность, которая рассчитывается по формулам |
| 🔧 Как строится работа | По каскадной модели — задачи идут строго одна за другой | Итеративный подход — проект делится на этапы (спринты), и каждый из них согласуется с заказчиком | Идёт по фазам — заимствовано у Waterfall | Задачи ставятся потоком, которым управляют с помощью Kanban-досок |
| 📈 Результат | Предсказуем — прописан в документах и не должен сильно отличаться на поздних этапах | Непредсказуем, и проект может полностью отойти от начального плана | Предсказуем, но может поменяться | Не конкретный продукт, а ценность, которая нужна клиенту.Не просто приложение для доставки, а скорость, удобство и функционал |
| ⚔️ Правки | Не прощает ошибок — нельзя откатиться к предыдущей задаче, чтобы что-то поправить | Ошибки исправляют регулярно. Правки могут вносить каждый раз на созвоне с заказчиком | Ошибки легко исправить на этапе разработки. Но важно обойтись без косяков во время планирования | Предотвращает ошибки, потому что это быстрее, чем исправлять |
Шесть методологий и фреймворков
Подходы: каким образом мы работаем и каких принципов придерживаемся? ⬇️
Методологии или фреймворки: что нам нужно сделать, чтобы сохранить принципы и при этом получить рабочий результат?
Scrum
Фреймворк Agile — то есть инструкция, в которой прописано, как работать. Суть: гибкость и равенство в команде важны, но и контролировать работу нужно, чтобы процесс не превратился в хаос.
- Следовать жёсткой структуре и не отходить от неё
- Ввести чёткие роли в команде
- Регулярно оценивать промежуточные результаты
- Использовать инструменты (артефакты) для визуализации работы
| 🤓 | 🫡 |
|---|---|
| Жёсткая структура | Работа по проекту разделена на этапы (спринты), каждый длится от двух недель до месяца. Результат спринта — продукт, которым уже можно пользоваться. В каждом спринте есть «события» — встречи с жёсткими правилами и целью. Планирование спринта — команда отбирает весь список задач на спринт и распределяет работу. Ежедневные встречи — в одно и то же время команда собирается в зуме, чтобы обсудить текущие задачи. Длительность — не дольше пяти минут. Обзор спринта — подводят итоги в конце работы, оценивают промежуточные результаты. Ретроспектива — анализируют работу во время спринта и разбирают ошибки. Структура обязательна и одинакова для всех. |
| Чёткие роли | У каждого в рабочем процессе своя роль и зона ответственности. Владелец продукта — определяет результат, формирует задачи и распределяет приоритеты. Scrum-мастер — следит за порядком, решает конфликты и проверяет, как команда соблюдает регламент. Команда разработки — программисты, дизайнеры и тестировщики, которые работают над проектом и встречаются в зуме. |
| Артефакты | Инструменты, благодаря которым команда может отслеживать процесс. Бэклог — список требований и задач по проекту. Бэклог спринта — задачи, которые команда должна отработать за спринт. Инкремент — результат отдельного спринта. Это готовая часть продукта, которую уже протестировали. |
Scrum повышает шансы того, что работа по проекту будет быстрой, а промежуточный результат — рабочим. Считается фреймворком Agile, потому что регулярные встречи — это та самая гибкость.
Какие могут быть подводные камни
- Работа зайдёт в тупик, если изменения в проекте будут каждый день, — придётся постоянно пересматривать планы спринта и терять время
- Коллеги могут перегореть на ежедневных встречах, потому что Scrum — это максимальная вовлечённость всех участников процесса
Kanban
Ещё один фреймворк Agile, но похож на Lean, потому что повторяет его философию. Главное — донести до клиента ценность продукта без потерь и постоянно улучшать рабочие процессы. Об этом мы уже написали выше. Здесь мы лишь дополним.
🤹 Ключевое в канбан-методе — управлять потоковым производством. Для этого ввели доски — сначала физические, а затем виртуальные, с помощью которых ты отслеживаешь путь задачи.
Система устроена так, чтобы помочь тебе выявить трудные места и понять, в каком моменте ты буксуешь — то есть сопротивляешься задаче. Так тебе проще будет найти причину «заторов» и устранить её.
Kanban-доски удобнее всего использовать в таск-менеджерах. В классическом варианте они разделены на три колонки. Вот так это выглядит в WEEEK.
Задачи — это карточки, которые ты перетаскиваешь слева направо в зависимости от того, в каком они статусе. В каждой карточке обязательно нужно дать описание, назначить исполнителя, проставить дедлайн, теги и приоритеты.
Название колонок можно менять, но лучше сохранять принцип — оно должно отражать стадию выполнения задачи.
Чем хороши Kanban-доски
- Снижают переработки с помощью WIP-лимитов. Если для колонки установлен лимит в семь задач, ты не сможешь взять восемь или десять
- Могут спрогнозировать вероятные сроки по проекту на основе данных — система собирает метрики, главная из которых — среднее время выполнения задачи. На основе этого строится прогноз
- Визуализируют работу — весь поток работы виден на одной доске. Каждая задача — это карточка, которая перемещается из колонки в колонку. Например, если колонка Готово пуста, а В работе переполнена, это сигнал, что команда не может завершать задачи и процесс надо пересмотреть
Какие могут быть подводные камни
- Само по себе наличие доски не организует работу. Если перенести хаос из головы и чатов на цифровую или физическую доску, не установив правил, получится тот же хаос, только визуализированный
- Метод требует внедрения — важно настроить мозги на принципы работы, чтобы не тратить время на бездумное перетягивание карточек
Scrumban
Scrum и Kanban хоть и разные, но работают в одном подходе — в Agile. Пользоваться методологиями по отдельности можно, но если есть ощущение, что стало тесно, то стоит попробовать гибрид — Scrumban.
Команда работает с досками, но при этом регулярно встречается в зуме, чтобы обсудить рабочие процессы. Таким образом можно и потоком управлять, и контролировать работу, но при этом не сходить с ума из-за бесконечных звонков по каждому шагу в проекте.
Six Sigma
Можно идеально выстроить рабочий процесс, но если в продукте или сервисе есть недочёты, то все усилия по внедрению методологий будут напрасны.
Метод «6 сигм» позволяет выявить ошибки во всём проекте, а не на этапе какой-то задачи. То есть смотрим шире — анализируем всё и сразу, находим вероятность дефектов и делаем всё, чтобы они не повторились
Метод появился на производстве Motorola, когда бракованного товара стало слишком много. Нужно было принять меры — придумать способ, с помощью которого дефекты можно спрогнозировать, проанализировать их причины и найти способ избежать их в будущем.
Как выявляют ошибки
🧐 Сигма — это отклонение от определённого значения. Чем меньше сигм, тем больше проблем.
Вероятность ошибок определяют на графике. Идея такая: нужно посчитать, сколько у компании может быть отклонений (сигм), если у неё миллион попыток сделать продукт идеально.
Ориентир — 6 сигм, то есть 3,4 дефекта на миллион. Это значит, что всё хорошо и оперативные вмешательства в рабочие процессы не нужны.
Для этого берут нижнее допустимое значение дефектов и верхнее, а затем проверяют, сколько сигм укладывается между средним значением и любым из допустимых.
Принципы методологии:
- Ценность продукта важнее всего
- Команда полностью вовлечена в проект
- Неэффективных процессов быть не должно
- Все цели измеримы
Что ещё нужно знать про «6 сигм»:
- Основывается на данных. Это статистический метод, поэтому он предполагает, что брать информацию из позиции «Мне кажется, что у нас плохой сервис, нужно с этим что-то сделать» — нельзя
- Добивается того, чтобы все процессы работы были предсказуемыми, то есть по регламенту и без ошибок
- Работает с причинами проблем и их следствием — не просто находит ошибку, а выясняет её коренную причину и думает, как её исправить
Как работать по методу «6 сигм». Алгоритм действий
Six Sigma использует строгий пятиэтапный алгоритм DMAIC (Define — Measure — Analyze — Improve — Control). Работа идёт в конкретной последовательности:
| Шаги алгоритма | Что делать |
|---|---|
| Определить — чётко сформулировать проблему, определить цели проекта и выделить клиентов процесса | Использовать опросы, статистику за прошлые периоды, прямое наблюдение. Важно определить базовые показатели, например текущий уровень дефектов, чтобы потом видеть прогресс |
| Измерить — собрать данные, чтобы объективно измерить текущее состояние процесса и его эффективность | Создать карту процесса (SIPOC), где прописаны поставщики, входы, процесс, выходы и клиенты. Это поможет всем понять границы проекта |
| Проанализировать — найти коренную причину проблем, используя собранные данные | Применять статистический анализ — графики, диаграммы разброса, метод «5 почему», диаграмму Исикавы |
| Улучшить — разработать, протестировать и внедрить решения, которые устранят коренные причины | Генерировать идеи, проверять гипотезы на практике, например запустить пилотный проект в ночную смену, рассчитать выгоду от внедрения |
| Проконтролировать — закрепить успех, стандартизировать процесс и внедрить систему постоянного мониторинга, чтобы проблема не вернулась | Создать инструкции, обучить сотрудников, внедрить контрольные карты для отслеживания ключевых показателей, назначить ответственных |
Какие могут быть подводные камни
- Требует особой подготовки сотрудников и чёткого понимания, зачем это всё
- Дорого стоит: обучение специалистов подобного уровня и внедрение системы в компанию — недешёвое удовольствие
- Не подходит для мелких проблем и станет для них избыточной. «6 сигм» лучше использовать для решения масштабных дефектов
Экстремальное программирование (XPM)
Метод, который радикально отличается от предыдущих. Экстремальное, потому что доводит ценности и практики Agile до предела. Идеален для проектов, где всё может измениться в любую секунду, но подходит только для разработки ПО.
🔥 Ключевой принцип — постоянная и прямая связь. В проекте участвует On-site Customer — человек, который постоянно доступен команде, чтобы отвечать на вопросы, прояснять требования и расставлять приоритеты
Принципы экстремального программирования
- Чем проще, тем лучше — касается всего: и рабочих процессов, и итогового кода
- Коммуникация решает всё — лучше обсудить задачу с командой, чем пытаться решить проблему самому и тратить время
- Тесная связь с заказчиком — быть готовыми внести изменения в код в любую минуту
- Смотреть шире — не бояться экспериментов и новых решений
- Уважать себя, коллег и правила, по которым строится работа
- Не начальник, а коуч: задача руководителя проекта в рамках методологии — организовать комфортную коммуникацию внутри команды и защитить её от внешнего влияния, чтобы никто из посторонних не вмешивался и не пытался навязать собственные правила
- Никаких переработок — важно всегда быть в тонусе, чтобы экстрим не выжал все соки
Практики экстремального программирования
Парное программирование. Используют принцип «Одна голова хорошо, а две — лучше». Один код — два разработчика. Сначала один пишет код, а второй правит ошибки, а затем они меняются местами. В конце выбирают самую рабочую версию и показывают её заказчику.
Сначала тестирование: разработчик прописывает тесты, перед тем как начать работать над кодом.
Код доступен для всех — любой программист может открыть код коллеги и поправить его, если считает нужным. Но есть определённые условия, которые помогут избежать каши и недопониманий:
- код должен быть написан в едином стиле, чтобы он выглядел одинаково, — эти вещи обговариваются заранее
- доработки кода всегда нужно интегрировать в предыдущую версию, чтобы сразу понимать, будет ли результат работать как надо
- каждый должен понимать, как работает система, — для этого проект сравнивают с тем, что доступно и легко воспринимается
Какие могут быть подводные камни
- Внедрение XP должно начинаться с открытого обсуждения этих новых ролей и ответственности. Необходимо обучать команду принципам самоорганизации, а менеджеров — навыкам коучинга
- Высокий уровень ответственности. Команда сама решает, как работать, и берёт на себя всю ответственность за результат
PRINCE2
Придумали британские учёные. Шутим, но метод и правда появился в Великобритании. Расшифровывается как «проекты в управляемой среде». Методологию используют в IT, государственных структурах, финансах, строительстве и любых проектах, где важен контроль и соблюдение сроков.
PRINCE2 не говорит, что нужно делать. У методологии другая цель — организовать процессы так, чтобы знать о рисках заранее, иметь на руках полную документацию по каждому этапу проекта, управлять так, чтобы не срывать сроки.
Кажется, будто процесс жёстко структурированный, но на самом деле методологию можно упростить для небольших команд, а для крупников — запустить по полной программе. Метод адаптируется.
PRINCE2 имеет две основных идеи:
👍 Для успеха нужно воспользоваться формулой 777. Не казино, а семь принципов, семь практик и семь процессов
✅ Что мешает нам завершать задачи спринта вовремя?
Семь принципов
1️⃣ Проект всегда должен быть обоснован с точки зрения денег. Он либо приносит прибыль, либо не нужен. Перед каждым этапом сверяются с обоснованием проекта, чтобы проверить, остался ли продукт актуальным. Если устарел, то могут свернуть работы
2️⃣ Легче учиться на чужих ошибках, чем на своих. Любое обучение — это опыт, его активно используют перед началом работ. Команда ищет похожие проекты, анализирует их ошибки и на основе этого продумывает работу так, чтобы не наступить на чужие или свои грабли
3️⃣ У каждого своя роль и зона ответственности. Помимо классических исполнителей и руководителей в команде есть совет — те люди, которые принимают решения по проекту, и инвесторы — те, кто дают на него деньги
4️⃣ Работа по проекту идёт чётко по этапам. Конец этапа значит, что поднимается вся документация и обновляется с учётом изменений. Новый этап не начнётся, пока все документы не будут готовы в том виде, какой должен быть
5️⃣ Управление по отклонениям — в любом проекте всегда есть риск, что что-то может пойти не так. Поэтому в документах прописывают допустимые отклонения от правил. Включают время, качество, деньги, объём работ, риски, выгоду и устойчивость. Если во время работы что-то вышло за рамки допустимого, то тогда вопрос передают совету по проекту и он решает, что делать дальше
6️⃣ Фокус на продукте, но мы бы перефразировали так: фокус на любых инструментах, которые необходимы для комфортной работы каждого участника рабочего процесса
7️⃣ Адаптация под проект в зависимости от сферы, где применяют PRINCE2. Это значит, что под конкретный проект нужно подобрать инструменты, которыми удобнее и уместнее всего пользоваться. Вряд ли рабочий завода будет пользоваться онлайн-графиками, чтобы оценить свою продуктивность
Семь практик
То, что нужно делать во время работы по методу PRINCE2.
1️⃣ Обосновать, почему проект прибыльный
2️⃣ Организовать работу по проекту, распределить роли и зоны ответственности
3️⃣ Прописать критерии качества проекта и каждого этапа в документах и регулярно проверять, насколько написанное соответствует действительности
4️⃣ Планировать на три уровня: по проекту, по каждому этапу и отдельно для сотрудников (например, раскидывать задачи на неделю или месяц)
5️⃣ Не принимать изменения без разрешения — только совет по проекту решает, можно ли что-то поменять
6️⃣ Контролировать работу — регулярно собирать отчёты и мониторить результаты
Семь процессов
Помним: у каждого проекта есть начало и конец, как и у каждого этапа. По методу PRINCE2 рабочие процессы тесно взаимосвязаны и выглядят следующим образом:
| 1️⃣ Предподготовка | Составить бриф, назначить руководителей | 3️⃣ Руководство проектом | 4️⃣ Управление этапами | 5️⃣ Управление поставкой продукта | 6️⃣ Управление границами этапов | 7️⃣ Закрытие проекта |
| 2️⃣ Инициация | Обосновать рентабельность проекта, просчитать риски, объём работ и каким образом будут оценивать результат | Совет принимает решение по проекту исходя из допустимых границ, следит за выполнением всех показателей и может свернуть проект, если поймёт, что работать уже невыгодно | Контролировать работу по каждому этапу проекта, управлять рисками | Следить за тем, чтобы команда работала чётко по регламенту и в рамках определённого этапа | Проверять работу в конце каждого этапа. Подводить итоги и контролировать, чтобы результат соответствовал тому, что прописано в документах | Протестировать продукт, проверить документацию, проследить, чтобы всё работало без сбоев и дальше |
Какие могут быть подводные камни
- Бюрократия, которая может тормозить проект. Без бумажки нельзя начать новый этап проекта, и нужно ждать одобрения свыше
- Риск скатиться в «работу для галочки» — PRINCE2 больше про жёсткую структуру и деньги, но меньше про ценности. Из-за этого работа может свестись к принципу «сделали, чтобы от нас отстали»
5 методов и инструментов планирования
Переходим на ступень ниже — инструменты, которые помогут тебе управлять, оценивать результаты и просчитывать риски. Обещаем, что в этом блоке будет коротко.
Метод критического пути (CPM)
Помогает оценить границы дозволенного — то есть минимальный срок проекта, от которого можно отталкиваться. Его суть — определить самую длительную последовательность взаимосвязанных критических задач и суммировать сроки каждой.
Задачи критические, потому что у них нет резерва времени — шаг влево или вправо хотя бы по одной из них невозможен, иначе весь срок по проекту придётся сдвигать. Задачи, которые входят в критический путь, требуют максимального контроля.
Метод критической цепи (CCPM)
Невозможно всё распланировать наверняка. Метод критической цепи был создан на случай, если в критическом пути что-то пошло не так. Упор не на жёсткой последовательности задач, а на грамотном распределении ресурсов и времени.
Критическая цепь — это самая длинная цепочка зависимых и независимых друг от друга задач. Поэтому, когда рассчитывают примерные сроки проекта, учитывают всё, в том числе и человеческий фактор. Более того, у каждой задачи есть резервное время на случай форс-мажоров.
Иерархическая структура работ (WBS)
Разбиваешь большие задачи на блоки более мелких и управляемых, которые тебе и команде будет проще понять и сделать, — на языке диджитальщиков это называется «декомпозиция».
Метод поможет оценить все задачи и понять, какие ресурсы нужны для достижения результата. Начинать декомпозицию лучше от обратного: сначала определись с желаемым результатом, а затем уже с задачами, которые помогут его достичь.
Диаграмма Ганта
Диаграмма, которая визуализирует всё: зависимости задач, приоритеты, вехи проекта, а главное — сроки. Смотри, как это выглядит, — покажем упрощённую версию, чтобы тебе было легче понять.
Задачи на графике выглядят как «колбаски» — чем длиннее, тем больше нужно времени на работу. Ты сможешь увидеть, какие задачи пересекаются друг с другом и что можно выполнять параллельно без ущерба дедлайнам.
Диаграмму реально адаптировать под любую сферу жизни, но есть нюанс. График идеален для тех проектов, где есть чёткая структура и дисциплина, но для творческих задач не подойдёт.
Диаграмма PERT (Program Evaluation and Review Technique)
Похожа на диаграмму Ганта, но нацелена не на конкретную задачу, а на проект целиком. Гант работает только с точными значениями, а PERT позволяет оценить сроки в условиях неопределённости.
Диаграмма PERT не так детальна, как Гант, но при этом её заслуги не стоит преуменьшать, так как с помощью неё можно ответить на вопрос «Какое минимальное время нам нужно на проект с учётом того, что мы точно не можем определить сроки по каждой отдельной задаче?»
Для того чтобы построить такую диаграмму, недостаточно просто разделить проект на этапы и отдельно прописать каждую задачу, даже незначительную. Вот что нужно ещё:
- определить зависимости
- для каждой задачи проставить примерный дедлайн — оптимистичный, пессимистичный, реалистичный и установленный
- рассчитать по формуле средние значения для каждой задачи и суммировать их
- построить диаграмму в специальных программах
Поймём, если твой мозг закипел от количества информации, но справедливости ради отметим, что мы рассказали о базовых вещах. В управлении проектами множество различных методов, функций, инструментов и даже практик. Но мы решили пока остановиться на вышеперечисленных, чтобы не перегружать тебя, и в конце перейти к приятному — трендам и лайфхакам.
Выбор методологии управления проектом
Поздравляем! Ты на финишной прямой. Мы дали очень много полезного материала, но выбор методологии зависит лишь от твоей профессиональной чуйки. Чтобы тебе было легче, мы собрали тренды в управлении проектами на 2026 год и небольшие лайфхаки, которые будут тебе полезны.
Тренды в управлении проектами. Коротко
▫️ИИ не заменит людей, но точно поможет сдать проект вовремя, если пользоваться им без фанатизма. Нейронке можно доверить построить график, подготовить расшифровку важного звонка, составить отчёт и проанализировать данные. Также можно настроить чат-бот, который будет отвечать на самые типовые вопросы в чатах
▫️Благополучие персонала могут включить в KPI проектов и задачи руководства. Тебе не показалось. Борьба с выгоранием — это тренд. Теперь хороший сотрудник не тот, кто пашет как лошадь, а тот, у кого устойчивая психика и стабильная самооценка
▫️Гибридные методологии — наше всё. Не существует универсальных решений, которые подошли бы под любой проект. Нужно проявить смекалку и адаптироваться
▫️Грамотного менеджмента внутри одного проекта недостаточно. Гораздо важнее уметь управлять портфелем проектов — то есть вообще всеми проектами, которые есть в компании. Научиться быстро реагировать на форс-мажоры и принимать взвешенные решения. А ещё неплохо воспитывать в каждом члене своей команды самостоятельного менеджера, чтобы всё работало как надо без твоего вмешательства
▫️Управлять проектами может любой — не воспринимай это в прямом смысле. Мы имеем в виду, что необязательно иметь почётное звание проджекта, чтобы взять ответственность за проект на себя. Достаточно пройти обучение при условии, что ты уже работаешь в компании и знаешь проект от и до. Выращенный менеджер внутри компании лучше, чем тот, которого пригласили
Лайфхаки по управлению проектами
Чтобы стать продуктивнее самому и управлять командой ещё лучше. Собрали топ-3 неочевидных, но рабочих совета, которые помогут в трудную минуту.
Не отказывайся от рукописных заметок. Письмо от руки включает мозг и поможет быстрее запомнить важную информацию. А ещё записать в блокнот — гораздо быстрее, чем искать нужную вкладку в браузере. Также на бумаге удобнее записывать идеи и даже брейнштормить.
Совет: лучше комбинировать — писать от руки и вести электронные заметки, например в базе знаний WEEEK, чтобы точно ничего не потерялось.
Сначала научись управлять своим временем, а затем — чужим. База, но без этого никуда. Для самоорганизации уже придумали множество техник — подробно каждую описали в нашей статье на VC.
Мысли нестандартно. Используй метод шести шляп — уходим от линейного мышления и рассматриваем проблему с шести точек: позитивное мышление, критика, эмоции и интуиция, факты и информация, креативность и идеи, управление процессом. Рассказали подробнее, при чём тут шляпы и как внедрить метод креативного мышления в жизнь.
Подписаться 
