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

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

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


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

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

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

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

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


Учебные курсы и сертификация
специалистов по ИТ-менеджменту

Комментариев: 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.

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

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

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

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

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

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

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT