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

Поток создания ценности — поток создания чего?

Прочитав замечательную статью моего коллеги «Все говорят: «Поток!». А ты построй поток» и возникшую после неё дискуссию, я подумала, что довольно часто сталкиваюсь с вопросом, а что же такое ценность? Много говорится о потоке создания ценности, о том, какие организационные шаги необходимо предпринять, чтобы сделать его сбалансированным и управляемым, но зачастую команды разработки плохо представляют, что лежит за самим этим понятием.

Кажется, что вся работа продуктовой команды направлена на создание ценности. Люди живут в привычном рабочем процессе и считают, что все их действия строго необходимы для развития продукта. Очень сложно заходит мысль, что часть этих рабочих процессов с точки зрения производственной системы является потерями, ценность не создающими.

Предназначение продуктовой команды заключается в создании ценности

Ценность – это линеечка, которую необходимо прикладывать ко всей деятельности в процессе создания и развития программного продукта для того, чтобы понять, какие рабочие процессы относятся непосредственно к потоку создания ценности, а какие являются поддерживающими. Но как определить саму эту линеечку?

Часто возникает ситуация, когда выверенное и прекрасно исполненное техническое решение при согласовании с бизнес-заказчиком отправляется в мусор. «Вы сделали не то! Это некачественная работа» — говорит бизнес. И разработчики остаются в недоумении, почему так?

Такая ситуация возникает, если была потеряна фокусировка на ценности.

Я люблю приводить пример с лестницей, которая ведёт в никуда, как на картинке. Это может быть прекрасная, высокотехнологичная лестница, с оптимальной шириной и высотой ступенек, с современным дизайном и продуманным выбором материалов для её создания. Но толку от неё не будет никакого, потому что она упирается в стену. Пользоваться ей невозможно, но строители недоумевают: «Мы выполнили все ваши требования! Вы хотели лестницу, и вы её получили!».

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

Что это означает на практике?

Представьте, что перед продуктовой командой поставлена задача реализовать приложение, скажем, для продавцов в закусочной. Тех самых мальчиков и девочек в фирменных бейсболках, которые кричат «свободная касса!».

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

Где он будет использовать это приложение? Он работает в очень ограниченном пространстве, где помимо планшета, на котором выводится это приложение, расположена касса, терминал оплаты, место для выдачи заказов, производственное оборудование и так далее.

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

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

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

Поэтому необходимо максимально точно и чётко донести ценность и сфокусировать на ней команду, и это важная задача для бизнеса.

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

Бизнес платит за ценность, а не за технические решения

В потоке создания ценности создаётся не функциональность, а именно ценность. Это понимание позволяет избежать ошибок, ненужной работы, которая будет забракована заказчиком или потребителем.

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

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

Такая постановка характерна для MVP, когда необходимо как можно скорее получить минимальную функциональность для проверки бизнес-гипотез.

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

Это и есть расширение ожиданий бизнеса, ведь очевидное решение не всегда является лучшим.

Строим от ценности

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

Что характерно, процессы, напрямую не создающие ценность, редко можно описать в виде потока. Это может быть регулярная деятельность, однако в основном она не требует последовательной обработки, этакой «эстафетной палочки» между различными участниками команды. Именно потому, что ценность создаётся совокупными усилиями всей продуктовой команды, а поддерживающие процессы более специализированы. Попытка описать их как поток – последовательное движение элементов работы по этапам обработки – терпит неудачу из-за отсутствия этого самого движения.

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

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

Разделение потока создания ценности и прочей полезной деятельности продуктовой команды позволяет чётче сфокусироваться на развитии продукта. Как говориться, делайте ту работу, которую нужно, а ту, которую не нужно – не делайте!

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT