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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цель не понял, задачу выполнил!

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

Менеджер продукта vs Владелец продукта

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

Блеск и нищета автономных команд

Неоднократно упоминавшийся на нашем портале Чарльз Бетц (Charles Betz, среди прочего автор «Digital Practitioner Body of Knowledge (DPBoK)», являющейся базой для соответствующей сертификации от The Open Group, консорциума, разработавшего TOGAF, IT4IT, к которым, кстати, Чарльз тоже приложил руку) опубликовал на прошедшей неделе любопытный фрагмент своей беседы с Agile-классиком Доном Райнерстеном (Don Reinertsen). Дон – автор книг «Разработка продуктов за половину времени» («Developing Products in Half the Time»), «Управление дизайн-фабрикой» («Managing the Design Factory»), «Принципы потока продуктовой разработки» («The Principles of Product Development Flow: Second Generation Lean Product Development»). В интервью эксперты рассуждают о недостатке автономных (читай «продуктовых») команд – сложности…

Как ускорить поток создания ценности?

Работая над созданием ценности, команда ИТ-разработки живёт в привычных для неё организационных процессах. Непредвзято взглянуть на свой поток и разобраться, где в нём существуют проблемные зоны, требующие улучшения, бывает очень не просто. Задачки ставятся и двигаются от этапа к этапу по сложившемуся маршруту. И кажется, что все логично, что ускорить этот процесс нельзя без увеличения количества исполнителей. Но так ли это на самом деле? Внутри потока создания ценности могут существовать процессы, существенно замедляющие его течение, делающие его непредсказуемым и неравномерным. Давайте рассмотрим причины, которые препятствуют движению элементов работы в потоке. Недостаточно информации для решения задачи Для того чтобы элементы работы…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;