Часть The Nature of Our Decisions.
В предыдущей части мы рассмотрели пять основных принципов для формирования экономического фреймворка:
- Все измеряем: мы должны понимать базовую экономику продукта — сколько мы тратим на его разработку, сколько мы будем зарабатывать когда продукт выйдет, когда мы планируем выпуск. С помощью этой базовой экономики мы должны уметь посчитать, во что нам обойдется то или иное решение в процессе разработки продукта. Считать мы это должны с помощью переменной «влияние на прибыль в течение ЖЦ продукта».
- Нельзя просто поменять одну величину: базовая экономика продукта строится на нескольких взаимосвязанных факторах, и изменение в одном факторе в какую-то сторону вызывает изменение в остальных. Факторы следующие: стоимость продукта в производстве (косты), прогнозируемая выручка за ЖЦ продукта, затраты на разработку продукта, длительность цикла от старта разработки продукта до выпуска, риски.
- Обязательно считать стоимость задержки: построив экономическую модель, мы должны тут же посчитать значение переменной «стоимость задержки (выпуска продукта)». Зная эту переменную, мы можем легко считать, во что нам обходится любая задержка выпуска продукта. Вычисляем планируемую выручку от продажи продукта в удобную единицу времени (неделю, месяц и т. д.), умножаем на прогнозируемую задержку — понимаем, сколько денег на этом теряем.
- Добавленная стоимость отражается в экономике продукта: добавленную стоимость/ценность и потери (waste) оцениваем так же, как остальные переменные, следующие из экономического фреймворка. Если мы каким-то действием увеличили прогнозируемую прибыль на ЖЦ продукта, то мы добавили ценности; если нет — мы понесли потери.
- Принцип бездействия: отслеживаем не производительность рабочих станций в момент выполнения работы, а состояния рабочих продуктов. Больше всего экономике продукта вредят не неэффективные инженеры, а зависшие в очередях рабочие продукты.
Теперь мы посмотрим на то, какие решения нам нужно с его помощью принимать. Суть этих решений диктует, какую систему поддержки принятия решений следует разработать.
E6: The U-Curve Principle #
Рейнертсен утверждает, что «Important trade-offs are likely to have U-curve optimizations » — то есть проблемы, которые нам нужно разрешать с помощью экономического фреймворка, после построения графика выглядят как U-образные кривые.
Из этого два следствия:
- во-первых, без квантификации найти верное решение будет очень сложно
- во-вторых — такая модель прощает неточности, нужно попасть в довольно обширный диапазон значений (выделено красным на графике). А значит, и исходные данные могут быть приблизительными.
E7: The Imperfection Principle #
Задача экономического фреймворка — помочь нам принимать более качественные решения, чем если бы мы руководствовались интуицией. Фреймворк не должен быть идеально точным, он должен быть достаточно хорошим — как минимум, лучше интуитивного метода.
Хороший поинт автора: узнав, что экономический фреймворк не дает супер-высокой точности, менеджеры склонны отказаться от его внедрения и продолжать использовать интуитивные методы — как будто это сильнее убережет их от ошибок.
Вот пример из практики Рейнертсена, который показывает нелепость такого отношения: интуитивные оценки стоимости задержки продукта (Cost of Delay) могут различаться в 50 раз внутри команды; это значит, что Петров считает, что неделя задержки продукта стоит компании 1000 долларов, а Иванов — 50000 долларов.
После введения фреймворка и подсчетов вилка сокращается до двухкратной разницы — т. е. становится точнее в 25 раз.
E8: The Principle of Small Decisions #
Нужно принимать не только большие, но и малые решения. Более того — в книге утверждается, что в куче маленьких решений и кроется львиная доля возможных улучшений.
Рейнертсен ругает менеджеров, чересчур всерьез воспринимающих принцип Парето. По его мнению, 20% решений, пользующихся пристальным вниманием управленцев, вполне могут таить в себе меньше возможностей, чем задвинутые за шкаф 80% остальных решений:
“Pareto Paradox: There is usually more actual opportunity in the undermanaged 80 percent than the overmanaged 20 percent.”
Выхлоп от каждого маленького решения, разумеется, меньше, чем от крупного, и маленькими решениями нужно правильно управлять, чтобы затраты на их принятие не стали запредельными — об этом дальше.
E9: The Principle of Continuous Economic Trade-offs #
Нельзя все спланировать заранее, принять все важные экономические решения в начале разработки, и потом просто сидеть и разрабатывать. Необходимость принимать решения о выборе из нескольких альтернатив будет возникать непредсказуемо в течение всей работы над продуктом — это нормально и этого не избежать.
Здесь очередное отличие от производства, где все решения приняты заранее, перед началом работы над партией, и любое отклонение от плана навредит — потому что план оптимален.
Применять подобный подход — с детальным поминутным планированием всех операций, максимизацией загрузки мощностей и сравнением факта с планом — в продуктовой разработке нельзя.
В продуктовой разработке у нас каждый рабочий такт появляется новая информация — как с рынка, так и изнутри процесса, и эту информацию лучше бы учесть.
Пример: мы оценили, что новая фича нужна половине наших клиентов и ее разработка займет две недели. Делаем? — Делаем.
Начав проектирование, мы поняли, что фича важна лишь одному проценту клиентов и потребует двух месяцев разработки. Экономическая эффективность фичи уменьшилась в двести раз (!), нужно срочно менять план.
Принцип E1 говорил нам, что мы тут собрались ради принятия верных экономических решений — и для этого фреймворк должен учесть полученную нами информацию и, если нужно, измениться для лучшего отражения реальности.
Следовать устаревшему плану в ситуации, когда все регулярно меняется — плохая стратегия.
E10: The First Perishability Principle #
Нужно уметь быстро распознавать возможности и быстро принимать решения. Возможности и риски возникают постоянно — об этом предыдущий принцип. Ценность от использования возможности со временем будет снижаться, препятствия вследствие возникновения рисков будут расти, и нужно успеть принять решение до его полного обесценивания.
Нужен алгоритм идентификации, оценки и процедуры принятия и согласования таких решений за минимально возможное время.
В девятой главе Рейнертсен предложит нам использовать стратегию децентрализованного контроля: нужно делегировать право принимать решение людям на том уровне, на котором эта возможность была обнаружена и может быть использована. Тогда менеджеры не будут узким местом для принятия множества маленьких решений из принципа E8 и не станут еще одним источником очередей. См. пример про самолеты ниже.
E11: The Subdivision Principle #
Плохие решения или опции можно превратить в хорошие. Плохое решение можно разделить на составляющие, оценить каждую составляющую с точки зрения улучшения общей экономики продукта, и использовать только те составляющие, которые дают хороший результат.
Рейнертсен приводит такой пример: одна компания, разрабатывающая полупроводники, использовала внешнего подрядчика для предоставления важной интеллектуальной собственности (ИС) для своего проекта. Ресурсов на внутреннюю разработку у компании не было.
В то же время использование внешней ИС — серьезный риск для проекта.
Компания отрядила одного инженера для мониторинга работы подрядчика. Если бы в какой-то момент потребовалось затащить разработку ИС внутрь компании — это удалось бы сделать довольно быстро и не с нуля, т. к. инженер был бы в курсе хода работ и достигнутых подрядчиком результатов.
То есть, компания использовала дешевый способ получить часть результата от сложной и дорогой деятельности. (я этот пример до конца не понимаю, и не уверен, что верно перевел, но другого у меня нет).
Дальше у нас глава Our Control Strategy — про то, как лучше всего работать с принимаемыми решениями. Из предыдущей главы мы помним, что решений нужно принимать много, их нужно принимать быстро и нерегулярно, и для этого нужно придумать правила и ограничения.
E12: The Principle of Early Harvesting #
Рейнертсен утверждает, что дешевые способы ускорить разработку продукта обычно встречаются на ранних стадиях — и нужно научить организацию эти решения находить и использовать.
Пример: в одной из организаций инженер мог без согласования принять решение, экономившее неделю разработки, если затраты на это решение не превышали 500$, и не более четырех недель за раз; лимит у менеджера был 1000$ и 8 недель, у директора — 5000$ и 16 недель. После достижения лимита сотрудник мог пойти к своему менеджеру, пройти ревью и получить «добро» на дальнейшие улучшения.
Таким образом компания смогла находить много простых способов сократить время цикла без сложных процедур согласования.
Два ключевых слова тут «много» и «простых».
E13: The First Decision Rule Principle #
Сильно похоже на предыдущий принцип. Если мы принимаем за факт необходимость принимать много небольших решений на нижних уровнях иерархии компании, то нужно передать полномочия и ответственность за решения на эти нижние уровни — т. е. децентрализовать процесс принятия решений. При этом нужно сохранять контроль за экономикой продукта, не вмешиваясь в каждое конкретное решение.
Для этого Рейнертсен вводит понятие economic decision rules; задачи этих правил:
- Привести к общему знаменателю все экономические решения и выборы в рамках проекта
- Обеспечить оптимальность этих решений на системном уровне
- Обеспечить передачу контроля на нижние уровни без существенного повышения рисков
- Оптимизировать процесс принятия решений.
Выполнение этих правил позволяет сделать принятие решений «дешевле» и быстрее.
Пример (был в первом посте): когда Боинг разрабатывал свой 777-й, руководители программы распределили вес и стоимость готового самолета на все подсистемы в начале проекта — к примеру, на крыло приходилось 60 тонн веса и 1,5 млрд стоимости. Распределение, само собой, было неидеальным — одной подсистеме не хватало веса, другой — бюджета, и командам, над ними работавшим, приходилось принимать экономически странные в рамках проекта решения. Например, у одной команды был избыток бюджета и недостаток веса, и она тратила 5000 долларов на «урезание» лишних пары кило веса (кг = 2500$); другая команда, у которой денег было впритык, но был хороший запас по весу, даже не рассматривала возможность урезать несколько килограмм веса по 50 долларов каждый (кг = 50$).
На уровне системы (самолета) каждое такое решение было субоптимальным: первая команда тратила слишком много денег на слабые улучшения, вторая — не использовала дешевую возможность улучшить подсистему.
Как можно было оптимизировать решения? Первый и очевидный способ — назначить отдельного человека проверять и уторговывать все решения. Это создало бы очереди из таких решений и разработка всерьез затянулась бы.
Вместо этого Боинг разработал правило, которое работало на уровне всей системы: любой инженер или проектировщик мог увеличить стоимость подсистемы или компонента на 300 долларов, если он при этом избавится от фунта веса — путем другого дизайна компонента, путем замены на более легкий аналог, и т. п.
И все полетело — пять тысяч инженеров получили возможность принимать решения без согласования при выполнении вышеописанных условий.
Руководство разработки не стало узким местом — оно устранилось из процесса принятия самих решений, сохранив при этом экономическую прозрачность и контроль надо общим бюджетом системы.
E14: The First Market Principle #
Менеджеры пользуются ресурсами компании для разработки продуктов без оглядки на стоимость этих ресурсов. Те, кто понаглее, аккумулируют избыточные ресурсы, потому что это им ничего не стоит — ну это же наша компания, чо вы.
Большинство компаний распределяют ресурсы не на основе детального анализа (его почти нигде нет), а централизованно, сообразно интуитивному пониманию. Менеджеры, отвечающие за разработку, никак не ограничиваются в своем желании запасти немного избыточных ресурсов — вдруг понадобятся.
Централизованное распределение ресурсов, подобно экономике СССР, во-первых сильно ограничивает возможность оптимизировать затраты, во-вторых — создает очереди.
Нужно децентрализовать и позволить рынку порешать: пусть менеджеры проектов/продуктов сами решают, какие ресурсы за какую стоимость использовать.
Пример: менеджер в компании решил поставить под контроль спрос на отдел компьютерного проектирования. Он решил предоставлять два уровня сервиса: стандартный и премиум. Стандартный стоил как обычно, премиумный стоил на 25% дороже и давал результат в течение 48 часов. Наценка использовалась для обеспечения премиумного сервиса ресурсами.
Такой подход лучше централизованного, потому что потребители этих услуг — проектные менеджеры, — сами решают, какой уровень сервиса им необходим, без вовлечения руководства и с пониманием возврата инвестиций. Ну, если они экономическим фреймворком пользуется.
Как именно менеджеры «платят» за использование отдела компьютерного моделирования — Рейнертсен не уточняет. Возможно, речь идет о прямом распоряжении бюджетом проекта (см. пост А. Турханова про вырождение понятия «проект»), возможно — на бумаге или за фантики.
E15: The Principle of Optimum Decision Timing #
В принципе E9 утверждалось, что мы не можем принять все важные решения до начала работы над продуктом. Что насчет обратного подхода — откладывать любое решение до последнего момента? На вопрос отвечает экономический фреймворк.
Рейнертсен сравнивает подход к таймингу решений с ценовой политикой авиакомпаний. Если билеты продаются недостаточно активно, софт автоматически снижает цену. По мере приближения даты полета билеты дорожают — чтобы стать максимально дорогими в последние дни.
Некоторые продуктовые решения нужно принять максимально рано — они определят важные архитектурные ограничения и свойства продукта. Например, форма модели кроссовка: от нее зависят материалы, раскрой, детейлинг, а уже от них зависит, какие потребуются станки и специалисты.
Некоторые решения можно откладывать в ожидании оптимального момента; например, цвет деталей кроссовка можно отложить, пока не будет готова и настроена линия — поменять цвет на настроенной линии мы можем довольно быстро, а вот слишком ранний выбор ценности нам не дает — можем не попасть в модные тренды.
Общее правило звучит так: решение нужно принимать тогда, когда дальнейшее ожидание перестает положительно влиять на экономику продукта.
Часть Some Basic Economic Concepts. В этой части рассматриваются несколько основных экономических принципов, которые помогают принимать правильные экономические решения.
E16: The Principle of Marginal Economics #
Чтобы определить, как именно продуктовое решение (новая фича, новый вариант продукта и т. п.) повлияет на экономику продукта, нужно использовать маржинальные значения ценности и костов, а не суммарные по продукту.
Это что-то вроде юнит-экономики: прирост ценности продукта (выраженный в объеме продаж или цене) должен быть выше, чем прирост затрат на реализацию фичи. Изолировав в отдельное вычисление рост ценности и рост затрат, мы получаем их маржинальные значения. Так мы можем сравнивать между собой разные потенциальные фичи: у какой лучше маржинальная прибыль, ту и надо брать в работу.
Пример: проект, в котором две фичи, завершен на 80%. Одна фича готова, вторая отстала на 10%. Какой фичей должна заняться команда?
Неправильный ответ: над отстающей фичей, потому что ТАКОВ БЫЛ ПЛАН.
Правильный ответ: над той фичей, у которой маржинальная прибыль выше. Нередко это уже готовая фича — ее можно улучшить.
Еще пример: фичу сделали на 95% довольно быстро, но оставшиеся 5% добить будет немного сложнее. Стоит ли команде доделывать фичу до победных ста процентов или сдать как есть?
Правильный ответ: посчитать эти 5% как отдельную фичу со своей маржинальной экономикой и принять решение.
E17: The Sunk Cost Principle #
Простой и понятный принцип: уже потраченные деньги в новых трейд-оффах не учитываем. В предыдущем примере именно поэтому предлагается считать пятипроцентный остаток фичи отдельно.
Пример: команда работает над проектом со средней прибыльностью, он выполнен на 90%. Появляется возможность начать новый проект с высокой прибыльностью. Что нужно выбрать: доделать первый проект или бросить его и начать второй, высокоприбыльный?
Нужно посчитать маржинальную прибыль по каждому из проектов, при этом в первом проекте в костах нужно учесть только оставшееся время/усилия на реализацию, а не потраченное + оставшееся. В таком свете высокоприбыльный проект вполне может таковым и не оказаться — в маржинальном выражении.
Этот же принцип неплохо освещен в психологии, в т.ч. Канеманом — см. https://en.wikipedia.org/wiki/Sunk_cost
E18: The Principle of Buying Information #
Информация снижает неопределенность, что может увеличить экономическую ценность продукта. Платить за такую информацию нужно столько, чтобы маржинальная экономическая ценность превышала маржинальные затраты на получение этой информации.
Пример: лотерейный билет с возможностью выиграть миллион долларов с шансом «один на миллион» не стоит покупать дороже, чем за доллар.
Иногда неуспешный продукт сам по себе является ценной информацией: операционка Windows 1.0 провалилась, но обеспечила микрософт ценными инсайтами, которые позволили потом завоевать рынок.
Другой пример. Клинические испытания лекарств делятся на фазы, ранние фазы более простые и дешевые; если лекарство проваливается на ранних фазах — можно не тратиться на последующие, более дорогие фазы. Так сначала информация покупается подешевле, потом, если все ок — подороже, и так далее. Экономию от невыхода на следующие фазы подсчитать несложно.
Рейнертсен утверждает, что существует экономически оптимальная последовательность действий по снижению риска. Низкозатратные мероприятия, устраняющие большой риск, должны проводиться раньше высокозатратных мероприятий, устраняющих очень малый риск.
Часть Debunking Some Popular Fallacies.
E19: The Insurance Principle #
Платить за страховку нужно не больше, чем потенциальные потери от наступления страхового случая. В частности, Рейнертсен сдержанно ругает подход set-based concurrent engineering (SBCE), подразумевающий разработку нескольких инженерных решений для каждой продуктовой подсистемы.
Например, при разработке новой модели автомобиля при этом подходе можно не выбирать конкретный двигатель, а выбрать несколько — и продолжать разработку с этим учетом, а двигатель окончательно выбрать когда-то потом. Очевидно, что это умножает количество требуемой работы на количество решений, и претензия Рейнертсена здесь в том, что такой подход выглядит как экономически нецелесообразная подстраховка.
Использовать такой подход или нет — это вопрос к экономическому фреймворку. Если расходы на разработку какого-то количества параллельных решений ниже, чем потенциальная польза от снижения рисков, то все ок.
E20: The Newsboy Principle #
В этом принципе рассматривается, как решение задачи продавца газет помогает взглянуть на продуктовые решения.
Задача звучит так: продавец газет зарабатывает 50 центов на проданной газете и теряет 25 на непроданной; сколько газет ему нужно закупить для максимизации прибыли, если он не знает точный спрос?
Поскольку заработок от продажи выше убытка от непроданной газеты, имеет смысл держать лишний запас — т. е. чтобы газет было больше, чем требует средний спрос.
Если посчитать функцию максимизации прибыли для указанных значений (вычислить т. н. критический фрактиль), мы увидим, что в среднем раз в три дня продавец будет распродавать весь тираж, не сумев удовлетворить спрос.
Вывод: в ситуации экономической асимметрии оптимум может быть достигнут даже при невысоком шансе на успех в каждом конкретном случае.
Раз в три дня продавец газет недозарабатывает, но в целом он зарабатывает настолько хорошо, насколько возможно.
Дальше Рейнертсен упоминает спикера на недавней (на момент написания книги — 2009 г.) конференции. Спикер рассказывал, что 96% продуктов неспособны поместиться в заданные экономические рамки — следовательно, нужно агрессивно фильтровать возникающие возможности и инициативы и тем самым улучшать ROI продукта.
В разработке продукта трейд-оффы асимметричные — на вложенный доллар возврат может быть и ноль, и десять, и сто, и тысяча. При этом бывают ситуации, к примеру, в фарме, когда разработчики лекарства ставят крест на молекуле-кандидате после инвестиций в ее проверку в районе десяти тысяч долларов — при том, что возврат может составить миллиарды долларов.
Рейнертсен предлагает венчур — браться за проработку продуктовых возможностей или инициатив с хорошим возвратом на инвестиции, даже если у них невысокая вероятность успеха.
E21: The Show Me the Money Principle #
Хотите от компании денег — говорите со стейкхолдерами на языке денег и показывайте с помощью фреймворка, что вы заботитесь и о расходной, и о доходной частях ваших решений. Будете говорить на языке денег — будете чаще и быстрее получать «добро» на ваши инициативы.
🏁 Первая часть закончилась. Подытожим:
- Экономический фреймворк позволяет свести все прокси-переменные и трейд-оффы к одной единице измерения — влиянию на прибыль на ЖЦ продукта. Всё оцениваем с помощью этой метрики.
- Несовершенные правила принятия решений лучше, чем интуитивные догадки; с помощью правил мы можем быстро находить и обрабатывать мелкие экономические возможности, пользуясь преимуществами децентрализованного управления.
- Всегда считаем стоимость задержки — с ее помощью обнаружим и победим очереди.
А очереди мы начнем рассматривать в следующем посте.
upd. А вот и следующий пост: https://artemushanov.ru/?go=all/chto-takoe-ocheredi/
.png)
.png)
.png.jpg)
