Управление проектами по Технологии быстрого результата

Жизненный цикл проекта в ТБР

В лекции изложена логика построения жизненного цикла проекта на базе технологии быстрого результата (ТБР). Раскрывается структура из четырех фаз: инициация, подготовка, внедрение (повторяющееся для каждого релиза) и завершение. Главный акцент сделан на итерационном подходе к запуску системы и минимизации ключевых ИТ-рисков через раннюю проверку решения на пилотной зоне. Также рассматривается специфика управления проектной командой: разделение задач по внедрению и сопровождению между разными исполнителями для исключения конфликта интересов и поддержания эффективности.

Основные мысли

В результате изучения лекции слушатель будет способен:
1. Перечислить и охарактеризовать четыре фазы жизненного цикла проектов технологии быстрого результата.
2. Объяснить, почему фаза внедрения может повторяться многократно, и как это связано с релизной моделью.
3. Классифицировать риски ИТ-проектов по категориям и сопоставить их с фазами, на которых они снимаются.
4. Сравнить суть операционной деятельности (сопровождение) и проектной, выявив между ними конфликт целей.
5. Предложить схему разделения ресурсов проектной команды для параллельного выполнения работ по развитию и поддержке системы.
6. Аргументировать необходимость развертывания специализированной информационной системы для организации поддержки пользователей.
Показывать лекцию целиком
Краткое изложение
Записаться
Структура жизненного цикла проекта

Жизненный цикл проектов технологии быстрого результата (ТБР) состоит из четырех уникальных фаз:
1. Инициация;
2. Требования и ИТ-инфраструктура (подготовительная);
3. Внедрение (релизная фаза);
4. Завершение.

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

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

Основная логика фаз:
• Фаза инициации по сути является запуском проекта.
• Фаза «Требования и ИТ-инфраструктура» — подготовительная. Здесь выполняются работы, предваряющие основной объем задач.
• Фазы внедрения (их может быть несколько) — это ядро проекта. В них выполняется основной объем работ: кастомизация, развертывание очередного релиза, запуск в эксплуатацию, ввод данных и обучение пользователей.
• Фаза завершения — финал проекта. Здесь происходит передача результатов в сопровождение и реализуются действия для непрерывного улучшения системы менеджмента качества (СМК) компании.

Борьба с рисками на ранних стадиях

Такая структура жизненного цикла призвана минимизировать риски ИТ-проекта. Главные и наиболее опасные риски связаны с неправильным определением границ и рамок проекта. Если неверно понять, что именно хочет заказчик, проект невозможно выполнить качественно и достичь его целей.

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

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

Пилотная зона и подготовка
В начале проекта мы работаем в так называемой пилотной зоне. Что это дает?

• Снятие технологических рисков. Мы проверяем, насколько предлагаемое типовое решение соответствует ключевым требованиям заказчика, например, по производительности или масштабируемости.
• Подготовка к запуску. Параллельно мы уточняем требования, проводим начальное обучение и готовим инфраструктуру компании к развертыванию системы.

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

Управление внедрением и поддержкой

Одна из особенностей ТБР — параллельное существование двух потоков работ после запуска первого релиза:
1. Основной поток (проектный) — выпуск последующих релизов.
2. Поток сопровождения (операционный) — поддержка того, что уже работает в промышленной эксплуатации.

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

Конфликт проектной и операционной деятельности
Одному человеку крайне сложно одновременно эффективно выполнять и проектные, и операционные задачи. Это два противоположных вида деятельности:
• Проекты — это изменения. Они предполагают планомерную, равномерную работу на удаленную цель с заранее запланированными длительными задачами.
• Сопровождение — это сохранение стабильности системы. Работа строится по непредсказуемым запросам, здесь нет утвержденных планов, а есть сплошные неожиданности.
Человеку требуется время для переключения из одного режима в другой (иногда несколько дней). Поэтому совмещение «полдня проекты, полдня поддержка» крайне неэффективно.

Рекомендация по организации команды
Команду проекта следует строить по принципу разделения труда:
• Одни люди (физически) отвечают за основной поток работ по внедрению: выпуск и запуск релизов.
• Другие люди — за сопровождение ранее выпущенных релизов.

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

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

Краткие итоги

Главная ценность представленного подхода к управлению ИТ-проектами заключается в смене фокуса с попытки реализовать весь функционал единовременно на итерационное и контролируемое наращивание ценности. Автор демонстрирует, что провалы проектов редко связаны с технической невозможностью реализации, а почти всегда коренятся в коммуникационных разрывах и неверно понятых целях на старте. В связи с этим максимальные инвестиции усилий предлагается направлять не на устранение последствий, а на превентивное снятие рисков. Инициация и пилотная зона становятся не бюрократической формальностью, а инструментом верификации реальных потребностей заказчика до начала масштабной разработки.

Практическая значимость такого взгляда для руководителя проекта заключается в переосмыслении понятия параллельной работы. Эксплуатация уже работающей системы и создание новых функций — это два антагонистичных процесса с разной природой мотивации и планирования. Попытка заставить одного исполнителя одновременно «тушить пожары» (реактивная работа) и методично достигать целей (проактивная работа) ведет к когнитивной перегрузке и снижению качества в обоих направлениях. Вывод о необходимости аппаратного разделения проектных и сервисных ролей — ключевой управленческий принцип, позволяющий избежать выгорания команды и обеспечить предсказуемость сервиса. Без внедрения специализированной информационной системы поддержки этот баланс удержать невозможно, так как хаос устных обращений неизбежно поглотит все ресурсы развития.
Структура жизненного цикла ТБР
Проекты технологии быстрого результата состоят из четырех фаз: Инициация, Требования и ИТ-инфраструктура, Внедрение и Завершение. Принципиальная особенность — фаза Внедрения может повторяться много раз, по числу запланированных релизов. Причем количество этих циклов может меняться по ходу проекта в зависимости от уточнения целей.

Эта модель соответствует стандартам PMI. Логика распределения работ такова:
• Инициация — формальный запуск.
• Требования и ИТ-инфраструктура — подготовка к основному блоку работ.
• Внедрение (повторяющаяся) — основной объем работ (кастомизация, запуск релиза, обучение пользователей).
• Завершение — закрытие документов и обязательств, передача в сопровождение и улучшение СМК.

Ключевой приоритет — снятие рисков
Главная цель такой структуры — минимизация рисков. Самые страшные риски — это неверное определение границ проекта. Если на старте недопонять желания заказчика (например, автоматизировать только бухгалтерский учет, проигнорировав налоговый), проект ждет провал, который станет очевиден лишь в финале.

Поэтому в начале мы работаем в пилотной зоне. Здесь решаются две задачи:
1. Проверка, выдержит ли типовое решение ключевые требования заказчика (производительность, масштабируемость) — снятие технологических рисков.
2. Уточнение требований и подготовка инфраструктуры.

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

Управление внедрением и поддержкой
Специфика ТБР в том, что после запуска первого релиза в промышленную эксплуатацию возникает два параллельных потока работ:
1. Разработка и запуск новых релизов (проектная деятельность).
2. Сопровождение того, что уже работает (операционная деятельность).

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

Поэтому в ТБР обязательно разделение ресурсов:
• Одни члены команды занимаются только внедрением.
• Другие — только поддержкой.

Допускается долгосрочная ротация (неделями или месяцами), но не ежедневное совмещение. Кроме того, критически необходимо внедрить информационную систему для автоматизации поддержки, чтобы регистрировать заявки и контролировать их решение, а не полагаться на устные просьбы.

Выводы

1. Жизненный цикл ТБР включает четыре фазы, но фаза внедрения может повторяться многократно по числу релизов.
2. Количество итераций внедрения не является жестко фиксированным и может меняться по ходу проекта при уточнении целей.
3. Последовательность фаз коррелирует с рекомендациями PMI и логически делится на инициацию, подготовку, основную работу и завершение.
4. Главные риски ИТ-проекта связаны с неправильным определением содержания и границ на старте, а не с технологиями.
5. Использование пилотной зоны необходимо для снятия технологических рисков и подтверждения соответствия типового решения ключевым требованиям до масштабирования.
6. Подготовка инфраструктуры и уточнение требований должны быть полностью завершены до начала основного объема работ по внедрению.
7. После запуска первого релиза в эксплуатацию возникает два параллельных потока: развитие (новые релизы) и поддержка (сопровождение работающей системы).
8. Совмещение одним человеком функций внедрения и сопровождения крайне неэффективно из-за конфликта плановой и реактивной деятельности.
9. Переключение режима работы с проектного на операционный требует адаптационного времени и не может происходить мгновенно.
10. Для эффективной работы необходимо физически разделять команду на исполнителей, отвечающих за внедрение, и на сотрудников службы поддержки.
11. Запуск системы в эксплуатацию по релизной модели требует обязательного развертывания автоматизированной информационной системы поддержки пользователей.

Вопросы для самопроверки

1. Из каких четырех фаз состоит жизненный цикл проекта по технологии быстрого результата?
2. Почему количество фаз «Внедрение» в ТБР может изменяться по ходу проекта?
3. Чем содержание подготовительной фазы принципиально отличается от фазы внедрения?
4. Какие задачи решаются на фазе завершения проекта помимо закрытия документов?
5. Какой тип рисков ИТ-проектов считается наиболее критичным и почему?
6. Каким образом работа в пилотной зоне помогает бороться с технологическими рисками?
7. В чем заключается конфликт целей между проектной и операционной деятельностью?
8. Почему нельзя поручить одному и тому же сотруднику одновременно разрабатывать новый релиз и сопровождать работающую систему?
9. Как следует организовать структуру проектной команды при использовании ТБР, чтобы не потерять эффективность?
10. Какова роль информационной системы в организации поддержки пользователей и почему недостаточно простых заявок по почте?
11. Что должно быть сделано в первую очередь при старте ИТ-проекта для предотвращения споров о границах системы в финале?
12. Как изменяется степень определенности требований к системе по мере прохождения фаз жизненного цикла ТБР?
Предыдущее занятие Следующее занятие
Вернуться к учебному плану
^