ITIL4 Управление проектами: как попасть в сроки, бюджет и сохранить нервы

Суть Project Management в ITIL 4

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

Это набор здравых практик, как запланировать, выполнить и закрыть проект так, чтобы:

• Уложиться в сроки (когда обещали — тогда и сдали)
• Уложиться в бюджет (не потратить в 2 раза больше)
• Сделать то, что нужно (а не то, что получилось)
• Не забыть ничего важного по дороге

Ключевая идея:

Проект ≠ Операционка

• Операционка — это когда ты каждый день делаешь одно и то же (обрабатываешь заявки, мониторишь серверы, деплоишь код)
• Проект — это когда ты делаешь что-то один раз, с чётким началом и концом, чтобы создать что-то уникальное

Простой пример:

Вот как выглядит внедрение новой CRM-системы:

Без управления проектом:

• Никто не знает, когда проект должен закончиться
• Требования постоянно меняются без контроля
• Бюджет растет как на дрожжах
• Команда не понимает приоритеты задач
• Стейкхолдеры не в курсе текущего статуса
• Тестирование проводится в последний момент
• Результат: Жопа. Система внедрена с опозданием на год, перерасходом бюджета в 2 раза и не соответствует ожиданиям пользователей

С управлением проектом:

• Четкий план с вехами и сроками
• Формализованный процесс управления изменениями
• Регулярный мониторинг бюджета
• Приоритизация задач на основе бизнес-ценности
• Регулярные статус-митинги со стейкхолдерами
• Тестирование интегрировано в процесс разработки
• Результат: Система внедрена вовремя, в рамках бюджета и соответствует ожиданиям пользователей

🔥 Какие проблемы эта практика решает

1. А когда это будет готово? — бесконечные ответы на простой вопрос роста напряжения директоров. Никто не знает точных сроков завершения работ и постоянно спрашивает об этом.
2. Ой, а мы еще вот это хотим — когда требования бездумно постоянно меняются без контроля, что приводит к бесконечному проекту.
3. У нас закончились деньги — когда бюджет исчерпан, а проект еще далек от завершения.
4. А кто этим занимается? — когда ответственность размыта, и никто не знает, кто за что отвечает.
5. Мы не успеваем к дедлайну — когда сроки горят, а работы еще непочатый край.
6. А зачем мы это вообще делаем? — Когда цели проекта не ясны или забыты в процессе выполнения.

Когда пора этим заняться

Если вы делаете небольшие изменения в системе, возможно, формальное управление проектом

Тебе не нужно проектное управление, если:

• Вы меняете цвет кнопки на сайте
• Задача занимает 1-2 дня
• Работает один человек

Пора задуматься, если:

• Работа затрагивает несколько команд или систем
• Сроки больше месяца
• Бюджет больше 500к рублей
• Если проект провалится — будет больно бизнесу
• Нужно координировать работу 3+ человек

Точно пора, если:

• Высокие риски (технические, финансовые, репутационные)
• Проект длится 3+ месяца
• Задействовано 5+ человек
• Бюджет 1+ млн рублей
• Результат критичен для бизнеса

Как это работает на практике

Ключевая модель: Тройное ограничение проекта

Тройное ограничение — это модель, которая показывает взаимосвязь между тремя основными параметрами проекта: содержанием (что делаем), временем (когда делаем) и стоимостью (сколько ресурсов тратим). Изменение одного параметра неизбежно влияет на другие.

• Если увеличиваем содержание → нужно больше времени или денег
• Если сокращаем время → нужно уменьшить содержание или увеличить стоимость
• Если сокращаем стоимость → нужно уменьшить содержание или увеличить время

Качество находится в центре этого треугольника и зависит от баланса всех трех параметров.

Кейс 1: Давайте добавим ещё функций!

• Увеличили содержание → нужно больше времени ИЛИ больше денег (больше людей)
• Если не увеличиваем ни то, ни другое → страдает качество

Кейс 2: Нам нужно быстрее!

• Сокращаем время → нужно урезать функционал ИЛИ добавить людей (денег)
• Если не делаем ни то, ни другое → страдает качество

Кейс 3: У нас урезали бюджет

• Меньше денег → меньше людей → нужно больше времени ИЛИ меньше функционала
• Если не корректируем → страдает качество

Модель: Жизненный цикл проекта

Жизненный цикл проекта включает все фазы от инициации до завершения. В зависимости от методологии (Waterfall, Agile, Hybrid), эти фазы могут выполняться последовательно или итеративно.

Инициация — отвечаем на вопросы:

• Зачем нам этот проект?
• Что будет, если его не сделать?
• Кто заказчик и кто будет пользоваться результатом?
• Сколько примерно это стоит и сколько займёт времени?

Планирование — детально разбираем:

• Что конкретно делаем?
• Кто это делает и когда (график, ресурсы)
• Сколько это стоит (бюджет)
• Что может пойти не так (риски)
• Как будем проверять качество

Выполнение — делаем:

• Координируем команду
• Решаем проблемы по мере их возникновения
• Общаемся со стейкхолдерами
• Документируем изменения

Контроль — проверяем:

• Укладываемся ли в сроки
• Не вылезаем ли за бюджет
• Соответствует ли качество ожиданиям
• Не появились ли новые риски

Завершение — закрываем:

• Передаём результат заказчику
• Документируем уроки (что было хорошо, что плохо)
• Закрываем все формальности
• Отмечаем успех с командой 🍺🍺🍺🍺🍺🍺

Модель: Матрица ответственности RACI

Матрица RACI помогает четко определить роли и ответственность в проекте:

• R (Responsible) — кто делает работу (может быть несколько человек)
• A (Accountable) — кто отвечает за результат (ТОЛЬКО ОДИН человек на задачу!)
• C (Consulted) — с кем советуемся перед решением
• I (Informed) — кого держим в курсе

Пример RACI-матрицы для проекта внедрения CRM:

Главное правило: на каждую задачу должен быть ОДИН человек с буквой A.
Если их два — никто ни за что не отвечает.

Модель: Управление изменениями в проекте

Почему это важно: Без формального процесса управления изменениями проект превращается в «а давайте ещё вот это добавим» и никогда не заканчивается.

Как это работает:

1. Кто-то хочет что-то изменить → оформляет запрос
2. PM оценивает влияние на сроки/бюджет/ресурсы
3. Если влияет → идём к заказчику: «Хотите это? Окей, но тогда +2 недели и +500к»
4. Заказчик решает: добавить изменение или отказаться
5. Если одобрено → обновляем план, бюджет, график
6. Выполняем изменение

Заказчик на середине проекта: А давайте добавим push-уведомления!

Я: Окей, это +3 недели разработки, +1 неделя тестирования, +300к рублей

Заказчик: Ого, дорого. А можно без них?

Я: Можно, добавим в следующей версии

Результат: проект закончен вовремя, push-уведомления сделали потом

Реальный пример

⚙️ Какие инструменты юзать в 2025 году

Для планирования и управления задачами

Яндекс Трекер

• Что умеет: Канбан, Gantt, спринты, бэклог, отчёты
• Когда полезен: Для команд от 5 человек, интеграция с Яндекс.Облаком
• Цена: От 300₽/мес на пользователя
• Фишка: Интеграция с Яндекс.Метрикой и DataLens

Kaiten

• Что умеет: Канбан-доски, WIP-лимиты, аналитика, автоматизация
• Когда полезен: Для Agile/Scrum команд, визуализация процессов
• Цена: От 250₽/мес на пользователя
• Фишка: Российская разработка, гибкая настройка досок

CrocoTime

• Что умеет: Учёт времени, Gantt, управление ресурсами, финансы
• Когда юзать: Когда нужно считать, сколько времени уходит на задачи
• Цена: От 200₽/мес на пользователя
• Фишка: Когда люди трекают время — работа идёт ответственнее, проверено.

Битрикс24

• Что умеет: Задачи, Gantt, CRM, документы, чаты, видеозвонки, 100500 всего
• Когда юзать: Когда нужен комбайн всё в одном
• Цена: От 6к/месяц (есть бесплатный тариф, но там печально)
• Фишка: Куча готовых интеграций для всего

Для коммуникации

VK WorkSpace

