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

Сложность увеличения отдачи от быстро работающей производственной системы

В недавней статье «Сдвиг влево: создание ценности в Scrum» («Shift Left: Value Creation in Scrum»)  Стефан Волперс, обращает внимание на то, что формирование ценности в Scrum не такая уж простая штука.

Как замечает автор, какими бы ни были эффективны в Scrum-команде разработчики (developers), если на вход в производственную систему поступает ерунда, то эффективность всей системы не будет максимальной («Garbage in, garbage out»).

© Stefan Wolpers, 2022
Поток создания ценности. Смещаем фокус влево.

{здесь люди, привыкшие к конструкции уровней «стратегический – тактический – операционный», возможно, вздрогнули; но, на самом деле, в данном случае это несущественно}

Основная идея автора в том, что большая часть описания фреймворка Scrum посвящена описанию устройства производственной системы: от бэклога продукта (product backlog) и до завершения (delivery). А вопрос о том, как управлять входным потоком задач в производственную систему, полностью не раскрыт:

“Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely…” Scrum Guide, 2020

«Владелец продукта отвечает за максимизацию ценности продукта, полученного в результате работы Скрам-команды. То, как это делается, может сильно различаться…» Scrum Guide, 2020

Цитата из заметки Стефана Волперса:

“In other words: product discovery is an essential part of Scrum, although it is not mentioned in the Scrum Guide.”
«Другими словами, исследование продукта – существенная часть Scrum, хотя и не упомянутая в Руководстве Scrum»

В Scrum за решение описываемой задачи отвечает владелец продукта (product owner, PO). Но на практике это работает, мягко говоря, очень по-разному. В частности, Стефан приводит набор примеров того, почему конструкция с владельцем продукта в реальной жизни работает не очень.

  • PO – не PO, а скорее роль, принимающая от заявки от владельца бюджета/Scram-команды.
  • PO следует собственным инстинктам, и никто из Scrum-команды не ставит под сомнение корректность такого процесса принятия решений.
  • PO действует «на основе данных». Однако выбраны не те метрики, которые уводят в сторону.
  • PO вкладывается в исследование пользователей. Однако умудряется выбрать нерепрезентативную целевую группу среди заказчиков.

Автор призывает уделять более серьёзное внимание product discovery, т.е. усиливать акцент на работу с левой частью потока создания ценности, чтобы обеспечить максимизацию ценности product backlog и, соответственно, максимизацию ценности, обеспечиваемой Scrum-командой.

На самом деле, данная задача не специфична именно для Scrum. Целясь в построение максимально эффективной производственной системы (с использованием абсолютно любых подходов, фреймворков, методов и систем), невозможно игнорировать организацию входа в эту систему. Ровно поэтому, например, в своё время в дополнение к Essential Kanban Condensed появилась публикация Essential Upstream Kanban.
Product discovery – критический элемент, без которого даже команда с быстрым product delivery не добьётся максимального результата.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM