The Principles of Product Development Flow, пост 2 — экономический фреймворк

Оригинал поста: https://artemushanov.ru/?go=all/reynertsen-post-2/

Это второй пост про книгу «The Principles of Product Development Flow» Дональда Рейнертсена.

Книга о том, как правильно принимать управленческие решения при разработке продукта.

Вторая часть книги посвящена экономическому взгляду на разработку продуктов:

“Our primary goal in product development is to make good economic choices.”

Вспомним основы.

Мы разрабатываем продукт, чтобы на нем можно было заработать. Выбор любой альтернативы на развилках — какое архитектурное решение принять, в каком порядке делать фичи, и т. д., — влияет на экономику продукта (для простоты будем рассматривать только коммерческие продукты).

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

Мы рассматриваем именно разработку продукта — не производство, не развитие. В книге не уточняется, что именно это за продукт, поэтому считаем, что подход универсальный и может быть одинаково полезен в разработке нового стула в лаборатории Икеи, новой модели автомобиля где-то в глубинах автоконцерна, нового вида шоколадных батончиков, или новой ERP/CRM/любыетрибуквы-системы.

Экономический подход Рейнертсена в общем виде звучит так:

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

В первом посте я задавался вопросом: почему именно прибыль, а не доход?
Ответ такой: доход не учитывает понесенные на всех этапах расходы, а значит — не отражает в полной мере экономическую модель продукта. Если строить анализ на основе дохода, а не прибыли, то не получится учесть расходы на разработку, невозможно посчитать точку безубыточности, учесть расходы на продажи, и т. п. — картина будет неполной.

Точность экономического фреймворка должна превосходить интуитивные оценки — этого достаточно.

Итак, часть вторая — 2. The Economic View.

Глава “The Nature of Our Economics”
Рейнертсен строит книгу следующим образом: в каждой главе он предлагает т. н. «принципы» и бегло иллюстрирует их. Так и пойдем.

E1: The Principle of Quantified Overall Economics

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

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

Пример: следует ли нам пустить разработанный продукт в производство без устранения всех обнаруженных дефектов? Разработчики говорят — айда погнали, представители завода говорят — вы гоните, сперва все косяки исправьте.

Начинаем применять экономический фреймворк.

1) Если мы исправим косяки продукта на заводе, это будет стоить в десять раз дороже, чем в лаборатории — 20000 евро против 2000.
2) На заводе, в условиях производства, мы обнаружим косяки за одну неделю, а в лаборатории — за пять недель.

Вопрос к экономическому фреймворку звучит так: стоит ли «покупать» четырехнедельное сокращение цикла за 18000 евро?
А ответ звучит так: если life-cycle profit impact (LCPI) от этого решения будет положительный — то стоит.

E2: The Principle of Interconnected Variables

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

Фреймворк Рейнертсена содержит следующие факторы:

Product Сost — стоимость продукта в производстве (сырье, работы, логистика)
Product Value — выручка, заработанная в течение жизни продукта; внутри сидят цена, объем продаж (зависящий от рынка) и прочее
Development Expense — затраты на разработку продукта
Cycle time — время на разработку продукта, от нулевой стадии до финальной
Risk — Оценка рисков для стадии разработки продукта

Эти пять факторов связаны друг с другом — изменение одного приведет, во-первых, к изменению остальных в какой-то пропорции и с каким-то вектором, во-вторых, к изменению LCPI.

Учитывая эти изменения, можно принимать решения более взвешенно. Чего нам будет стоить уменьшение веса изделия на 1 кг? Что нам даст увеличение эффективности на 1%? Во что нам обойдется увеличение наработки на отказ еще на 1000 часов? Экономический фреймворк с правильно подобранными показателями должен давать ответы на эти вопросы.

E3: The Principle of Quantified Cost of Delay

В любой непонятной ситуации считай стоимость задержки.

Cost of Delay (CoD) — одна из «чувствительностей» (sensitivities) в экономическом фреймворке и важнейший концепт книги. Стоимость задержки определяет, как увеличение времени цикла (Cycle Time) повлияет на прибыль жизненного цикла (Product Value).

Как CoD связана с основными факторами:

Product Сost может вырасти из-за задержки, т. к. меняются цены на производственные ресурсы.
Product Value снижается, т. к. продукт меньше времени проведет на рынке, может пропустить благоприятное окно для выхода на рынок и т. п.
Development Expenses — время разработки увеличивается, увеличиваются связанные косты и появляются дополнительные риски
Cycle time — напрямую влияет на CoD, т. к. стоимость задержки считается именно по дельте увеличения/уменьшения времени цикла
Risk — риски могут как увеличиться, так и уменьшиться.

В идеале, стоимость задержки нужно считать и понимать в каждый конкретный момент времени на любой стадии разработки.

Экономическая модель конкретного продукта может быть довольно сложной, в ней больше факторов, но логика расчета CoD примерно такая:

Вычисляем планируемую недельную выручку от продаж продукта: умножаем ожидаемый объем продаж в неделю на цену продукта. Вместо недели можно взять любой удобный промежуток времени.
Оцениваем время, требуемое для завершения разработки и вывода продукта на рынок.
Вычисляем стоимость задержки — умножаем недельную выручку на количество недель задержки.

Теперь мы можем оценивать разные компромиссы, сравнивая стоимость задержки и потенциальную выгоду от этой задержки.

Методы оценки через диапазоны — из книги «Как измерить все, что угодно»

Поскольку нам не нужна супер-точность, считаем на тех данных, которые есть, и используем метод диапазонов; прогноза от отделов маркетинга и продаж вполне хватит для расчетов.

Например, мы рассматриваем возможность потратить дополнительно две недели на тестирование продукта перед выводом на рынок. Считаем стоимость задержки и потенциальную выгоду от такого тестирования. Какая может быть выгода, если сравнивать со стоимостью задержки? Будет меньше возвратов по гарантии и можно сократить гарантийный бюджет; будет меньше обращений в сервисные центры, у них будет меньше загрузка, меньше расходов на персонал; клиентам можно обещать качество «выше, чем у конкурентов», продажи вырастут на 10% — и так далее. Важно, что вопрос из разряда примитивных бинарных («хорошее качество лучше, чем плохое — значит, надо тестировать») переходит в разряд экономических и приходится напрячься и посчитать, а что именно нам такое тестирование даст.

Если заглянуть чуть дальше в книгу, мы увидим, что стоимость задержки помогает при оценке очередей — второго важнейшего понятия книги. В отличие от условных двух недель тестирования, очереди не несут никакой пользы, только вред, и стоимость задержки помогает вычислить количество этого вреда.

upd. Статья из блога Kaiten.ru про стоимость задержки — https://kaiten.ru/blog/stoimost-zadierzhiek-v-kanban/

E4: The Principle of Economic Value-Added

Четвертый принцип утверждает, что добавленная стоимость любой деятельности должна выражаться в изменении цены, которую за продукт готов заплатить рациональный покупатель. Если внесение изменения в продукт не обеспечит повышение цены или объема продаж продукта — в общем, роста фактора Product Value, — то это действие является потерей (waste).

Рейнертсен снова противопоставляет продуктовый и производственный подходы: в бережливом производстве проверка и тестирование продукции считаются неизбежными потерями (necessary waste), не добавляющими ценности продукту; с точки зрения экономического фреймворка это справедливо только в случае, когда тестирование не улучшает экономику продукта.

Пример: фармацевтическая компания проводит клинические испытания всех новых продуктов. Прибавит ли что-то к ценности продукта испытание первой фазы, имеющее пятидесятипроцентную вероятность прохождения? Или это просто потери?
Ответ: cнизив риск с помощью испытаний, компания существенно расширяет для себя географию продаж и маркетинговые возможности — т. е. получает возможность продавать больше и чаще, чем в случае когда тестирование не было произведено. Так что — да, прибавит.

Раз мы выразили добавленную стоимость через понятия экономического фреймворка, то не помешает сделать то же самое и с потерями.
Потери (waste) — это безуспешные методы оптимизации экономики продукта. То есть, какие-то активности были предприняты (= ресурсы потрачены), а экономика продукта в положительную сторону не изменилась. Их влияние тоже нужно уметь вычислять через факторы экономического фреймворка.

Пример: у нас есть отдел компьютерного проектирования; что лучше — использовать его с загрузкой в 80% и двухнедельными очередями, или с 90-процентной загрузкой и четырёхнедельными очередями? Нужно посчитать экономические потери от недозагрузки и экономические потери от очередей, сравнить их между собой и выбрать нужный вариант.

E5: The Inactivity Principle

Хороший и правильный принцип — «Watch the work product, not the worker».

Цитата:

In product development, our greatest waste is not unproductive engineers, but work products sitting idle in process queues

Давайте сначала разберемся, что такое work product/work item.