• Что умеет: Чаты, видеозвонки, документы, календарь
• Когда юзать: Замена Slack/Teams
• Цена: От 0₽
• Фишка: Товарищь майор идёт в комплекте — стабильно

Телеграм

• Что умеет: Чаты, каналы, боты, файлы до 2 ГБ
• Когда юзать: Для быстрой коммуникации, неформального общения
• Цена: Бесплатно
• Фишка: Все уже в нём сидят, никого не надо упрашивать

Для документации

Confluence (пока работает через VPN)

• Что умеет: Wiki, база знаний, шаблоны, интеграция с Jira
• Когда юзать: Для структурированной документации
• Цена: От $5.50/мес на пользователя

Notion (работает через VPN)

• Что умеет: Документы, базы данных, wiki, шаблоны
• Когда юзать: Для гибкой документации и баз знаний
• Цена: От $8/мес на пользователя

МойОфис

• Что умеет: Документы, таблицы, презентации, совместная работа
• Когда юзать: Замена Google Docs/Office 365
• Цена: От 200₽/мес на пользователя
• Фишка: Работает без VPN, на этом всё

Для отчётности и аналитики

Яндекс DataLens

• Что умеет: Дашборды, графики, интеграция с разными источниками
• Когда юзать: Для визуализации метрик проекта
• Цена: От 0₽
• Фишка: Интеграция с Яндекс Трекером

Power BI (работает через VPN)

• Что умеет: Мощная аналитика (пока ещё лучшие на рынке), дашборды, интеграция с Excel
• Когда юзать: Для сложной аналитики и отчётов
• Цена: От $10/мес на пользователя

Главное правило: инструмент — это дай бог чтоб 20% успеха. 80% — это процессы и люди. Не пытайтесь автоматизировать хаос.

📋 Как внедрить и не облажаться

Для маленькой команды (1-5 человек, проекты до 3 месяцев)

Что нужно:

1. Простой план — список задач с дедлайнами в Google Sheets или Trello
2. Еженедельные встречи — 30 минут, что сделали, что делаем, где проблемы
3. Один ответственный — кто следит за сроками и приоритетами
4. Базовый учёт рисков — список «что может пойти не так» и план Б

Чего НЕ надо:

• ❌ Детальных Gantt-диаграмм
• ❌ Формальных процессов управления изменениями
• ❌ Еженедельных отчётов
• ❌ Выделенного проектного менеджера

Чек-лист запуска проекта:

•  Понятно, что делаем и зачем? Если не понятно зачем — зачем вообще делать?
•  Есть список задач с примерными сроками? Чтобы понимать, что делать дальше
•  Понятно, кто за что отвечает? Чтобы не было «я думал, ты делаешь»
•  Договорились, как часто созваниваемся? Чтобы вовремя ловить проблемы
•  Есть место, где храним документы/код? Чтобы не искать всё по чатам постоянно

Для средней команды (5-15 человек, проекты 3-6 месяцев)

Что нужно:

1. Детальный план — Декомпозиция задач, график с зависимостями, вехи
2. Система управления задачами — Яндекс Трекер, Kaiten, Битрикс24
3. Еженедельные статус-митинги — с командой (15-20 мин) и стейкхолдерами (5-15 мин)
4. Формальное управление изменениями — запросы, оценка, одобрение
5. Управление рисками — реестр рисков, план реагирования
6. Базовая документация — требования, архитектура, решения

Чего НЕ надо:

• ❌ Детального планирования на год вперёд
• ❌ Формализации процесса закупок
• ❌ Сертифицированного менеджера проектов тоже не надо

Чек-лист запуска проекта:

•  Есть устав проекта (цели, содержание, ограничения)? Формальное одобрение и рамки проекта
•  Собраны и документированы требования? Чтобы делать то, что нужно
•  Сделана декомпозиция работ? Чтобы ничего не забыть
•  Есть график с вехами и зависимостями? Чтобы понимать критический путь
•  Оценён бюджет (с резервом 20%)? Чтобы не закончились деньги
•  Описан топ-5 рисков? Чтобы не было сюрпризов
•  Создана RACI-матрица? Чтобы все знали, кто за что отвечает
•  Есть система управления задачами? Чтобы отслеживать прогресс
•  Определён процесс согласования изменений? Чтобы проект не расползался
•  Есть план коммуникаций (кто, кому, когда, что)? Чтобы все были в курсе

