Comments 6
Не черновичок, часом, опубликовали?..
<= отклонить, и => отклонитьа где же отложить? Каковы детали этой ветки? Когда и в киких условиях принимаем, и когда возвращаемся к рассмотру изменения?
Спасибо за замечание.
Поправил схему.
В идеале должно быть так.
1. Принято решение «Отложить»
2. Нужно уточнить до какой даты. И потом когда наступит дата, то снова обсудить изменение…
Процедура может повторится еще 2 раза.
3. Если 3 раза принимается решение «Отложить», то изменение автоматически принимает статус «Отклонено». (Это должно быть закреплено в регламенте управления изменения или аналогичными документами. Либо на словах то это звучит так: «Коллеги, мы уже третий раз по этому изменению никак не можем принять решение. Давайте его отклоним раз в нем нет такой ценности». Подобная фраза заставляет серьезнее отнестись к изменению и все-таки принять решение.)
На практике все зависит от вашей настойчивости и вашей способности заставить заказчика принять решение по изменениям. Может он готов запустить изменение в работу, но он боится попросить у своего шефа дополнительный бюджет, поэтому все откладывает на потом. А без бюджета вы не запустите изменение в проект.
Поправил схему.
В идеале должно быть так.
1. Принято решение «Отложить»
2. Нужно уточнить до какой даты. И потом когда наступит дата, то снова обсудить изменение…
Процедура может повторится еще 2 раза.
3. Если 3 раза принимается решение «Отложить», то изменение автоматически принимает статус «Отклонено». (Это должно быть закреплено в регламенте управления изменения или аналогичными документами. Либо на словах то это звучит так: «Коллеги, мы уже третий раз по этому изменению никак не можем принять решение. Давайте его отклоним раз в нем нет такой ценности». Подобная фраза заставляет серьезнее отнестись к изменению и все-таки принять решение.)
На практике все зависит от вашей настойчивости и вашей способности заставить заказчика принять решение по изменениям. Может он готов запустить изменение в работу, но он боится попросить у своего шефа дополнительный бюджет, поэтому все откладывает на потом. А без бюджета вы не запустите изменение в проект.
Стало яснее, но есть еще одно замечание:
Думаю более правильное будет вот так
P.S.
Если 3 раза отложенона блок-схеме изображен как if. Нужно бы добавить описанную Вами ветку возврата.
5. Решениена блок-схеме изображен как if, а нужно бы как switch.
Думаю более правильное будет вот так
Скрытый текст
P.S.
Управление изменениями в Scrum
десятки и сотни миллионов рублейДовольно высокий уровень. Завидую если владеете достоверной информацией. Но можете ли сравнить подход scrum и допустим waterfall (я лично с ним только и сталкивался). Очень интересно было бы.
waterfall — каскадная модель управления проектами (содержащая 1 итерацию), scrum — итеративная модель.
Большинство проектов во всех сферах жизни (ИТ, строительство, организационные проекты ) реализуются по каскадной модели.
Итеративная модель имеет преимущество в том, что последовательность этапов (анализ — разработка — тестирование и т.д.) повторяется много раз, а каскадная модель предполагает прохождение точек невозврата (один этап завершился — начался новый, без возврата назад). Поэтому и управлять изменениями в скрам можно более гибко, чем в водопаде.
Но описанный выше подход применяется и к scrum. Просто он более универсальный, чем scrum. Об этом будет описано в следующих частях.
Большинство проектов во всех сферах жизни (ИТ, строительство, организационные проекты ) реализуются по каскадной модели.
Итеративная модель имеет преимущество в том, что последовательность этапов (анализ — разработка — тестирование и т.д.) повторяется много раз, а каскадная модель предполагает прохождение точек невозврата (один этап завершился — начался новый, без возврата назад). Поэтому и управлять изменениями в скрам можно более гибко, чем в водопаде.
Но описанный выше подход применяется и к scrum. Просто он более универсальный, чем scrum. Об этом будет описано в следующих частях.
del
Sign up to leave a comment.
Профессиональное управление изменениями