{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Блоги: заметки с тегом pdflow",
    "_rss_description": "Автоматически собираемая лента заметок, написанных в блогах на Эгее",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": false,
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/blogengine.ru\/blogs\/tags\/pdflow\/",
    "feed_url": "https:\/\/blogengine.ru\/blogs\/tags\/pdflow\/json\/",
    "icon": false,
    "authors": [
        {
            "name": "Илья Бирман",
            "url": "https:\/\/blogengine.ru\/blogs\/",
            "avatar": false
        }
    ],
    "items": [
        {
            "id": "133833",
            "url": "https:\/\/artemushanov.ru\/?go=all\/the-principles-of-product-development-flow-post-5-ocheredi-i-cap\/",
            "title": "The Principles of Product Development Flow, пост 7 — очереди и capacity utilization",
            "content_html": "<p class=\"foot\">🔬 Это пост с разбором очередной части книги Дона Рейнертсена <i>The Principles of Product Development Flow<\/i>. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу <a href=\"https:\/\/artemushanov.ru\/?go=tags\/pd-flow\/\">pdflow<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-3.png\" width=\"338\" height=\"500\" alt=\"\" \/>\n<\/div>\n<p>Цитата из <a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-takoe-ocheredi\/\">предыдущего поста<\/a>:<\/p>\n<blockquote>\n<p>Рейнертсен считает, что очереди — одна из главных причин задержек в продуктовой разработке, а работать с ними мало кто умеет.<\/p>\n<\/blockquote>\n<p>Рассмотрим два первых принципа — про то, почему очереди вредны и почему с ними никто не борется.<\/p>\n<h3>Q1: The Principle of Invisible Inventory: Product development inventory is physically and financially invisible<\/h3>\n<p>Очереди в продуктовой разработке невидимы.<\/p>\n<p>На физическом производстве очереди заметны: если перед станком скопились детали на обработку — что-то идет не так. Если партия станков не завершена — это есть в отчетах, и финдиректор может сказать, сколько всего на заводе «незавершенки» (WIP — <i>Work In Progress<\/i>).<\/p>\n<p>В разработке физических деталей нет. Работа ведется над информацией — схемами, чертежами, спецификациями, тасками, юзер-сторями и прочими эпиками. О том, сколько таких артефактов распихано по джирам и фигмам — финансовому директору точно неведомо. Артефакты такого рода Дон называет DIP — <i>Design In Progress<\/i>.<\/p>\n<p>Такая физическая и финансовая невидимость артефактов проектирования не позволяет привычным образом оценить, а сколько же их у нас в работе и в какие очереди они выстроились. Не умея их обнаружить, мы не можем вычислить их влияние на экономику разрабатываемого продукта.<\/p>\n<h3>Q2: The Principle of Queueing Waste: Queues are the root cause of the majority of economic waste in product development<\/h3>\n<p class=\"note\">Здесь и далее я буду переводить термин «waste» из бережливого менеджмента как «непродуктивные затраты». Такой перевод излишне длинный, зато более конкретный, чем «потери».<\/p>\n<p>Дон рубит сплеча: очереди — основной источник потерь и непродуктивных затрат в продуктовой разработке.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-59.png\" width=\"600\" height=\"337\" alt=\"\" \/>\n<\/div>\n<p>Во-первых, очереди в разработке продуктов гораздо длиннее очередей в производстве. Горизонты в производстве — часы и дни, в разработке — месяцы и годы. Заготовка или деталь точно будут обработаны если не завтра, то через пару дней — а дизайн-артефакт может два месяца ждать, пока конструкторский отдел до него доберется в списке своих работ.<\/p>\n<p>Из Q1 мы знаем, что очереди в разработке продуктов невидимы — а значит, никто за ними не следит и никто не старается сократить. Более того, в компаниях, занимающихся разработкой, иногда принято хвалиться размерами своего бэклога — «у нас до следующего января отдел разработки занят».<\/p>\n<p>Во-вторых, очереди создают много непродуктивных затрат.<br \/>\nИсточники затрат:<\/p>\n<ul>\n<li>Увеличение цикла разработки: чем длиннее очередь — тем дольше рабочий продукт будет ждать, пока за него возьмутся. Если мы знаем про очереди, мы можем придумать, как спрогнозировать и посчитать потери от ожидания.<\/li>\n<li>Рост рисков: этапы обработки рабочих продуктов разделены длительным временем ожидания, поэтому растут риски. Чем дольше мы ждем — тем выше вероятность, что могут произойти нежелательные изменения на рынке, у конкурентов или в используемых технологиях.<\/li>\n<li>Увеличение вариабельности: когда мы сильно нагружаем наши мощности по разработке, сильно растет вариабельность.<\/li>\n<li>Увеличение накладных расходов: чем больше РП сидит в очередях — тем длиннее очереди, больше встреч и отчетов.<\/li>\n<li>Снижение качества: из-за очередей мы получаем фидбек о сделанной работе позже. Если программист начал писать код исходя из неверных предпосылок и получил фидбек на следующий день — можно быстро откатиться и исправить. Если фидбек придет только через неделю, то придется выкинуть результаты нескольких дней работы.<\/li>\n<li>Снижение мотивации: нет необходимости торопиться и пилить дизайны для приложения за день или два, если продакт сможет посмотреть их только через неделю.<\/li>\n<\/ul>\n<p>В конце этой главы Дон подчеркивает, что мнение «очереди вне критического пути не стоят компании денег» — ошибочное. Вышеописанные источники проблем показывают, что это не так: лишь один из них — увеличение времени цикла, — удлиняет критический путь и повышает стоимость задержки; остальные пять источников проблем вполне могут касаться процессов, не лежащих на критическом пути, но способных сильно навредить.<\/p>\n<h2>Поведение очередей<\/h2>\n<p>Дальше Дон предлагает обсудить, как загрузка мощностей и вариабельность влияют на размер очередей.<\/p>\n<h3>Что такое Capacity Utilization<\/h3>\n<p>Capacity utilization здесь и далее я буду называть «загрузкой мощностей». Прежде, чем перейти к принципу Q3, который полностью про загрузку мощностей, нужно бы определиться, о каких таких мощностях идет речь.<\/p>\n<p>Сам Рейнертсен не дает определения, разве что вскользь упоминает:<\/p>\n<blockquote>\n<p>...capacity utilization is the ratio of two factors, demand and capacity, that are individually hard to estimate.<\/p>\n<\/blockquote>\n<p>Мощность, или capacity — это некоторый показатель того, сколько полезной работы ресурс сможет проделать в единицу времени.<br \/>\nСкажем, у программиста в рабочем дне восемь часов; из них час уходит на синки, два часа — на созвоны и встречи, оставшиеся пять часов посвящены работе над продуктовыми задачами. Значит, мощность\/капасити программиста — 5 часов. Если он все пять часов работает над одним продуктом, то загрузка его мощности будет 100%.<br \/>\nЕсли у нас не один программист, а отдел из 10 человек, и 8 из них постоянно заняты в разработке — мы можем сказать, что загрузка мощностей составляет 80%.<\/p>\n<p>В статье <a href=\"https:\/\/hbr.org\/2012\/05\/six-myths-of-product-development\">Six Myths Of Product Development<\/a> (HBR, 2012) Рейнертсен и его соавтор Штефан Томске в качестве первого мифа приводят следующий:<\/p>\n<blockquote>\n<ol start=\"1\">\n<li>High utilization of resources will make the department more efficient.<\/li>\n<\/ol>\n<\/blockquote>\n<p>Поскольку это миф, то читаем наоборот: полная загрузка мощностей отдела не улучшит, а ухудшит общий результат компании.<br \/>\nВот те раз.<\/p>\n<p>Дон и Штефан объясняют это следующим: продуктовая разработка — это деятельность с высокой степенью неопределенности (высокой вариабельностью). На старте проекта непонятно, какие задачи потребуется решить, сколько времени займет их решение и как с ними справится команда. Если команда занята на сто процентов, свежеприбыашая задача встанет в очередь на ожидание.<br \/>\nВ разработке задачи прибывают из разных источников, не всегда предсказуемо, среди них могут быть срочные и важные. Держать их в очереди рискованно: может быть упущено оптимальное временное окно и задача утратит смысл, не получится улучшить продуктовую экономику.<\/p>\n<p>Да, некоторым менеджерам будет невыносимо видеть, что двое из десяти разработчиков заняты ерундой вместо разработки — спеки причесывают или код рефакторят. И на уровне подразделения, изолированного от остальных отделов компании, эти два программиста испортят статистику. Зато они готовы будут подхватить срочную и важную задачу, когда она внезапно прилетит — и не провалить проект в целом, что скажется на результатах всей компании. Их нужно воспринимать как буферный запас, который работает на глобальный оптимум в ущерб локальному.<\/p>\n<p>Правило, однако, не звучит как «всегда держите Х% мощности в резерве». Правило звучит так:<\/p>\n<p class=\"loud\">С помощью экономического фреймворка следует сопоставить стоимость очереди и стоимость неиспользуемых мощностей, чтобы найти правильный баланс.<\/p>\n<p>Загрузка мощностей (capacity utilisation) обозначается буквой «ро» —  <tt>ρ<\/tt> и вычисляется следующим образом:<\/p>\n<blockquote>\n<p><tt>ρ = λ \/ μ<\/tt><\/p>\n<\/blockquote>\n<p>где <tt>λ<\/tt> — интенсивность поступления задач (например, количество задач в единицу времени), а <tt>μ<\/tt> — интенсивность обработки задач (пропускная способность ресурса, например, количество задач, которые система может обработать в единицу времени).<\/p>\n<p><b>Пример 1: Оператор в кол-центре<\/b><\/p>\n<ul>\n<li>Один оператор может обслужить 10 звонков в час (μ = 10).<\/li>\n<li>В среднем поступает 8 звонков в час (λ = 8).<\/li>\n<li>Загрузка: <tt>ρ = 8\/10 = 0,8 (80%)<\/tt><\/li>\n<\/ul>\n<p>Ресурс работает с 80%-й загрузкой, что считается безопасным уровнем.<\/p>\n<p><b>Пример 2: Конвейерная линия<\/b><\/p>\n<ul>\n<li>Линия может обрабатывать 100 деталей в час (μ = 100 ).<\/li>\n<li>Поступает 120 деталей в час (λ = 120 ).<\/li>\n<li>Загрузка: <tt>ρ = 120\/100 = 1,2 (120%)<\/tt><\/li>\n<\/ul>\n<p>Система перегружена, что приводит к появлению очередей.<\/p>\n<p class=\"note\">Про детальные правила расчета можно почитать, например, в курсе ШСМ «Рациональная работа» <a href=\"https:\/\/aisystant.system-school.ru\/lk\/#\/course\/ontologics-sobr\/2024-11-21T2253\/50307\">по ссылке<\/a>.<\/p>\n<p>При разработке продукта сложно оценить загрузку мощностей с достаточной точностью. Сложность эта возникает потому, что загрузка мощностей — это соотношение двух факторов, <i>спроса<\/i> и <i>запаса мощностей<\/i>, каждый из которых сложно оценить.<br \/>\n«Спрос» в данном случае — это работы, которые необходимо выполнить для решения задачи. Эти работы раньше не выполнялись, они для сотрудника новые. С оценкой трудоемкости таких работ легко можно промахнуться, скажем, на 10%.<br \/>\n«Мощности» в данном случае — это производительность сотрудника в решении поставленной задачи, которую он никогда не выполнял ранее. При ее оценке тоже запросто можно ошибиться на 10%.<\/p>\n<p>Две ошибки по 10% каждая дают нам в комбинации возможный диапазон загрузки мощностей от 55 до 95%. То есть наш сотрудник то ли наполовину свободен, то ли полностью занят. Если мы будем вычислять очереди исходя из такого широкого диапазона, разница между крайними значениями может составить до 25 раз.<\/p>\n<p>Результат будет точнее, если измерять размер очереди и работу в процессе (WIP). Об этом в следующих постах.<\/p>\n<h3>Q3: The Principle of Queueing Capacity Utilization: Capacity utilization increases queues exponentially<\/h3>\n<p><mark>С увеличением загрузки мощностей очереди растут экспоненциально.<\/mark><\/p>\n<p>Высокую загрузку мощностей Дон называет главной причиной роста очередей. За тринадцать лет преподавания он вывел, что средняя компания-разработчик загружает свои мощности примерно на 98,5%.<\/p>\n<p>Кривая зависимости времени цикла от загрузки мощностей для очередей типа <tt>M\/M\/1\/∞<\/tt> выглядит так:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/the-principles-of-product-development-flow-post-5-ocheredi-i-cap.png\" width=\"1018\" height=\"690\" alt=\"\" \/>\n<\/div>\n<p>При уменьшении доступных мощностей в два раза очередь тоже растет примерно в два раза. Когда мы увеличиваем загрузку мощностей с 60 до 80 процентов — очереди удваиваются (с 2 до 4), после увеличения загрузки с 80 процентов до 90 — еще раз удваиваются, с 4 до 9.<\/p>\n<p>Отделы продуктовой разработки склонны загружать мощности до уровня, допустимого в детерминистических процессах (= практически лишенных вариабельности). Это означает, что любая новая задача — важная, срочная, большая или малая, — гарантированно встает в очередь.<\/p>\n<p>Зная загрузку мощностей <tt>ρ<\/tt> для процессов с очередями типа <tt>M\/M\/1\/∞<\/tt>, мы можем предсказать следующее:<\/p>\n<ol start=\"1\">\n<li>В каком проценте случаев новая работа встанет в очередь из-за загруженного ресурса: <tt>1 − ρ<\/tt><\/li>\n<li>Среднее количество элементов в очереди: <tt>ρ² \/ (1 − ρ)<\/tt><\/li>\n<li>Среднее количество элементов в системе: <tt>ρ \/ (1 − ρ)<\/tt><\/li>\n<li>Какую долю длительности цикла занимает время нахождения элемента в очереди: <tt>ρ<\/tt><\/li>\n<li>Отношение времени цикла к времени создания добавленной стоимости: <tt>1 \/ (1 − ρ)<\/tt><\/li>\n<\/ol>\n<p>Простые формулы, которые приводят к удивительным инсайтам: если мы загрузили отдел на 95% — то любая задача 95% времени цикла проведет в очереди.<\/p>\n<h3>Q4: The Principle of High-Queue States: Most of the damage done by a queue is caused by high-queue states<\/h3>\n<p>Этот принцип — про местных черных лебедей: наибольший ущерб наносят длинные очереди, появление которых маловероятно.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-84.png\" width=\"959\" height=\"639\" alt=\"\" \/>\n<\/div>\n<p>Вероятность того, что мы найдем очередь в определенном количественном состоянии, является функцией от загрузки мощностей. Состояния с малыми очередями более вероятны, чем состояния с большими очередями, однако последние обычно более важны.<\/p>\n<p>В таблице представлены вероятности разных состояний очереди <tt>M\/M\/1\/∞<\/tt> при загрузке мощностей 75%.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/the-principles-of-product-development-flow-post-5-ocheredi-i-cap-3.png\" width=\"674\" height=\"548\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Вероятность вычисляется по формуле <tt>(1 − ρ)ρⁿ<\/tt><\/div>\n<\/div>\n<p>Мы можем увидеть, что вероятность нахождения в очереди двух объектов составляет 75% от вероятности нахождения в очереди одного объекта (14,1% и 18,8% соответственно). При этом нахождение в очереди двух объектов создает двойную стоимость задержки и экономический ущерб от очереди из двух объектов составит 150% ущерба от очереди с одним объектом. Вывод: чем длиннее очередь — тем сильнее увеличивается время цикла и выше ущерб.<\/p>\n<h3>Подытожим<\/h3>\n<p>Очереди важны: они создают предпосылки для большого количества проблем в продуктовой разработке. Работать с ними умеют не все, поэтому в продуктовой разработке решения по сокращению затрат могут приниматься неоптимально.<\/p>\n<p>Что важно знать про поведение очередей:<\/p>\n<ol start=\"1\">\n<li>Высокая загрузка мощностей (выше 80%) экспоненциально увеличивает очереди. Проще: очередь удваивается при сокращении свободных мощностей вдвое. Нужно считать затраты на очередь и затраты на содержание неизрасходованной мощности, выбирать оптимальную пропорцию.<\/li>\n<li>Наибольший ущерб наносят «черные лебеди» — длинные очереди, появление которых маловероятно. Нужно вовремя прогнозировать появление таких очередей. Мониторь, измеряй, вмешивайся.<\/li>\n<\/ol>\n<p>В следующем посте: влияние вариабельности на очереди; последовательные очеред (когда выход одной очереди становится входом для другой); оптимальная конфигурация очереди (аэропортовские оптимальнее супермаркетовых).<\/p>\n",
            "date_published": "2025-01-29T19:52:07+05:00",
            "date_modified": "2025-01-30T00:13:19+05:00",
            "tags": [
                "pdflow",
                "post",
                "Дон Рейнертсен",
                "менеджмент",
                "экономика"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Wed, 29 Jan 2025 19:52:07 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "133833",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "128048",
            "url": "https:\/\/artemushanov.ru\/?go=all\/primenenie-ekonomicheskogo-freymvorka-reynertsena\/",
            "title": "The Principles of Product Development Flow, пост 6: применение экономического фреймворка",
            "content_html": "<p class=\"foot\">🔬 Это пост с разбором очередной части книги Дона Рейнертсена <i>The Principles of Product Development Flow<\/i>. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу <a href=\"https:\/\/artemushanov.ru\/?go=tags\/pd-flow\/\">pdflow<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-3.png\" width=\"338\" height=\"500\" alt=\"\" \/>\n<\/div>\n<p><a href=\"https:\/\/artemushanov.ru\/?go=all\/primenenie-ekonomicheskogo-freymvorka-reynertsena-video\/\">Предыдущий пост<\/a> был с видосиком, теперь текст.<\/p>\n<p>Мне было интересно опробовать фреймворк на физическом продукте, потому что там больше процессов и сложнее расходная часть. На кикстартере я нашел зарядку 3-в-1 — нормальный кандидат.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-53.png\" width=\"1552\" height=\"873\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Ссылка: <a href=\"https:\/\/www.kickstarter.com\/projects\/mobfree-official\/xupercable\/description\">https:\/\/www.kickstarter.com\/projects\/mobfree-official\/xupercable\/description<\/a><\/div>\n<\/div>\n<p>Дальше я действовал так:<\/p>\n<ol start=\"1\">\n<li>Описал процесс создания продукта и составил список ролей, которые будут заниматься этими операциями.<\/li>\n<li>Составил перечень расходов на производство продукции.<\/li>\n<li>Посчитал себестоимость продукта.<\/li>\n<li>Составил табличку по продажам — сколько будем продавать и почем.<\/li>\n<li>Посчитал life-cycle profit продукта и прочие итоговые значения.<\/li>\n<li>Стал примерять к табличке-фреймворку разные кейсы и смотреть, что меняется.<\/li>\n<\/ol>\n<h3>Процесс создания продукта<\/h3>\n<p>Нам важно понять, сколько будет стоить разработка продукта. Разработка зарядки идет как-то так: сначала проектируем электронику, затем проектируем корпус, прототипируем и проверяем, добиваемся требуемых выходных показателей.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-54.png\" width=\"1258\" height=\"1126\" alt=\"\" \/>\n<\/div>\n<p>Получив рабочие прототипы, проектируем заводскую версию и стараемся сделать ее технологичной — чтобы в производстве единица стоила дешевле.<br \/>\nСоставляем список ролей для всего перечисленного, составляем календарный план, понимаем требуемую численность персонала. Умножаем на зарплаты — получаем бюджет на кадры. Докидываем аренду помещений, закупку инвентаря и деталей — получаем бюджет на разработку продукта. Время цикла тоже известно — у нас есть календарный план.<\/p>\n<h3>Производство продукции<\/h3>\n<p>Дальше нужно подготовить продукт к производству. Ищем подходящий завод, договариваемся, делаем пробные партии. Ищем нужные комплектующие, налаживаем закуп.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-55.png\" width=\"538\" height=\"918\" alt=\"\" \/>\n<\/div>\n<p>Обнаружив какое-то количество заводов, готовых поработать с нами, запрашиваем у них стоимость производства. Торгуемся, договариваемся. Зная стоимость закупа и стоимость операций на заводе, составляем смету на производство единицы продукции. Получаем себестоимость.<\/p>\n<p>Итак, у нас есть время цикла, расходы на разработку и себестоимость единицы продукции.<\/p>\n<h3>Продажи<\/h3>\n<p>Прикидываем стоимость лидов из разных каналов. Мы будем продавать через собственный сайт, через маркетплейсы и через партнеров — агентства, занимающиеся корпоративными подарками. Прикидываем объемы продаж — ну пусть будет 2000. Делим маркетинговые расходы на количество прогнозируемых продаж — получаем среднюю цену лида. Добавляем к ней административные расходы на маркетинг-продажи — получаем стоимость продажи на единицу продукции. Плюсуем к себестоимости.<\/p>\n<p>Зная себестоимость и цены на рынке, придумываем цену. 3000 ₽ за штуку выглядит разумно — верхний ценовой сегмент, но у нас и продукт ого-го.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-56.png\" width=\"1070\" height=\"552\" alt=\"\" \/>\n<\/div>\n<p>Продавать зарядку мы будем в течение трех лет, а дальше посмотрим — либо прекратим, либо выпустим новую версию. Поэтому все прогнозы и расчеты будем вести исходя из жизненного цикла продукта в 36 месяцев.<\/p>\n<p>Теперь у нас есть ценность: объем продаж и цена. Можно посчитать стоимость задержки и life-cycle profit.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-57.png\" width=\"1818\" height=\"842\" alt=\"\" \/>\n<\/div>\n<p>Основа для фреймворка готова.<\/p>\n<h3>Проверяем наши решения<\/h3>\n<p>Дальше просто: когда у нас появляется некоторая инициатива — мы смотрим на фреймворк и меняем значения в некоторых ячейках. Фиксируем изменения и делаем вывод — если life-cycle profit стал выше, то инициатива стоящая и нужно ее внедрять. Если нет — то нет.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-58.png\" width=\"1740\" height=\"1090\" alt=\"\" \/>\n<\/div>\n<p>Поиграть с цифрами можно, сделав копию моей таблицы: <a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/1mKWzrGmZW8DzepJd6QN8yXwMJhiZxoK3GUB6Zl9cbAc\/edit?usp=sharing\">https:\/\/docs.google.com\/spreadsheets\/d\/1mKWzrGmZW8DzepJd6QN8yXwMJhiZxoK3GUB6Zl9cbAc\/edit?usp=sharing<\/a><\/p>\n",
            "date_published": "2024-05-24T19:54:47+05:00",
            "date_modified": "2024-05-30T22:56:25+05:00",
            "tags": [
                "pdflow",
                "post",
                "Дон Рейнертсен",
                "Создание продукта",
                "экономика"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Fri, 24 May 2024 19:54:47 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "128048",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "127990",
            "url": "https:\/\/artemushanov.ru\/?go=all\/primenenie-ekonomicheskogo-freymvorka-reynertsena-video\/",
            "title": "The Principles of Product Development Flow, пост 5 — применение экономического фреймворка (видео)",
            "content_html": "<p class=\"foot\">🔬 Это пост с разбором очередной части книги Дона Рейнертсена <i>The Principles of Product Development Flow<\/i>. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу <a href=\"https:\/\/artemushanov.ru\/?go=tags\/pd-flow\/\">pdflow<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-3.png\" width=\"338\" height=\"500\" alt=\"\" \/>\n<\/div>\n<p>Записал разбор экономического фреймворка Рейнертсена на кейсах. Показываю, как правильно оценивать продуктовые решения с точки зрения экономики.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/qT2WeaW-QxY?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<p>\n00:00 Вступление<br \/>\n01:07 Как устроена табличка<br \/>\n08:37 Кейс первый: вводим СОК, сокращаем возвраты<br \/>\n11:28 Кейс второй: сертифицируем, чтобы увеличить продажи<br \/>\n13:18 Кейс третий: заменим кабель на более дешевый<br \/>\n16:04 Кейс четвертый: китайский завод<br \/>\n17:34 Кейс пятый: добавить кабель лайтнинг<br \/>\n19:05 Заключение<br \/>\n<\/p>\n<\/div>\n<p>upd. залил на vk<\/p>\n<iframe src=\"https:\/\/vk.com\/video_ext.php?oid=2131309&id=456239143\" width=\"426\" height=\"240\" allow=\"autoplay; encrypted-media; fullscreen; picture-in-picture; screen-wake-lock;\" frameborder=\"0\" allowfullscreen><\/iframe>\n<p>и рутуб:<\/p>\n<iframe width=\"720\" height=\"405\" src=\"https:\/\/rutube.ru\/play\/embed\/e16f741095cc88e2bb8f48da81447c42\/?p=IRutXlp5Z717Z-LdbygGcQ\" frameBorder=\"0\" allow=\"clipboard-write; autoplay\" webkitAllowFullScreen mozallowfullscreen allowFullScreen><\/iframe>\n<p>Принципы, относящиеся к экономическому фреймворку, я разбирал во <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-2\/\">втором<\/a> и <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/\">третьем<\/a> постах о книге.<\/p>\n<p>Поиграть с цифрами можно тут: <a href=\"https:\/\/docs.google.com\/spreadsheets\/d\/1mKWzrGmZW8DzepJd6QN8yXwMJhiZxoK3GUB6Zl9cbAc\/edit?usp=sharing\">https:\/\/docs.google.com\/spreadsheets\/d\/1mKWzrGmZW8DzepJd6QN8yXwMJhiZxoK3GUB6Zl9cbAc\/edit?usp=sharing<\/a><\/p>\n",
            "date_published": "2024-05-18T10:26:33+05:00",
            "date_modified": "2024-10-26T22:09:11+05:00",
            "tags": [
                "pdflow",
                "post",
                "Дон Рейнертсен",
                "моделирование",
                "Создание продукта",
                "экономика"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Sat, 18 May 2024 10:26:33 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "127990",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "127937",
            "url": "https:\/\/artemushanov.ru\/?go=all\/chto-takoe-ocheredi\/",
            "title": "The Principles of Product Development Flow, пост 4 — что такое «очереди»",
            "content_html": "<p class=\"foot\">🔬 Это пост с разбором очередной части книги Дона Рейнертсена <i>The Principles of Product Development Flow<\/i>. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу <a href=\"https:\/\/artemushanov.ru\/?go=tags\/pd-flow\/\">pdflow<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-3.png\" width=\"338\" height=\"500\" alt=\"\" \/>\n<\/div>\n<p>В предыдущей части про <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/\">экономический фреймворк<\/a> стало понятно, что время цикла — важная метрика с точки зрения экономики разработки продукта.<\/p>\n<p class=\"loud\">Дешевые способы уменьшить время цикла разработки увеличивают прибыль на жизненном цикле продукта.<\/p>\n<p>Один из таких способов — устранение периодов неактивности, когда над РП никто не работает и он висит в ожидании. Такие периоды называются очередями, и сегодня мы разберемся, что они такое.<\/p>\n<p><img src=\"https:\/\/artemushanov.ru\/pictures\/chto-takoe-ocheredi-1.png\" width=75% height=75%><\/p>\n<p class=\"foot\">© Страдающее Средневековье<\/p>\n<h3>Зачем рассматривать очереди<\/h3>\n<p>Рейнертсен считает, что очереди — одна из главных причин задержек в продуктовой разработке, а работать с ними мало кто умеет.<\/p>\n<p>Вот перечень проблем, которые вызывают очереди:<\/p>\n<ul>\n<li>Увеличение цикла разработки: чем длиннее очередь — тем дольше рабочий продукт будет ждать, пока за него возьмутся. Если мы знаем про очереди, мы можем придумать, как спрогнозировать и посчитать потери от ожидания.<\/li>\n<li>Рост рисков: этапы обработки рабочих продуктов разделены длительным временем ожидания, поэтому растут риски. Чем дольше мы ждем — тем выше вероятность, что могут произойти нежелательные изменения на рынке, у конкурентов или в используемых технологиях.<\/li>\n<li>Увеличение вариабельности: когда мы сильно нагружаем наши мощности по разработке, сильно растет вариабельность. Подробнее — в следующих постах.<\/li>\n<li>Увеличение накладных расходов: чем больше РП сидит в очередях — тем длиннее очереди, больше встреч и отчетов.<\/li>\n<li>Снижение качества: из-за очередей мы получаем фидбек о сделанной работе позже. Если программист начал писать код исходя из неверных предпосылок и получил фидбек на следующий день — можно быстро откатиться и исправить. Если фидбек придет только через неделю, то придется выкинуть результаты работы за неделю.<\/li>\n<li>Снижение мотивации: нет необходимости торопиться и пилить дизайны для приложения за день или два, если продакт сможет посмотреть их только через неделю.<\/li>\n<\/ul>\n<p>Просто понимание того, что очереди — есть, и их можно обнаружить, уже дает возможность находить и устранять очевидные заторы в работе какими-то интуитивно понятными методами.<\/p>\n<p>Коротко я вопроса очередей касался в <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#queuesblindness\">первом<\/a> посте про книгу. Там была такая иллюстрация:<\/p>\n<div style=\"border-radius: 25px; border:1px solid #DCDCDC;padding:20px;margin:20px;\"><p class=\"foot\">🟢 — работа над РП<\/p>\n<p class=\"foot\">🔴 — ожидание в очереди<\/p>\n<p>Ситуация у нас такая:<br \/>\n🟢🟢🔴🔴🔴🔴🔴🔴🟢🟢🔴🔴🔴🔴🔴🔴🔴🟢🟢<\/p>\n<p>То есть над РП работают два дня, потом он шесть дней ждет, потом еще два дня в работе, еще семь дней ждет, и наконец финальные два дня в работе перед выпуском. Итого цикл 19 дней, чистое время работы над РП 6 дней.<\/p>\n<\/div><p>Для ускорения разработки нужно уменьшить время цикла, т. е. завершить работы над рабочим продуктом быстрее, чем за 19 дней. Как это сделать? Ответ: сокращать «красные» этапы ожидания, когда РП висит в очереди на обработку; сокращение «зеленых» этапов сложнее и даст меньший эффект.<\/p>\n<p>Чтобы сократить этапы ожидания, нужно их для начала обнаружить, а для этого нужна правильная «оптика» и понимание, куда смотреть. Подходящий инструментарий может предложить раздел тервера под названием «теория очередей».<\/p>\n<h3>Теория очередей<\/h3>\n<p>Теория появилась в начале 20 века как практический метод решить задачу Копенгагенской телефонной компании: требовалось понять, сколько телефонных линий требуется для обслуживания какого-то количества абонентов. Задача на тот момент была нетривиальной: звонки поступали в случайном порядке и спрогнозировать их было невозможно, как и длительность каждого конкретного разговора.<\/p>\n<p>Датский инженер по фамилии Эрланг разработал матмодели для формализации этих проблем, что помогло лучше прогнозировать трафик, оптимизировать количество операторов, снизить время ожидания на коммутацию — в общем, оптимизировать затраты, добившись при этом достаточного уровня сервиса.<\/p>\n<h3>Основные понятия<\/h3>\n<p class=\"note\">Термины и проч. по теории очередей — <a href=\"https:\/\/staff.um.edu.mt\/jskl1\/simweb\/intro.htm\">https:\/\/staff.um.edu.mt\/jskl1\/simweb\/intro.htm<\/a><\/p>\n<p><i>Процесс прибытия<\/i> (Arrival Process): паттерн, по которому в очередь попадают новые объекты. Он описывает, как объекты (например, телефонные звонки) поступают в систему. Может быть случайным или детерминированным.<br \/>\n<i>Механизм обслуживания<\/i> (Service Mechanism): описывает, как обслуживаются объекты. Это может зависеть от таких факторов, как количество серверов (операторов), способ определения приоритетности задач и время, необходимое для обслуживания задачи (длительность звонка).<br \/>\n<i>Сервер<\/i> (Server): ресурс, который осуществляет работу над объектами из очереди; в нашем случае — оператор, который коммутирует звонки<br \/>\n<i>Дисциплина очереди<\/i> (Queue Discipline): означает порядок, в котором обслуживаются объекты. Распространены такие дисциплины, как «первым пришел — первым ушел» (FIFO), «последним пришел — первым ушел» (LIFO) и обслуживание на основе приоритетов.<br \/>\n<i>Емкость<\/i> (Capacity): количество объектов (например, абонентов), которые система может обслуживать одновременно.<br \/>\n<i>Длина очереди<\/i> (Queue Length): количество объектов, ожидающих в очереди.<\/p>\n<p>Два важнейших показателя для очередей — <b>заполняемость<\/b> и <b>время цикла<\/b>. Зная их, можно измерять:<\/p>\n<ul>\n<li>количество РП в очереди, количество РП в сервисе, общее количество в системе;<\/li>\n<li>время, проведенное РП в очереди, в сервисе, в системе в целом.<\/li>\n<\/ul>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/Mm1_queue.png\" width=\"292\" height=\"119\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Лямбда — это процесс прибытия, Мю — механизм обслуживания<\/div>\n<\/div>\n<p>На иллюстрации — тип очереди <tt>M\/M\/1\/∞<\/tt> в <a href=\"https:\/\/en.wikipedia.org\/wiki\/Kendall%27s_notation\">нотации Кендалла<\/a>, именно с него Рейнертсен предлагает начать. В нотации элементы означают, в порядке очереди: «М» — тип процесса прибытия, «М» — тип механизма обслуживания, «1» — количество серверов, «∞» — максимальный размер очереди. «М» — значит «<a href=\"https:\/\/ru.wikipedia.org\/wiki\/%D0%9C%D0%B0%D1%80%D0%BA%D0%BE%D0%B2%D1%81%D0%BA%D0%B8%D0%B9_%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81\">Марковский процесс<\/a>», и он в нашем примере относится и к прибытию, и к сервису. Это означает, что в прибытии время между поступлениями распределено экспоненциально (меньший интервал между поступлениями более вероятен, чем больший), при этом следующий интервал прибытия не зависит от любых предыдущих. Для сервиса\/обслуживания то же самое: длительность сервиса разная для каждого РП, на временном ряду длительности распределяются экспоненицально, длительность каждого следующего сервиса не зависит от предыдущих.<br \/>\nЕсли по простому описать этот тип очереди, получится примерно следующее: люди приходят на оформление визы независимо друг от друга и со случайными интервалами, встают в очередь в единственное окно, обслуживание каждого человека занимает примерно 15 минут, но иногда может и 30, а может и 5.<\/p>\n<h3>На практике<\/h3>\n<p>Если заземлять все вышеописанное на реалии продуктовой софтверной разработки, то элементами очереди могут быть любые промежуточные рабочие продукты: дизайн-макеты, требования, юзер-стори (или другие элементы бэклога), реализованные фичи, документация.<\/p>\n<p>Серверами могут быть: арт-директор, обозревающий дизайн-макеты; тимлид, анализирующий требования или юзер-стори; продакт, превращающий инсайты в спеки. Процесс прибытия у нас зависит от предыдущего звена: когда дизайнер нарисует макет, или инженер по требованиям разработает требования, или ПМ напишет юзер-стори.<br \/>\nПолучается несколько последовательных очередей, выход из одной становится входом в другую — про это тоже будет в книге.<\/p>\n<p>Дисциплина очереди в разработке обычно задается приоритетом, а механизм обслуживания зависит от типа задачи и команды.<\/p>\n<p>Принципы начнем рассматривать в следующих постах.<\/p>\n",
            "date_published": "2024-05-14T18:22:21+05:00",
            "date_modified": "2024-07-10T05:53:46+05:00",
            "tags": [
                "pdflow",
                "post",
                "Дон Рейнертсен",
                "менеджмент",
                "очереди"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Tue, 14 May 2024 18:22:21 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "127937",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "122381",
            "url": "https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/",
            "title": "The Principles of Product Development Flow, пост 3 — снова экономический фреймворк",
            "content_html": "<p class=\"foot\">🔬 Это пост с разбором очередной части книги Дона Рейнертсена <i>The Principles of Product Development Flow<\/i>. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу <a href=\"https:\/\/artemushanov.ru\/?go=tags\/pd-flow\/\">pdflow<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-3.png\" width=\"338\" height=\"500\" alt=\"\" \/>\n<\/div>\n<p>Часть <b>The Nature of Our Decisions<\/b>.<\/p>\n<p>В предыдущей части мы рассмотрели пять основных принципов для формирования экономического фреймворка:<\/p>\n<ol start=\"1\">\n<li>Все измеряем: мы должны понимать базовую экономику продукта — сколько мы тратим на его разработку, сколько мы будем зарабатывать когда продукт выйдет, когда мы планируем выпуск. С помощью этой базовой экономики мы должны уметь посчитать, во что нам обойдется то или иное решение в процессе разработки продукта. Считать мы это должны с помощью переменной «влияние на прибыль в течение ЖЦ продукта».<\/li>\n<li>Нельзя просто поменять одну величину: базовая экономика продукта строится на нескольких взаимосвязанных факторах, и изменение в одном факторе в какую-то сторону вызывает изменение в остальных. Факторы следующие: стоимость продукта в производстве (косты), прогнозируемая выручка за ЖЦ продукта, затраты на разработку продукта, длительность цикла от старта разработки продукта до выпуска, риски.<\/li>\n<li>Обязательно считать стоимость задержки: построив экономическую модель, мы должны тут же посчитать значение переменной «стоимость задержки (выпуска продукта)». Зная эту переменную, мы можем легко считать, во что нам обходится любая задержка выпуска продукта. Вычисляем планируемую выручку от продажи продукта в удобную единицу времени (неделю, месяц и т. д.), умножаем на прогнозируемую задержку — понимаем, сколько денег на этом теряем.<\/li>\n<li>Добавленная стоимость отражается в экономике продукта: добавленную стоимость\/ценность и потери (waste) оцениваем так же, как остальные переменные, следующие из экономического фреймворка. Если мы каким-то действием увеличили прогнозируемую прибыль на ЖЦ продукта, то мы добавили ценности; если нет — мы понесли потери.<\/li>\n<li>Принцип бездействия: отслеживаем не производительность рабочих станций в момент выполнения работы, а состояния рабочих продуктов. Больше всего экономике продукта вредят не неэффективные инженеры, а зависшие в очередях рабочие продукты.<\/li>\n<\/ol>\n<p>Теперь мы посмотрим на то, какие решения нам нужно с его помощью принимать. Суть этих решений диктует, какую систему поддержки принятия решений следует разработать.<\/p>\n<p><a name=\"e6\"><\/a><\/p>\n<h3>E6: The U-Curve Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e6\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Рейнертсен утверждает, что «Important trade-offs are likely to have U-curve optimizations » — то есть проблемы, которые нам нужно разрешать с помощью экономического фреймворка, после построения графика выглядят как U-образные кривые.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-34.png\" width=\"936\" height=\"812\" alt=\"\" \/>\n<\/div>\n<p>Из этого два следствия:<\/p>\n<ul>\n<li>во-первых, без квантификации найти верное решение будет очень сложно<\/li>\n<li>во-вторых — такая модель прощает неточности, нужно попасть в довольно обширный диапазон значений (выделено красным на графике). А значит, и исходные данные могут быть приблизительными.<\/li>\n<\/ul>\n<p><a name=\"e7\"><\/a><\/p>\n<h3>E7: The Imperfection Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e7\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Задача экономического фреймворка — помочь нам принимать более качественные решения, чем если бы мы руководствовались интуицией. Фреймворк не должен быть идеально точным, он должен быть <i>достаточно хорошим<\/i> — как минимум, лучше интуитивного метода.<\/p>\n<p>Хороший поинт автора: узнав, что экономический фреймворк не дает супер-высокой точности, менеджеры склонны отказаться от его внедрения и продолжать использовать интуитивные методы — как будто это сильнее убережет их от ошибок.<\/p>\n<p>Вот пример из практики Рейнертсена, который показывает нелепость такого отношения: интуитивные оценки стоимости задержки продукта (Cost of Delay) могут различаться в 50 раз внутри команды; это значит, что Петров считает, что неделя задержки продукта стоит компании 1000 долларов, а Иванов — 50000 долларов.<\/p>\n<p>После введения фреймворка и подсчетов вилка сокращается до двухкратной разницы — т. е. становится точнее в 25 раз.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-35.png\" width=\"1524\" height=\"668\" alt=\"\" \/>\n<\/div>\n<p><a name=\"e8\"><\/a><\/p>\n<h3>E8: The Principle of Small Decisions  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e8\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Нужно принимать не только большие, но и малые решения. Более того — в книге утверждается, что в куче маленьких решений и кроется львиная доля возможных улучшений.<\/p>\n<p>Рейнертсен ругает менеджеров, чересчур всерьез воспринимающих принцип Парето. По его мнению, 20% решений, пользующихся пристальным вниманием управленцев, вполне могут таить в себе меньше возможностей, чем задвинутые за шкаф 80% остальных решений:<\/p>\n<blockquote>\n<p>“Pareto Paradox: There is usually more actual opportunity in the undermanaged 80 percent than the overmanaged 20 percent.”<\/p>\n<\/blockquote>\n<p>Выхлоп от каждого маленького решения, разумеется, меньше, чем от крупного, и маленькими решениями нужно правильно управлять, чтобы затраты на их принятие не стали запредельными — об этом дальше.<\/p>\n<p><a name=\"e9\"><\/a><\/p>\n<h3>E9: The Principle of Continuous Economic Trade-offs  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e9\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Нельзя все спланировать заранее, принять все важные экономические решения в начале разработки, и потом просто сидеть и разрабатывать. Необходимость принимать решения о выборе из нескольких альтернатив будет возникать непредсказуемо в течение всей работы над продуктом — это нормально и этого не избежать.<\/p>\n<p>Здесь очередное отличие от производства, где все решения приняты заранее, перед началом работы над партией, и любое отклонение от плана навредит — потому что план оптимален.<\/p>\n<p>Применять подобный подход — с детальным поминутным планированием всех операций, максимизацией загрузки мощностей и сравнением факта с планом — в продуктовой разработке нельзя.<\/p>\n<p>В продуктовой разработке у нас каждый рабочий такт появляется новая информация — как с рынка, так и изнутри процесса, и эту информацию лучше бы учесть.<\/p>\n<p><b>Пример<\/b>: мы оценили, что новая фича нужна половине наших клиентов и ее разработка займет две недели. Делаем? — Делаем.<br \/>\nНачав проектирование, мы поняли, что фича важна лишь одному проценту клиентов и потребует двух месяцев разработки. Экономическая эффективность фичи уменьшилась в двести раз (!), нужно срочно менять план.<\/p>\n<p><a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-2\/#e1\">Принцип E1<\/a> говорил нам, что мы тут собрались ради принятия верных экономических решений — и для этого фреймворк должен учесть полученную нами информацию и, если нужно, измениться для лучшего отражения реальности.<\/p>\n<p>Следовать устаревшему плану в ситуации, когда все регулярно меняется — плохая стратегия.<\/p>\n<p><a name=\"e10\"><\/a><\/p>\n<h3>E10: The First Perishability Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e10\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Нужно уметь быстро <a href=\"https:\/\/artemushanov.ru\/?go=all\/stepping-stones-i-osoznanie-vozmozhnostey-odo-1\/\">распознавать возможности<\/a> и быстро принимать решения. Возможности и риски возникают постоянно — об этом предыдущий принцип. Ценность от использования возможности со временем будет снижаться, препятствия вследствие возникновения рисков будут расти, и нужно успеть принять решение до его полного обесценивания.<\/p>\n<p>Нужен алгоритм идентификации, оценки и процедуры принятия и согласования таких решений за минимально возможное время.<\/p>\n<p>В девятой главе Рейнертсен предложит нам использовать стратегию децентрализованного контроля: нужно делегировать право принимать решение людям на том уровне, на котором эта возможность была обнаружена и может быть использована. Тогда менеджеры не будут узким местом для принятия множества маленьких решений из принципа E8 и не станут еще одним источником очередей. См. пример про самолеты ниже.<\/p>\n<p><a name=\"e11\"><\/a><\/p>\n<h3>E11: The Subdivision Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e11\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Плохие решения или опции можно превратить в хорошие. Плохое решение можно разделить на составляющие, оценить каждую составляющую с точки зрения улучшения общей экономики продукта, и использовать только те составляющие, которые дают хороший результат.<\/p>\n<p>Рейнертсен приводит такой пример: одна компания, разрабатывающая полупроводники, использовала внешнего подрядчика для предоставления важной интеллектуальной собственности (ИС) для своего проекта. Ресурсов на внутреннюю разработку у компании не было.<br \/>\nВ то же время использование внешней ИС — серьезный риск для проекта.<br \/>\nКомпания отрядила одного инженера для мониторинга работы подрядчика. Если бы в какой-то момент потребовалось затащить разработку ИС внутрь компании — это удалось бы сделать довольно быстро и не с нуля, т. к. инженер был бы в курсе хода работ и достигнутых подрядчиком результатов.<\/p>\n<p>То есть, компания использовала дешевый способ получить <i>часть результата<\/i> от сложной и дорогой деятельности. (я этот пример до конца не понимаю, и не уверен, что верно перевел, но другого у меня нет).<\/p>\n<p>Дальше у нас глава <b>Our Control Strategy<\/b> — про то, как лучше всего работать с принимаемыми решениями. Из предыдущей главы мы помним, что решений нужно принимать много, их нужно принимать быстро и нерегулярно, и для этого нужно придумать правила и ограничения.<\/p>\n<p><a name=\"e12\"><\/a><\/p>\n<h3>E12: The Principle of Early Harvesting  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e12\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Рейнертсен утверждает, что дешевые способы ускорить разработку продукта обычно встречаются на ранних стадиях — и нужно научить организацию эти решения находить и использовать.<\/p>\n<p>Пример: в одной из организаций инженер мог без согласования принять решение, экономившее неделю разработки, если затраты на это решение не превышали 500$, и не более четырех недель за раз; лимит у менеджера был 1000$ и 8 недель, у директора — 5000$ и 16 недель. После достижения лимита сотрудник мог пойти к своему менеджеру, пройти ревью и получить «добро» на дальнейшие улучшения.<\/p>\n<p>Таким образом компания смогла находить много простых способов сократить время цикла без сложных процедур согласования.<\/p>\n<p>Два ключевых слова тут «много» и «простых».<\/p>\n<p><a name=\"e13\"><\/a><\/p>\n<h3>E13: The First Decision Rule Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e13\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Сильно похоже на предыдущий принцип. Если мы принимаем за факт необходимость принимать много небольших решений на нижних уровнях иерархии компании, то нужно передать полномочия и ответственность за решения на эти нижние уровни — т. е. децентрализовать процесс принятия решений. При этом нужно сохранять контроль за экономикой продукта, не вмешиваясь в каждое конкретное решение.<\/p>\n<p>Для этого Рейнертсен вводит понятие <i>economic decision rules<\/i>; задачи этих правил:<\/p>\n<ul>\n<li>Привести к общему знаменателю все экономические решения и выборы в рамках проекта<\/li>\n<li>Обеспечить оптимальность этих решений на системном уровне<\/li>\n<li>Обеспечить передачу контроля на нижние уровни без  существенного повышения рисков<\/li>\n<li>Оптимизировать процесс принятия решений.<\/li>\n<\/ul>\n<p>Выполнение этих правил позволяет сделать принятие решений «дешевле» и быстрее.<\/p>\n<p><b>Пример<\/b> (был в первом посте): когда Боинг разрабатывал свой 777-й, руководители программы распределили вес и стоимость готового самолета на все подсистемы в начале проекта — к примеру, на крыло приходилось 60 тонн веса и 1,5 млрд стоимости. Распределение, само собой, было неидеальным — одной подсистеме не хватало веса, другой — бюджета, и командам, над ними работавшим, приходилось принимать экономически странные в рамках проекта решения. Например, у одной команды был избыток бюджета и недостаток веса, и она тратила 5000 долларов на «урезание» лишних пары кило веса (кг = 2500$); другая команда, у которой денег было впритык, но был хороший запас по весу, даже не рассматривала возможность урезать несколько килограмм веса по 50 долларов каждый (кг = 50$).<\/p>\n<p>На уровне системы (самолета) каждое такое решение было субоптимальным: первая команда тратила слишком много денег на слабые улучшения, вторая — не использовала дешевую возможность улучшить подсистему.<\/p>\n<p>Как можно было оптимизировать решения? Первый и очевидный способ — назначить отдельного человека проверять и уторговывать все решения. Это создало бы очереди из таких решений и разработка всерьез затянулась бы.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/the-principles-of-product-development-flow-post-3-snova-ekonomic.png\" width=\"1260\" height=\"1102\" alt=\"\" \/>\n<\/div>\n<p>Вместо этого Боинг разработал правило, которое работало на уровне всей системы: любой инженер или проектировщик мог увеличить стоимость подсистемы или компонента на 300 долларов, если он при этом избавится от фунта веса — путем другого дизайна компонента, путем замены на более легкий аналог, и т. п.<\/p>\n<p>И все полетело — пять тысяч инженеров получили возможность принимать решения без согласования при выполнении вышеописанных условий.<\/p>\n<p>Руководство разработки не стало узким местом — оно устранилось из процесса принятия самих решений, сохранив при этом экономическую прозрачность и контроль надо общим бюджетом системы.<\/p>\n<p><a name=\"e14\"><\/a><\/p>\n<h3>E14: The First Market Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e14\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Менеджеры пользуются ресурсами компании для разработки продуктов без оглядки на стоимость этих ресурсов. Те, кто понаглее, аккумулируют избыточные ресурсы, потому что это им ничего не стоит — ну это же наша компания, чо вы.<\/p>\n<p>Большинство компаний распределяют ресурсы не на основе детального анализа (его почти нигде нет), а централизованно, сообразно интуитивному пониманию. Менеджеры, отвечающие за разработку, никак не ограничиваются в своем желании запасти немного избыточных ресурсов — вдруг понадобятся.<\/p>\n<p>Централизованное распределение ресурсов, подобно экономике СССР, во-первых сильно ограничивает возможность оптимизировать затраты, во-вторых — создает очереди.<\/p>\n<p>Нужно децентрализовать и позволить рынку порешать: пусть менеджеры проектов\/продуктов сами решают, какие ресурсы за какую стоимость использовать.<\/p>\n<p><b>Пример<\/b>: менеджер в компании решил поставить под контроль спрос на отдел компьютерного проектирования. Он решил предоставлять два уровня сервиса: стандартный и премиум. Стандартный стоил как обычно, премиумный стоил на 25% дороже и давал результат в течение 48 часов. Наценка использовалась для обеспечения премиумного сервиса ресурсами.<\/p>\n<p>Такой подход лучше централизованного, потому что потребители этих услуг — проектные менеджеры, — сами решают, какой уровень сервиса им необходим, без вовлечения руководства и с пониманием возврата инвестиций. Ну, если они экономическим фреймворком пользуются.<\/p>\n<p>Как именно менеджеры «платят» за использование отдела компьютерного моделирования — Рейнертсен не уточняет. Возможно, речь идет о прямом распоряжении бюджетом проекта (см. <a href=\"https:\/\/alex-turkhanov.medium.com\/как-понятие-проекта-раздулось-до-полной-потери-смысла-и-что-с-этим-делать-c7c040912edc#:~:text=Проект%20—%20это%20временный%20бизнес%2C%20ограниченный%20от%20регулярного%3B%20ресурсы%20под%20ведение%20которого%20привлекаются%2C%20мобилизуются%20на%20время%20реализации%20проекта%2E\">пост А. Турханова<\/a> про вырождение понятия «проект»), возможно — на бумаге или за фантики.<\/p>\n<p><a name=\"e15\"><\/a><\/p>\n<h3>E15: The Principle of Optimum Decision Timing  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e15\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>В принципе E9 утверждалось, что мы не можем принять все важные решения до начала работы над продуктом. Что насчет обратного подхода — откладывать любое решение до последнего момента? На вопрос отвечает экономический фреймворк.<\/p>\n<p>Рейнертсен сравнивает подход к таймингу решений с ценовой политикой авиакомпаний. Если билеты продаются недостаточно активно, софт автоматически снижает цену. По мере приближения даты полета билеты дорожают — чтобы стать максимально дорогими в последние дни.<\/p>\n<p>Некоторые продуктовые решения нужно принять максимально рано — они определят важные архитектурные ограничения и свойства продукта. Например, форма модели кроссовка: от нее зависят материалы, раскрой, детейлинг, а уже от них зависит, какие потребуются станки и специалисты.<\/p>\n<p>Некоторые решения можно откладывать в ожидании оптимального момента; например, цвет деталей кроссовка можно отложить, пока не будет готова и настроена линия — поменять цвет на настроенной линии мы можем довольно быстро, а вот слишком ранний выбор ценности нам не дает — можем не попасть в модные тренды.<\/p>\n<p>Общее правило звучит так: решение нужно принимать тогда, когда дальнейшее ожидание перестает положительно влиять на экономику продукта.<\/p>\n<p>Часть <b>Some Basic Economic Concepts<\/b>. В этой части рассматриваются несколько основных экономических принципов, которые помогают принимать правильные экономические решения.<\/p>\n<p><a name=\"e16\"><\/a><\/p>\n<h3>E16: The Principle of Marginal Economics  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e16\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Чтобы определить, как именно продуктовое решение (новая фича, новый вариант продукта и т. п.) повлияет на экономику продукта, нужно использовать маржинальные значения ценности и костов, а не суммарные по продукту.<\/p>\n<p>Это что-то вроде юнит-экономики: прирост ценности продукта (выраженный в объеме продаж или цене) должен быть выше, чем прирост затрат на реализацию фичи. Изолировав в отдельное вычисление рост ценности и рост затрат, мы получаем их маржинальные значения. Так мы можем сравнивать между собой разные потенциальные фичи: у какой лучше маржинальная прибыль, ту и надо брать в работу.<\/p>\n<p><b>Пример<\/b>: проект, в котором две фичи, завершен на 80%. Одна фича готова, вторая отстала на 10%. Какой фичей должна заняться команда?<br \/>\nНеправильный ответ: над отстающей фичей, потому что ТАКОВ БЫЛ ПЛАН.<br \/>\nПравильный ответ: над той фичей, у которой маржинальная прибыль выше. Нередко это уже готовая фича — ее можно улучшить.<\/p>\n<p>Еще <b>пример<\/b>: фичу сделали на 95% довольно быстро, но оставшиеся 5% добить будет немного сложнее. Стоит ли команде доделывать фичу до победных ста процентов или сдать как есть?<br \/>\nПравильный ответ: посчитать эти 5% как отдельную фичу со своей маржинальной экономикой и принять решение.<\/p>\n<p><a name=\"e17\"><\/a><\/p>\n<h3>E17: The Sunk Cost Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e17\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Простой и понятный принцип: уже потраченные деньги в новых трейд-оффах не учитываем. В предыдущем примере именно поэтому предлагается считать пятипроцентный остаток фичи отдельно.<\/p>\n<p><b>Пример<\/b>: команда работает над проектом со средней прибыльностью, он выполнен на 90%. Появляется возможность начать новый проект с высокой прибыльностью. Что нужно выбрать: доделать первый проект или бросить его и начать второй, высокоприбыльный?<\/p>\n<p>Нужно посчитать маржинальную прибыль по каждому из проектов, при этом в первом проекте в костах нужно учесть только оставшееся время\/усилия на реализацию, а не потраченное + оставшееся. В таком свете высокоприбыльный проект вполне может таковым и не оказаться — в маржинальном выражении.<\/p>\n<p>Этот же принцип неплохо освещен в психологии, в т.ч. Канеманом — см. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Sunk_cost\">https:\/\/en.wikipedia.org\/wiki\/Sunk_cost<\/a><\/p>\n<p><a name=\"e18\"><\/a><\/p>\n<h3>E18: The Principle of Buying Information  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e18\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Информация снижает неопределенность, что может увеличить экономическую ценность продукта. Платить за такую информацию нужно столько, чтобы маржинальная экономическая ценность превышала маржинальные затраты на получение этой информации.<\/p>\n<p><b>Пример<\/b>: лотерейный билет с возможностью выиграть миллион долларов с шансом «один на миллион» не стоит покупать дороже, чем за доллар.<\/p>\n<p>Иногда неуспешный продукт сам по себе является ценной информацией: операционка Windows 1.0 провалилась, но обеспечила микрософт ценными инсайтами, которые позволили потом завоевать рынок.<\/p>\n<p>Другой <b>пример<\/b>. Клинические испытания лекарств <a href=\"https:\/\/ru.wikipedia.org\/wiki\/Клиническое_исследование#Фазы_клинических_исследований\">делятся на фазы<\/a>, ранние фазы более простые и дешевые; если лекарство проваливается на ранних фазах — можно не тратиться на последующие, более дорогие фазы. Так сначала информация покупается подешевле, потом, если все ок — подороже, и так далее. Экономию от невыхода на следующие фазы подсчитать несложно.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-36.png\" width=\"1178\" height=\"437\" alt=\"\" \/>\n<\/div>\n<p>Рейнертсен утверждает, что существует экономически оптимальная последовательность действий по снижению риска. Низкозатратные мероприятия, устраняющие большой риск, должны проводиться раньше высокозатратных мероприятий, устраняющих очень малый риск.<\/p>\n<p>Часть <b>Debunking Some Popular Fallacies<\/b>.<\/p>\n<p><a name=\"e19\"><\/a><\/p>\n<h3>E19: The Insurance Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e19\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Платить за страховку нужно не больше, чем потенциальные потери от наступления страхового случая. В частности, Рейнертсен сдержанно ругает подход set-based concurrent engineering (SBCE), подразумевающий разработку нескольких инженерных решений для каждой продуктовой подсистемы.<\/p>\n<p>Например, при разработке новой модели автомобиля при этом подходе можно не выбирать конкретный двигатель, а выбрать несколько — и продолжать разработку с этим учетом, а двигатель окончательно выбрать когда-то потом. Очевидно, что это умножает количество требуемой работы на количество решений, и претензия Рейнертсена здесь в том, что такой подход выглядит как экономически нецелесообразная подстраховка.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-37.png\" width=\"434\" height=\"414\" alt=\"\" \/>\n<\/div>\n<p>Использовать такой подход или нет — это вопрос к экономическому фреймворку. Если расходы на разработку какого-то количества параллельных решений ниже, чем потенциальная польза от снижения рисков, то все ок.<\/p>\n<p><a name=\"e20\"><\/a><\/p>\n<h3>E20: The Newsboy Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e20\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>В этом принципе рассматривается, как решение задачи продавца газет помогает взглянуть на продуктовые решения.<\/p>\n<p>Задача звучит так: продавец газет зарабатывает 50 центов на проданной газете и теряет 25 на непроданной; сколько газет ему нужно закупить для максимизации прибыли, если он не знает точный спрос?<\/p>\n<p>Поскольку заработок от продажи выше убытка от непроданной газеты, имеет смысл держать лишний запас — т. е. чтобы газет было больше, чем требует средний спрос.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-38.png\" width=\"483\" height=\"600\" alt=\"\" \/>\n<\/div>\n<p>Если посчитать функцию максимизации прибыли для указанных значений (вычислить т. н. критический фрактиль), мы увидим, что в среднем раз в три дня продавец будет распродавать весь тираж, не сумев удовлетворить спрос.<\/p>\n<p><b>Вывод<\/b>: в ситуации экономической асимметрии оптимум может быть достигнут даже при невысоком шансе на успех в каждом конкретном случае.<\/p>\n<p>Раз в три дня продавец газет недозарабатывает, но в целом он зарабатывает настолько хорошо, насколько возможно.<\/p>\n<p>Дальше Рейнертсен упоминает спикера на недавней (на момент написания книги — 2009 г.) конференции. Спикер рассказывал, что 96% продуктов неспособны поместиться в заданные экономические рамки — следовательно, нужно агрессивно фильтровать возникающие возможности и инициативы и тем самым улучшать ROI продукта.<\/p>\n<p>В разработке продукта трейд-оффы асимметричные — на вложенный доллар возврат может быть и ноль, и десять, и сто, и тысяча. При этом бывают ситуации, к примеру, в фарме, когда разработчики лекарства ставят крест на молекуле-кандидате после инвестиций в ее проверку в районе десяти тысяч долларов — при том, что возврат может составить миллиарды долларов.<\/p>\n<p>Рейнертсен предлагает венчур — браться за проработку продуктовых возможностей или инициатив с хорошим возвратом на инвестиции, даже если у них невысокая вероятность успеха.<\/p>\n<p><a name=\"e21\"><\/a><\/p>\n<h3>E21: The Show Me the Money Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/#e21\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Хотите от компании денег — говорите со стейкхолдерами на языке денег и показывайте с помощью фреймворка, что вы заботитесь и о расходной, и о доходной частях ваших решений. Будете говорить на языке денег — будете чаще и быстрее получать «добро» на ваши инициативы.<\/p>\n<p>🏁 Первая часть закончилась. Подытожим:<\/p>\n<ol start=\"1\">\n<li>Экономический фреймворк позволяет свести все прокси-переменные и трейд-оффы к одной единице измерения — влиянию на прибыль на ЖЦ продукта. Всё оцениваем с помощью этой метрики.<\/li>\n<li>Несовершенные правила принятия решений лучше, чем интуитивные догадки; с помощью правил мы можем быстро находить и обрабатывать мелкие экономические возможности, пользуясь преимуществами децентрализованного управления.<\/li>\n<li>Всегда считаем стоимость задержки — с ее помощью обнаружим и победим очереди.<\/li>\n<\/ol>\n<p>А очереди мы начнем рассматривать в следующем посте.<\/p>\n<p>upd. А вот и следующий пост: <a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-takoe-ocheredi\/\">https:\/\/artemushanov.ru\/?go=all\/chto-takoe-ocheredi\/<\/a><\/p>\n",
            "date_published": "2023-08-15T01:37:25+05:00",
            "date_modified": "2024-10-17T22:49:47+05:00",
            "tags": [
                "pdflow",
                "post",
                "Дон Рейнертсен",
                "менеджмент",
                "Создание продукта",
                "экономика"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Tue, 15 Aug 2023 01:37:25 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "122381",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "121567",
            "url": "https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-2\/",
            "title": "The Principles of Product Development Flow, пост 2 — экономический фреймворк",
            "content_html": "<p class=\"foot\">🔬 Это пост с разбором очередной части книги Дона Рейнертсена <i>The Principles of Product Development Flow<\/i>. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу <a href=\"https:\/\/artemushanov.ru\/?go=tags\/pd-flow\/\">pdflow<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/GA2UaaGBrM.png\" width=\"338\" height=\"500\" alt=\"\" \/>\n<\/div>\n<p>Книга о том, как правильно принимать управленческие решения при разработке продукта.<\/p>\n<p>Вторая часть книги посвящена экономическому взгляду на разработку продуктов:<\/p>\n<p class=\"loud\">“Our primary goal in product development is to make good economic choices.”<\/p>\n<p>Вспомним основы.<\/p>\n<p>Мы разрабатываем продукт, чтобы на нем можно было заработать. Выбор любой альтернативы на развилках — какое архитектурное решение принять, в каком порядке делать фичи, и т. д., — влияет на экономику продукта (для простоты будем рассматривать только коммерческие продукты).<\/p>\n<p>Экономика продукта складывается из двух базовых показателей: расходов и доходов. Пока мы разрабатываем продукт — мы несем расходы. Когда мы продаем продукт — мы получаем доход. Нужно, чтобы доходы в какой-то момент после начала продаж превысили расходы, иначе наш продукт неуспешен. Разница между доходами и расходами — это прибыль, ради нее все и затевается.<\/p>\n<p>Мы рассматриваем именно <i>разработку<\/i> продукта — не производство, не развитие. В книге не уточняется, что именно это за продукт, поэтому считаем, что подход универсальный и может быть одинаково полезен в разработке нового стула в лаборатории Икеи, новой модели автомобиля где-то в глубинах автоконцерна, нового вида шоколадных батончиков, или новой ERP\/CRM\/любыетрибуквы-системы.<\/p>\n<p>Экономический подход Рейнертсена в общем виде звучит так:<\/p>\n<p class=\"loud\">Любое решение во время разработки продукта должно приниматься с точки зрения его влияния на прибыль в масштабах жизненного цикла продукта.<\/p>\n<p>В первом посте я <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#:~:text=%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B8%D1%82%D1%8C%20life%2Dcycle%20profit%20%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%B0\">задавался вопросом<\/a>: почему именно прибыль, а не доход?<br \/>\nОтвет такой: доход не учитывает понесенные на всех этапах расходы, а значит — не отражает в полной мере экономическую модель продукта. Если строить анализ на основе дохода, а не прибыли, то не получится учесть расходы на разработку, невозможно посчитать точку безубыточности, учесть расходы на продажи, и т. п. — картина будет неполной.<\/p>\n<p>Точность экономического фреймворка должна превосходить интуитивные оценки — этого достаточно.<\/p>\n<p>Итак, часть вторая — <b>2. The Economic View<\/b>.<\/p>\n<p><b>Глава “The Nature of Our Economics”<\/b><br \/>\nРейнертсен строит книгу следующим образом: в каждой главе он предлагает т. н. «принципы» и бегло иллюстрирует их. Так и пойдем.<\/p>\n<p><a name=\"e1\"><\/a><\/p>\n<h3>E1: The Principle of Quantified Overall Economics  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-2\/#e1\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Первый принцип предлагает нам измерять все, что может влиять на экономику продукта, вычислять это влияние и принимать решения на основе цифр.<\/p>\n<p>Любое продуктовое изменение может влиять на доходную и расходную части: например, более ранний вывод продукта на рынок даст заработать больше за счет более раннего старта продаж, а добавление новой возможности в продукт увеличит расходы, замедлит выход, но при этом увеличит доход за счет охвата большей части аудитории.<\/p>\n<p><b>Пример<\/b>: следует ли нам пустить разработанный продукт в производство без устранения всех обнаруженных дефектов? Разработчики говорят — айда погнали, представители завода говорят — вы гоните, сперва все косяки исправьте.<\/p>\n<p>Начинаем применять экономический фреймворк.<\/p>\n<p>1) Если мы исправим косяки продукта на заводе, это будет стоить в десять раз дороже, чем в лаборатории — 20000 евро против 2000.<br \/>\n2) На заводе, в условиях производства, мы обнаружим косяки за одну неделю, а в лаборатории — за пять недель.<\/p>\n<p><tt><\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td>Исправить в лаборатории<\/td>\n<td>Пустить на завод<\/td>\n<\/tr>\n<tr>\n<td>5 недель<\/td>\n<td>1 неделя<\/td>\n<\/tr>\n<tr>\n<td>2000 евро<\/td>\n<td>20000 евро<\/td>\n<\/tr>\n<\/table>\n<p><\/tt><br \/>\nВопрос к экономическому фреймворку звучит так: стоит ли «покупать» четырехнедельное сокращение цикла за 18000 евро?<br \/>\nА ответ звучит так: если life-cycle profit impact (LCPI) от этого решения будет положительный — то стоит.<\/p>\n<p><a name=\"e2\"><\/a><\/p>\n<h3>E2: The Principle of Interconnected Variables  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-2\/#e2\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Принимая решение об изменении в продукте и измеряя его влияние на экономику, следует учитывать, что изменение затронет сразу несколько факторов. Предлагается использовать анализ чувствительности.<\/p>\n<p>Фреймворк Рейнертсена содержит следующие факторы:<\/p>\n<ul>\n<li>Product Сost — стоимость продукта в производстве (сырье, работы, логистика)<\/li>\n<li>Product Value — выручка, заработанная в течение жизни продукта; внутри сидят цена, объем продаж (зависящий от рынка) и прочее<\/li>\n<li>Development Expense — затраты на разработку продукта<\/li>\n<li>Cycle time — время на разработку продукта, от нулевой стадии до финальной<\/li>\n<li>Risk — Оценка рисков для стадии разработки продукта<\/li>\n<\/ul>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/the-principles-of-product-development-flow-post-2-ekonomicheskiy.png\" width=\"1268\" height=\"1239\" alt=\"\" \/>\n<\/div>\n<p>Эти пять факторов связаны друг с другом — изменение одного приведет, во-первых, к изменению остальных в какой-то пропорции и с каким-то вектором, во-вторых, к изменению LCPI.<\/p>\n<p>Учитывая эти изменения, можно принимать решения более взвешенно. Чего нам будет стоить уменьшение веса изделия на 1 кг? Что нам даст увеличение эффективности на 1%? Во что нам обойдется увеличение наработки на отказ еще на 1000 часов? Экономический фреймворк с правильно подобранными показателями должен давать ответы на эти вопросы.<\/p>\n<p><a name=\"e3\"><\/a><\/p>\n<h3>E3: The Principle of Quantified Cost of Delay  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-2\/#e3\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p><mark>В любой непонятной ситуации считай стоимость задержки.<\/mark><\/p>\n<p>Cost of Delay (CoD) — одна из «чувствительностей» (sensitivities) в экономическом фреймворке и важнейший концепт книги. Стоимость задержки определяет, как увеличение времени цикла (Cycle Time) повлияет на прибыль жизненного цикла (Product Value).<\/p>\n<p>Как CoD связана с основными факторами:<\/p>\n<ul>\n<li>Product Сost может вырасти из-за задержки, т. к. меняются цены на производственные ресурсы.<\/li>\n<li>Product Value снижается, т. к. продукт меньше времени проведет на рынке, может пропустить благоприятное окно для выхода на рынок и т. п.<\/li>\n<li>Development Expenses — время разработки увеличивается, увеличиваются связанные косты и появляются дополнительные риски<\/li>\n<li>Cycle time — напрямую влияет на CoD, т. к. стоимость задержки считается именно по дельте увеличения\/уменьшения времени цикла<\/li>\n<li>Risk — риски могут как увеличиться, так и уменьшиться.<\/li>\n<\/ul>\n<p>В идеале, стоимость задержки нужно считать и понимать в каждый конкретный момент времени на любой стадии разработки.<\/p>\n<p>Экономическая модель конкретного продукта может быть довольно сложной, в ней больше факторов, но логика расчета CoD примерно такая:<\/p>\n<ol start=\"1\">\n<li>Вычисляем планируемую недельную выручку от продаж продукта: умножаем ожидаемый объем продаж в неделю на цену продукта. Вместо недели можно взять любой удобный промежуток времени.<\/li>\n<li>Оцениваем время, требуемое для завершения разработки и вывода продукта на рынок.<\/li>\n<li>Вычисляем стоимость задержки — умножаем недельную выручку на количество недель задержки.<\/li>\n<\/ol>\n<p>Теперь мы можем оценивать разные компромиссы, сравнивая стоимость задержки и потенциальную выгоду от этой задержки.<\/p>\n<p class=\"note\">Методы оценки через диапазоны — из книги «<a href=\"https:\/\/books.google.ru\/books\/about\/%D0%9A%D0%B0%D0%BA_%D0%B8%D0%B7%D0%BC%D0%B5%D1%80%D0%B8%D1%82%D1%8C_%D0%B2%D1%81%D0%B5_%D1%87%D1%82%D0%BE_%D1%83.html?id=AZ-yA5PSxmMC&redir_esc=y\">Как измерить все, что угодно<\/a>»<\/p>\n<p>Поскольку нам не нужна супер-точность, считаем на тех данных, которые есть, и используем метод диапазонов; прогноза от отделов маркетинга и продаж вполне хватит для расчетов.<\/p>\n<p>Например, мы рассматриваем возможность потратить дополнительно две недели на тестирование продукта перед выводом на рынок. Считаем стоимость задержки и потенциальную выгоду от такого тестирования. Какая может быть выгода, если сравнивать со стоимостью задержки? Будет меньше возвратов по гарантии и можно сократить гарантийный бюджет; будет меньше обращений в сервисные центры, у них будет меньше загрузка, меньше расходов на персонал; клиентам можно обещать качество «выше, чем у конкурентов», продажи вырастут на 10% — и так далее. Важно, что вопрос из разряда примитивных бинарных («хорошее качество лучше, чем плохое — значит, надо тестировать») переходит в разряд экономических и приходится напрячься и посчитать, а что именно нам такое тестирование даст.<\/p>\n<p>Если заглянуть чуть дальше в книгу, мы увидим, что стоимость задержки помогает при оценке очередей — второго важнейшего понятия книги. В отличие от условных двух недель тестирования, очереди не несут никакой пользы, только вред, и стоимость задержки помогает вычислить количество этого вреда.<\/p>\n<p><b>upd.<\/b> Статья из блога Kaiten.ru про стоимость задержки — <a href=\"https:\/\/kaiten.ru\/blog\/stoimost-zadierzhiek-v-kanban\/\">https:\/\/kaiten.ru\/blog\/stoimost-zadierzhiek-v-kanban\/<\/a><\/p>\n<p><a name=\"e4\"><\/a><\/p>\n<h3>E4: The Principle of Economic Value-Added  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-2\/#e4\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Четвертый принцип утверждает, что добавленная стоимость любой деятельности должна выражаться в изменении цены, которую за продукт готов заплатить рациональный покупатель. Если внесение изменения в продукт не обеспечит повышение цены или объема продаж продукта — в общем, роста фактора Product Value, — то это действие является потерей (waste).<\/p>\n<p>Рейнертсен снова противопоставляет продуктовый и производственный подходы: в бережливом производстве проверка и тестирование продукции считаются неизбежными потерями (necessary waste), не добавляющими ценности продукту; с точки зрения экономического фреймворка это справедливо только в случае, когда тестирование не улучшает экономику продукта.<\/p>\n<p>Пример: фармацевтическая компания проводит клинические испытания всех новых продуктов. Прибавит ли что-то к ценности продукта испытание первой фазы, имеющее пятидесятипроцентную вероятность прохождения? Или это просто потери?<br \/>\nОтвет: cнизив риск с помощью испытаний, компания существенно расширяет для себя географию продаж и маркетинговые возможности — т. е. получает возможность продавать больше и чаще, чем в случае когда тестирование не было произведено. Так что — да, прибавит.<\/p>\n<p>Раз мы выразили добавленную стоимость через понятия экономического фреймворка, то не помешает сделать то же самое и с потерями.<br \/>\nПотери (waste) — это безуспешные методы оптимизации экономики продукта. То есть, какие-то активности были предприняты (= ресурсы потрачены), а экономика продукта в положительную сторону не изменилась. Их влияние тоже нужно уметь вычислять через факторы экономического фреймворка.<\/p>\n<p>Пример: у нас есть отдел компьютерного проектирования; что лучше — использовать его с загрузкой в 80% и двухнедельными очередями, или с 90-процентной загрузкой и четырёхнедельными очередями? Нужно посчитать экономические потери от недозагрузки и экономические потери от очередей, сравнить их между собой и выбрать нужный вариант.<\/p>\n<p><a name=\"e5\"><\/a><\/p>\n<h3>E5: The Inactivity Principle  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-2\/#e5\">&nbsp<font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Хороший и правильный принцип — «Watch  the work product, not the worker».<\/p>\n<p>Цитата:<\/p>\n<p class=\"loud\">In product development, our greatest waste is not unproductive engineers, but work products sitting idle in process queues<\/p>\n<p>Давайте сначала разберемся, что такое work product\/work item.<\/p>\n<p>Под «рабочим продуктом» мы будем понимать результат выполнения работы, выраженный физически — настолько, насколько возможно. Если у нас задача «составить родмеп на следующий год», то рабочим продуктом будет не абстрактное «составленный родмеп на 2024», а табличка в экселе с названием «2024 Roadmap for ’product name’», заполненная по определенному шаблону.<br \/>\nЕсли у нас задача «выточить заготовки для ножек» на мебельной фабрике, то рабочий продукт — выточенные ножки.<br \/>\nЕсли у нас задача — спроектировать ножки, чтобы их потом можно было выточить, то рабочий продукт — проектная документация для ножек в экселе, выполненная по определенному образцу.<\/p>\n<p>Ссылки:<\/p>\n<ul>\n<li><a href=\"http:\/\/sewiki.ru\/Категория:Рабочие_продукты\">http:\/\/sewiki.ru\/Категория:Рабочие_продукты<\/a><\/li>\n<li><a href=\"https:\/\/tenchat.ru\/media\/602562-kak-ya-stala-rezhe-bespokoitsya-chto-nichego-ne-sdelala-za-den\">https:\/\/tenchat.ru\/media\/602562-kak-ya-stala-rezhe-bespokoitsya-chto-nichego-ne-sdelala-za-den<\/a><\/li>\n<\/ul>\n<p>Смысл этого принципа примерно такой: в продуктовой разработке важно отслеживать не загруженность и\/или эффективность работы людей, а состояние рабочих продуктов в любой момент времени — в том числе и когда над ними не работают. Потому что — цитата из <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#queuesblindness\">предыдущего поста<\/a>:<\/p>\n<div style=\"border-radius: 25px; border:1px solid #DCDCDC;padding:20px;margin:20px;\"><p>Очереди увеличивают цикл одного рабочего продукта, время от начала работы над ним до выпуска в финальном виде.<br \/>\nХочется сделать такой вывод: нет смысла увеличивать эффективность работы над рабочими продуктами, пока мы не оптимизируем очереди.<br \/>\n<b>Пример<\/b>:<br \/>\n🟢 — работа над РП<br \/>\n🔴 — ожидание в очереди<br \/>\nСитуация у нас такая:<br \/>\n🟢🟢🔴🔴🔴🔴🔴🔴🟢🟢🔴🔴🔴🔴🔴🔴🔴🟢🟢<br \/>\nТо есть над РП работают два дня, потом он шесть дней ждет, потом еще два дня в работе, еще семь дней ждет, и наконец финальные два дня в работе перед выпуском. Итого цикл 19 дней, чистое время работы над РП 6 дней.<br \/>\nДопустим, мы удвоим эффективность инженеров и они смогут решить задачу в два раза быстрее — за три дня:<br \/>\n🟢🔴🔴🔴🔴🔴🔴🟢🔴🔴🔴🔴🔴🔴🔴🟢<br \/>\nЭкономия: 🟢🟢🟢<br \/>\nПолучаем цикл 16 дней. Плюс затраты на увеличение эффективности инженеров.<br \/>\nА теперь вместо этого сократим очереди вдвое:<br \/>\n🟢🟢🔴🔴🔴🟢🟢🔴🔴🔴🔴🟢🟢<br \/>\nЭкономия: 🔴🔴🔴🔴🔴🔴<br \/>\nПолучаем цикл 13 дней и не трогаем инженеров, пусть работают как работали.<\/p>\n<\/div><p>Конец цитаты. Получается, что следить нужно не за инженерами (ты еще поди увеличь продуктивность в два раза — тоже огого задача), а за состоянием рабочих продуктов — <i>особенно<\/i> когда работа над ними не ведется.<\/p>\n<p>Важные следствия:<\/p>\n<ol start=\"1\">\n<li>Чтобы использовать этот принцип — нужно понимать концепцию «рабочего продукта»; иногда РП понятны интуитивно — в задаче «сделай мне презу для клиента» речь идет о паверпоинтовском файле, можно не уточнять; но иногда итоговый РП непонятен — и лучше бы прояснить, в каком виде заказчик ждет результат от исполнителя. Уточнить могут оба: хороший руководитель\/заказчик всегда опишет, что именно и в каком виде он ждет, а хороший исполнитель — задаст конкретные вопросы, если ему неясно. В софтверной разработке РП бывают описаны в техзадании или критериях приемки (acceptance criteria) и обычно представляют собой <i>фичи<\/i> — определенное поведение разработанного софта в каком-то контексте.<\/li>\n<li>Нужно наладить учет и контроль движения РП. В софтверной разработке за это отвечают ишью трекеры (джира, ютрек) — они позволяют видеть картину по всем РП разом, и в то же время отслеживать любой из них. Без нормально организованного учета часть работ и усилий станет невидимой для менеджмента. Опять-таки, иногда интуитивного понимания достаточно («Где мой отчет за май?! Вы его уже неделю мурыжите!»), но если работ и РП много — будут потери и рассинхрон.<\/li>\n<li>Для руководителей. Основанием для ответа на вопрос «насколько хорошо работает Сидоров» может стать не общая интуитивная оценка, не сумма наблюдений, насколько усердно тот орудует у кульмана\/компьютера\/станка, а контроль и анализ прошедших через Сидорова рабочих продуктов.<\/li>\n<li>Для исполнителей — во-первых, добивайтесь <s>отстоя пены<\/s> нормальной постановки задач через рабочие продукты; во-вторых, если ваш руководитель или заказчик неспособен это сделать — обучитесь формулировать сами, например, с помощью практики «<a href=\"https:\/\/vc.ru\/design\/676975-termin-ponimanie-zadachi\">понимание задачи<\/a>»; в-третьих, сами начните планировать работу, отталкиваясь от РП — зачастую это проще, чем мириться с абстрактной постановкой задачи. По некоторым задачам сначала можно согласовать рабочий продукт, а уже потом приниматься за его изготовление.<br \/>\nПример: вам поручили презентацию для клиента, куда нужно включить коммерческое предложение по двум продуктам. Вы за полчаса накидываете черновик презентации прямо в паверпоинте, идете показать: «Семен Иваныч, такой формат подойдет? Тут будет описание продукта-1, тут описание продукта-2, тут — табличка с ценами с учетом скидки за объем, тут — наши регалии и отзывы клиентов». На готовом материале — пусть и черновом — обсуждать задачу гораздо легче, чем на пальцах.<\/li>\n<\/ol>\n<p>Продолжение: <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/\">https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-3\/<\/a><\/p>\n",
            "date_published": "2023-07-10T14:26:17+05:00",
            "date_modified": "2024-05-30T22:51:43+05:00",
            "tags": [
                "pdflow",
                "post",
                "Дон Рейнертсен",
                "книги",
                "Создание продукта",
                "экономика"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Mon, 10 Jul 2023 14:26:17 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "121567",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "121564",
            "url": "https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/",
            "title": "The Principles of Product Development Flow, пост 1 — введение",
            "content_html": "<p class=\"foot\">🔬 Это пост с разбором очередной части книги Дона Рейнертсена <i>The Principles of Product Development Flow<\/i>. Книга рассказывает, как правильно принимать решения при разработке продуктов и не помереть раньше времени. Все посты — по тегу <a href=\"https:\/\/artemushanov.ru\/?go=tags\/pd-flow\/\">pdflow<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/GA2UaaGBrM.png\" width=\"338\" height=\"500\" alt=\"\" \/>\n<\/div>\n<p>Книга о том, как правильно принимать управленческие решения при разработке продукта.<\/p>\n<p>Читать я ее начал <a href=\"https:\/\/artemushanov.ru\/?go=all\/kak-chitat-slozhnuyu-knigu\/\">вот так<\/a>, в этом посте публикую мысли-размышления по поводу основных понятий книги, почерпнутых из введения и пары презентаций на тему.<\/p>\n<p><a name=\"manvsdev\"><\/a><\/p>\n<h3>Разработка продукта и производство продукта  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#manvsdev\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>«Разработка продукта» в книге противопоставляется «производству продукта».<\/p>\n<p>Разработка — это создание «рецепта» продукта. Его можно создать один раз, создавать тот же самый рецепт во второй раз смысла нет — за него не заплатят. Примеры результата разработки: техническая карта овощных консервов; спецификация и техническая карта для смартфона; требования-conops-макеты экранов для софта.<\/p>\n<p>Производство продукта — это процесс выпуска готового продукта в большом количестве по тем самым рецептам. Компания получает деньги за каждый выпущенный экземпляр продукта.<\/p>\n<p>В производстве операции могут быть нормированы, для каждой единицы продукта набор операций одинаковый, можно планировать работу по принципу FIFO и довольно точно прогнозировать срок выпуска партии. Найти косячные места в производстве, особенно физическом, несложно: если перед каким-то производственным участком скопилась куча заготовок, то на этом участке что-то не так. Временные рамки для производства — это часы и дни.<\/p>\n<p>В разработке же набор операций для каждого нового продукта уникален и не похож на операции для предыдущего (или каждого нового варианта продукта — колу в стекле, в пластике и в ЖБ можно считать тремя разными вариантами).<\/p>\n<p>Работы нельзя нормировать, рабочие продукты могут быть практически невидимы, потому что зачастую это просто информация или описания. Такие рабочие продукты Рейнертсен называет <i>Design in Process<\/i> (DIP). Временные рамки — месяцы и годы.<\/p>\n<p>Один из главных инсайтов:<\/p>\n<p class=\"loud\">В разработке продукта нельзя использовать те же управленческие методы, что и в производстве.<\/p>\n<p>В разработке гораздо больше неопределенности, невозможно нормирование, централизация скорее вредит, а принятые на производстве метрики не отражают реальности. Поэтому тойотовская система производства, голдратовская TOC или шесть сигм для разработки не подходят.<br \/>\nВ софте «разработку» и «производство» вообще не всегда можно друг от друга отделить.<\/p>\n<p><a name=\"flow\"><\/a><\/p>\n<h3>Что такое «поток»  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#flow\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Поток (flow) в названии книги — это непрерывное и плавное течение работ и рабочих продуктов в ходе разработки нового продукта. В обратную сторону с той же скоростью текут деньги.<\/p>\n<p>Разработка, говорит книга, должна стучать ровным пульсом, а не аритмией страдать, чтобы и деньги поступали плавно и предсказуемо.<\/p>\n<p>Чтобы обеспечить плавность течения потока, нужно перейти на работу малыми партиями, быстро получать обратную связь по выполненным работам, и ограничивать работу-в-процессе. Приключение на двадцать минут, вошли-вышли.<\/p>\n<iframe src=\"\/\/coub.com\/embed\/17q2w7?muted=false&autostart=false&originalSize=false&startWithHD=false\" allowfullscreen frameborder=\"0\" width=\"640\" height=\"360\" allow=\"autoplay\"><\/iframe>\n<p><a name=\"twelveproblems\"><\/a><\/p>\n<h3>Двенадцать проблем в продуктовой разработке  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#twelveproblems\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Такая вот картинка из презентации <a href=\"https:\/\/www.slideshare.net\/SebastianRadics\/the-principles-of-product-development-flow-a-summary\">The Principles of product development flow — a summary<\/a>:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1.png\" width=\"790\" height=\"400\" alt=\"\" \/>\n<\/div>\n<p>Дальше по порядку<\/p>\n<p><a name=\"failurequant\"><\/a><\/p>\n<h3>Неудачная квантификация экономики  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#failurequant\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Чтобы иметь возможность сравнивать самые разные продуктовые решения между собой и выбирать из них лучшие, предлагается ввести показатель, через который можно оценить любое предлагаемое решение. Решения могут быть разные, самое распространенное — какую фичу\/вариант фасовки\/новую упаковку брать в работу следующей? На что следует потратить ограниченный ресурс продуктовой команды в следующем рабочем цикле?<\/p>\n<p>В основе метода Рейнертсена — экономический взгляд на продукт. Рейнертсен предлагает все мерять в деньгах, потому что на языке денег можно говорить с любыми стейкхолдерами в компании.<\/p>\n<p class=\"loud\">Продуктовые решения должны измеряться в деньгах<\/p>\n<p>Продукт, или продуктовая фича, должны принести N денег за свой жизненный цикл; сам цикл ограничен, можно считать что это величина постоянная, сколько-то лет\/месяцев. Любое действие, например, задержка вывода на рынок, влияют на эту эту сумму в плюс или в минус (задержка — в минус). Любое предпринимаемое действие нужно научиться оценивать в этих вот «влияниях» на прибыль продукта и принимать решение на основе них.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-10.png\" width=\"752\" height=\"714\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Пять ключевых индикаторов для оценки: время цикла, косты продукта, ценность продукта, затраты на разработку, риск<\/div>\n<\/div>\n<p>Для начала нужно вычислить <i>life-cycle profit<\/i> продукта — количество денег, которое продукт заработает в течение своего жизненного цикла (далее LCP; пока что мне непонятны тонкости вычисления именно прибыли на ЖЦ продукта, так что разъяснений не будет). Делать это можно любым доступным методом — статистическим, экспертным, математическим и т. п., можно вовлекать людей из продаж и финансов для помощи. Оценка с точностью до трех знаков после запятой тут не нужна, если примерно понятен порядок значения — уже хорошо.<\/p>\n<p>После этого нужно посчитать, какое влияние каждое из доступных нам решений окажет на LCP. Это влияние выражается показателем <i>life-cycle profit impact<\/i> (далее LCPI). Понять это предлагается через вопрос вида «как скажется на прибыльности продукта задержка выпуска этой фичи (версии, обновления, фасовки и т. п.) на 60 (например) дней?». Ответ на этот вопрос называется «стоимостью задержки» (Cost of Delay, CoD).<br \/>\nВ сравнении с интуитивным методом, предлагаемый фреймворк должен показывать более точные результаты. В книге описывается, что интуитивные оценки стоимости задержки одного и того же проекта среди коллег могут различаться в 50 раз: в приведенном примере это был диапазон от 10 000 до 500 000 долларов за двухнедельную задержку.<\/p>\n<p>Стоимость задержки показывает, во сколько нам обходится «лежание» готового рабочего продукта или DIP в очереди на обработку следующим звеном. Например, инженеры за три дня подготовили спецификации на новый продукт и передали в производство для оценки. Оценка займет один день. А производство сможет взяться за эти карты только через две недели — у них завал и куча заявок. В итоге вместо четырех дней техкарты будут подготовлены и одобрены за 14 дней. Если мы знаем стоимость задержки — мы можем понять, сколько денег компания потеряла за время ожидания.<\/p>\n<p>Стоимость задержки нужна, чтобы вычислять: стоимость очередей; стоимость избыточных запасов; выгоду от использования малых партий; оценку снижения вариабельности. Обо всем этом — ниже.<\/p>\n<p>Вот отдельное видео про стоимость задержки: <a href=\"https:\/\/vimeo.com\/101506552\">https:\/\/vimeo.com\/101506552<\/a><br \/>\nШакальский скрин оттуда:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-1.png\" width=\"704\" height=\"400\" alt=\"\" \/>\n<\/div>\n<p>Фича была сделана за 46 недель, при этом 38 недель провела в ожидании своей очереди на каком-то из этапов. То есть чистого времени требовалось примерно 8 недель.<br \/>\nИ вот эти очереди — они зачастую невидимы в не-физических производствах.<\/p>\n<p>Поэтому оценивается обычно не полный цикл работы над РП, не сами очереди, а только кусочек цикла, когда над РП идет какая-то работа. Это вот к пунктам про невидимость очередей и фокус на «эффективности».<\/p>\n<p>Если отсутствие фичи стоит нам $200k в неделю, мы недополучили $8 млн за 38 недель ожидания. Если мы это понимаем, то мы мы можем управлять решениями исходя из финансово-экономических предпосылок, а не любых других.<\/p>\n<p>Вкратце: когда мы планируем взять фичу в спринт\/релиз, мы должны выбирать ту, у которой выше стоимость задержки.<\/p>\n<p><a name=\"queuesblindness\"><\/a><\/p>\n<h3>Слепость к очередям  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#queuesblindness\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Очереди — главная причина проблем в продуктовой разработке. При этом почти никто измерять очереди не умеет (я пока что тоже).<\/p>\n<p class=\"note\">Одна из причин, как мне кажется, это незнакомство в целом с концепцией очереди применительно к управлению проектом; довольно контринтуитивная штука<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-8.png\" width=\"680\" height=\"484\" alt=\"\" \/>\n<\/div>\n<p>В изучении очередей Рейнертсен пользовался наработками <a href=\"https:\/\/ru.wikipedia.org\/wiki\/Теория_массового_обслуживания\">теории массового обслуживания<\/a>.<\/p>\n<p>Что такое «очередь»? Это когда у нас есть <a href=\"http:\/\/sewiki.ru\/Категория:Рабочие_продукты\">рабочий продукт<\/a> в каком-то состоянии, и над ним не ведется работа, он находится в ожидании. Передали фичу из производства в QA — она в бэклоге неделю отлеживается. Передали потом техписателям — еще неделю лежит.<br \/>\nВот это ожидание и есть «очередь»: у того, кто должен над этим РП сейчас работать, есть какая-то другая работа в процессе, а за ней еще парочка. Классически очереди работают по принципу <a href=\"https:\/\/ru.wikipedia.org\/wiki\/FIFO\">FIFO<\/a>, и в случае разработки это не оптимальный вариант.<br \/>\nТакие виртуальные рабочие продукты в процессе не ставятся на баланс предприятия и не видны в финансовом разрезе, поэтому финансовый аспект очередей и задержки тоже невидим.<\/p>\n<p>Очереди увеличивают цикл одного рабочего продукта, время от начала работы над ним до выпуска в финальном виде.<\/p>\n<p>Хочется сделать такой вывод:<\/p>\n<p class=\"loud\">нет смысла увеличивать эффективность работы над рабочими продуктами, пока мы не оптимизируем очереди.<\/p>\n<p><b>Пример<\/b>:<\/p>\n<p class=\"foot\">🟢 — работа над РП<\/p>\n<p class=\"foot\">🔴 — ожидание в очереди<\/p>\n<p>Ситуация у нас такая:<br \/>\n🟢🟢🔴🔴🔴🔴🔴🔴🟢🟢🔴🔴🔴🔴🔴🔴🔴🟢🟢<\/p>\n<p>То есть над РП работают два дня, потом он шесть дней ждет, потом еще два дня в работе, еще семь дней ждет, и наконец финальные два дня в работе перед выпуском. Итого цикл 19 дней, чистое время работы над РП 6 дней.<\/p>\n<p>Допустим, мы удвоим эффективность инженеров и они смогут решить задачу в два раза быстрее — за три дня:<br \/>\n🟢🔴🔴🔴🔴🔴🔴🟢🔴🔴🔴🔴🔴🔴🔴🟢<br \/>\nЭкономия: 🟢🟢🟢<br \/>\nПолучаем цикл 16 дней. Плюс затраты на увеличение эффективности инженеров.<\/p>\n<p>А теперь вместо этого сократим очереди вдвое:<br \/>\n🟢🟢🔴🔴🔴🟢🟢🔴🔴🔴🔴🟢🟢<br \/>\nЭкономия: 🔴🔴🔴🔴🔴🔴<br \/>\nПолучаем цикл 13 дней и не трогаем инженеров, пусть работают как работали.<\/p>\n<p>Проблема с обнаружением очередей в разработке продукта — в «невидимости» рабочих продуктов, зависших в ожидании. В физическом производстве очередь видно глазами: перед станком лежит горка деталей на обработку. А в продуктовой разработке большая часть РП — это информационные объекты, описания, код и тому подобные артефакты. Очереди, в которых они застревают, не видны, если не знать, что они есть.<\/p>\n<p>Обнаружить очереди можно по наблюдаемым последствиям: увеличенному времени цикла, отложенной обратной связи, меняющимся приоритетам и характеру докладов о статусе РП («ждем», «еще не приступили» и т. п.). Стоимость задержки увеличивается линейно в зависимости от размера очереди.<\/p>\n<p>Очереди можно проиллюстрировать на Cumulative Flow Diagram:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-2.png\" width=\"800\" height=\"562\" alt=\"\" \/>\n<\/div>\n<p>По оси X время, по оси Y размер очереди; левая наклонная Arrivals — это прибывающие (пассажиры, объекты, что угодно), точка на X это начало цикла; правая наклонная Departures — выбывающие, точка на X это конец цикла. Горизонтальная прямая от точки на Arrivals до точки на Departures — это длительность цикла. Вертикальная прямая от Departures до Arrivals — размер очереди.<\/p>\n<p>Вот пример из все той же презентации <a href=\"https:\/\/www.slideshare.net\/SebastianRadics\/the-principles-of-product-development-flow-a-summary\">The Principles of product development flow — a summary<\/a>:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-3.png\" width=\"649\" height=\"400\" alt=\"\" \/>\n<\/div>\n<p>График показывает, как именно понимание очередей может предсказать проблемы на проекте по сравнению с измерением времени цикла или обратной связи.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-4.png\" width=\"325\" height=\"400\" alt=\"\" \/>\n<\/div>\n<p>Во время 21 прибывает партия из 400 людей — и со времени 41 мы узнаем об увеличении времени цикла в 2 раза — горизонтальная стрелка, параллельная оси x, показывает нам это; при этом время увеличится еще, и мы это увидим из графика раньше, чем дождемся соответствующего человека в конце цикла.<br \/>\nДлительность цикла удвоилась: чтобы количество прибывших превратилось в такое же количество убывших, требуется вдвое больше времени. Как раз потому, что прибыло больше, а скорость обработки одного осталась прежней.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-5.png\" width=\"400\" height=\"383\" alt=\"\" \/>\n<\/div>\n<p>Время цикла — это прямая, параллельная горизонтали, пересекающая обе наклонные. Или время, в течение которого количество убывших стало равно количеству прибывших.<br \/>\nСмысл графика: если мы знаем про очереди и умеем их измерять — мы можем предсказать проблему с увеличением длительности цикла просто по факту увеличения очереди, не дожидаясь завершения цикла.<\/p>\n<p><a name=\"efficiency\"><\/a><\/p>\n<h3>Поклонение эффективности  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#efficiency\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p class=\"note\">Вики: «Эффекти́вность (лат. effectivus) — соотношение между достигнутым результатом и использованными ресурсами (ISO 9000:2015)»<\/p>\n<p>Так сложилось, что в работе компании стараются эффективно использовать промежутки, когда идет работа над каким-то рабочим продуктом, и абсолютно игнорируют очереди, когда РП болтается без дела; отсюда<br \/>\nпомешательство на личной эффективности, битва за продуктивность, тайм-менеджмент и т. п.<br \/>\nЗатраты на всякие подпроцессы в разработке обычно считаются так: стоимость ресурса в ед. времени + стоимость простоя\/задержки; без понимания очередей, мы не можем посчитать стоимость задержки. А раз мы не понимаем стоимость задержки — мы фокусируемся на эффективности использования ресурса.<\/p>\n<p>Еще раз вспоминаем про пример сверху с шариками 🟢🔴.<\/p>\n<p>Мы хотим, чтобы эффективность была высокой, и в этом своем стремлении можем достигать опасно высокого уровня загрузки ресурса.<br \/>\nУровень может быть опасным, потому что при высоких уровнях утилизации ресурса неконтролируемо растут очереди.<\/p>\n<p>Эффективность — это только прокси показатель, он не отражает всю экономическую картину разработки РП. Нужно уметь измерять вклад повышения эффективности на общую экономику и трейд-оффы ее повышения.<\/p>\n<p><a name=\"variability\"><\/a><\/p>\n<h3>Неприятие вариабельности  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#variability\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Под вариабельностью в книге понимается вероятность возникновения изменений в ходе разработки. Я сам пока не вполне эту концепцию понимаю, немного помог пример в конце параграфа.<\/p>\n<p>В производстве высокая вариабельность вредит: когда нужно просто производить продукцию по спецификации, любое отклонение от плана помешает. Петров забухал и не пришел — значит, какой-то участок простаивает, работа замедляется, план под угрозой. У деталей от нового поставщика другой допуск точности — нужно переналаживать линию, это время, план под угрозой. В производстве обычно стараются сократить вариабельность, чем более предсказуемо все пойдет — тем лучше.<\/p>\n<p>В разработке продукта без вариабельности не будет инноваций: если мы не будем иногда менять план и отказываться от уже принятых решений, то не сможем использовать возникающие возможности себе на пользу. Нужно допускать полезные изменения и уметь снижать влияние вредных на разработку. С другой стороны, чем выше степень вариабельности, тем больше рисков.<\/p>\n<p>Сама степень вариабельности — это прокси-метрика, с точки зрения книги нас должно интересовать влияние вариабельности на экономику проекта.<\/p>\n<p>В видео <a href=\"https:\/\/youtu.be\/L6v6W7jkwok\" class=\"nu\">«<u>Don Reinertsen — Second Generation Lean Product Development Flow<\/u>»<\/a> Дон приводит пример с Боингом. Если бы проект по разработке 777-го был полностью избавлен от вариабельности, то инженеры бы не взялись тестировать новый предложенный поставщиками сплав алюминия и лития — он был легче алюминия и мог сэкономить вес. Сплав в итоге не подошел, у него были проблемы с прочностью; зато подошли композиты, которые после испытаний и проверок добавили в проект. В исходной документации не было ни алюминий-литиевого сплава, ни композитов, но их обнаружение и внедрение пошло проекту на пользу.<\/p>\n<p><a name=\"conformance\"><\/a><\/p>\n<h3>Поклонение соответствию\/конформность  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#conformance\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Под «конформностью» в книге подразумевается слепое следование изначальному плану.<br \/>\nВ традиционном подходе считается, что любое отклонение от изначального плана — это плохо, и если оно случилось, нужно вернуть ситуацию на рельсы. Крайне редко кто-то прикидывает, чего это будет стоить проекту\/компании, и принимает решение на основе подсчета; обычно же считают, что следование плану всегда целесообразно.<\/p>\n<p>Это, однако, может быть экономически нецелесообразно и противоречит <a href=\"https:\/\/dzen.ru\/a\/Yi5nhKzByXqSXJw-\">методу рационального фланера<\/a>, скрывает открывающиеся возможности.<\/p>\n<p>Да и сами запланированные действия могут поменять какие-то свои детали: косты, ценность.<\/p>\n<p>Вывод: нужно регулярно пересматривать план и проактивно искать открывающиеся возможности. Про возможности см. <a href=\"https:\/\/artemushanov.ru\/?go=all\/stepping-stones-i-osoznanie-vozmozhnostey-odo-1\/\">пост про осознание возможностей<\/a>.<\/p>\n<p><a name=\"batches\"><\/a><\/p>\n<h3>Институционализация больших партий  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#batches\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Большие партии → дешевле производить → больше прибыль. Это справедливо для производства, но не для разработки.<\/p>\n<p>Считается, что с большими партиями снизится вариабельность. Чуть выше мы уже поняли, что понижать ее до нуля в разработке нельзя. А от больших партий она уменьшится вроде как немного, зато добавит кучу неопределенности в силу дальнего горизонта планирования. Компания станет менее гибкой на этот горизонт, т. к. под проект будут забронированы мощности, выделен страховой запас и так далее.<\/p>\n<p>Другая проблема — отложенный фидбек. Чем больше партия, тем длиннее цикл, и тем дольше мы не получим фидбек. В <a href=\"https:\/\/marketing.wikireading.ru\/h9DG6Tl7Pk\">примере с письмами<\/a> из книги Эрика Риса «Бизнес с нуля» (Lean Startup в оригинале), отец с двумя дочерьми собираются разослать несколько сотен писем. На каждом письме нужно поставить печать, вложить в конверт, написать адрес, заклеить конверт. Можно начать делать все по этапам, а можно обрабатывать каждое письмо по отдельности. В этой байке победил второй вариант — работа с малыми партиями.<\/p>\n<p>Дальше цитата:<\/p>\n<blockquote>\n<p>«Предположим, что письма не помещаются в конверты. При работе с большими партиями мы узнаем об этом только в конце. А подход небольших партий позволит увидеть это почти сразу. Что, если конверты бракованные и не заклеиваются? При работе большими партиями нам придется вынуть письма из всех конвертов, взять новые конверты и снова вложить в них письма. Выполняя работу небольшими партиями, мы сразу увидим, что конверты бракованные, и нам не нужно будет ничего переделывать.»<\/p>\n<\/blockquote>\n<p>Водопадное планирование подразумевает использование «фазовых ворот», когда все рабочие продукты приходят одной большой партией к следующему этапу. В примере про конверты — сначала мы все письма подписываем, и только потом приступаем к этапу «положить в конверт». Это тоже вариант работы с большими партиями.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-6.png\" width=\"800\" height=\"380\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Пример: на малых партиях гораздо быстрее получаем фидбек, при этом время цикла на тот же объем РП остается прежний<\/div>\n<\/div>\n<p>Малые партии гораздо лучше подходят для работы, но для их обеспечения нужно научиться снижать транзакционные косты.<\/p>\n<p>В видео <a href=\"https:\/\/youtu.be\/L6v6W7jkwok\" class=\"nu\">«<u>Don Reinertsen — Second Generation Lean Product Development Flow<\/u>»<\/a> Дон приводит такой бытовой пример: допустим, вам надоело два раза в неделю ходить и покупать яйца. Вам нужно 2-3 штуки в день, вы вычисляете, что на год вам нужно тысячу с небольшим яиц. И вот у вас есть два крайних варианта: купить яиц сразу на год, или покупать яйца два раза в неделю. В случае с яйцами на год, у вас снижаются до минимума транзакционные издержки: нужно один раз договориться с продавцом, доставить яйца домой, и все. Зато сильно повышаются издержки на хранение: придется купить второй холодильник.<\/p>\n<p>Выбор правильного размера партии — это выбор правильной точки на графике пересечения издержек на хранение\/поддержку и транзакционных издержек:<\/p>\n<div class=\"e2-text-picture\">\n<div class=\"fotorama\" data-width=\"1254\" data-ratio=\"1.6035805626598\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-9.png\" width=\"1254\" height=\"782\" alt=\"\" \/>\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-11.png\" width=\"1216\" height=\"942\" alt=\"\" \/>\n<\/div>\n<\/div>\n<p>Про малые партии в софтверной разработке есть хорошее упражнение про <a href=\"https:\/\/docs.google.com\/document\/d\/1TCuuu-8Mm14oxsOnlk8DqfZAA1cvtYu9WGv67Yj_sSk\/pub\">правильную нарезку слона<\/a>. Да и весь скрам, в общем-то, об этом.<\/p>\n<p><a name=\"cadence\"><\/a><\/p>\n<h3>Недоиспользование каденса\/каденции  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#cadence\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>В книге под <i>cadence<\/i> понимается регулярность чего-либо; например, встречи для ревью дизайна, или регулярные поставки версий продукта.<\/p>\n<p>Пример такой: если не назначать отдельную встречу каждый раз, когда нужно провести ревью дизайна очередной партии РП, а проводить эти ревью по графику раз в неделю, то транзакционные издержки на назначение таких встреч будут минимальными, и можно выносить на ревью даже небольшое количество рабочих продуктов (=малую партию).<\/p>\n<p><a name=\"timelines\"><\/a><\/p>\n<h3>Управление таймлайнами, а не очередями  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#timelines\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Таймлайны — это временны́е аспекты задач внутри проекта. Но учитывать мы их можем только по тем периодам, когда работа делается, а очередей и простоев мы не видим.<br \/>\nНужно сделать очереди видимыми, понимать их стоимость и научиться ими управлять.<\/p>\n<p><a name=\"lackofflex\"><\/a><\/p>\n<h3>Негибкость  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#lackofflex\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Придерживаемся устаревшего плана, специализируем работников, загружаем мощности до предела.<br \/>\nПро устаревший план выше было. А вот про специализацию работников интересное: на производствах платят больше тем сотрудникам, которые могут работать на нескольких производственных участках или станках, а не на одном.<br \/>\nВ продуктовой же разработке (да и в софтверной) приветствуется специализация. При этом, если мы признаем, что полностью избавляться от вариабельности нельзя, то специализация в случае изменений скорее вредит, чем помогает.<\/p>\n<p>Про загрузку мощностей до предела — примерно такая же ситуация. Если загрузка ресурса выше 60-70%, то резко растут очереди.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reynertsen-post-1-7.png\" width=\"400\" height=\"270\" alt=\"\" \/>\n<\/div>\n<p><a name=\"control\"><\/a><\/p>\n<h3>Централизованный контроль  <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-1\/#control\"> <font color=\"silver\">#<\/font><\/a><\/h3>\n<p>Упрощаем управление до прямого директивного, недоиспользуем или пропускаем новые возможности из-за централизации. Решения, которые нужно принять руководителю с полномочиями, выстраиваются в еще одну очередь.<\/p>\n<p>Снова пример с Боингом-777: в какой-то момент стало понятно, что самолет не помещается в целевой вес, обещанный клиентам. Запахло миллионными штрафами, нужно было срочно облегчать самолет. Инженерам разрешили не согласовывать затраты за облегчение конструкции, если избавление от фунта веса обходилось в триста долларов или меньше. В итоге 5000 инженеров смогли принимать самостоятельные решения без согласования, руководитель программ не стал узким местом в принятии этих решений. Поскольку он все равно контролировал итоговую стоимость проекта, изменения ему были видны и он мог на них повлиять.<\/p>\n<p><b>Пока осталось за кадром:<\/b><\/p>\n<ul>\n<li>Отсутствие ограничения работы в процессе (WIP) — делаем много всего одновременно, удлиняем очереди, теряем гибкость<\/li>\n<li>Не-экономический контроль потока — контролируем не по эк. метрикам, а по каким-то другим.<\/li>\n<\/ul>\n<p>Продолжение: <a href=\"https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-2\/\">https:\/\/artemushanov.ru\/?go=all\/reynertsen-post-2\/<\/a><\/p>\n<p>Перевод первой главы книги, ч1 © «Лидеры изменений»: <a href=\"https:\/\/communities.changeleaders.ru\/enterprise-agile-russia\/princzipy-potoka-razrabotki-produktov-1-problematika\/\">https:\/\/communities.changeleaders.ru\/enterprise-agile-russia\/princzipy-potoka-razrabotki-produktov-1-problematika\/<\/a><\/p>\n<p>Перевод первой главы книги, ч2 © «Лидеры изменений»: <a href=\"https:\/\/communities.changeleaders.ru\/enterprise-agile-russia\/princzipy-potoka-razrabotki-produktov-2-resheniya\/\">https:\/\/communities.changeleaders.ru\/enterprise-agile-russia\/princzipy-potoka-razrabotki-produktov-2-resheniya\/<\/a><\/p>\n",
            "date_published": "2023-02-05T18:56:17+05:00",
            "date_modified": "2025-07-29T18:38:37+05:00",
            "tags": [
                "pdflow",
                "post",
                "Дон Рейнертсен",
                "книги",
                "менеджмент"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Sun, 05 Feb 2023 18:56:17 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "121564",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        }
    ],
    "_e2_version": 4079,
    "_e2_ua_string": "Aegea 11.0 (v4079e)"
}