Для большой команды (15+ человек, проекты 6+ месяцев)

Что нужно:

1. Опытный менеджер проекта — по PMBOK/PRINCE2/ITIL
2. Выделенный PM — на полную ставку
3. Детальное планирование — WBS, сетевые диаграммы, критический путь
4. Управление освоенным объёмом (EVM) — для контроля сроков и бюджета
5. Формальные процессы — изменения, риски, качество, коммуникации
6. Регулярная отчётность — еженедельно команде, ежемесячно руководству
7. Управление стейкхолдерами — анализ влияния, планы вовлечения
8. Документация — всё, что может понадобиться

Чего НЕ надо:

• ❌ Бюрократии ради бюрократии
• ❌ Отчётов, которые никто не читает
• ❌ Процессов, которые тормозят работу
• ❌ Управления ради управления, не делайте так

Чек-лист запуска проекта:

•  Разработан и утверждён устав проекта? Формальное одобрение высшим руководством
•  Проведён анализ стейкхолдеров? Чтобы понимать, кто может повлиять на проект
•  Собраны детальные требования? Чтобы не переделывать потом
•  Создана детальная WBS? Чтобы оценить объём работ
•  Разработан детальный график? Чтобы видеть критический путь
•  Составлен детальный бюджет с резервами? Чтобы контролировать расходы
•  Проведён анализ рисков (качественный/количественный)? Чтобы подготовиться к проблемам
•  Есть план тестирования? Чтобы результат соответствовал ожиданиям
•  Есть план управления ресурсами? Чтобы люди были доступны, когда нужно
•  Есть план коммуникаций? Чтобы все получали нужную информацию
•  Есть процесс управления изменениями? Чтобы контролировать расползание проекта
•  Определены метрики и KPI проекта? Чтобы измерять и держать всех в фокусе
•  Есть система отчётности? Чтобы руководство было в курсе
•  Проведён kick-off meeting? Чтобы все поняли цели и свою роль

Как не переусложнять:

• Если отчёт никто не читает — не пишите его
• Если процесс тормозит работу — упростите его
• Если встреча не приносит пользы — отмените её
• Если документ не используется — не поддерживайте его

🚫 Золотой топ факапов или как делать не надо

1. Начнём делать, а там разберёмся

Что происходит: Проект стартует без чёткого плана, требований и понимания объёма работ.

К чему приводит:

• Постоянные переделки
• Сроки сдвигаются каждую неделю
• Бюджет растёт как на дрожжах
• Команда выгорает

Как избежать: Потратьте 10-15% времени проекта на планирование. Это окупится в 10 раз.

2. «Мы не будем документировать, всё и так понятно

Что происходит: Всё держится в головах, решения принимаются на словах.

К чему приводит:

• Через месяц никто не помнит, почему так решили
• Новый человек в команде не может разобраться
• При уходе ключевого человека всё рушится

Как избежать: Документируйте минимум:

• Цели проекта и критерии успеха
• Ключевые архитектурные решения
• Важные договорённости с заказчиком
• Изменения в содержании/сроках/бюджете

3. «Давайте ещё вот это добавим, это же быстро

Что происходит: Каждое такое маленькое изменение кажется незначительным.

К чему приводит:

• Проект никогда не заканчивается
• Scope creep — содержание расползается
• Команда делает 150% от изначального плана

Как избежать:

• Формальный процесс управления изменениями
• Каждое изменение = оценка влияния
• Хотите добавить? Окей, что убираем или сколько добавляем времени/денег?

4. Зачем нам статус-митинги, мы и так общаемся

Что происходит: Нет регулярной синхронизации команды.

К чему приводит:

• Люди работают в разных направлениях
• Проблемы всплывают слишком поздно
• Стейкхолдеры не в курсе и начинают паниковать

Как избежать:

• Еженедельные 30-минутные статус-митинги с командой
• Еженедельные 15-минутные апдейты для стейкхолдеров
• Месячные обзоры прогресса

5. Риски? Какие риски? Всё будет хорошо

Что происходит: Никто не думает, что может пойти не так.

