Профессиональное управление изменениями

    По статистике средний ИТ-проект за месяц прирастает изменениям на 5%. Несложно посчитать, что за полгода проект изменяется практически на треть, а за год проект становится больше чем на половину. Более того, одной из основных причин неудачных ИТ-проектов является неуправляемый поток изменений, приводящий к провалу проекта. Предлагаю использовать системный подход к управлению изменениям.

    Процедура управления изменениями


    Вначале будет рассказано об общей схеме управления изменениями. В последующих частях будут более детально описаны аспекты управления изменениями и как адаптировать эту процедуру к различным изменениям.(см. содержание внизу статьи).



    Для сравнения, в большинстве проектов это выглядит так:


    1. Запрос на изменение

    Инициатор высказывает требование, которое выходит за рамки проекта и является изменением. Это еще не сигнал к действию, а пока что только запрос.

    2. Фиксация запроса в реестре изменений

    Любые запросы на изменение нужно фиксировать в специальном документе «Реестр запросов на изменение» (или Реестр изменений), где содержится список всех запросов на изменения.
    Подробнее этот процесс будет рассмотрен в части 2.

    3. Анализ изменения

    Этот процесс позволяет понять, как предлагаемое изменение повлияет на проект. Также на этапе анализа проводится оценка последствий, что будет, если изменение принять и что проект потеряет, если отказаться от изменения.
    Подробнее этот процесс будет рассмотрен в части 2.

    4. Переговоры

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

    5. Решение

    По результатам обсуждения предлагаемого изменения должно быть принято одно из трех решений:
    — Принять
    — Отклонить
    — Отложить.

    6. Внесение изменений в план

    1) Внести изменения в базовый план (первоначальный план проекта), так как изначально работа над проектом планировалась по одному сценарию, а теперь этот сценарий изменился.
    2) В рабочий план, который должен являться вашим навигатором по проекту.

    7. Выполнение работ

    Так как изменение внесено в план, то оно является частью проекта. Работаем с ним, как с обычными задачами проекта.
    Здесь все просто. Нужно выполнить работы.

    8. Проверка результатов

    И сдать на проверку.
    Если работы приняты, то работы по реализации изменения считаются завершенными.
    • +3
    • 11,1k
    • 6
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 6
    • +2
      Не черновичок, часом, опубликовали?..
      • 0
        <= отклонить, и => отклонить
        а где же отложить? Каковы детали этой ветки? Когда и в киких условиях принимаем, и когда возвращаемся к рассмотру изменения?
        • 0
          Спасибо за замечание.
          Поправил схему.
          В идеале должно быть так.
          1. Принято решение «Отложить»
          2. Нужно уточнить до какой даты. И потом когда наступит дата, то снова обсудить изменение…
          Процедура может повторится еще 2 раза.
          3. Если 3 раза принимается решение «Отложить», то изменение автоматически принимает статус «Отклонено». (Это должно быть закреплено в регламенте управления изменения или аналогичными документами. Либо на словах то это звучит так: «Коллеги, мы уже третий раз по этому изменению никак не можем принять решение. Давайте его отклоним раз в нем нет такой ценности». Подобная фраза заставляет серьезнее отнестись к изменению и все-таки принять решение.)

          На практике все зависит от вашей настойчивости и вашей способности заставить заказчика принять решение по изменениям. Может он готов запустить изменение в работу, но он боится попросить у своего шефа дополнительный бюджет, поэтому все откладывает на потом. А без бюджета вы не запустите изменение в проект.
          • 0
            Стало яснее, но есть еще одно замечание:
            Если 3 раза отложено
            на блок-схеме изображен как if. Нужно бы добавить описанную Вами ветку возврата.
            5. Решение
            на блок-схеме изображен как if, а нужно бы как switch.

            Думаю более правильное будет вот так
            Скрытый текст



            P.S.
            Управление изменениями в Scrum
            десятки и сотни миллионов рублей
            Довольно высокий уровень. Завидую если владеете достоверной информацией. Но можете ли сравнить подход scrum и допустим waterfall (я лично с ним только и сталкивался). Очень интересно было бы.
            • 0
              waterfall — каскадная модель управления проектами (содержащая 1 итерацию), scrum — итеративная модель.
              Большинство проектов во всех сферах жизни (ИТ, строительство, организационные проекты ) реализуются по каскадной модели.
              Итеративная модель имеет преимущество в том, что последовательность этапов (анализ — разработка — тестирование и т.д.) повторяется много раз, а каскадная модель предполагает прохождение точек невозврата (один этап завершился — начался новый, без возврата назад). Поэтому и управлять изменениями в скрам можно более гибко, чем в водопаде.

              Но описанный выше подход применяется и к scrum. Просто он более универсальный, чем scrum. Об этом будет описано в следующих частях.
        • –1
          del

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.