Comments 19

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

Мне показалось, что тут больше об изменениях в организации — структура, процессы и т. п. Нет? Или "что у кого болит..."

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

А если уникальное, но неограниченное по, как минимум, времени? Ну типа продуктовой компании, приходят таски (уникальные, разнообразные) и пилят их по приоритетам, какую за час, какую за полгода?

Это тогда уже не проектный, а продуктовый подход. Проект всегда ограничен по времени (внедрение CRM, разработка софта по ТЗ, строительство дома, запуск конвейерной линии), его после реализации передают в эксплуатацию/оперирование.
Продукт же может развиваться бесконечно (хабр, Acronis Cyber Cloud, Яндекс.Такси)

То есть любую деятельность внутри организации можно отнести либо к проектной, либо к продуктовой, либо к операционной деятельности?

В парадигме проектного подхода – на проектную и операционную деятельность.
В парадигме продуктового – я не уверен, что всегда можно отделить операционную. Хотя тут можно подискутировать
Внедрение изменений в процессе именно операционной деятельности — весьма интересно. Ждём.
Я так понимаю: если этот процесс достаточно четко регламентирован, то и говорить о сопротивлении изменениям не придётся :-)

1) не везде он регламентирован чётко
2) "итальянские забастовки" никто не отменял

Есть два типа сопротивления изменениям:
-сопротивление от начальников, обычно происходит при инициативе соотрудников. Если не принимать без обьяснения причин, то постепенно отдел превращается в тухлое болото.
-сопротивление от соотрудников, когда саботируются инициативы спущенные сверху.
Я так понимаю, данный пост о втором случае. А что делают в первом?
Меняют работу? :)
Без желания или готовности поддерживать сверху действительно обычно мало путного выходит. Но если в организации не два уровня, а больше, а сопротивление где-то посередине, то вопрос уже, можно ли внутри компании как-то доносить идеи на +1 +2 уровня вверх от своего руководства.
Ну и каждая инициатива – это мини-проект, который нужно уметь «продать». Отличный повод углубиться в маркетинг или почитать про пирамиду Минто.

Я пару раз пропихивал изменения в команду без ведома начальства, эмулируя привычный начальству процесс. Например, автоматический деплой внедрил. Оно только в заслугу себе поставило, что уменьшилось число сбоёв при деплое.

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

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

Направленных на это изменений, может и маловато, но есть те, которые направлены на то же увеличение прибыли или иные бизнес-метрики, но и улучшают положение сотрудников. например, в результате автоматизации с них снимается рутинная монотонная работа и осатётся только более-менее творческая. У тех, кого не сократят, конечно :)

В ИТ обычно все хорошо с соцпакетом, во многих компаниях даже опционы есть. Ну и несколько раз на своей памяти сталкивался с переездами в новые офисы с улучшенными условиями (даже если компании это для PR не нужно).
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

4 December 2003

Location

Сингапур

Employees

1,001–5,000 employees

Registered

9 August 2008

Habr blog