Прочитав замечательную статью моего коллеги «Все говорят: «Поток!». А ты построй поток» и возникшую после неё дискуссию, я подумала, что довольно часто сталкиваюсь с вопросом, а что же такое ценность? Много говорится о потоке создания ценности, о том, какие организационные шаги необходимо предпринять, чтобы сделать его сбалансированным и управляемым, но зачастую команды разработки плохо представляют, что лежит за самим этим понятием.
Кажется, что вся работа продуктовой команды направлена на создание ценности. Люди живут в привычном рабочем процессе и считают, что все их действия строго необходимы для развития продукта. Очень сложно заходит мысль, что часть этих рабочих процессов с точки зрения производственной системы является потерями, ценность не создающими.
Предназначение продуктовой команды заключается в создании ценности
Ценность – это линеечка, которую необходимо прикладывать ко всей деятельности в процессе создания и развития программного продукта для того, чтобы понять, какие рабочие процессы относятся непосредственно к потоку создания ценности, а какие являются поддерживающими. Но как определить саму эту линеечку?
Часто возникает ситуация, когда выверенное и прекрасно исполненное техническое решение при согласовании с бизнес-заказчиком отправляется в мусор. «Вы сделали не то! Это некачественная работа» – говорит бизнес. И разработчики остаются в недоумении, почему так?
Такая ситуация возникает, если была потеряна фокусировка на ценности.
Я люблю приводить пример с лестницей, которая ведёт в никуда, как на картинке. Это может быть прекрасная, высокотехнологичная лестница, с оптимальной шириной и высотой ступенек, с современным дизайном и продуманным выбором материалов для её создания. Но толку от неё не будет никакого, потому что она упирается в стену. Пользоваться ей невозможно, но строители недоумевают: «Мы выполнили все ваши требования! Вы хотели лестницу, и вы её получили!».
Любой запрос на изменение функциональности программного продукта может быть реализован множеством различных способов. Пространство решений слишком неопределённое и обширное, несмотря на то, насколько хорошо была прописана изначальная постановка требований. Выбор конкретного решения остаётся на стороне команды разработки и зачастую проистекает из технических и архитектурных аспектов построения информационной системы. В этом случае есть большой риск, что ожидания бизнеса и видение разработчиков разойдутся в важных параметрах, определяющих качество реализации.
Что это означает на практике?
Представьте, что перед продуктовой командой поставлена задача реализовать приложение, скажем, для продавцов в закусочной. Тех самых мальчиков и девочек в фирменных бейсболках, которые кричат «свободная касса!».
Кто конечный потребитель этого приложения? Скорее всего это молодой человек с невысоким уровнем компьютерной грамотности, который получает бонусы за быстрое обслуживание заказов.
Где он будет использовать это приложение? Он работает в очень ограниченном пространстве, где помимо планшета, на котором выводится это приложение, расположена касса, терминал оплаты, место для выдачи заказов, производственное оборудование и так далее.
Каким образом он будет пользоваться приложением? Постоянно и очень быстро! Ему некогда разбираться в сложном интерфейсе, поскольку это одна из множества операций, которые он должен выполнять с большой скоростью. Где-то между тем, как пробить и выдать чек, прокричать на кухню, чего не хватает для сборки заказа, произвести расчёт с покупателем, налить молочный коктейль, всё упаковать и сложить на поднос… И не забывать улыбаться!
Для бизнес-заказчика, отлично представляющего все бизнес-процессы, главной ценностью является то, чтобы разрабатываемое приложение был простым, страхующим от ошибок и с хорошо визуализированным интерфейсом. Соответственно и выбор вариантов реализации должен исходить из этой ценности.
Для команды разработки не всегда очевидно, что является самым важным, в чем основная польза тех функциональных изменений, которые создаются в процессе развития программного продукта. Зачастую разработчики плохо себе представляют бизнес-процессы в реальном мире, не погружены в предметную область, не знают о сложностях и болях пользователей. Им не ясно какое решение из всего пространства возможностей будет лучшим, что является граничным условием для выбора?
Поэтому необходимо максимально точно и чётко донести ценность и сфокусировать на ней команду, и это важная задача для бизнеса.
Требования не должны браться в работу, пока не описана ценность, которую они несут. Иначе легко угодить в ситуацию, когда поставляемая функциональность будет в итоге не востребована. И вся сложная работа по поиску и созданию технического решения будет проделана зря, а потраченного времени уже не вернуть.
Бизнес платит за ценность, а не за технические решения
В потоке создания ценности создаётся не функциональность, а именно ценность. Это понимание позволяет избежать ошибок, ненужной работы, которая будет забракована заказчиком или потребителем.
Что характерно, когда бизнес-заказчики начинают формулировать свои требования к продукту на основе ценности, очень часто их ожидания могут быть расширены со стороны команды разработки за счет их знаний о функциональных возможностях своего продукта. Как только разработчикам становится понятно, в чем польза и важность тех изменений, которые необходимы бизнесу, они чётче начинают видеть лучшие решения для этой задачи.
Вернёмся к нашему примеру с лестницей. Исходя из того, что является бизнес-ценностью, и должен строиться запрос на создание функциональности. Например так: основная ценность состоит в том, чтобы как можно быстрее получить лестницу, ведущую на второй этаж. Это будет означать, что самым важным является скорость разработки готового результата, а его польза – это создание новой возможности перемещения между этажами. Тогда выбор решения будет идти в пользу быстрой реализации, без изысков и лишних деталей.
Такая постановка характерна для MVP, когда необходимо как можно скорее получить минимальную функциональность для проверки бизнес-гипотез.
Или же запрос может быть сформулирован таким образом: требуется комфортное средство достижения второго этажа. Заметьте, главная польза и важность тут сосредоточены вокруг некоего целевого состояния, а выбор вариантов реализации не ограничен. Это означает, что в поиске решений разработчики могут выйти на другие варианты, помимо лестницы. Например, предложить лифт, если архитектура позволяет его достаточно просто реализовать.
Это и есть расширение ожиданий бизнеса, ведь очевидное решение не всегда является лучшим.
Строим от ценности
Когда команда строит поток создания ценности, важно разделять, как писал мой коллега, деятельность ценность создающую, и ту, которая направлена на обеспечение полезных и нужных процессов, напрямую ценность не приносящих. Существование продуктовой команды обосновано именно тем, сколько ценности она создаёт. Перекос в сторону поддерживающих процессов будет означать, что команда не соответствует своему предназначению.
Что характерно, процессы, напрямую не создающие ценность, редко можно описать в виде потока. Это может быть регулярная деятельность, однако в основном она не требует последовательной обработки, этакой «эстафетной палочки» между различными участниками команды. Именно потому, что ценность создаётся совокупными усилиями всей продуктовой команды, а поддерживающие процессы более специализированы. Попытка описать их как поток – последовательное движение элементов работы по этапам обработки – терпит неудачу из-за отсутствия этого самого движения.
Тем не менее, очень важно проявлять и визуализировать внепотоковую деятельность. Это необходимо для того, чтобы сбалансировать распределение ресурсов продуктовой команды между потоком создания ценности и другими рабочими процессами. Основная ёмкость ресурсов должна быть выделена под поток.
Отстройка потока создания ценности и управление им требует чёткого полноценного описания и визуализации всех этапов, узких мест, очередей, блокеров и рисков. А то, насколько подробным должно быть описание поддерживающих рабочих процессов, зависит от их сложности и объёма.
Разделение потока создания ценности и прочей полезной деятельности продуктовой команды позволяет чётче сфокусироваться на развитии продукта. Как говориться, делайте ту работу, которую нужно, а ту, которую не нужно – не делайте!