[Agile, Управление продуктом] Цель продукта – это промежуточная стратегическая цель (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 4 месяца
Сообщений: 27286

news_bot ^® написал(а)
05-Фев-2021 15:31

Цитировать

Привет, Хабровчане. Для будущих студентов курса «Agile Project Manager» и всех интересующихся подготовили перевод интересной статьи.
Также приглашаем всех желающих на открытый вебинар по теме «Техники оценки Agile проектов для различных контекстов». На занятии разберём виды оценок проектов и задач в зависимости от срочности, размера и сложности объёма работ, коснёмся классического инструмента critical path. Участники научатся выбирать и применять «размеры футболок», человеко-часы, story points, PERT.

В руководстве по Evidence-Based Management говорится не только о Стратегической Цели, но и о промежуточной стратегической цели, которая нужна для пересмотра и адаптации вашего прогресса относительно намеченного видения вашего продукта.Достижение стратегических целей требует экспериментов, проверки и адаптации.Ключом к реализации agile-мышления в бизнесе является идея экспериментов, и мы не знаем, куда хотим прийти, в основном потому, что наше будущее находится за туманом войны. Степень неопределенности будущего всегда высока, и ничто так хорошо не иллюстрирует это высказывание, как пандемия COVID-19. Каждому бизнесу приходилось пересматривать свои стратегические цели чаще, чем обычно, хотя даже «как обычно» – это уже очень много.

Туман войны (нем. Nebel des Krieges) – это неопределенность в осознании ситуации, испытываемая участниками военных действий. Этот термин стремится охватить неопределенность в собственных возможностях, возможностях противника и его намерениях во время сражения, операции или кампании. Военные силы пытаются рассеять туман войны с помощью военной разведки и систем отслеживания.— Википедия

С тех пор, как я представил Evolution not Transformation: This is the Inevitability of change, я все больше и больше осознаю, что именно бизнес и исполнительное руководство тормозят отказ от традиционных практик, которые были разработаны для управления работниками фабрик, в пользу тех, которые необходимы для управления когнитивной работой. Даже беглый взгляд на многие современные компании, способные адаптироваться к изменениям в бизнесе, может сказать об их большем успехе, чем тех, которые управляются традиционным способом. Вспомните о Spotify, Zappos, Microsoft, Apple, Google.Мы должны использовать ключевые практики продуктовых исследований, адаптированные к современной реальности, а именно:

Итоговый результат важнее выходного объема. Чтобы пересмотреть существующую практику управления, нужно задаться вопросом «Улучшает ли практика наши результаты или она увеличивает выходные показатели?» Не попадайтесь в ловушку, пытаясь выдать много некачественного и нецелевого выхлопа. Вам хочется, чтобы ваши умные и творческие сотрудники тратили время на ценные результаты, которые меняли бы поведение ваших клиентов на благо организации. Вот несколько примеров традиционных практик, которые нацелены на максимизацию выходного объема, а не качественного результата: задачи и бонусы, департаменты (продажи, маркетинг, HR, инженеры, тестирование), иерархическая структура работ, зависимость зарплаты от должности. Вам, скорее всего, придется пересмотреть влияние этих методов на желаемые результаты, если, конечно, вы не управляете фабрикой во время промышленной революции. У Standish Group из Бостона есть годовой отчет, который пошагово с помощью анализа данных показывает как традиционные методы управления проектами (Prince2/PMI и другие) оказывают негативное влияние на способность вашей организации доставлять ценность при когнитивной работе, такой как разработка программного обеспечения, продажи или маркетинг.
Инвестиционные возможности. Нам все еще нужен бюджет, но вместо традиционного проектного подхода, который попадает в ловушку преобладания объемов выпуска над качественным результатом, нужна новая модель, отражающая результаты и возможности для исследования, которые сделают ваш бизнес успешнее. Новая модель бюджета может вращаться вокруг команд доставки, которые и являются нашими инвестициями. Как думаете, сколько команд вы готовы инвестировать в исследование какой-либо возможности? В течение года вы можете корректировать курс того, на что команды тратят свое время, в зависимости от того, какие результаты в процессе исследования вы получаете. Прекратите вкладывать время команд доставки в те области, от которых вы не получаете адекватной отдачи от инвестиций. Можно каждый год оценивать, сколько команд в каждом из наших потоков создания ценности мы готовы финансировать.
Эксперименты. Неудач не существует, есть только опыт, и наша цель должна состоять в том, чтобы минимизировать затраты на этот опыт и максимизировать успех. Нужно проводить короткие итерации экспериментов над каждой инвестиционной возможностью. Хорошим примером здесь являются команды Azure DevOps в Microsoft. У Microsoft есть около 42 команд, которые компания может инвестировать в Azure Pipelines, Azure Boards, Azure Repos и другие вертикали продуктов. У каждой вертикали есть своя промежуточная стратегическая цель (цель продукта) и бюджет «на количество сотрудников» (команд), который они могут использовать для инвестиций в продвижение к этой промежуточной стратегической цели, по одному эксперименту за итерацию. Если руководство считает, что компания недостаточно продвинулась в определенной вертикали, оно может перетасовывать команды для решения этой проблемы по результатам анализа рынка.
Опираться на гипотезы. Чтобы интерпретировать результат эксперимента, нужна какая-то гипотеза. Гипотеза — это что-то вроде предположения, но с одним важным отличием: есть четкая метрика, которая покажет нам, верно ли наше предположение. Подтверждение предположений с помощью данных и минимальных затрат – это ответственность Product-менеджера (или Product Owner-а). Крайне важно провести множество небольших экспериментов, в которых команды доставки создают небольшие ценные результаты, которые можно проверить на реальных пользователях.

Вам нужно пересмотреть использование терминов объема и неудачи в свете этой новой реальности и превратиться в бережливую организацию, чья работа основана на данных, экспериментах и исследованиях, которые позволяют адаптироваться к переменам в бизнесе по мере их возникновения!

Узнать подробнее о курсе «Agile Project Manager».
Записаться на открытый вебинар по теме «Техники оценки Agile проектов для различных контекстов».

===========
Источник:
habr.com
===========
===========
Автор оригинала: Martin Hinshelwood
===========Похожие новости:

Теги для поиска: #_agile, #_upravlenie_produktom (Управление продуктом), #_otsenka_proektov (оценка проектов), #_agile, #_upravlenie_produktom (управление продуктом), #_blog_kompanii_otus (
Блог компании OTUS
), #_agile, #_upravlenie_produktom (
Управление продуктом
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 04-Июл 13:18
Часовой пояс: UTC + 5