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

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

Управление продуктом

Продуктовый подход для всех?

Марти Каган и Крис Джонс, авторы книги «Transformed» в недавней заметке рассуждают о том, чем отличаются традиционные ИТ-подразделения от продуктовых, и о том, применима ли продуктовая модель (продуктовый подход) к традиционным компаниям, которые всё чаще проявляют интерес к этой модели. Любопытно, что при довольно большом объёме статьи, её логическая структура сводится к простому и понятному набору тезисов. Их можно использовать как базу для вопросов, на которые необходимо ответить при принятии решении о начале трансформации. Ниже краткий пересказ ключевых элементов. Самое главное в продуктовом подходе – ориентация на конечный бизнес-результат (в противовес, например ориентации на соблюдение жёстких сроков реализации инициатив, проектов,…

РИТМ приглашает авторов!

Наверняка вы уже слышали про РИТМ. На недавней конференции itSMF России про него было рассказано много, и рассказано интересно. Пока до конца неизвестно что означает в РИТМе буква “Р” – то ли “Российская”, то ли “Рациональная”. Та же история с буквой “М” – модель? методология? менеджмент? Как я понял, это сейчас не важно, решим позже. А важно вот что: не только была анонсирована идея РИТМа, но уже полным ходом идут работы по разработке российского свода знаний по ИТ-менеджменту. Определена верхнеуровневая модель, сформулированы принципы создания этого свода знаний и принципы, которые в собственно свод знаний войдут. Идёт активная работа по проработке…

Девять признаков того, что ваш продукт, возможно, не продукт

В недавно опубликованном заметке Павел Хурbн (Paweł Huryn) отмечает 9 «красных флагов», свидетельствующих о том, что наш «продукт» — это, на самом деле, проекты. Огромный документ, описывающий требования к продукту (Product Requirements Document, PRD): вы начинаете инициативу, документируя всё. «Пилим фичи» (feature factory): просто реализуйте то, что указано в требованиях. Не спрашивайте, почему. Водопад: все требования собираются на «начальном этапе». Диаграмма Ганта: дорожная карта, показывающая какая функциональность в какие моменты времени будет реализована. Не производится «исследования» продукта (discovery): нет необходимости проверять идеи перед их реализацией. Нет дизайнера: в команде нет дизайнера продукта. Нет аналитики: вы понятия не имеете, как люди…

Продуктовый подход. Необходим ли поток? И при чём здесь трансформация?

Довольно часто в общении с представителями разных организаций на тему продуктового подхода приходиться уточнять само понятие «продуктовый подход». Ведь это словосочетание не патентованное. Не существует единственной «правильной» книжки, где даётся единственно верное определение этого понятия. Поэтому оно бывает нагружено разными смыслами. Некоторые из них неразрывно связаны с понятием «трансформация». Та самая, которая цифровая (и которая не сводится к повсеместному внедрению цифровых технологий – более того, широкое распространение использование цифровых технологий не является сутью цифровой трансформации [если есть задача разобраться в этом, добро пожаловать на курс «Трансформация ИТ в традиционных компаниях»]).Попробуем разобраться и выстроить некоторую структуру. Можно продуктовый подход без потока?…

5 правил лучших продуктовых команд

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

Нужно ли поскорее устранять все выявленные дефекты?

Работа над дефектами – известная область разработки ПО, вызывающая вечные и непримиримые споры. Заметьте, что я использовал именно слова “работа над”, а не “управление” – из того, что я вижу вокруг, управления дефектами почти ни в одной команде разработки нет.

Как защитить зрелую команду от деградации

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

Еженедельные ритуалы, которые стоит освоить менеджеру ИТ-проекта

Сегодня я хочу рассказать о буднях менеджера проекта. Когда я управляю проектом, то придерживаюсь определенного списка деятельности на каждую неделю. Эта комплексная деятельность требует встреч или обсуждений, но наличие четкого представления о том, чем необходимо заниматься каждую неделю помогает сделать более ясным, на чем следует сфокусироваться.

Три вещи, которые нас мотивируют

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

Весення уборка в бэклоге продукта: порядок за четыре шага!

Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 

27 антипаттернов бэклога продукта

Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM