Управление IT‑проектами

Роль менеджера и жизненный цикл IT‑проекта

Зачем нужен менеджер в IT‑проекте

IT‑проект — это временная работа, нацеленная на создание уникального результата: продукта, сервиса, интеграции или изменения в существующей системе. У проекта всегда есть ограничения по:

срокам

бюджету

содержанию работ (что именно делаем)

качеству (каким должно получиться)

рискам (что может пойти не так)

Менеджер проекта (Project Manager, PM) нужен, чтобы согласовать ожидания заинтересованных сторон, превратить их в понятный план, организовать команду и довести работу до результата при неизбежных изменениях.

> Plans are nothing; planning is everything. — Дуайт Д. Эйзенхауэр (часто цитируется как принцип проектного управления) Dwight D. Eisenhower Presidential Library — цитаты

Кто такие заинтересованные стороны

Заинтересованные стороны (stakeholders) — это люди или группы, которые:

влияют на проект (например, заказчик, ИБ-служба, архитектурный комитет)

зависят от результата (пользователи, служба поддержки, бизнес-подразделение)

выполняют работу (команда разработки, тестирования, аналитики)

Одна из ключевых задач PM — выявить стейкхолдеров и договориться с ними о правилах взаимодействия: кто принимает решения, как согласуются изменения, как часто и в каком виде будет отчетность.

Роль менеджера проекта

Менеджер проекта отвечает не за написание кода, а за управление работой так, чтобы продукт появился вовремя и был полезен.

Основные обязанности

Формулировать цель проекта вместе с бизнесом и командой.

Определять рамки проекта: что входит в работу, а что не входит.

Организовывать планирование: этапы, сроки, ресурсы, зависимости.

Управлять коммуникациями: встречи, статусы, эскалации.

Управлять рисками: выявление, профилактика, план действий.

Поддерживать прозрачность: прогресс, проблемы, прогноз сроков.

Управлять изменениями: оценка влияния и согласование.

Закрывать проект: приемка результата, передача в поддержку, итоги.

Что важно уметь

Системно мыслить: видеть картину целиком, а не отдельные задачи.

Договариваться: балансировать интересы бизнеса, команды и ограничений.

Работать с неопределенностью: IT часто начинается с неполных требований.

Понимать предметную область: достаточно, чтобы задавать правильные вопросы.

Границы ответственности: PM, Product Manager и Team Lead

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

| Роль | Главный фокус | Типичные вопросы | |---|---|---| | Менеджер проекта (PM) | Сроки, процесс, координация, риски | Когда будет готово? Что мешает? Как синхронизировать команды? | | Продуктовый менеджер (Product) | Ценность для пользователя и бизнеса | Что именно нужно сделать? Зачем? Как измеряем успех? | | Тимлид/техлид | Технические решения и качество реализации | Как реализовать? Какие стандарты? Какие техриски? |

Если в проекте нет выделенного Product Manager, часть продуктовых задач часто ложится на PM, и это нужно явно согласовать.

Жизненный цикл IT‑проекта

Жизненный цикл — это последовательность стадий, через которые проходит проект от идеи до закрытия. На практике это не всегда строго линейный путь: в IT часто есть возвраты, уточнение требований и пересборка планов.

!Общая схема стадий проекта и их повторяемость

Инициация

Цель стадии — понять, зачем нужен проект и кто за него отвечает.

Обычно на выходе есть:

формулировка цели и ожидаемой ценности

первичный список стейкхолдеров

высокоуровневые ограничения (срок, бюджет, платформа)

критерии успеха (как поймем, что получилось)

решение о старте и назначение ответственных

Ключевой артефакт часто называют уставом проекта (project charter) или инициирующим документом: краткая фиксация договоренностей о запуске.

Планирование

Цель стадии — превратить цель в управляемый план и общие правила работы.

Что обычно планируется:

содержание работ: перечень результатов и границы (что делаем / что не делаем)

структура работ: крупные блоки и зависимости

сроки: этапы, контрольные точки, релизы

ресурсы: команда, загрузка, подрядчики

качество: критерии приемки, определение “готово”

риски: топ‑риски и планы реагирования

коммуникации: кто и как часто получает статусы

В гибких подходах (Agile) детальный план делается на ближайший горизонт, а остальное уточняется по мере продвижения.

Полезные источники по гибким принципам:

Agile Manifesto

The Scrum Guide

Реализация

Цель стадии — выполнить запланированную работу и создать результаты.

Для IT‑проектов реализация часто включает:

анализ и уточнение требований

проектирование (архитектура, UX)

разработку

тестирование

подготовку инфраструктуры

документацию

обучение пользователей

Важно: PM не “гонит команду”, а создает условия, в которых команда может стабильно поставлять результат: снимает блокеры, помогает с приоритетами и согласованиями, управляет зависимостями между командами.

Мониторинг и контроль

Эта стадия идет параллельно с реализацией. Цель — понимать реальное состояние проекта и вовремя корректировать курс.

Что контролируется:

прогресс относительно плана (что готово, что нет)

отклонения по срокам и бюджету

качество (дефекты, результаты тестов, инциденты)

изменения требований и их влияние

риски и появление новых рисков

Один из практичных подходов — регулярно отвечать на три вопроса:

что сделано

что мешает

что будет сделано дальше и каков прогноз по срокам

Завершение

Цель стадии — формально закончить проект и передать результат в эксплуатацию.

Типичные действия:

приемка результата заказчиком по критериям

передача в поддержку и эксплуатацию (доступы, инструкции, SLA/регламенты)

закрытие договоров и финансов

итоговый отчет и разбор уроков (что улучшить в следующих проектах)

Пропуск завершения — частая проблема: продукт “как будто запустили”, но никто не владеет операционными задачами, документация не готова, ответственность размыта.

Модели жизненного цикла: когда что выбирать

В IT чаще всего встречаются два подхода.

Предиктивный (Waterfall‑подобный)

Характеристики:

требования стараются зафиксировать заранее

план детальный и рассчитан на весь проект

изменения проходят через формальную процедуру согласования

Подходит, когда:

требования стабильны

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

нужна жесткая отчетность и контрактные обязательства

Итеративный/инкрементальный (Agile‑подобный)

Характеристики:

результат поставляется частями (итерациями, релизами)

требования уточняются по мере получения обратной связи

план пересматривается регулярно

Подходит, когда:

продукт развивается в условиях неопределенности

важна скорость проверки гипотез

нужна быстрая поставка ценности пользователям

На практике часто применяется гибрид: например, предиктивные правила для бюджета и согласований, но итеративная разработка и релизы.

Контрольные точки, этапы и результаты

Чтобы управлять проектом, нужно различать несколько понятий.

Результат (deliverable) — конкретный проверяемый итог работы: модуль, интеграция, отчет, настроенный контур.

Контрольная точка (milestone) — момент проверки или принятия решения: “дизайн согласован”, “готовы к пилоту”. Контрольная точка сама по себе может не быть “вещью”, которую можно потрогать.

Этап (phase) — крупный период проекта, объединяющий набор результатов и контрольных точек.

Полезная практика — определять stage gate: “ворота” между этапами, где принимается решение продолжать, менять план или останавливать проект.

Как PM распределяет ответственность: простая матрица RACI

Чтобы избежать фраз “я думал, это вы делаете”, применяют матрицу RACI:

R (Responsible) — выполняет работу

A (Accountable) — отвечает за итог и принимает результат

C (Consulted) — консультирует (двусторонняя связь)

I (Informed) — информируется (односторонняя связь)

!Пример распределения ролей и ожиданий

Типичные риски IT‑проектов и роль менеджера

PM не устраняет все риски, но делает их видимыми и управляемыми.

Частые риски:

размытые требования и постоянные изменения без оценки влияния

скрытые зависимости (другая команда, поставщик, инфраструктура)

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

недооценка тестирования и качества данных

проблемы с доступами, контурами, безопасностью

“последняя миля”: релиз, миграции, обучение, поддержка

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

Практический старт: что сделать PM в первые две недели

Зафиксировать цель, критерии успеха и границы проекта.

Составить карту стейкхолдеров и договориться о каналах коммуникаций.

Уточнить модель жизненного цикла: предиктивная, итеративная или гибрид.

Определить ближайшие контрольные точки и минимально жизнеспособный план.

Собрать топ‑риски и назначить владельцев рисков.

Согласовать формат отчетности и порядок принятия решений.

Эти действия создают управляемость: даже если план изменится, команда и заказчик понимают, как проектом управляют.

Планирование: цели, требования, WBS, сроки и бюджет

Планирование в IT‑проекте превращает идею из стадии инициации в управляемую работу: появляются измеримые цели, понятный состав результатов, реалистичный график и прозрачный бюджет. В прошлой статье мы разобрали жизненный цикл и роль PM; здесь сфокусируемся на том, как именно собрать план так, чтобы им можно было управлять и пересобирать при изменениях.

Что такое «хороший план» в IT

Хороший план — это не документ на 200 страниц, а набор договоренностей, которые помогают принимать решения.

Обычно план отвечает на вопросы:

Зачем делаем проект и по каким критериям поймем, что он успешен.

Что именно делаем и где границы (что не делаем).

Как устроена работа (подход, роли, процесс согласований).

Когда будут контрольные точки и поставка ценности.

Сколько это стоит и из чего складывается стоимость.

Что может пойти не так и какой запас прочности заложен.

Важно: в Agile‑подходах планирование не исчезает, оно становится итеративным и чаще пересматривается.

Полезные источники по гибким принципам:

Agile Manifesto

The Scrum Guide

Цели, критерии успеха и границы

Цель проекта и измеримость

Цель должна быть понятной бизнесу и команде и не путаться с решением.

Плохо: «Сделать мобильное приложение».

Лучше: «Увеличить долю оплат через мобильный канал и снизить нагрузку на кассы за счет self‑service».

Чтобы цель стала управляемой, фиксируют:

Метрики успеха (что измеряем).

Целевые значения (какой результат считаем достаточным).

Срок достижения (к какому моменту).

Acceptance criteria и Definition of Done

В IT полезно разделять два уровня готовности.

Критерии приемки (acceptance criteria): условия, при которых заказчик принимает конкретную фичу или результат.

Определение готовности (Definition of Done, DoD): внутренний стандарт команды, что должно быть сделано, чтобы задача считалась завершенной.

Пример DoD для фичи:

код в основной ветке

автотесты прошли

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

выполнен code review

фича развернута на тестовом окружении

Границы: in scope и out of scope

Одна из главных причин срыва сроков — непроговоренные ожидания. Поэтому в планировании явно фиксируют:

что входит в проект

что не входит в проект

что является предпосылками и зависимостями (например, «доступы к API выдаст другая команда»)

Это становится основой для управления изменениями: если появляется новая идея, ее можно оценить относительно границ и согласованных целей.

Требования: от потребности к спецификации

Что такое требование

Требование — это утверждение о том, что должно быть реализовано, чтобы дать пользователю или бизнесу нужный результат.

Полезно различать:

Бизнес‑требования: зачем это бизнесу, какой эффект.

Пользовательские требования: что нужно пользователю (сценарии, задачи).

Функциональные требования: что система должна делать.

Нефункциональные требования: как система должна работать (производительность, безопасность, доступность, аудит, совместимость).

Ограничения: что нельзя нарушать (регуляторика, стандарты, платформа, дедлайн).

Техники выявления требований

В IT редко бывает один «идеальный» источник требований; обычно нужна комбинация.

интервью со стейкхолдерами

воркшопы и совместное моделирование процессов

анализ текущих данных и логов

прототипирование (быстрая проверка понимания)

пользовательские сценарии (use cases)

Приоритизация: что делаем сначала

В планировании важно не просто собрать список, а определить порядок поставки ценности.

Один из распространенных подходов — MoSCoW:

Must have: без этого релиз не имеет смысла

Should have: важно, но можно пережить без этого

Could have: приятно, если успеем

Won’t have: осознанно не делаем сейчас

Справка: MoSCoW method

WBS: декомпозиция работ и «100% объема»

Зачем нужна WBS

WBS (Work Breakdown Structure) — иерархическая структура работ или результатов, которая разбивает проект на управляемые части.

WBS помогает:

не забыть важные куски работ (тестирование, миграции, доступы, обучение)

корректно оценивать сроки и бюджет

распределять ответственность

видеть зависимости и критический путь

Справка: Work breakdown structure

Принципы хорошей WBS

Ориентация на результаты: на верхних уровнях лучше говорить языком deliverables.

Правило 100%: WBS должна покрывать весь согласованный объем работ проекта.

Достаточная детализация: элементы должны быть достаточно маленькими, чтобы их можно было оценить и назначить ответственным.

!Пример декомпозиции проекта на крупные блоки работ

WBS и Agile‑бэклог

Если проект идет итеративно, WBS часто живет рядом с backlog.

WBS дает «карту» проекта и контроль полноты.

Backlog дает порядок и детализацию поставки ценности.

Практика: WBS удобно держать на уровне крупных блоков и результатов, а внутри блоков вести backlog (эпики, user stories).

Оценка и планирование сроков

Что влияет на срок

Срок — это не только сумма оценок задач. Влияют:

зависимости между командами и системами

доступность людей и параллельная загрузка

очереди на согласования (ИБ, архитектура, закупки)

тестовые контуры, данные, доступы

релизные окна и ограничения эксплуатации

Как получать оценки

Оценка — это всегда прогноз. Полезно фиксировать не только число, но и допущения.

Распространенные способы:

экспертная оценка

аналогия с похожими задачами

декомпозиция и нижнеуровневая оценка (bottom‑up)

групповые методы (например, Planning Poker)

В зрелом планировании оценка обычно включает отдельные активности, которые часто забывают:

интеграции и контрактирование API

тестирование и исправление дефектов

подготовку релиза, миграции, откат

документацию и обучение

Зависимости и критический путь

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

Зависимость: задача B не может начаться, пока не закончится задача A.

Критический путь: самая длинная цепочка зависимых задач; задержка любой задачи на этом пути задержит проект.

Справка: Critical path method

!Иллюстрация зависимостей и критического пути

Контрольные точки и stage gates

Из прошлой статьи: контрольные точки (milestones) и stage gates помогают управлять ожиданиями. В планировании их фиксируют как точки принятия решений.

Примеры контрольных точек:

требования согласованы

архитектура согласована

готов пилот

завершен UAT

релиз в прод

проект передан в поддержку

Бюджет: из чего складывается стоимость

Типовые статьи затрат в IT

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

Обычно выделяют:

трудозатраты команды (разработка, тестирование, аналитика, DevOps)

подрядчики и аутсорс

лицензии и подписки

инфраструктура (облако, железо, сети)

безопасность (сканеры, аудит, пентест)

обучение и коммуникации (если требуется)

Прямая стоимость и резервы

В бюджете важно разделять:

Базовую оценку: сколько стоит «сделать по плану».

Резерв на риски (contingency): заложен под известные риски (например, вероятность доработок по ИБ‑замечаниям).

Управленческий резерв (management reserve): запас под неизвестные неизвестности, часто управляется на уровне спонсора.

Даже простой резерв дисциплинирует обсуждение: если появляется изменение, становится ясно, из какого источника оно финансируется.

Бюджет и модель контрактов

Если есть подрядчик, планирование сильно зависит от типа договора.

Fixed price: выше требования к фиксации объема и процедурам изменений.

Time and Materials: проще стартовать, но нужна сильная приоритизация и прозрачность прогресса.

Сборка базового плана: минимальный набор артефактов

Чтобы план работал, достаточно согласовать «скелет».

Цель и критерии успеха: метрики, целевые значения, срок.

Границы: in scope, out of scope, допущения.

Список результатов: deliverables и контрольные точки.

WBS/Backlog‑структура: декомпозиция до уровня, который можно оценить.

График: зависимости, этапы, релизные окна, критический путь.

Бюджет: статьи затрат, резервы, правила расходования.

Процедура изменений: как оцениваем влияние и кто утверждает.

Практичный принцип: чем выше неопределенность, тем короче горизонт детального планирования, но тем строже дисциплина пересборки плана и коммуникаций.

Частые ошибки планирования и как их избежать

Планируют только разработку и забывают тестирование, релиз, поддержку.

Не фиксируют out of scope, из-за чего объем «расползается».

Путают цель с решением и теряют смысл проекта.

Не учитывают внешние зависимости и очереди на согласования.

Делают один «идеальный» план и не пересматривают его при изменениях.

Антидот: план как система договоренностей + регулярный пересмотр по фактам прогресса и изменений.

Методологии: Waterfall, Agile/Scrum, Kanban и гибрид

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

роль менеджера и жизненный цикл IT‑проекта

планирование: цели, требования, WBS, сроки и бюджет

Теперь добавим к этому операционную систему выполнения плана: как принимать решения о детализации, как управлять изменениями, как измерять прогресс и как поставлять результат.

Важно: в IT часто говорят методология, подход, фреймворк и процесс вперемешку. В рамках курса будем считать, что:

подход задает общую философию (предиктивно или адаптивно)

фреймворк задает набор правил, ролей и событий (например, Scrum)

процесс описывает конкретные шаги и артефакты в вашей организации

Две крайности: предиктивный и адаптивный подход

В реальности большинство проектов лежит на шкале между двумя полюсами:

Предиктивный (Waterfall‑подобный): сначала максимально описываем что делаем, затем выполняем по плану и контролируем отклонения.

Адаптивный (Agile‑подобный): принимаем, что требования и понимание будут меняться, и строим процесс так, чтобы быстро получать обратную связь и корректировать курс.

!Шкала между предиктивным и адаптивным подходом

Выбор не должен превращаться в религию. Методология — это инструмент, который должен соответствовать:

уровню неопределенности требований

цене ошибки и регуляторным ограничениям

способности команды поставлять маленькими порциями

зрелости инфраструктуры релизов и тестирования

ожиданиям стейкхолдеров по отчетности и контролю

Waterfall: когда требуется предсказуемость и фиксация объема

Суть подхода

Waterfall (каскадная модель) предполагает последовательные фазы: требования → проектирование → разработка → тестирование → внедрение. Ключевая идея — по возможности заранее зафиксировать объем работ и критерии приемки, а изменения проводить через формальную процедуру.

Справка: Waterfall model

Что обычно считается сильными сторонами

Понятная структура этапов и документов.

Удобно для контрактов с фиксированным объемом.

Проще объяснить прогресс через завершение фаз и контрольные точки.

Типовые слабые места в IT

Риск поздно обнаружить, что сделали не то, что нужно пользователю.

Изменения требований становятся дорогими.

Тестирование и интеграция часто концентрируются в конце, а это увеличивает риск сюрпризов на финише.

Когда Waterfall уместен

Требования стабильны и хорошо понимаемы заранее.

Высокая цена ошибки и нужна строгая трассируемость (например, регуляторика).

Есть жесткие внешние зависимости и формальные согласования.

Роль PM в Waterfall

PM делает сильный акцент на:

фиксации границ in scope и out of scope

управлении изменениями через оценку влияния на сроки и бюджет

контроле прохождения stage gates и приемке артефактов по критериям

Связь с планированием из прошлой статьи прямая: WBS, зависимости, критический путь и бюджет становятся основой базового плана.

Agile как принципы и Scrum как фреймворк

Agile: о чем это на самом деле

Agile — это не “делаем без плана”, а делаем планирование непрерывным и принимаем решения на основе обратной связи.

Источник: Agile Manifesto

Практически это означает:

поставлять ценность небольшими порциями (инкрементами)

получать обратную связь раньше и чаще

регулярно пересматривать приоритеты и планы

Scrum: базовая механика

Scrum — популярный фреймворк для итеративной разработки, где работа организована спринтами фиксированной длины.

Источник: The Scrum Guide

#### Основные роли

Product Owner: отвечает за ценность и приоритеты.

Scrum Master: помогает команде следовать Scrum и устраняет препятствия на уровне процесса.

Developers: кросс‑функциональная команда, которая создает инкремент.

В терминах проекта из предыдущих статей: PM может существовать рядом со Scrum, но его фокус обычно смещается на управление стейкхолдерами, зависимостями, бюджетом, рисками и внешними stage gates.

#### Основные события

Sprint Planning: выбираем цель спринта и план.

Daily Scrum: ежедневная синхронизация.

Sprint Review: показываем результат и собираем обратную связь.

Sprint Retrospective: улучшаем процесс.

#### Артефакты

Product Backlog: упорядоченный список того, что нужно продукту.

Sprint Backlog: что делаем в спринте.

Increment: готовый результат, потенциально пригодный к поставке.

Чем Scrum отличается от “просто Agile”

Agile — набор ценностей и принципов.

Scrum — конкретные роли, события и правила, которые помогают эти принципы реализовать.

Когда Scrum подходит

Можно поставлять результат инкрементами.

Нужна регулярная проверка гипотез и приоритетов.

Команда относительно стабильна и может работать в ритме спринтов.

Роль планирования в Scrum

Планирование из прошлой статьи никуда не исчезает, оно меняет форму:

WBS часто держат на уровне крупных результатов.

Детализация уходит в backlog (эпики, user stories).

Оценка и сроки уточняются итеративно, опираясь на фактический темп команды.

Kanban: управление потоком и ограничение незавершенной работы

Kanban — подход к управлению работой как потоком задач через этапы процесса (например, анализ → разработка → тестирование → готово), с акцентом на прозрачность и предсказуемость.

Справка: Kanban

Ключевые понятия

Визуализация потока: доска, где видно, на каком этапе каждая задача.

Ограничение WIP (work in progress): лимит задач “в работе” на этап.

Pull‑принцип: берем новую задачу, когда освободилась емкость.

Управление временем прохождения (cycle time): сколько задача идет от “взяли” до “готово”.

Почему WIP‑лимиты важны

Если команда одновременно начинает слишком много задач, то:

растет переключение контекста

увеличивается очередь на тестирование и ревью

“почти готово” копится, а поставка замедляется

WIP‑лимиты заставляют заканчивать начатое, прежде чем начинать новое.

Когда Kanban подходит

Поступают задачи разного размера и срочности, нужен гибкий приоритет.

Есть много поддержки, инцидентов, мелких улучшений.

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

Kanban и проектная работа

Kanban можно использовать и в проектах, если:

проект можно разложить на поток задач

вам важнее непрерывная поставка, чем “ритм спринтов”

нужно управлять очередями между этапами (например, много согласований или тестирования)

Гибрид: когда проект требует и контроля, и адаптивности

