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