Портал №1 по управлению цифровыми
и информационными технологиями

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Консалтинг
по управлению ИТ

Agile, Scrum, разработка ПО

Что люди не понимают в управлении потоком создания стоимости

Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.

6 тенденций в ИТ, за которыми нужно следить

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

Воля и разум

Любое серьёзное преобразование в компании, от «внедрения» какого-либо нового ИТ-процесса до пресловутой цифровой трансформации, является организационным изменением: требуется изменить уже имеющиеся системы управления, чтобы они стали работать по-новому, или обрели новые свойства и способности. Приходится работать с формальной стороной (регламенты), культурной стороной (как у нас принято делать дела), технической составляющей, политической и так далее. Это — очень интересная работа, проводить организационные изменения в средних и крупных компаниях. К счастью, в области управления орг.изменениями накоплено достаточно знаний и опыта — есть замечательные публикации, методики, инструменты. Некоторые из них применяются уже десятки лет, другие являются относительно новыми. В частности, некоторые эксперты выделяют три явно...

6 неожиданных советов для улучшения встреч продуктовой команды

 Скучные. Непродуктивные. Увязающие в спорах. Я уже писал о нескольких вариантах неудачных встреч. Хотя каждая плохая встреча безобразна по-своему, конечный результат обычно один и тот же – никакого прогресса. Это особенно серьёзно сказывается на производительности. Продуктовым командам нужны единство и ясность. Когда все объединены вокруг одних и тех же целей и не боятся делиться мнениями, можно проводить очень эффективные и результативные встречи. Продуктовые команды находятся на острие высокотехнологичной организации, поэтому интеграция различных точек зрения необходима для обеспечения исключительного качества обслуживания клиентов. В идеале на собрании продуктовой команды присутствуют представители от специалистов по продукту, разработчиков, маркетинга, продаж и группы клиентского опыта...

Действительно ли управление ИТ-продуктами – это управление продуктами?

«Странный вопрос!» – подумал я. Но я стараюсь быть осторожным в своих суждениях. Некто спросил меня, считаю ли я, что управление ИТ-продуктами – это действительно управление продуктами? Это не было провокационным вопросом, но я подозреваю, что сейчас многие из тех, кто работает над созданием внутренних инструментов поддержки, отреагирует на него недоброжелательно. Суть этого вопроса скрывает опасение, что такая строчка в резюме может помешать потенциальной карьере менеджера продукта. Это явная неправда. Разумеется, развитие продукта, созданного для внутренних пользователей, является управлением продуктом. И всё же должна быть какая-то причина, которая заставляет сомневаться в статусе менеджера ИТ-продукта. Возможно, некоторые люди думают так, поскольку...

Управление ИТ-услугами в краткосрочной и долгосрочной перспективе

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

Почему продуктовый подход не работает?

Многие компании, чей успех основан на возможности быстро реагировать на изменяющиеся требования конкурного рынка и адаптироваться к сложному поведению потребителей, сталкиваются с необходимостью переводить внутреннюю ИТ-разработку в новую систему управления рабочими процессами. Есть запрос со стороны бизнеса на то, чтобы программное обеспечение, поддерживающее определённые бизнес-функции, производилось быстрее. И есть ожидания, что эту проблему способен решить продуктовый подход. Однако зачастую в компаниях не получается достичь нужных темпов ИТ-разработки, хотя они прикладывают серьёзные управленческие усилия к тому, чтобы провести изменения в работе. ИТ-ландшафт преобразуется в комплекс ИТ-продуктов, выделяются продуктовые команды, призванные управлять их развитием, но никакого значительно ускорения поставки ценности не происходит...

Страшно, аж жуть!

Около половины организаций, участвовавших в опросе Gartner, заявили, что они могут отслеживать финансовые выгоды от проектов по обеспечению клиентского опыта (CX), в то время как опрос Gartner лидеров рынка показывает, что более 80% организаций ожидают, что они будут конкурировать в основном на основе CX. Это означает, что доля компаний, где очень высоки требования бизнеса к скорости поставки новой функциональности, возможно, существенно выше, чем принято считать. Уже мало кого удивляет то, что банки, ритейл, отельный бизнес серьёзно вкладываются в то, что называется DevOps, Agile, ITIL® 4 High Velocity IT, цифровую трансформацию и пр. Но цифры из упомянутого отчёта, по-видимому, показывают, что...

Дорожная карта развития продукта vs диаграмма Ганта

Диаграммы Ганта теряют свою популярность. Особенно среди энтузиастов Agile, которые полагают, что даты и зависимости подавляют креативность и инновации. Это может быть правдой, если команда работает очень линейно и каждую фазу не может начинать пока не будет завершена предыдущая. Несмотря на то, что сегодня большинство команд таким образом не работают, я понимаю, откуда исходит скептицизм. Диаграммы Ганта считаются пережитком очень медленных и негибких стилей работы. У процесса развития продукта нет чёткой даты начала и окончания. И нужно действовать быстро, чтобы идти в ногу с потребностями клиентов. Поэтому логично отдавать предпочтение гибкости, а не структурированности. Создание успешного продукта требует рабочей среды,...

От обыденности к мотивации: преобразуйте свои ретроспективы

Двенадцатый из основных принципов гибкой разработки (Agile) гласит: “Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом корректирует свое поведение”. Мы называем это время размышлений ретроспективой. Не следует путать с обзором (сессией для обсуждения поставляемых продуктов)! Цель ретроспективы состоит исключительно в том, чтобы определить, как мы работали вместе как команда. Какие процессы работали, какие нет? И какие обязательства мы можем взять на себя, чтобы улучшить наше сотрудничество в будущем? Избегайте обыденных ретроспектив Ретроспективы — жизненно важный винтик в ритме каждой agile-команды. Они требуют критического взгляда, направленного внутрь команды, чтобы изучить нас самих и наших...

Шаг «Отложено» в потоке создания ценности

Рассмотрим простейший поток создания ценности: На ваш взгляд, что в этом потоке не так? Подумайте, и когда будете готовы — листайте ниже.                     Ответ бросается в глаза — один из шагов отличается от других. Опциональный шаг «Отложено» подразумевает, что задача, двигающаяся по потоку, может встать на паузу после этапа «В работе», но до этапа «Проверка». Причины этой паузы из схемы не ясны, но шаг «Отложено» даже визуально, из-за подписи «(опционально)», уже выглядит инородным. Однако проблема не в инородности. Проблема в том, что на схеме изображён не поток создания ценности, а что-то иное: бизнес-процесс,...

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM