Портал №1 по управлению цифровыми
и информационными технологиями

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

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


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

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

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

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

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


«VAP: Управление изменениями и конфигурациями в ИТ»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 25

  • «F vj»

    Рука дрогнула...

    А наш вебинар «Управление изменениями и релизами: один или два процесса?» не даёт ответ на этот вопрос? Или этот ответ неубедителен?

  • Victoria Golubeva

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

  • Andrey Kapustin

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

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

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

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

  • Andrey Kapustin

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

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

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

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

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

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

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

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

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

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

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

  • Вадим

    еще один критерий — необходимость привлечения внешних (по отношению к внутреннему ИТ) ресурсов

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Vladimir Lyaleko

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

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

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

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

        • Vladimir Lyaleko

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

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

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

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

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

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

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

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

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

    • Alexander Peshkov

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

  • Pavel Solopov

    А может быть Изменение это цель, а Проект способ достижения цели?

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

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

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

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

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

      • Pavel Solopov

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

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

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

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

    • Ну, началось...

      Предлагаю заканчивать прелюдию и переходить к главному вопросу — а что такое «проект»?

      Это ведь тоже основополагающее понятие, как и «сервис». Без определения термина дальше никак 🙂

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

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

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

        • Предлагаю тему считать закрытой.

          (наконец-то пришёл лесник, который всех разогнал 🙂 )

          Я полностью согласен с изложенной точкой зрения.

  • Данил Матесов

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

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

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

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

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

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

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

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

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

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

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

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


Добавить комментарий для Vladimir LyalekoОтменить ответ

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT