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

[S_A]

Не черновичок, часом, опубликовали?..

[icepro]

<= отклонить, и => отклонить

а где же отложить? Каковы детали этой ветки? Когда и в киких условиях принимаем, и когда возвращаемся к рассмотру изменения?

[Kirilkin]

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

На практике все зависит от вашей настойчивости и вашей способности заставить заказчика принять решение по изменениям. Может он готов запустить изменение в работу, но он боится попросить у своего шефа дополнительный бюджет, поэтому все откладывает на потом. А без бюджета вы не запустите изменение в проект.

[icepro]

Стало яснее, но есть еще одно замечание:

Если 3 раза отложено

на блок-схеме изображен как if. Нужно бы добавить описанную Вами ветку возврата.

5. Решение

на блок-схеме изображен как if, а нужно бы как switch.

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

Скрытый текст

P.S.

Управление изменениями в Scrum

десятки и сотни миллионов рублей

Довольно высокий уровень. Завидую если владеете достоверной информацией. Но можете ли сравнить подход scrum и допустим waterfall (я лично с ним только и сталкивался). Очень интересно было бы.

[Kirilkin]

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

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

[Kirilkin]

del