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

главный редактор «Управляем предприятием»

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

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

Жизненный цикл проекта призван минимизировать риски и отрицательные особенности информационно-технологических (ИТ) проектов. Наиболее существенные из них:

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

Жизненный цикл проекта (рис. 1) по ТБР состоит из четырех основных фаз:

  • фаза 0. Инициация проекта;
  • фаза 1. Требования и ИТ-инфраструктура;
  • фаза 2. Внедрение последовательных релизов системы. Фаз 2 может быть несколько (2.1, 2.2, ... 2.N) в зависимости от количества будущих релизов (обновлений) системы;
  • фаза 3. Завершение проекта.

При этом жизненный цикл имеет несколько особенностей:

  • фаза 0 — особая, поскольку проекта как такового еще нет, идут только предпроектные мероприятия, но формализация их в виде фазы 0 имеет принципиальное значение – результат этих мероприятий очень важен для успеха проекта;
  • каждая из фаз 2.1, 2.2, ... 2.N представляет собой мини-проект, проводимый по итерационной модели и заканчивающийся внедрением рабочего релиза системы, актом приема-сдачи работ и передачей очередного релиза системы в эксплуатацию;
  • проектные и операционные работы в ТБР выполняются параллельно, релизы новых версий «накатываются» на уже рабочую систему, которая передана на поддержку;
  • ключевые активности в проекте — управление коммуникациями, управление требованиями и изменениями и планирование работ – ведутся постоянно.

  жизненный цикл проекта

ПО — программное обеспечение, ИС — информационная система, АС — автоматизированная система

Рис. 1. Жизненный цикл проекта по ТБР с указанием наиболее важных выходных результатов фаз (документов и продуктов), а также сквозных активностей.

Компетенции руководителя проекта

Функции руководителя проекта в ТБР сильно отличаются от классического понимания. Он должен не столько раздавать задания и контролировать их исполнение, сколько превратить группу разрозненных и никогда не работавших друг с другом профессионалов из двух разных компаний (заказчика и исполнителя) в единую и сплоченную команду. Его задача — создать рабочую атмосферу и условия для роста доверия как внутри команды, так и в отношениях с заинтересованными лицами компании-заказчика, наладить коммуникации и самоорганизовать команду изнутри, устранить внешние препятствия. Это больше роль «папы», чем «генерала».

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

  • многие люди от природы хорошо коммуницируют и умеют создавать доверительную атмосферу (как правило, в компаниях такие люди уже есть;
  • формальное обучение практикам ТБР можно провести намного быстрее, чем обучение по PMBOK (Project Management Body of Knowledge — свод знаний по управлению проектами);
  • сравнение умений

Безусловно, при таком подходе есть и минусы: зависимость успеха проекта от личности его руководителя возрастает. При «классическом» проектном управлении справиться с трудностями руководителю проекта помогает весь наработанный объем методологий и приемов, а в ТБР это в большей степени зависит от его личностных качеств.

  Сравнение технологий

 Рис. 2. Сравнение умений и навыков руководителя проекта в ТБР и в «классическом» проектном управлении

Условия применения и ограничения ТБР

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

Преимущества

Недостатки

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

 

  • невозможность прогнозировать сроки и бюджет всего проекта, практически невозможно (или крайне сложно) вести проект от фиксированного бюджета;
  • требуется наличие практически готовой методологии и политик учета;
  • необходимость контроля объема технологических изменений и организационных изменений, происходящих в компании;
  • необходима активность и высокая скорость принятия решений заказчиком;
  • высокие требования к коммуникативным навыкам членов команды проекта;
  • повышенные требования к компетенции всех членов команды проекта (команда небольшая, скорость проекта высокая и «новички» в команде недопустимы);
  • сложности с проработкой оптимальной архитектуры решения: в условиях постоянных изменений и акцента на скорости качество приносится в жертву – архитектура решения может быть не оптимальной;
  • сложности с документированием решения в условиях постоянных изменений и релизов.

 

Можно сформулировать пять ключевых критериев, при выполнении которых рекомендуется применять ТБР Условия применения довольно жесткие. Однако они – именно рекомендованные, и, по словам авторов методологии, если одно из них не выполнено, применение ТБР возможно. Но риски проекта при этом существенно повышаются.

Методики и рекомендации, снижающие риски при работе по ТБР
Авторы ТБР проанализировали риски, которые наиболее существенным образом могут сказаться на достижении целей ИТ-проектов, и предложили минимально необходимые и достаточные методики и инструменты, способные привести к успеху на проекте:1. технологии снижения трансакционных издержек, ускорения и повышения эффективности:
  • технология эффективных коммуникаций и организации непрерывной, быстрой и эффективной обратной связи;
    o технология облегченного проектного документирования;
  • технология подготовки руководства пользователя в ходе обучения совместно с пользователем;
2. технологии определения и уточнения требований в ходе презентационного семинара или ролевого тренинга;3. технология гибкого планирования работ, ресурсов и затрат;4. тиражные готовые типовые и отраслевые решения, облегчающие прототипирование информационной системы;5. архитектура «1С:Предприятие», позволяющая «на лету» разрабатывать и часто (ежедневно) вносить существенные изменения в работающую систему и по ходу проекта реализовывать потребности, возникшие в результате изменений в бизнесе и окружении;

6. пакет типовых документов (договора, соглашения, протоколы), поддерживающих технологию ТБР.

Ключевые критерии применения ТБР:

  • масштаб — общая численность команды проекта 7—10 человек (и сотрудников заказчика, и подрядчика), объем – 2–3 тыс. человеко-часов разработки методологии учета и т. д., срок — 4—6 месяцев. При этом оценка масштаба проекта предполагает, что предпроектные работы не входят в содержание проекта;
  • критичность технологических изменений (доработок тиражной системы) – относительно небольшие изменения (например, в отчетах), не затрагивающие архитектуру приложения;
  • критичность организационных изменений – внедрение ИТ-системы неминуемо связано с организационными преобразованиями в компании, однако ТБР эффективна только в условиях небольших и относительно локальных организационных изменений, преобразований, находящихся в рамках полномочий заказчика системы и не затрагивающих принципы управления компанией;
  • готовность компании к быстрому принятию решений — ТБР работает только в условиях, когда заказчик (или заказчики) ИТ-системы может и готов быстро принимать решения; короткий цикл обратной связи достижим только в условиях быстрого принятия решений;
  • готовность методологий и политик учета — быстрых результатов не удастся добиться, если, кроме внедрения программного продукта, будет вестись разработка и утверждение методологий (если они необходимы в проекте, то, по мнению авторов ТБР, разработка методологий должна вестись за рамками проекта).

Если масштаб и критичность выше, а готовность компании ниже, то необходимо использовать технологию корпоративного внедрения решений на базе продуктов семейства «1С:Предприятие». Алгоритм принятия решения об использовании ТБР показан на рис. 3.

алгоритм принятия решений

Рис. 3. Алгоритм принятия решения об использовании ТБР, а также технологий корпоративного и стандартного внедрения.

К важнейшим условиям применимости ТБР необходимо отнести и высокую мотивацию заказчика и подрядчика на получение результата. Безусловно, выполнение этого условия в значительной степени зависит от внутренней ситуации в компании. Однако, в отличие от приведенных выше критериев, его нельзя считать «железобетонным» – мотивация к проекту может и должна повышаться по мере его развития и появления первых результатов.

 

© «УПРАВЛЯЕМ ПРЕДПРИЯТИЕМ»
Все права защищены. Все торговые марки являются собственностью их правообладателей.