Информация

Дата основания
Местоположение
Сингапур
Сайт
www.acronis.com
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 19

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

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

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

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

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

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

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

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

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

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

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

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

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

В ИТ обычно все хорошо с соцпакетом, во многих компаниях даже опционы есть. Ну и несколько раз на своей памяти сталкивался с переездами в новые офисы с улучшенными условиями (даже если компании это для PR не нужно).
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.