В парадигме проектного подхода – на проектную и операционную деятельность.
В парадигме продуктового – я не уверен, что всегда можно отделить операционную. Хотя тут можно подискутировать
Это тогда уже не проектный, а продуктовый подход. Проект всегда ограничен по времени (внедрение CRM, разработка софта по ТЗ, строительство дома, запуск конвейерной линии), его после реализации передают в эксплуатацию/оперирование.
Продукт же может развиваться бесконечно (хабр, Acronis Cyber Cloud, Яндекс.Такси)
В ИТ обычно все хорошо с соцпакетом, во многих компаниях даже опционы есть. Ну и несколько раз на своей памяти сталкивался с переездами в новые офисы с улучшенными условиями (даже если компании это для PR не нужно).
Меняют работу? :)
Без желания или готовности поддерживать сверху действительно обычно мало путного выходит. Но если в организации не два уровня, а больше, а сопротивление где-то посередине, то вопрос уже, можно ли внутри компании как-то доносить идеи на +1 +2 уровня вверх от своего руководства.
Ну и каждая инициатива – это мини-проект, который нужно уметь «продать». Отличный повод углубиться в маркетинг или почитать про пирамиду Минто.
Да, не всегда очевидно, но любую деятельность внутри организации можно отнести либо к проектной (что-то уникальное, с конечным временем и ресурсами) и операционной (привычные повторяющиеся повседневные задачи).
То, о чем говорите вы – скорее относится к оптимизации операционной деятельности. И здесь действуют все правила внедрения изменений – есть «статус кво», есть сопротивление, есть вовлеченные люди. Будет продолжение этой темы во второй статье, где мы как попробую описать, какие подходы могут помочь это сопротивление преодолеть.
Да, верно. Но тут и тема требований тоже по касательной затронута.
Управление изменениями требований в классических проектах – это отдельный процесс, который позволяет проекту развиваться предсказуемо. Удовлетворение заказчика даже на поздних этапах и приветствие изменений, конечно, часто является базовой ценностью, но это ближе уже к гибким подходам и Agile Manifesto. Тут еще важно помнить про управление ожиданиями.
Но большая часть статьи конечно про организационные, процессные и иные изменения в компании.
В парадигме продуктового – я не уверен, что всегда можно отделить операционную. Хотя тут можно подискутировать
Продукт же может развиваться бесконечно (хабр, Acronis Cyber Cloud, Яндекс.Такси)
Без желания или готовности поддерживать сверху действительно обычно мало путного выходит. Но если в организации не два уровня, а больше, а сопротивление где-то посередине, то вопрос уже, можно ли внутри компании как-то доносить идеи на +1 +2 уровня вверх от своего руководства.
Ну и каждая инициатива – это мини-проект, который нужно уметь «продать». Отличный повод углубиться в маркетинг или почитать про пирамиду Минто.
То, о чем говорите вы – скорее относится к оптимизации операционной деятельности. И здесь действуют все правила внедрения изменений – есть «статус кво», есть сопротивление, есть вовлеченные люди. Будет продолжение этой темы во второй статье, где мы как попробую описать, какие подходы могут помочь это сопротивление преодолеть.
Управление изменениями требований в классических проектах – это отдельный процесс, который позволяет проекту развиваться предсказуемо. Удовлетворение заказчика даже на поздних этапах и приветствие изменений, конечно, часто является базовой ценностью, но это ближе уже к гибким подходам и Agile Manifesto. Тут еще важно помнить про управление ожиданиями.
Но большая часть статьи конечно про организационные, процессные и иные изменения в компании.