Гибридный подход — это комбинация предиктивных и адаптивных практик. В IT он встречается чаще всего, потому что:

бюджет, закупки, ИБ‑согласования и архитектурные комитеты любят предиктивность

разработка и уточнение требований выигрывают от итеративности

Типовые гибридные схемы

Предиктивный контур проекта + Agile‑разработка: есть этапы, контрольные точки и базовый бюджет, но внутри этапов команда работает спринтами.

Waterfall для внешнего подрядчика + Agile внутри заказчика: контракт фиксирует крупные результаты, а внутри результаты декомпозируются итеративно.

Scrum для разработки + Kanban для поддержки и срочных работ: часть команды работает спринтами, часть — потоком с WIP‑лимитами.

Что важно, чтобы гибрид работал

Явно определить какие элементы фиксированы (например, бюджетный лимит и контрольные точки).

Явно определить что можно менять (состав фич в рамках цели, порядок поставки, детализацию требований).

Согласовать процедуру изменений: кто утверждает, по каким критериям, как обновляется прогноз.

Связь с предыдущей статьей: гибрид почти всегда опирается на базовые артефакты планирования (цель, границы, deliverables, этапы, бюджет), но допускает регулярную пересборку детального плана.

Как выбрать подход: практичная матрица факторов

Ниже — ориентир для выбора. Это не строгие правила, а подсказка, какие вопросы задавать на старте.

| Фактор | Waterfall‑подобный | Agile/Scrum | Kanban | Гибрид | |---|---|---|---|---| | Неопределенность требований | Низкая | Средняя/высокая | Средняя/высокая | Средняя | | Цена ошибки | Высокая, нужна формализация | Управляется частыми проверками | Управляется ограничением WIP и быстрым исправлением | Баланс | | Тип работы | Проект с фиксированным результатом | Продукт/развитие инкрементами | Поток задач, поддержка, улучшения | Смешанный | | Частота поставки | Реже, крупными релизами | Регулярно по спринтам | Непрерывно/по готовности | Комбинация | | Отчетность для стейкхолдеров | По фазам и документам | По инкрементам и метрикам | По потоку и времени прохождения | По контрольным точкам + итерациям |

Минимальный набор вопросов для выбора

Насколько вероятны изменения требований после старта?

Можно ли поставить ценность частями (инкрементами), или результат “работает только целиком”?

Какие внешние stage gates обязательны (ИБ, закупки, регуляторика)?

Как часто реально возможны релизы в прод (окна, эксплуатация, инфраструктура)?

Что важнее для успеха: предсказуемость по плану или скорость обучения и корректировки?

Типичные ошибки внедрения методологий

Путают Scrum с микроменеджментом через ежедневные отчеты, а не с инспекцией и адаптацией.

Берут Waterfall “потому что так привычнее”, игнорируя неопределенность требований.

Внедряют Kanban‑доску, но не ограничивают WIP, поэтому поток не улучшается.

Делают гибрид, но не договариваются, что именно фиксировано, и получают хаос вместо баланса.

Роль PM при разных подходах

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

В Waterfall PM сильнее сфокусирован на базовом плане, приемке фаз, управлении изменениями и контрактной дисциплине.

В Scrum‑среде PM чаще отвечает за стейкхолдеров, зависимости, бюджет, риски, внешние согласования и целостный роадмап.

В Kanban‑среде PM (или service delivery manager) усиливает управление потоком: прозрачность очередей, причины задержек, договоренности об SLA и классах обслуживания.

В гибриде PM становится “переводчиком” между мирами: защищает адаптивность разработки, не теряя управляемости по срокам, бюджету и обязательным контрольным точкам.

Следующая практическая задача после выбора подхода — настроить измерение прогресса и прозрачную отчетность для стейкхолдеров так, чтобы она соответствовала выбранной методологии.

Исполнение и контроль: коммуникации, качество, риски и изменения

Исполнение и контроль превращают план в реальный результат. Если в прошлых статьях мы:

определили роль PM и жизненный цикл IT‑проекта

собрали базовый план: цели, требования, WBS, сроки, бюджет

выбрали способ организации работы: Waterfall, Scrum, Kanban или гибрид

то здесь добавим практики, которые удерживают проект управляемым во время реализации: коммуникации, контроль прогресса, качество, риски и изменения.

!Цикл управления проектом во время реализации

Что именно означает «контроль» в IT‑проекте

Контроль в проектном управлении не равен микроменеджменту. Это регулярные ответы на вопросы:

где мы находимся относительно цели и плана

что изменилось и как это влияет на сроки, бюджет и результат

какие решения нужно принять сейчас, чтобы не потерять управляемость

В IT контроль почти всегда идет параллельно с выполнением работ и опирается на факты:

готовые результаты, которые можно проверить

измеримые метрики потока или выполнения

зафиксированные риски, проблемы, изменения и решения

Коммуникации: как сделать проект предсказуемым для стейкхолдеров

Проблемы проектов часто выглядят как технические, но корень у них коммуникационный:

ожидания не синхронизированы

решения приняты не теми людьми или не в тот момент

изменения “прилетели” в команду без оценки влияния

Карта стейкхолдеров и правила взаимодействия

Коммуникации начинаются с ответов:

кто влияет на проект и кто зависит от результата

кто принимает решения и по каким вопросам

как выглядит путь эскалации, если договориться не получилось

Практичный инструмент PM на исполнении: коммуникационный план.

Коммуникационный план: минимальный состав

Чтобы коммуникационный план работал, он должен быть коротким и применимым.

