Comments 19
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика. Изменение требований приветствуется, даже на поздних стадиях разработки. Управление изменениями это не столько об отклонениях от первоначального плана, сколько о взаимодействии и сотрудничестве.
Мне показалось, что тут больше об изменениях в организации — структура, процессы и т. п. Нет? Или "что у кого болит..."
Управление изменениями требований в классических проектах – это отдельный процесс, который позволяет проекту развиваться предсказуемо. Удовлетворение заказчика даже на поздних этапах и приветствие изменений, конечно, часто является базовой ценностью, но это ближе уже к гибким подходам и Agile Manifesto. Тут еще важно помнить про управление ожиданиями.
Но большая часть статьи конечно про организационные, процессные и иные изменения в компании.
Он называется PMBOK, от Body of Knowledge
А как же изменения вносимые не в рамках проектов? Например периодические улучшения работы серверов, влияющие на разработчиков и пользователей 1С: сегодня сместили время бэкапа, завтра переместили сервер в виртуалку. Такими изменениями управлять тоже надо. Но, поскольку это повседневная деятельность, связанная с взаимодействием исполнителей и команд внутри ИТ-подразделения, то это не проектный менеджмент, а скорей регламентируемая деятельность. В смысле, описываемая регламентом «Управление изменениями».
Про это вам есть что рассказать? Интересно…
То, о чем говорите вы – скорее относится к оптимизации операционной деятельности. И здесь действуют все правила внедрения изменений – есть «статус кво», есть сопротивление, есть вовлеченные люди. Будет продолжение этой темы во второй статье, где мы как попробую описать, какие подходы могут помочь это сопротивление преодолеть.
А если уникальное, но неограниченное по, как минимум, времени? Ну типа продуктовой компании, приходят таски (уникальные, разнообразные) и пилят их по приоритетам, какую за час, какую за полгода?
Продукт же может развиваться бесконечно (хабр, Acronis Cyber Cloud, Яндекс.Такси)
Я так понимаю: если этот процесс достаточно четко регламентирован, то и говорить о сопротивлении изменениям не придётся :-)
-сопротивление от начальников, обычно происходит при инициативе соотрудников. Если не принимать без обьяснения причин, то постепенно отдел превращается в тухлое болото.
-сопротивление от соотрудников, когда саботируются инициативы спущенные сверху.
Я так понимаю, данный пост о втором случае. А что делают в первом?
Без желания или готовности поддерживать сверху действительно обычно мало путного выходит. Но если в организации не два уровня, а больше, а сопротивление где-то посередине, то вопрос уже, можно ли внутри компании как-то доносить идеи на +1 +2 уровня вверх от своего руководства.
Ну и каждая инициатива – это мини-проект, который нужно уметь «продать». Отличный повод углубиться в маркетинг или почитать про пирамиду Минто.
Я пару раз пропихивал изменения в команду без ведома начальства, эмулируя привычный начальству процесс. Например, автоматический деплой внедрил. Оно только в заслугу себе поставило, что уменьшилось число сбоёв при деплое.
Исключительно на основную цель бизнеса — извлечение прибыли. Крохи, конечно, какие-то перепадают, ключевым, ибо для остальных сотрудников все ништяки рисуются в будущем, а когда будущее наступает уже совсем другие цели, сотрудники, начальники. И никто не помнит про обещания не то, что при наступлении будущего, но и через неделю после обещаний.
И да, грустная диаграмма про неизлечимых пациентов как обновленную личность.
Направленных на это изменений, может и маловато, но есть те, которые направлены на то же увеличение прибыли или иные бизнес-метрики, но и улучшают положение сотрудников. например, в результате автоматизации с них снимается рутинная монотонная работа и осатётся только более-менее творческая. У тех, кого не сократят, конечно :)
Project Management: Управление изменениями, часть 1