К чему приводит:

• Когда проблема случается — паника и хаос
• Нет плана Б
• Проект встаёт колом

Как избежать:

• В начале проекта: «Что может пойти не так?»
• Для каждого риска: вероятность + план реагирования
• Ежемесячный пересмотр рисков

6. У нас нет времени на тестирование

Что происходит: Тестирование откладывается на последний момент.

К чему приводит:

• Критические баги находятся перед релизом
• Приходится переносить дедлайн
• Или релизить с багами (и потом тушить пожары)

Как избежать:

• Тестирование — часть процесса разработки, а не отдельный этап в конце
• Автоматизированные тесты для критичного функционала
• Регулярные ревью кода

7. Проектный менеджер? Зачем? Разработчики сами справятся

Что происходит: Нет человека, который отвечает за проект целиком.

К чему приводит:

• Никто не следит за сроками и бюджетом
• Никто не общается со стейкхолдерами
• Разработчики тратят время на менеджмент вместо кода

Как избежать:

• Для проектов 3+ месяца — выделенный PM
• Для маленьких проектов — хотя бы тимлид с PM-функциями

✅ Заключение: почему без проектного управления ваша компания обречена

За 15 лет в ИТ я видел десятки компаний. И вот что я заметил:

Все компании, где не было проектного управления, заканчивали одинаково плохо.

Даже если по началу казалось, что «да ладно, мы и так на собрании договоримся, зачем нам эти формальности».

Это всегда развивается:

Стадия 1: У нас всё под контролем (0-20 человек)

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

Что происходит: Иногда проекты заканчиваются вовремя, иногда нет. Но пока это не критично.

Стадия 2: Что-то пошло не так (20-50 человек)

Компания растёт, проектов становится больше, они сложнее. Договориться на словах уже сложно — слишком много людей. Начинаются проблемы:

• Проекты постоянно срываются
• Бюджеты резиновые
• Разработчики не понимают приоритеты
• Стейкхолдеры орут

Что происходит: Руководство начинает паниковать и вводить контроль. Но без системы это превращается в микроменеджмент и хаос.

Стадия 3: Мы тонем (50+ человек)

Компания большая, но процессов нет. Каждый проект — это отдельная история со своими правилами. Никто не знает:

• Сколько реально стоил каждый проект
• Почему сроки срываются
• Кто за что отвечает
• Как приоритизировать задачи

Что происходит:

• Лучшие люди уходят (потому что работать в хаосе = выгорание)
• Клиенты уходят (потому что обещания не выполняются)
• Инвесторы уходят (потому что нет предсказуемости)

Стадия 4: Конец

Компания либо:

• Умирает — не выдерживает конкуренции
• Деградирует — превращается в зомби, которая еле-еле держится
• Продаётся за копейки — потому что никто не хочет покупать хаос

Исключения: Есть только два типа компаний, где может не быть формального проектного управления:

1. Стартапы на ранней стадии — когда вы делаете MVP и ищете product-market fit. Тут важна скорость, а не процессы. Но как только нашли fit — пора внедрять управление.
2. Продуктовые компании с одним продуктом — где нет проектов как таковых, есть непрерывная разработка. Но даже там нужны процессы планирования, приоритизации и контроля.

Почему это работает именно так?

Проектное управление — это не бюрократия. Это в первую очередь — предсказуемость.

Когда у вас есть процессы:

• Вы можете планировать на месяцы вперёд
• Вы можете обещать клиентам сроки и выполнять их
• Вы можете считать, сколько стоят ваши проекты
• Вы можете масштабироваться без хаоса

Без процессов вы работаете в режиме пожарной команды = постоянно тушите горящие дедлайны, выгораете сами и выжигаете команду.

Мой совет:

Если ты работаешь в компании, где нет проектного управления:

• Если это стартап — окей, но как только найдёте нишу — внедряйте процессы
• Если это не стартап — беги оттуда. Серьёзно. Ничего хорошего тебе там не светит.

Потому что компания, которая не умеет управлять проектами — это компания, которая не умеет выполнять обещания. А бизнес без выполненных обещаний — это не бизнес, это лотерея.

Не играй в лотерею со своей карьерой.