| Аудитория | Цель коммуникации | Формат | Частота | Владелец | |---|---|---|---|---| | Спонсор | Решения по приоритетам, бюджету, эскалации | Статус + короткий созвон | Раз в 1-2 недели | PM | | Заказчик/бизнес | Демонстрация результата, согласование изменений | Демо + список решений | По итерациям или раз в 2 недели | PO/PM | | Команда | Синхронизация и снятие блокеров | Daily/стендап | Ежедневно | Team/Scrum Master | | ИБ/архитектура/эксплуатация | Согласования, готовность к релизу | Чек‑лист + встреча | По контрольным точкам | PM/Tech Lead |

Статус-отчет: что в нем должно быть

Статус нужен не для «галочки», а чтобы стейкхолдеры принимали решения вовремя.

Хороший статус обычно содержит:

текущий статус по срокам, бюджету, объему и рискам

что сделано с прошлого статуса

что планируется до следующего статуса

блокеры и где нужна помощь

изменения и решения, которые нужно утвердить

прогноз даты ближайших контрольных точек

Эскалации: как не доводить до «пожара»

Эскалация не должна быть неожиданностью. Полезно заранее договориться:

что считается блокером

сколько времени команда пытается решить вопрос до эскалации

кому и в каком формате эскалируем

какие решения может принять PM, а какие только спонсор или комитет

Контроль прогресса: чем измерять «движение» при разных подходах

Методология влияет на то, какие метрики честнее всего показывают состояние.

В Waterfall‑подобной модели

Контроль обычно строится вокруг:

готовности фаз и артефактов (stage gates)

выполнения графика (план-факт по задачам и контрольным точкам)

управления отклонениями и изменениями базового плана

Полезный принцип: контролировать не только активность, но и проверяемый результат.

В Scrum

Контроль чаще строится вокруг:

готового инкремента по итогам спринта

Sprint Goal и факта ее достижения

качества по DoD

управления бэклогом и приоритетами

Источники:

Agile Manifesto

The Scrum Guide

Важно: скорость команды в спринтах может меняться. Нельзя «обещать» сроки, опираясь только на разовую скорость, не учитывая риски, отпускной сезон, внешние зависимости и изменения.

В Kanban

Контроль строится вокруг потока:

ограничения незавершенной работы (WIP)

времени прохождения задач

стабильности входящего потока и классов обслуживания

Полезные понятия:

cycle time: время от взятия задачи в работу до готовности

lead time: время от запроса до готовности

cumulative flow diagram: показывает очереди и узкие места

Справка:

Kanban

Cumulative flow diagram

В гибриде

Чаще всего работают два уровня контроля одновременно:

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

уровень исполнения: спринты или поток задач, качество, фактическая поставка

Ключ к гибриду: явно определить, что фиксировано, а что можно менять, и привязать к этому правила отчетности и согласования изменений.

Качество: как сделать так, чтобы «готово» действительно было готово

Качество в IT легко потерять, если думать о нем как о финальной проверке перед релизом. Практичнее управлять качеством постоянно.

Качество: два разных управленческих действия

Обеспечение качества (quality assurance): профилактика дефектов через процесс, стандарты, практики.

Контроль качества (quality control): проверка результата, поиск дефектов и несоответствий.

Проекту нужны оба механизма.

Definition of Done как страховка от “почти готово”

DoD полезно делать коротким и проверяемым. Пример для продуктовой команды:

| Пункт DoD | Зачем это нужно | |---|---| | Код прошел review | Снижаем дефекты и расхождение стандартов | | Пройдены автотесты и сборка | Не ломаем базовую работоспособность | | Пройдено тестирование по чек‑листу | Ловим регресс и ошибки сценариев | | Обновлены документация или runbook | Обеспечиваем поддержку и эксплуатацию | | Фича развернута на нужном контуре | Убираем сюрпризы интеграции |

Качество и нефункциональные требования

Частая причина проблем в проде: проект сделал функциональность, но не закрыл нефункциональные требования.

Типовые нефункциональные требования:

производительность

доступность

безопасность

аудит и трассируемость

совместимость и миграции

наблюдаемость: логи, метрики, алерты

Практика: явно включать их в план и критерии приемки, а не хранить “в голове”.

Качество как набор “quality gates”

Чтобы качество не зависело от героизма, полезны автоматизированные и организационные “ворота”, например:

запрет релиза без прохождения тестов и проверок

обязательный security review для изменений в критичных компонентах

чек‑лист готовности к релизу от эксплуатации

критерии “готовы к пилоту” и “готовы к промышленной эксплуатации”

Риски и проблемы: как удерживать неопределенность под контролем

Риск и проблема: в чем разница

Риск — возможное событие в будущем, которое может повлиять на цели проекта.

Проблема (issue) — уже случившееся событие, которое мешает проекту и требует действия.

Это разные режимы управления:

с рисками работают заранее, чтобы снизить вероятность или ущерб

проблемы устраняют и эскалируют по срокам

Реестр рисков: минимальный набор полей

Реестр рисков полезен, даже если это простая таблица.

Обычно достаточно:

описание риска

причина

вероятность и влияние

владелец риска

план реагирования

триггер: как поймем, что риск “активируется”

текущий статус

Матрица вероятность-влияние

Матрица помогает договориться, какие риски действительно требуют внимания.

Справка: Risk matrix

!Приоритизация рисков по вероятности и влиянию

Стратегии реагирования на риски

Классические варианты:

избегать: изменить план так, чтобы риск исчез

снизить: уменьшить вероятность или влияние

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

принять: осознанно ничего не делать, но иметь план на случай наступления

Важно: у “принятия” должен быть владелец и понимание последствий.

RAID как компактный инструмент контроля

RAID‑лог объединяет четыре списка:

Risks: риски

Assumptions: допущения

Issues: проблемы

Dependencies: зависимости

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

Управление изменениями: как не утонуть в scope creep

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

Уточнение и изменение: что считать change request

Полезное правило:

если мы уточняем требование, но не меняем согласованные границы и критерии, это уточнение

если меняется объем, срок, бюджет, качество, риски или обязательства по контрольным точкам, это изменение, которое нужно согласовать

Процесс change control: минимальный рабочий вариант

Справка: Change control

!Понятный поток согласования изменений

Чтобы change control работал, нужно заранее договориться о трех вещах:

Кто имеет право утверждать изменения разных типов.

Какие критерии обязательны для оценки влияния.

Как обновляются план, прогноз и коммуникации после решения.

Оценка влияния: что проверять

Перед утверждением изменения полезно пройти чек‑лист влияния:

содержание: что добавляем или убираем

сроки: какие задачи и зависимости сдвигаются

бюджет: нужны ли дополнительные затраты или резерв

качество: меняются ли DoD, критерии приемки, тестовая стратегия

риски: появляются ли новые риски или растет влияние существующих

эксплуатация: релизные окна, миграции, обратная совместимость

безопасность и регуляторика: нужны ли новые согласования

Change log и прозрачность

Даже в Agile‑среде полезен журнал изменений:

что изменили

почему

кто утвердил

какое влияние признано допустимым

Это снижает конфликты на финише проекта и помогает разбирать причины отклонений.

Практический ритм исполнения: базовая «операционная система» PM

Ниже пример ритма, который можно адаптировать под Scrum, Kanban или гибрид.

ежедневная синхронизация команды по блокерам

еженедельный статус для стейкхолдеров с прогнозом и решениями

регулярная ревизия рисков и зависимостей

контроль качества через DoD и quality gates

фиксированный путь для изменений и эскалаций

Ключевая идея: чем проще и регулярнее этот ритм, тем меньше в проекте сюрпризов.

Типичные ошибки на исполнении и контроле

Статусы описывают активность, но не дают прогноза и не поднимают решения.

DoD формальный, но не отражает реальную готовность к релизу.

Риски не имеют владельцев и планов реагирования.

Изменения добавляются в работу без оценки влияния и без обновления ожиданий.

Эскалация происходит поздно, когда вариантов уже мало.

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

Завершение проекта и улучшения: релизы, поддержка, ретроспектива

Завершение IT‑проекта часто ошибочно воспринимают как момент, когда код попал в прод. На практике это только один из шагов. Проект считается успешно завершенным, когда:

результат принят по понятным критериям

пользователи действительно могут им пользоваться

есть владелец в эксплуатации и поддержке

команда и стейкхолдеры зафиксировали уроки и улучшения

Эта статья логически продолжает предыдущие темы курса:

из планирования (цели, критерии приемки, DoD, границы) берется база для приемки и передачи

из исполнения и контроля (качество, риски, изменения, коммуникации) — дисциплина релизов, контроль готовности и управляемая стабилизация

Релиз как управляемая операция, а не «событие в конце»

Релиз — это организованный переход изменения в среду, где им пользуются. В проектной логике релиз связан с тремя вещами:

ценность: что именно начинает работать для пользователя

риск: что может сломаться и как откатиться

ответственность: кто принимает решение «выпускаем» и кто поддерживает после

Минимальная терминология релиза

Релиз — поставка функциональности в прод или в целевую среду.

Деплой — техническая операция развертывания.

Запуск (go‑live) — момент, когда функциональность становится доступной реальным пользователям.

Пилот — ограниченный запуск на части аудитории или трафика.

Откат (rollback) — возвращение к предыдущей версии при проблемах.

Стратегии релиза: как выбирать с учетом рисков

Выбор стратегии — часть управления рисками и качеством (связь с предыдущей статьей).

| Стратегия | Суть | Когда уместна | Основной риск | |---|---|---|---| | Big bang | Включаем сразу всем | Небольшие изменения, простая система | Высокая цена ошибки | | Пилот | Ограниченный запуск | Новая функция для широкой аудитории | Нужны критерии расширения | | Canary | Небольшой процент трафика | Есть метрики и наблюдаемость | Сложность настройки | | Blue‑Green | Две среды, переключение трафика | Нужна быстрая смена версии | Цена инфраструктуры | | Feature flags | Включение по флагу | Нужно отделить деплой от запуска | Дисциплина управления флагами |

Полезные справочные материалы:

Blue-green deployment

Canary release

Feature toggle

!Иллюстрация принципа Blue‑Green релиза и точки контроля

Готовность к запуску: критерии, чек‑лист и «ворота качества»

В прошлых статьях мы вводили критерии приемки и DoD. На завершении проекта их нужно связать в единую картину: готовность к запуску.

Что такое критерии готовности к релизу

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

Типовой состав критериев:

функциональные критерии приемки выполнены

DoD соблюден (код, тесты, документация, контуры)

закрыты обязательные требования безопасности и комплаенса

подготовлен план отката и проверена возможность отката

определены метрики успеха и настроен мониторинг

согласован план коммуникаций пользователям

Release readiness checklist: минимальный рабочий вариант

Чек‑лист лучше держать коротким и повторяемым, чтобы он реально использовался.

Версия и состав релиза зафиксированы.

Есть утвержденный план релиза с окном и ответственными.

Есть план отката и критерии, когда откатываем.

Пройдены тесты, включая регрессию и критичные нефункциональные проверки.

Подготовлены миграции данных (если есть) и проверен сценарий восстановления.

Настроены логи, метрики и алерты для ключевых сценариев.

Подготовлены инструкции для поддержки (runbook) и база знаний.

Согласованы доступы, эксплуатационные требования и ограничения.

Практика: превратить чек‑лист в quality gate — если пункт не выполнен, релиз нельзя начинать без явного решения и принятого риска.

Запуск и стабилизация: «гиперкар» и контроль в первые дни

После go‑live у проекта есть краткий период повышенного внимания. Часто его называют hypercare.

