Вопрос из зала: разница между изменением и проектом

Постоянный участник дискуссий на нашем портале Александр Пешков спрашивает:


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

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

Если второе — тогда проектами становятся только те разработки, которые изменяют пользовательские функции или параметры качества. Здесь нюансы — какие именно параметры и функции? Можно ли считать пользовательскими функции консоли администратора приложения, к примеру?

Какая у вас практика, и какие есть плюсы/минусы у этих подходов?

Каков процент проектов в общем объеме изменений, в первом и втором случаях?


ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Victoria Golubeva

    Мы внутри компании договорились, что под проектами понимаем те работы, которые либо требуют значительных финансовых затрат, либо занимают у рабочей группы более 10 рабочих дней на тестирование и внедрение (при условии загруженности только этими работами). Остальное — изменения.

  2. Andrey Kapustin

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

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

    — существенное кол-во ресурсов на реализацию

    — внешние изменения для пользователя НЕ определяют организации фазы, т. к. к примеру рефакторинг/редезайн

  3. Andrey Kapustin

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

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

    — существенное кол-во ресурсов на реализацию

    — видение Заказчика данного изменения как существенного/крупного: например кардинально меняется бизнес-процесс

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

    «Какая у вас практика, и какие есть плюсы/минусы у этих подходов?»

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

    Мне кажется, что попытка со стороны IT сепаратизировать в портфеле больше проектов, чем их в голове Заказчика, чревата недопониманием и трениями. Если Вы уверены что некоторые изменения достойны быть названы проектами, то в пору поговорить с Заказчиком на эту тему, привести аргументы (по ресурсам, сцеплению с другими проектами, влиянию на Бизнес) и организовать проект руками самого Заказчика.

    «Каков процент проектов в общем объеме изменений, в первом и втором случаях?»

    90% по первой схеме, 10% нет.

    В 10% входят крупные изменения, на которые пока не удалось выбить денег, но по которым ведется работа с Заказчиком: что без этого будет плохо.

  4. Станислав Уштей

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

    Это два разных процесса. Смотрим ITIL для процесса управления Изменениями и смотрим PMBOK для процесса управления проектом.

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

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

    Пример: Мы можем создать институт менеджеров изменений, при этом поручить им :

    1. Общение с бизнесом в рамках решения вопросов, связанных с изменением информационного решения (ИР) – роль «менеджер изменений»;

    2. Владение ИР и обеспечение их целостности при изменениях – роль «бизнес-архитектор»;

    3. Организацию сопровождения при приеме ИР в промышленную эксплуатацию;

    4. Управление уровнем сервисов в рамках поддержки и сопровождения ИР (как бы считая ИР -сервисом) – роль «менеджер сервиса»

    5. Контроль и управление проектом при реализации изменений ИР – роль «руководитель проекта».

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

    Понятно, что это пример и разделить можно и по другому.

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

    1. Vladimir Lyaleko

      У меня вот при детальном изучении проектной методологи RRINCE2 сложилось прямо противоположное представление. Изменение по сути частный случай проекта. Это отчасти подтверждает раздел 1.3 книги Service Strategy где описывается BPM Guidens.

      1. Станислав Уштей

        На него можно смотреть как на частный случай при функциональном подходе, когда люди что-то делают. Нельзя возразить против того, что для проведения любого изменения нужен проект — «мини», с трудоемкостью 1 ч/д или «макси», с трудоемкостью 10000 ч/д

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

        С моей точки зрения — очень важно различать деятельность организационно-штатного подразделения (см. пример) и ролевое исполнение процессов. Во втором случае получается более глубокое понимание деятельности сотрудников компании

        1. Vladimir Lyaleko

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

          Если посмотреть 7 процессов PRINCE2, то они фактически представляют собой расширенный жизненный цикл изменения. Мапинг сделать очень просто. Более того, в методологии отдельным разделом написано про адаптацию, мол управление проектами может быть адаптированно для изменений любой сложности! Принципы управления похожи, цели ещё более похожи! Компетенции зависят от задачи...

          В своей практике встречал компании где управление проектами и изменениями это один вид деятельности. При это в одной компании всё называют изменениями, в другой всё называют проектами, но подход к работе у них по сути один и тот же.

          Про организационную деятельность и ролевое исполнение процессов полностью согласен.

          1. Станислав Уштей

            Очень правильно сказано – абсолютно с Вами согласен.

            Мы живем в относительном мире, а основное правило Архитектуры компании — ЕА это то, о чем договорились все заинтересованные стороны.

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

            Мне идеи BPM симпатичны тем, что они позволяют использовать для построения EA или отдельных систем управления компании различные методологии и их framework-и, а самое главное избегать зависимости от них и их создателей. Обсуждаемый вопрос великолепный тому пример: как только мы встали на что-то жестко-ограниченное: PRINCE2 или на ASAP/RUNSAP — сразу начинается «путанится», с которой и связан обсуждаемый вопрос.

            При этом , я на пример, с удовольствием использую ASAP/RUNSAP, чтобы выстроить операционные процессы управления жизненным циклом Информационного решения, а вы вот PRINCE2 наверное

    2. Alexander Peshkov

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

    1. Станислав Уштей

      Тут можно запутаться, так как цель изменить Информационное решение (ИР) конечно общая и для проводимого проекта, и для проводимого изменения.

      Если мы работаем в процессном поле то можно увидеть разницу:

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

      2. При управлении проектом – нужно проуправлять ресурсами и выполнить план проекта. При этом менеджер проекта может вообще не знать, что он создает.

      P.S. Коллеги, я понимаю, что специализированные методологии управления проектами замахиваются именно на знание того, что именно они создают. Я в своих рассуждениях опираюсь на практики BPM и ITSM

      1. Pavel Solopov

        менеджер проекта может вообще не знать, что он создает

        Что-то у меня большие сомнения в результатах от такого проекта.

        Это похоже на наши госпроекты. Где главное не дорога, а количество уложенного асфальта.

        1. Станислав Уштей

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

      1. Роман Журавлёв

        Управление проектами — это сложный дорогой способ управлять изменениями. Проект(ы) — это изменение (-ния), проводимое (-мые) с применением указанного способа.

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

        Отношение границ ИТ-проектов и ИТ-изменений действительно блестяще описано в вебинаре ДИ, слайды 8-10, лучше не скажешь.

  5. Данил Матесов

    Выдержка из учебных материалов Школы Бизнеса Открытого Университета

    ----------------------------------

    Управление проектами и управление изменениями взаимосвязаны, но не идентичны. Как определить, следует ли применить для решения рассматриваемой проблемы идеи и методы управления изменениями или более подходящими являются идеи и методы управления проектами? Ответ на этот вопрос не может дать выявление характера проблемы. Полезно начать с ответа на вопрос, является ли проблема ограниченной или неограниченной. Сводка различий между между ограниченными и неограниченными проблемами приведена в таблице 1.

    Ограниченные Неограниченные

    Временной масштаб Ограниченный Большой или неопределенный

    Приоритеты Ясные Спорные

    Степень понимания Высокая Низкая

    Решение Сходство с известными решениями Неопределенность характера решений

    Количество заинтересованных сторон Малое Большое

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

    Последствия Ограниченные Неясные или опасные

    Ограниченные проблемы скорее всего будут поддаваться рациональному, линейному и упорядоченному подходу, характерному для управления проектами. В случае ограниченной проблемы можно сказать: «Мы находимся в пункте А и должны попасть в пункт Б». Неограниченные проблемы в силу присущего им вовлечения множества интересов, большей неопределенности и сложности обычно не поддаются решению методами управления проектами. Столкнувшись с неограниченной проблемой, Вы можете сказать: «Мы должны попасть из пункта А в пункт Б», но затем пункт Б может быстро превратиться в пункт В или Г, а закончиться все может тем, что Вы начнете сомневаться в том, действительно ли вы находитесь в пункте А! К неограниченным проблемам требуется итерационный подход.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
7
Учебный курс:
Основы ITIL (очно)