Под «рабочим продуктом» мы будем понимать результат выполнения работы, выраженный физически — настолько, насколько возможно. Если у нас задача «составить родмеп на следующий год», то рабочим продуктом будет не абстрактное «составленный родмеп на 2024», а табличка в экселе с названием «2024 Roadmap for ’product name’», заполненная по определенному шаблону.
Если у нас задача «выточить заготовки для ножек» на мебельной фабрике, то рабочий продукт — выточенные ножки.
Если у нас задача — спроектировать ножки, чтобы их потом можно было выточить, то рабочий продукт — проектная документация для ножек в экселе, выполненная по определенному образцу.

Ссылки:

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

Очереди увеличивают цикл одного рабочего продукта, время от начала работы над ним до выпуска в финальном виде.
Хочется сделать такой вывод: нет смысла увеличивать эффективность работы над рабочими продуктами, пока мы не оптимизируем очереди.
Пример:
🟢 — работа над РП
🔴 — ожидание в очереди
Ситуация у нас такая:
🟢🟢🔴🔴🔴🔴🔴🔴🟢🟢🔴🔴🔴🔴🔴🔴🔴🟢🟢
То есть над РП работают два дня, потом он шесть дней ждет, потом еще два дня в работе, еще семь дней ждет, и наконец финальные два дня в работе перед выпуском. Итого цикл 19 дней, чистое время работы над РП 6 дней.
Допустим, мы удвоим эффективность инженеров и они смогут решить задачу в два раза быстрее — за три дня:
🟢🔴🔴🔴🔴🔴🔴🟢🔴🔴🔴🔴🔴🔴🔴🟢
Экономия: 🟢🟢🟢
Получаем цикл 16 дней. Плюс затраты на увеличение эффективности инженеров.
А теперь вместо этого сократим очереди вдвое:
🟢🟢🔴🔴🔴🟢🟢🔴🔴🔴🔴🟢🟢
Экономия: 🔴🔴🔴🔴🔴🔴
Получаем цикл 13 дней и не трогаем инженеров, пусть работают как работали.

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

Важные следствия:

Чтобы использовать этот принцип — нужно понимать концепцию «рабочего продукта»; иногда РП понятны интуитивно — в задаче «сделай мне презу для клиента» речь идет о паверпоинтовском файле, можно не уточнять; но иногда итоговый РП непонятен — и лучше бы прояснить, в каком виде заказчик ждет результат от исполнителя. Уточнить могут оба: хороший руководитель/заказчик всегда опишет, что именно и в каком виде он ждет, а хороший исполнитель — задаст конкретные вопросы, если ему неясно. В софтверной разработке РП бывают описаны в техзадании или критериях приемки (acceptance criteria) и обычно представляют собой фичи — определенное поведение разработанного софта в каком-то контексте.
Нужно наладить учет и контроль движения РП. В софтверной разработке за это отвечают ишью трекеры (джира, ютрек) — они позволяют видеть картину по всем РП разом, и в то же время отслеживать любой из них. Без нормально организованного учета часть работ и усилий станет невидимой для менеджмента. Опять-таки, иногда интуитивного понимания достаточно («Где мой отчет за май?! Вы его уже неделю мурыжите!»), но если работ и РП много — будут потери и рассинхрон.
Для руководителей. Основанием для ответа на вопрос «насколько хорошо работает Сидоров» может стать не общая интуитивная оценка, не сумма наблюдений, насколько усердно тот орудует у кульмана/компьютера/станка, а контроль и анализ прошедших через Сидорова рабочих продуктов.
Для исполнителей — во-первых, добивайтесь ~~отстоя пены~~ нормальной постановки задач через рабочие продукты; во-вторых, если ваш руководитель или заказчик неспособен это сделать — обучитесь формулировать сами, например, с помощью практики «понимание задачи»; в-третьих, сами начните планировать работу, отталкиваясь от РП — зачастую это проще, чем мириться с абстрактной постановкой задачи. По некоторым задачам сначала можно согласовать рабочий продукт, а уже потом приниматься за его изготовление.
Пример: вам поручили презентацию для клиента, куда нужно включить коммерческое предложение по двум продуктам. Вы за полчаса накидываете черновик презентации прямо в паверпоинте, идете показать: «Семен Иваныч, такой формат подойдет? Тут будет описание продукта-1, тут описание продукта-2, тут — табличка с ценами с учетом скидки за объем, тут — наши регалии и отзывы клиентов». На готовом материале — пусть и черновом — обсуждать задачу гораздо легче, чем на пальцах.