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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сделайте свою команду несчастной с помощью этих популярных антипаттернов управления проектами

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

Дорожная карта и бэклог продукта – зачем нам два инструмента планирования?

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;