Зачем нужен hypercare

нагрузка и поведение пользователей отличаются от тестовых условий

всплывают редкие сценарии и интеграционные эффекты

поддержка еще не накопила опыт

Что заранее определить на период hypercare

срок периода (например, 1–2 недели)

расширенный график дежурств и контакты эскалации

приоритеты исправлений (какие дефекты блокируют работу)

формат ежедневных статусов (коротко: инциденты, метрики, решения)

критерии выхода из hypercare (стабильные метрики, нет критичных инцидентов)

Связь с «Исполнением и контролем»: в hypercare особенно важны прозрачные статусы, быстрые эскалации и заранее согласованные критерии решений.

Передача в поддержку и эксплуатацию: чтобы проект не «повис в воздухе»

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

Чем поддержка отличается от проекта

в проекте цель — создать и запустить

в поддержке цель — обеспечить стабильную работу и предсказуемые изменения

Поэтому передача должна включать не только артефакты, но и договоренности о режиме работы.

Минимальный пакет для передачи (handover package)

описание сервиса и его границ

архитектурная схема на понятном уровне

runbook: типовые операции, перезапуски, процедуры

мониторинг: какие метрики смотреть и какие алерты считать критичными

доступы и роли: кто что может делать

база знаний: FAQ, типовые ошибки пользователей

список известных ограничений и технического долга

контакты владельцев компонент и интеграций

Справочная терминология:

Service-level agreement

Runbook

Модель поддержки: кто за что отвечает

Чтобы не возникало «мы думали, это вы», закрепляют роли и каналы.

| Объект ответственности | Проектная команда | Поддержка (1–2 линия) | Эксплуатация/SRE/DevOps | Владелец продукта/бизнес | |---|---|---|---|---| | Инциденты в проде | Консультация, исправления в hypercare | Прием обращений, первичная диагностика | Восстановление, инфраструктура | Приоритеты, коммуникации бизнесу | | Изменения и улучшения | Передает бэклог и контекст | Фиксирует запросы пользователей | Оценивает риски изменений | Принимает решения о ценности | | Документация и знания | Формирует стартовый пакет | Ведет базу знаний | Ведет эксплуатационные регламенты | Утверждает пользовательские инструкции |

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

Формальное закрытие проекта: что нужно зафиксировать

Закрытие — это не бюрократия ради бюрократии. Это точка, где:

подтверждается достижение цели (или фиксируется отклонение)

закрываются финансовые и контрактные обязательства

принимаются решения о дальнейшей судьбе бэклога

Типовые артефакты закрытия

акт/протокол приемки по критериям

итоговый статус по целям, срокам, бюджету и объему

список открытых дефектов и их владельцы (уже вне проекта)

change log ключевых изменений, повлиявших на план

финальная версия RAID‑лога с выводами

список улучшений процесса (action items)

Практика: если часть объема переносится в «после проекта», важно формально определить, кто владелец этой работы и в каком процессе она будет выполняться (продуктовый бэклог, отдельный проект, операционные задачи).

Ретроспектива и postmortem: как извлечь уроки без поиска виноватых

Завершение проекта — лучший момент превратить опыт в улучшения, пока контекст свеж.

Ретроспектива: цель и правила

Ретроспектива — встреча, где команда улучшает способ работы. Даже если вы не используете Scrum, сама практика полезна.

Источник, где ретроспектива закреплена как событие Scrum:

The Scrum Guide

Минимальные правила:

обсуждаем процессы и решения, а не личности

опираемся на факты (метрики, события, таймлайн)

выходим с небольшим числом конкретных улучшений и владельцами

Postmortem по инцидентам: когда он нужен

Если на запуске или в hypercare были значимые инциденты, полезен отдельный разбор.

Практика blameless postmortem широко описана в инженерной культуре надежности:

Site Reliability Engineering (книга)

Что фиксируют в postmortem:

что произошло и какой был эффект

таймлайн: обнаружение, эскалации, действия

первопричины и системные факторы (например, недостаток мониторинга)

что помогло, а что мешало

конкретные меры предотвращения повторения

!Шаблон таймлайна для postmortem и привязки улучшений

Превращаем выводы в изменения: чтобы «уроки» не остались в документе

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

Как сделать улучшения исполнимыми

Выберите 3–5 улучшений, не больше.

Сформулируйте их как наблюдаемый результат, а не пожелание.

Назначьте владельца и срок.

Определите, где это будет жить: бэклог продукта, бэклог платформы, задачи поддержки, регламенты.

Пример хорошей формулировки:

плохо: «улучшить тестирование»

лучше: «добавить автотесты на 5 критичных сценариев оплаты и включить их в обязательный quality gate перед релизом; владелец — QA lead; срок — 3 недели»

Что измерять после завершения

Метрики зависят от цели проекта, но логика одна: проверяем, что ценность получена, а система стабильна.

продуктовые метрики (например, доля пользователей, которые перешли на новый сценарий)

операционные метрики (количество инцидентов, время восстановления)

метрики качества релизов (процент откатов, критичные дефекты после релиза)

метрики поддержки (объем обращений, повторяемые темы)

Роль PM на завершении

На этапе завершения PM делает работу, которую «не видно в коде», но которая определяет реальный успех:

обеспечивает согласованную приемку по критериям

организует готовность к релизу и управляемый запуск

проводит передачу в поддержку с ясными владельцами

закрывает хвосты по решениям, изменениям, рискам и обязательствам

помогает команде превратить опыт в конкретные улучшения

Если предыдущие статьи курса давали инструменты как планировать и контролировать, то эта статья фиксирует важный принцип: проект заканчивается не релизом, а переходом результата в устойчивую эксплуатацию и улучшением способа работы на следующий цикл.