Если вас поставили руководить программой, то первая вещь, которая для вас меняется - это планирование. Теперь вам нужно планировать не достижение целей, а получение бизнес-эффектов. Бизнес-эффекты - это больше денег, меньше трат, быстрый выход на рынок или низкая текучка ключевых людей. По сравнению с управлением проектами содержание программы менее важно, чем при управлении проектом, где зафиксированное содержание изменять нельзя. Другими словами программы реализуют стратегические цели, а проекты тактические.
Хорошей базой для того, чтобы освоить управление программой, служит стандарт PMI. У третьей версии стандарта есть русский перевод. Этот стандарт рассказывает про концептуальную дисциплину управления программами, что в них всех есть общее. В нем нет конкретики про то, как получать бизнес-эффекты в программах.
Если говорить про инженерные программы, то конкретика есть в стандартах ISO15288 и ISO12207. Первый стандарт преимущественно для “железных” систем, второй преимущественно для софта. Эти стандарты рассказывают, какие эффекты можно получить в программах и для каждого эффекта указывают, с кем должен общаться руководитель программы, чтобы запланировать получение бизнес-эффектов. Это могут быть либо менеджеры либо инженеры.
Когда говорят, что в компании есть управление программами, то на практике это означает, что есть какие-то элементы, общие для всех проектов. Эти элементы называют инфраструктурой проектов. Обычно в инфраструктуру входит управленческая отчетность, финансовый контроль, управление рисками и закупками, процедуры принятия решения и другие корпоративные функции. Польза стандартов ISO15288/12207 в том, что в них есть полный список того, что можно унифицировать в программах, чтобы получить пользу. Но элементы инфраструктуры проектов - это не батарейки, которые можно менять как угодно, это процессы с людьми и сложными техническими системами. И повторное использование элементов инфраструктуры может быть сложным, на этом пути есть множество ловушек.
Чтобы понять стандарты ISO15288/12207, нужно различать целевую и обеспечивающую системы. Целевые системы поставляются заказчику, за них платят деньги, у них есть жизненный цикл и их строят инженеры. Целевой системой розничной торговой сети является магазин. У магазина есть жизненный цикл, его надо задумать, разработать, построить, запустить и открыть для покупателей, а потом закрыть. Обеспечивающие системы “протаскивают” целевую систему по жизненному циклу. Обеспечивающие системы - это организации, предприятия, процессы и проекты. Думают про целевые и обеспечивающие системы одинаково, но используют разные слова:
Целевая
|
Обеспечивающая
|
Продукт
|
Проект
|
Системная архитектура
|
Архитектура предприятия
|
Системные требования
|
Стратегия
|
Системные интерфейсы
|
Бизнес-интерфейсы (OLA, SLA)
|
Системные функции
|
Бизнес-функции
|
Конструкция, структура системы
|
Организационная структура (матричная)
|
 |
| Вначале вы придумываете, какой магазин вы откроете - дискаунтер, бутиковый, что вы в нем будете продавать, по каким ценам, какой будет имидж и марка магазина. Потом вы формируете его ассортиментную матрицу, делаете планировку торгового зала, размещаете оборудование. Потом арендуете помещение и строите магазин, и открываете его для покупателей. Это не календарный план по этапам проекта, потому что после открытия вы можете придумывать новую планировку торгового зала, задумывать тематические товарные выставки, менять ценообразование. Каждый из этих овалов может идти в параллель другим. Это практики жизненного цикла целевой системы. |
Определение жизненного цикла целевой системы и ее обеспечивающих систем все вместе называются моделью жизненного цикла. Модель жизненного цикла - общая база процессов и задач жизненного цикла системы, которая также нужна для общения и понимания в больших проектах и программах.
 |
| Модели жизненного цикла даже для такой простой системы, как магазин, бывают достаточно большими, но на их разработку обязательно нужно заложить время и ресурсы, это сильно помогает потом в общении и организации работ. Модель жизненного цикла определяет логику создания и получения пользы от целевой системы. Все планы проектов строятся, исходя из этой логики. |
В ISO15288 есть 4 группы процессов. Каждый из 30 процессов можно унифицировать и положить в основу инфраструктуры проектов. Такое организационно-техническое решение программы можно создать один раз и использовать в нескольких проектах. Такое повторное использование и дает те самые бизнес-эффекты, которые нужно получать в программах. Например, вы можете создать метрологическую службу на предприятии и использовать во всех программах одну измерительную лабораторию, и это будет дешевле и лучше, чем держать разные службы метрологов для каждого проекта по отдельности. Или можете создать единый процесс управления знаниями и базу знаний и лучших практик, объединить все это в корпоративный университет, и экономить на подготовке кадров для подразделений и проектов. В стандарте и сопутствующих документах есть много примеров и объяснений, как это сделать.
На пути повторного использования организационно-технических решений есть много трудностей, я укажу на основные.
Разработка дизайна обеспечивающей системы опережает разработку дизайна целевой.
Очень часто бывает, что к руководителю проекта приходит финансовый менеджер и требует подать детальный бюджет, а руководитель требует рассчитать сроки реализации проекта. При этом техническое решение проработано только на принципиальном уровне, нет многих необходимых деталей. В этой ситуации мы можем сказать, что от менеджера требуют проработать дизайн обеспечивающей системы более детально, чем проработан дизайн целевой системы. Это невыполнимое требование, организационные решения проекта могут быть известны и рассчитаны ровно в той же мере, в какой известны требования и конструкция продукта.
“Да тут все то же, что и в том проекте!”.
Иногда кажется, что можно просто взять уже работающее и опробованное решение и применить его в своем проекте. Решение работало хорошо в другом проекте, но у этого решения другие диапазоны работы. Например, автоматическая касса хорошо работает в придомовом магазине с 1000 посетителями в день, но будет абсолютно непригодна для гипермаркета с 60,000 посетителей в день.
Меняется ли что-то в окружении системы? - Скорее всего нет, но времени на изучение не дают.
Даже типовые и простые проекты нужно тщательно прорабатывать и изучать место их установки, эксплуатации, порядок обслуживания, потому что другая окружающая среда может привести к полному провалу проекта. Например, проектировщики бутылки воды не учли, что бывает Солнце.
Это же покупное изделие или продукт, зачем проектировать систему? Бери и настраивай.
Даже если вы ставите 1С в типовой конфигурации, нельзя полностью исключать из проекта сбор и анализ требований, разработку архитектуры, верификацию и валидацию. Не бывает двух идентичных процессов и компаний, не бывает двух идентичных установок даже типовых продуктов.
В итоге, если вам нужно начать управлять программами, вам нужно:
- Изучить концептуальную дисциплину управления программами;- Разработать модель жизненного цикла с использованием ISO15288/12207;
- Избегать ошибок повторного использования.
Комментариев нет:
Отправить комментарий