Все статьи
Принципы потока разработки продуктов — #1 проблематика
Дата: 16.07.2025
Перевод легендарной книги для менеджеров крупных компаний, которые хотят конкурировать в цифровую эпоху.
Нас ведёт к беде не то, что мы чего-то не знаем… К беде ведёт знание, которое мы считаем «истинным», но которое на самом деле ошибочно.
Содержание
Зачем писать эту книгу? После 30 лет консультирования организаций по разработке продуктов мне посчастливилось работать со многими умными и опытными разработчиками. У меня была возможность увидеть, что они делают и какие результаты получают. В то же время я столкнулся со всеми стандартными советами о том, как следует управлять разработкой продукта. Любопытно, что то, что на самом деле работает, на удивление отличается от стандартных советов. Почему?
Я убежден что доминирующая парадигма управления продуктовой разработкой фундаментально неверна. Именно фундаментально, в своей основе.
Она ровно так же неверна, как и управление производством (прим. пер. — здесь и далее под производством следует понимать manufacturing-деятельность) до момента появления и распространения сначала в Японии а потом и в мире подходов бережливого производства (Lean manufacturing).
Я верю, что новая предлагаемая в книге парадигма может бросить вызов сложившимся практикам продуктовой разработки и хочу ускорить ее распространение и адаптацию в индустрии. Чтобы сделать это, я хочу помочь людям понять ее. Это и есть назначение книги.
Подход, который я раскрою в этой книге, в той или иной мере всегда присутствовал в процессах разработки. В конце концов разработчики повторяют поведение (прим. пер. — речь о неформальном следовании определенным практикам), которое работает, даже если теоретически оно не должно работать. Но обнаружение успешного поведения и его повторения недостаточно для применения этих практик и распространение этого поведения на большом масштабе. Разработчикам необходимо извлечь из этого опыта сам основополагающий механизм, почему эти практики работают. Только обобщив эти принципы мы можем расширить их применение от нескольких отдельных успешных прецедентов до основных подходов, которые трансформируют весь процесс разработки.
Давайте начнем с иллюстрации. Официально многие разработчики продуктов имеют этапные (phase-gate) процессы. Работы разделены на взаимоисключающие этапы, разделенные вехами (контрольными точками). Один этап выполнения должен быть завершен, прежде чем начнется следующий. Например, такие процессы обычно требуют, чтобы все требования к продукту были определены до начала деятельности по дизайну и проектированию.
Команда делает это и предоставляет менеджменту исчерпывающие требования к продукту при проверке контрольных точек. Затем им предоставляется разрешение на выход из этапа определения требований и начало этапа проектирования продукта. На первый взгляд, эта процедура кажется вполне разумной, и она, кажется, работает.
То, что происходит на самом деле, совсем отличается от исходного процесса. Когда я опрашивал менеджеров на своих курсах по разработке продуктов, 95% признают, что они начинают проектировать, прежде чем узнают все требования. На самом деле, статистически команда разработки продукта начинает проектирование, когда известно 50% требований. Они просто не афишируют это руководству.
Вместо этого они участвуют в проверенном временем ритуале запроса разрешения на продолжение (прим. пер. — инициируют старт следующего этапа работ). Существует неявная политика «не спрашивай, не говори» (Dont Ask — Dont Tell). Менеджеры вежливо избегают спрашивать, начались ли уже действия следующего этапа, а разработчики незаметно избегают упоминания, что они уже пошли дальше. На практике преобладает разумное поведение, несмотря на наличие неважно функционирующей формальной процедуры.
Неявное пересечение деятельности по дизайну/проектированию с написанием требований является лишь одним из простых примеров этой альтернативной парадигмы в действии. Среди прочего, эта парадигма подчеркивает важность следующих аспектов: небольшие порции работ (small batch size), быстрая обратная связь и ограничение количества задач в работе (WIP, Work In Process).
Эти три конкретных метода на практике широко применяются на протяжении всего процесса разработки. Когда мы поймем, почему они работают, мы можем адаптировать их к десяткам ситуаций (прим. пер. — в том числе за границами непосредственно продуктовой деятельности).
В своей основе эта новая парадигма направлена и фокусируется на достижении потока. Этот поток во многом схож с методами бережливого производства и может быть по аналогии определен как бережливая продуктовая разработка (Lean Product Development, LPD). Тем не менее, методы бережливого производства были оптимизированы для области с совершенно иными характеристиками, чем в классическом производстве.
Например, в классическом Lean-производстве поток имеет дело с предсказуемыми и повторяющимися задачами, однородными затратами на задержку и однородной продолжительностью задач (прим. пер. — homogeneous job, речь идет о некоторой стандартизированности и предсказуемости предмета работ).
В результате производство последовательно работает в простом порядке «первый пришел — первым вышел» (FIFO, First In — First Out). Приоритетность FIFO почти никогда не является экономически оптимальной в разработке продукта, потому что разработка продукта имеет дело с высокой изменчивостью и неопределенностью, неповторяющимся и неоднотипным, неоднородным порядком действий. Разные проекты почти всегда имеют разные затраты на задержку, и они представляют собой разные нагрузки на наши ресурсы.
Как вы увидите, эти новые проблемы заставляют нас выйти далеко за рамки идей бережливого производства. Если мы открыты для передовых идей из других областей, мы можем это сделать. Чтобы отличить этот более продвинутый подход от идей бережливого производства, мы назовем его — продуктовая разработка основанная на потоке (Flow-Based Product Development).
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, подписывайтесь на Telegram-канал Enterprise Agile Russia.
В чем заключается проблема
Современные подходы производства и разработки институционализировали набор внутренне согласованных, но несостоятельных убеждений и практик (прим. пер. — автор называет это термином «ортодоксия убеждений», я буду использовать этот термин далее). Это создало тесную взаимосвязанную и самоподдерживающуюся систему, из которой очень трудно вырваться. Даже когда мы меняем одну часть практик, другие части сдерживают нас, блокируя преимущества наших изменений. Когда наши изменения не приносят пользы, мы возвращаемся к старым подходам.
Давайте посмотрим, как наши текущие убеждения усиливают друг друга. Например, если мы объединим веру в то, что эффективность — это хорошо, со слепотой к очередям, мы загрузим наш процесс разработки до высокого уровня использования мощностей (утилизации емкости). В конце концов, недоиспользованные мощности — это отходы и невозвратные потери. Высокая загрузка мощностей может привести к образованию очередей, но эти очереди не имеют видимой стоимости (прим. пер. — речь идет о стоимости задержки, но об этом позднее). Таким образом, эти два убеждения в совокупности приводят нас к катастрофическому уровню использования ресурсов. Это, в свою очередь, приводит к большим очередям и длительному времени цикла разработки.
Возьмем другой пример. Если мы объединим убеждение, что изменчивость (требований, приоритетов) — это плохо, с неспособностью правильно оценить экономические показатели и экономические перспективы изменения приоритетов, мы будем минимизировать изменчивость, жертвуя другими, не поддающимися количественной оценке экономическими целями. Мы создадим несклонный и консервативный к риску процесс разработки, который будет стремиться «сделать все правильно с первого раза». Мы будем слепо принимать такие концепции, как разработка продуктов по методу «Шесть сигм» (Six Sigma) (прим. пер. — производство будет отлично выполнять свою работу, но эти прекрасные внутренние показатели не будут отражать успех продукта с точки зрения экономики в целом). Такое неприятие риска вытеснит инновации из процесса разработки. В итоге мы будем удивляться, почему наши продукты не отличаются от других и имеют низкую рентабельность. Таким образом, наша нынешняя система убеждений заставляет нас выбирать снижение вариативности и изменчивости вместо прибыльности. Тем не менее, она вводит нас в заблуждение, заставляя думать, что мы увеличиваем прибыль.
В этой главе я хочу оспорить некоторые из основных убеждений современной ортодоксии и подчеркнуть, что в них не так. Конечно, это лишь краткое введение в эти спорные идеи. Ортодоксальные убеждения достаточно хорошо защищены, поэтому позже в этой книге мы должны будем атаковать их более тяжелым оружием. Пока же я просто выпущу несколько трассирующих снарядов, чтобы вы могли увидеть, где находятся цели. Я лишь прошу вас быть открытыми к возможности того, что нынешняя ортодоксия глубоко дисфункциональна и несостоятельна. Давайте выделим двенадцать ключевых проблем нынешнего подхода.
- Failure to Correctly Quantify Economics (неспособность корректно оценить экономический эффект).
- Blindness to Queues (слепота и отсутствие видимости очередей).
- Worship of Efficiency (поклонение результативности).
- Hostility to Variability (враждебность к изменчивости).
- Worship of Conformance (поклонение соответствию).
- Institutionalization of Large Batch Sizes (институализация планирования больших порций работ).
- Underutilization of Cadence (недозагрузка каденций/итераций).
- Managing Timelines instead of Queues (управление сроками вместо очередей).
- Absence of WIP Constraints (отсутствие ограничений незавершенной работы).
- Inflexibility (отсутствие гибкости).
- Noneconomic Flow Control (контроль потока разработки, не опирающийся на экономические факторы).
- Centralized Control (централизованный контроль).
#1 — Неспособность корректно оценить экономический эффект
Возможно, самая главная слабость нынешней ортодоксии — это ее неспособность правильно количественно оценить экономику. Ключевое слово — правильно. Когда все сделано правильно, экономическая схема проливает яркий свет на все темные уголки разработки продукта. Сегодня мы освещаем только часть ландшафта. Затем мы фокусируемся на этих хорошо освещенных деталях. Мы похожи на пьяницу под фонарным столбом, который ищет свои ключи там, где лучше всего светит, а не там, где он их уронил.
Эта критика может удивить разработчиков продуктов, поскольку большинство убеждены, что они правильно количественно оценивают экономику. Тем не менее, именно это убеждение блокирует их от прогресса. Например, единственный способ понять экономическую важность очередей — это количественная оценка стоимости задержки для проектов разработки продуктов. Тем не менее, сегодня только 15%разработчиков продуктов знают стоимость задержки, связанной с их проектами.
Сегодня разработчики сосредоточены на показателях, которые мы называем прокси-переменными (опосредованные, косвенные показатели). Прокси-переменная — это количественный показатель, который заменяет реальную экономическую цель: Life-Cycle Profit (LSP), прибыль в течение жизненного цикла.
Например, разработчики измеряют время цикла разработки и стремятся сделать его короче. Однако, когда вы спросите их, насколько снизится LSP прибыль жизненного цикла из-за недельной задержки, они вряд ли ответят, так как, скорее всего, не обладают этой информацией. Cycle time — время цикла разработки — это лишь косвенный показатель.
Разработчики измеряют процент «value-added»-времени и стремятся сделать его больше. Но если вы спросите их, насколько увеличится прибыль в течение жизненного цикла, когда они сделают это, они не знают. Процент «value-added»-времени — это лишь косвенная переменная. Фокусируясь на косвенных переменных, разработчики продуктов обманывают себя, думая, что они понимают экономику. Это не так.
Опасность фокусировки на косвенных переменных заключается в том, что косвенные переменные сильно взаимосвязаны и взаимодействуют друг с другом. Повышение загрузки производственных мощностей имеет положительный эффект в виде повышения эффективности и отрицательный — в виде увеличения времени цикла. Чтобы понять чистое воздействие, мы должны объединить оба эффекта. Для этого мы должны выразить изменения всех косвенных переменных в одной и той же единице измерения. Этой единицей измерения должно быть влияние на прибыль в течение всего жизненного цикла, которое является конечным показателем успеха разработки продукта.
Только когда мы понимаем связь между прокси-переменными и прибылью жизненного цикла, мы можем реально увидеть экономические последствия нашего выбора. В главе 2 я покажу вам, как экономический фреймворк (прим. пер. — предлагаемый далее автором) поможет нам в этом.
#2 — Слепота и отсутствие видимости очередей
Мало кто из разработчиков понимает, что очереди являются самой важной причиной низкой производительности разработки. Очереди приводят к тому, что в нашем процессе разработки слишком много пакетов работ по проектированию в процессе (Design-In-Progress, DIP). Разработчики не знают о DIP, они не измеряют его и не управляют им. Они даже не понимают, что DIP — это проблема. Например, разработчики продуктов скажут, что хотят быть более инновационными и никогда не поймут, что высокий уровень DIP подрывает эту цель. Когда DIP высок, время цикла разработки увеличивается. Когда время цикла неоправданно высокое, инновации происходят так поздно, что они становятся имитацией и подражанием, гонкой за настоящими лидерами.
Здесь необходимо остановиться подробнее, поскольку важно сделать дифференциацию между введенным термином DIP и широко известным WIP.
- WIP — это любые задачи, взятые в работу, но незавершённые (например, код в разработке, несделанные тесты, ненаписанная документация).
- DIP — это частный случай WIP, но акцент на проектировании и дизайне решений (незавершённые архитектурные идеи, «висящие» дизайн-гипотезы, невалидированные требования).
Примитивная аналогия:
- WIP — детали на конвейере, которые ещё не стали товаром.
- DIP — чертежи этих деталей, которые ещё не утверждены к производству.
DIP — это любые непроверенные гипотезы, незавершенные идеи, недопроектированные требования, архитектурные решения. Это все то, что повлияет в последствии на WIP.
И снова придется оговориться, что автор, критикует неконтролируемое накопление DIP и отсутствие явных границ между приемлемо задокументированным дизайном решением для начала работ по разработке и откровенно сырым дизайном решения. Излишняя полнота требований и дизайна ведут к росту сроков реализации.
Автор подчёркивает парадокс: команды хотят быть «инновационными», но «не видят», что высокий DIP превращает их идеи в «устаревшие имитации». Причина: длинные циклы разработки («innovation occurs so late that it becomes imitation»). Пока продукт выходит, рынок или конкуренты уже предлагают аналоги. Можно привести еще один пример: стартап, который год «дорабатывает» фичу, теряет первенство, даже если изначально она была прорывной.
Также автор выступает против иллюзии «продуктивности»: команды считают, что «много работают», если у них много задач в прогрессе. Но реальная ценность — только в «готовых» решениях. Однако, чем меньше DIP, тем быстрее обратная связь от рынка и адаптация.
Некоторые могут сказать, что очереди — не главная проблема, есть ещё технический долг или плохие требования и прочее. Но автор намеренно гиперболизирует роль DIP, чтобы подчеркнуть «системный эффект» управленческих ошибок.
Есть две важные причины, по которым разработчики продуктов не замечают DIP.
- Во-первых, запасы (незавершенное производство) финансово невидимы при разработке продукта. Мы не учитываем частично завершенные разработки в качестве активов на нашем балансе; мы относим расходы на НИОКР по мере их возникновения. Если мы спросим финансового директора, сколько у нас запасов в процессе разработки продукта, ответ будет: «Ноль».
- Во-вторых, мы не замечаем запасов, связанных с разработкой продукции, потому что они обычно физически невидимы. Незавершенный дизайн и прочее (DIP) — это информация, а не физические объекты. Мы не видим кучи DIP, когда проходим через инженерный отдел или команду аналитиков. В процессе разработки продукта наши запасы — это биты на дисковом накопителе, а дисковые накопители в отделе разработки продукта очень большие.
Но если мы слепы к DIP, то мы также слепы к опасности работы с высоким уровнем DIP. Как вы увидите в главе 3, очереди лежат в основе большого количества проблем, связанных с разработкой продуктов. Они увеличивают неопределенность (вариативность), риск и время цикла. Они снижают эффективность, качество и мотивацию.
Чтобы понять экономическую стоимость очередей, разработчики продуктов должны уметь отвечать на два вопроса.
- Во-первых, насколько велики наши очереди? Сегодня только 2% разработчиков продуктов измеряют очереди.
- Во-вторых, какова стоимость этих очередей? Чтобы ответить на этот второй вопрос, мы должны определить, как размер очереди преобразуется в стоимость задержки, а для этого необходимо знать стоимость задержки. Сегодня только 15% разработчиков продуктов знают, во сколько им обходится задержка. Поскольку так мало компаний могут ответить на оба вопроса, не стоит удивляться, что управление очередями сегодня осуществляется неэффективно.
Я должен подчеркнуть, что конечная причина слепоты к очередям кроется в неспособности правильно оценить экономику. Мы можем научиться видеть все, что считаем важным. Как только мы количественно определим стоимость задержки, мы осознаем стоимость очередей. Как только мы осознаем стоимость очередей, у нас появляется мотивация измерять их и управлять ими. Без стоимости задержки очереди кажутся бесплатными и, следовательно, недостойными внимания.
#3 — Поклонение результативности
Efficiency (результативность) – степень реализации запланированной деятельности и достижения запланированных результатов. Effectiveness (эффективность) – связь между достигнутым результатом и тем, насколько целесообразно использованы ресурсы.
Но на что обращают внимание разработчики продуктов? Современные разработчики неправильно пытаются максимизировать результативность. Это естественное следствие «слепоты к очередям» и неспособности правильно оценить экономику в количественном выражении.
Любой подпроцесс в рамках разработки продукта может и должен быть рассмотрен с экономической точки зрения.
Общая стоимость подпроцесса складывается из стоимости его пропускной способности и стоимости задержки, связанной с его временем цикла. В ознакомительных целях мы опустим третью стоимость, связанную с выполнением подпроцесса. Позже в этой книге мы будем использовать более полную экономическую схему (прим. пер. — оценивая результативность подпроцесса, например, этапа дизайна или тестирования, нельзя смотреть только на прямые затраты и локальные показатели эффективности — критично учитывать, как его скорость влияет на экономику всего продукта).
Если мы слепы к очередям, мы не будем знать стоимость задержки. Мы будем знать только стоимость пропускной способности в единицу времени. Тогда, если мы стремимся минимизировать общие затраты, мы сосредоточимся только на той части, которую мы можем видеть — на результативном использовании мощностей (прим. пер. — отражает ли это стоимость упускаемых возможностей? Полагаю, что нет, напротив, это ведет к бесперспективной с экономической точки зрения гонке за полную утилизацию ресурсов производства, которая не является самоцелью).
Это объясняет, почему современные разработчики продуктов считают, что результативность желательна, а нерезультативность — это нежелательная форма отходов (waste в терминологии бережливого производства) (прим. пер. — неэффективность с точки зрения оптимального использования ресурсов для достижения финансового результата, а именно результативность выраженная в высокой степени утилизации или скорости завершения и прочем). Это приводит к тому, что они загружают свои процессы до опасно высокого уровня нагрузки. Насколько высокий? Руководители, приходящие на мои занятия по разработке продуктов, сообщают, что в ходе предварительных опросов они работают с 98,5% загрузкой. К чему это приведет? В главе 3 мы объясним, почему образуются большие очереди, когда процессы с изменчивостью работают при высоком уровне загрузки. В действительности ошибочное стремление к результативности создает огромные издержки в неизмеряемой, невидимой части процесса разработки продукта — в его очередях.
В чем первопричина этой проблемы? И снова это неспособность правильно оценить экономические показатели и перспективу. Хотя результативность и оказывает экономическое воздействие, она является лишь еще одной косвенной переменной (proxy variable). Мы должны принимать решения, основываясь на общей экономической эффективности. Поскольку высокая загрузка мощностей одновременно повышает результативность и увеличивает стоимость задержки, мы должны учитывать совокупное влияние этих двух факторов.
Достичь этого мы сможем только если выразим оба фактора в одной и той же единице измерения — прибыли за жизненный цикл. Если мы сделаем это, то всегда придем к выводу, что процесс разработки продукта, близкий к полной загрузке ресурсов — это экономическая катастрофа.
#4 — Враждебность к изменчивости
Отсутствие четкого экономического мышления также приводит к глубокому непониманию роли изменчивости в разработке продукта. Сегодня большинство разработчиков продуктов считают, что изменчивость — это плохо, и пытаются ее устранить. Такой акцент на снижении вариативности глубоко ошибочен по трем важным причинам.
- Во-первых, без изменчивости мы не сможем внедрять инновации. При разработке продуктов создаются «рецепты» продуктов, а не сами продукты. Если дизайн не меняется, то не может быть и добавленной стоимости. Но когда мы меняем дизайн, мы вносим неопределенность и изменчивость в результаты. Мы не можем устранить всю изменчивость, не устранив всю добавленную стоимость.
- Во-вторых, изменчивость — это лишь косвенная переменная. На самом деле нас интересует влияние на экономическую стоимость этой изменчивости. Как вы увидите в главе 4, эта экономическая стоимость зависит от того, как изменчивость преобразуется в экономическую функцию отдачи. Очень важно обращать внимание как на количество изменчивости, так и на природу этой функции отдачи. Когда мы начинаем рассматривать изменчивость таким образом, мы обычно обнаруживаем, что гораздо проще изменить функцию отдачи, чем уменьшить основную величину изменчивости.
- В-третьих, с небольшой помощью теории ценообразования опционов (option pricing theory) мы обнаружим, что на самом деле можем разрабатывать процессы развития таким образом, чтобы увеличение изменчивости улучшало, а не ухудшало наши экономические показатели производительности.
Economic Payoff Function (функция экономической выгоды/платежа/отдачи) — это математическая модель, которая описывает взаимосвязь между действиями экономических агентов (игроков) и их выгодой (прибылью, полезностью, доходом). Она используется в теории игр, микроэкономике и управлении для анализа стратегий и принятия решений.
Простыми словами это «формула», которая показывает:
- какие выгоды получит игрок (компания, индивид, государство) в зависимости от своих действий или действий других;
- как выбор (например, цена товара, уровень инвестиций) влияет на результат.
К сожалению, современные процессы разработки продуктов пронизаны методами и практиками, которые без какой-либо критики принимают идею о том, что изменчивость — это плохо. Разработчики встраивают буферы в свои планы (перестраховываются трудозатратами), чтобы уменьшить изменчивость. Они внедряют практики Six Sigma для снижения неопределенности. Они стремятся создать повторяющиеся процессы для уменьшения неопределенности и вариативности.
Мои опросы разработчиков продуктов показывают, что 65% разработчиков считают желательным устранить как можно больше вариативности при разработке продукта. Изменчивость рассматривается как враг. Эта точка зрения полностью оторвана от глубокого понимания экономики разработки продукта.
Минимизация экономического воздействия изменчивости — цель, глубоко отличная от минимизации самой изменчивости.
#5 — Поклонение соответствию
Помимо глубокого непонимания изменчивости, у современных разработчиков продуктов есть укоренившиеся заблуждения относительно того, как реагировать на эту изменчивость. Они считают, что всегда должны стремиться к тому, чтобы фактическая производительность соответствовала первоначальному плану. Они полагают, что выгода от исправления отклонений от плана всегда будет превышать затраты на это. Это вызывает совершенно неоправданное доверие к первоначальному плану и мешает компаниям использовать возникающие возможности. Такое поведение не имеет экономического смысла.
Мы живем в неопределенном мире. Мы должны признать, что наш первоначальный план был основан на нечетких (первоначальных оценочных) данных и рассматривался на большую временную перспективу. Например, мы могли начать разработку, полагая, что для создания фичи потребуется 1 неделя усилий и ее оценят 50% наших клиентов. По мере разработки мы могли обнаружить, что эта фича потребует 10 недель усилий и будет оценена только 5% наших клиентов. Соотношение затрат и выгод изменится в 100 раз. Такая открывшаяся информация полностью меняет экономику нашего первоначального выбора. В таких случаях слепое следование первоначальному плану уничтожает экономическую ценность (прим. пер. — разумеется, мотивация разработки понятна — выполнили то, что требовалось, однако, в целом экономическая перспектива выполнения данной работы становится сомнительна).
Чтобы эффективно управлять разработкой продукта, мы должны осознать, что на протяжении всего цикла разработки постоянно поступает новая ценная информация. Вместо того чтобы застывать во времени, придерживаясь первоначального плана, мы должны научиться делать правильный экономический выбор, используя эту новую информацию.
Соответствие первоначальному плану стало еще одним препятствием, мешающим нам принимать правильные экономические решения.
И снова мы имеем дело со случаем, когда косвенная переменная, соответствие первоначальному плану, заслоняет реальный вопрос, который заключается в принятии правильных, экономически мотивированных решений.
#6 — Институализация планирования больших порций работ
Batch size — размер порции работ, количество задач, которые могут быть взяты в работу в рамках определенного периода времени.
Наша слепота к очередям и ориентация на эффективность (по факту ориентированная на максимизацию утилизации ресурсов) приводят к тому, что мы институционализируем крупные порции работ. Крупные порции работ кажутся привлекательными, поскольку они дают эффект масштаба, повышающий результативность (высокую утилизацию ресурсов). Кроме того, крупные порции работ, как представляется, снижают изменчивость, поскольку объединяют многие виды деятельности. Однако, это повышение результативности, снижение изменчивости и неопределенности — лишь иллюзия. Как вы увидите позже, в главе 5, крупные порции работ могут быть сильно неэффективны.
Более того, скромное снижение изменчивости за счет объединения вариаций будет полностью перекрыто геометрическим увеличением неопределенности, вызванным более длинными горизонтами планирования, связанными с крупными порциями работ.
Сегодняшняя ортодоксальная практика поощряет максимально возможные размеры порции работ. Например, большинство разработчиков продуктов используют этапные процессы, которые передают 100% рабочего продукта в одной большой порции на следующий этап. Мы не можем сделать размер порции больше 100%.
Мы посвятим главу 5 пониманию удивительных преимуществ небольших порций и методов, которые мы можем использовать для их достижения. В частности, мы рассмотрим, как мы можем создать условия для работы с мелкими порциями, систематически снижая транзакционные издержки.
Не стоит удивляться тому, что, поскольку современная ортодоксальная практика игнорирует влияние большого размера порций работ, она также не делает акцент на снижении транзакционных издержек. Фактически, только 3% разработчиков имеют официальную программу по снижению транзакционных издержек.
#7 — Недозагрузка каденций/итераций
Современные процессы разработки обычно передают информацию асинхронно, большими порциями. Процесс, основанный на потоке, предоставляет информацию в регулярном режиме небольшими порциями. На самом деле, регулярность помогает снизить операционные издержки и делает небольшие порции более экономически целесообразными. Давайте рассмотрим простой пример. Во многих компаниях производство хочет получить от инженеров полностью готовый проект (предполагаемой в разработке порции изменений). Они говорят инженерам, что не хотят видеть никаких чертежей, пока инженеры не прекратят вносить изменения в дизайн и проект. Когда дизайн и проект готовы, они рассматриваются одной большой порцией работ. Все 200 дизайн-проектов могут быть рассмотрены в один день. Компании считают, что это повышает эффективность работы рецензентов, поскольку они могут видеть весь проект сразу. Но эти 200 проектов были выполнены не за один день. Они могли быть выполнены в течение 10 недель. Первые 20 чертежей, которые были завершены, возможно, ждали рассмотрения 9 недель. Что произошло за эти 9 недель? Если инженер сделал неверное предположение в одном из первых 20 чертежей, то это неверное предположение останется неоспоренным до финальной рецензии. Без обратной связи с рецензией это неверное предположение может быть включено еще в 180 чертежей. Разбивая рассмотрение чертежей на небольшие порции, мы повышаем качество, эффективность и время цикла.
Но как сделать так, чтобы все эти небольшие совещания не приводили к увеличению накладных расходов? Мы проводим эти совещания регулярно и в определенные сроки. Каждую среду в 13:00 мы рассматриваем все чертежи, выполненные за последнюю неделю. Нет необходимости в объявлении о встрече и согласовании расписания. Совещания, синхронизированные с регулярной и предсказуемой периодичностью, имеют очень низкие затраты на организацию. На них приходится очень мало лишних накладных расходов.
В главе 6 мы увидим, почему каденция и синхронизация являются удивительно мощными инструментами для разработки продукта. Мы узнаем, как каденция помогает контролировать прогрессирующее накопление вариативности в процессах разработки. Сегодняшняя ортодоксальная практика ограничивает объем работ и загоняет изменчивость во временные рамки. Новая парадигма ограничивает сроки и загоняет изменчивость в рамки работ. Эти два подхода кардинально отличаются друг от друга.
#8 — Управление сроками вместо очередей
Мы уже отмечали, что компании не управляют очередями разработки продуктов. Чем же они управляют? Сроками. Сегодняшняя ортодоксия делает акцент на управлении сроками, а не на управлении очередями процессов. Мы обучаем наших менеджеров проектов тому, как создавать эти сроки и как ими управлять. По сути, это та же ошибка, которую мы совершали в производстве до появления производственной системы Toyota (TPS, Toyota Production System). Мы создавали подробные графики с помощью наших систем планирования производства. Чем детальнее мы составляли планы, тем больше становилось время цикла.
Мы предпочитаем крайне детальное планирование, потому что не понимаем статистику изменчивости. Непонимание изменчивости опасно в повторяющемся мире производства, но это еще более опасно при разработке продукта, где изменчивость и вариативность гораздо выше (прим. пер. — подразумевается, что в сфере производства работы преимущественно однотипны и предсказуемы, однако, есть место вариативности).
Большинство разработчиков продуктов не понимают статистику высоко гранулированных и подробных графиков. Гранулированный график делит временные интервалы на очень маленькие отрезки. Когда мы это делаем, коэффициент вариации для каждого из этих отрезков становится очень высоким. Это делает дисперсию очень высокой, а соответствие — маловероятным. Хуже того, если мы настойчиво поощряем соответствие графику, люди будут создавать резервы на случай непредвиденных обстоятельств, чтобы их задачи не выбивались из графика. Чем более детализированным является расписание, тем больше резервы для выполнения запланированных работ. И эти резервы суммируются в еще более длинные сроки. Чем больше мы увеличиваем детализацию планирования и чем сильнее пытаемся стимулировать производительность, тем хуже становится наша проблема.
В отличие от этого, когда мы делаем акцент на потоке, мы сосредотачиваемся на очередях, а не на сроках. Очереди — гораздо лучшая переменная управления, чем время цикла, потому что, как вы увидите, очереди являются опережающими индикаторами будущих проблем с временем цикла. Контролируя размер очереди, мы автоматически достигаем контроля над сроками.
Наша слепота в отношении очередей и непонимание изменчивости скрывают эту возможность. Нынешняя ортодоксия сосредоточена на планировании и управлении сроками, вместо более мощного подхода — управления очередями.
#9 — Отсутствие ограничений незавершенной работы
Один из самых мощных способов управления очередями — использование ограничений WIP. Эта техника практически отсутствует в современных процессах разработки. Только 3% разработчиков используют ограничения WIP. Напротив, в современном производстве (manufacturing) этот метод широко распространен. Один из самых ярких примеров — система канбан, используемая компанией Toyota (прим. пер. — справедливо было бы заметить, что с 2010 года прошло достаточно много времени и сейчас, вероятно, автор не стал бы так радикально заявлять об отсутствии практик управления ограничениями WIP в разработке).
В главе 7 с помощью теории очередей мы рассмотрим силу ограничений WIP и их влияние на время цикла. Ограничения WIP еще более важны в продуктовой разработке, чем в производстве, потому что продуктовая разработка имеет большую внутреннюю изменчивость.
Если мы ограничимся относительно простыми ограничениями WIP, используемыми в бережливом производстве, мы не сможем в полной мере использовать возможности ограничений WIP. Вместо этого мы изучим некоторые из более продвинутых идей, используемых в мире телекоммуникаций.
Если бы мы показали производственную систему Toyota специалисту по интернет-протоколам, он, скорее всего, заметил бы: «Это механизм управления очередями tail-dropping FIFO. Это то, с чего начинался Интернет 30 лет назад. Сейчас мы уже на четыре поколения превзошли этот метод». Я упоминаю об этом, чтобы побудить вас взглянуть на подходы к потоку управления не только в производственной (manufacturing) сфере.
Как упоминалось ранее, в производстве (manufacturing) существует передовой взгляд на то, как достичь потока при наличии четырех условий: предсказуемые и повторяющиеся задачи, однородные затраты на задержку и однородная продолжительность выполнения задач. В разработке продукта эти четыре условия практически никогда не присутствуют.
В главе 7 я познакомлю вас с более продвинутыми идеями, пришедшими из других областей. Очень важно, что в этих других областях поток достигается не за счет устранения изменчивости; они разработали методы, позволяющие достичь потока в условиях высокой изменчивости. В результате эти методы чрезвычайно актуальны для разработчиков продуктов.
#10 — Отсутствие гибкости
В погоне за эффективностью разработчики продуктов используют специализированные ресурсы, загруженные до высокого уровня использования (прим. пер. — как ранее и описывалось, фокус на максимальной загрузке и результативности использования ресурса, и это типичная прокси-величина, не отражающая экономически обоснованную эффективность).
Наша современная ортодоксия принимает негибкость в обмен на эффективность. Но что происходит, когда эта негибкость сталкивается с изменчивостью? Мы получаем задержки. Что же делать? Современная ортодоксия предлагает сосредоточиться на изменчивости. Мы можем уменьшить эту изменчивость напрямую или создать буферы и резервы для маскировки изменчивости.
Я уже объяснял, почему снижение изменчивости не является выходом. Позже в этой книге вы увидите, что буферы и резервы — тоже опасный подход. За снижение изменчивости они платят временем цикла, которое является очень дорогим параметром для обмена на снижение изменчивости.
Разработка продуктов на основе потока предполагает, что наши процессы разработки могут быть эффективными и оперативными в условиях изменчивости. Для этого мы должны сделать ресурсы, людей и процессы адаптивными. Некоторые уроки того, как это сделать, мы можем почерпнуть на наших заводах, а еще больше — в телекоммуникационных сетях. На наших фабриках мы создаем гибкость, платя больше тем рабочим, которые могут работать на большем количестве станций производственной линии. Мы ценим адаптивность и платим за нее. В отличие от этого, большинство организаций, занимающихся разработкой продуктов, поощряют исключительно специализацию.
В телекоммуникационных сетях мы используем адаптивные подходы, которые позволяют нам приспосабливаться к возникающим перегрузкам менее чем за секунду. В области разработки продуктов мы еще не осознали огромную ценность адаптивности как явной стратегии использования экономических преимуществ изменчивости. Вместо этого мы все еще пытаемся устранить или скрыть изменчивость.
#11 — Контроль потока разработки, не опирающийся на экономические факторы
Существует множество систем, используемых для управления потоками в современных процессах разработки, но, к сожалению, ни одна из них не основана на экономике. Некоторые компании придерживаются подхода производителей, когда задания обрабатываются в последовательности FIFO. Это имеет смысл в классическом производстве, поскольку задачи, как правило, однородны. Все они предъявляют одинаковые временные требования к ресурсам и имеют одинаковую стоимость задержки. Эти два условия практически никогда не встречаются при разработке продукта.
Другие компании расставляют приоритеты на основе показателей рентабельности проекта, таких как возврат инвестиций (ROI, Return Of Investment). На первый взгляд, это экономический подход, но это лишь иллюзия.
Расставляя приоритеты, мы предполагаем реализовывать один проект раньше другого. Как правило, лучше всего отложить проект с низкой стоимостью задержки. Это говорит о том, что мы не должны определять приоритеты только лишь по прибыльности самой по себе, приоритизация должна учитывать так же, как на эту прибыльность влияет задержка. Конечно, это можно сделать только тогда, когда мы знаем стоимость задержки, а такой информации нет у 85% разработчиков.
Однако, другие компании используют более сложные методы, например концепцию «Критической цепи» Голдратта.
Концепция критической цепи (Critical Chain Project Management, CCPM), разработанная Элияху Голдраттом, — это метод управления проектами, который фокусируется на оптимизации использования ресурсов и минимизации задержек.
Основные идеи:
- Критическая цепь — это последовательность задач, определяющая минимальное время выполнения проекта с учетом ограничений ресурсов.
- Буферы — вместо добавления резервов времени к каждой задаче, создаются общие буферы (проектный, ресурсный, фидерный) для защиты от неопределенностей.
- Фокус на ресурсах — учитывается доступность ключевых ресурсов, чтобы избежать простоев и конфликтов.
- Устранение мультизадачности — ресурсы сосредотачиваются на одной задаче до её завершения, что ускоряет выполнение.
- Цель — повысить предсказуемость и скорость выполнения проектов, минимизируя потери времени и ресурсов.
При таком подходе каждый проект снабжается буфером, а приоритет отдается проекту с наименьшим оставшимся буфером. В классической теории составления расписаний этот метод называется «минимальное время простоя первым» (Minimum Slack Time First, MST) (прим. пер. — это алгоритм планирования задач, при котором приоритет отдаётся задаче с наименьшим резервным временем (slack time). Чем меньше slack time, тем более срочной считается задача. Приоритет отдаётся задаче, у которой slack time «минимальный», ближе к обещанному сроку).
Этот метод MST может побудить вас направить ресурсы на работу с низкой стоимостью задержки и истощенным буфером, а не на работу с высокой стоимостью задержки, которая опережает график. Это противоположно тому, что предлагает экономический взгляд.
Сегодня не существует зрелого метода для управления потоками, если только мы не считаем игнорирование экономики методом. Опять же, мы можем проследить эту проблему до ключевой точки — отсутствия экономического понимания. Хороший экономический фреймворк решает многие дилеммы планирования.
#12 — Централизованный контроль
Наконец, сегодняшняя ортодоксальная практика разработки продуктов склонна к централизованному управлению. Мы создаем офисы управления проектами. Мы создаем централизованные информационные системы. Мы централизуем буферы, чтобы воспользоваться преимуществами эффективности такого подхода. Наше внимание к централизации возникает потому, что мы ценим результативность больше, чем время отклика. Мы увидим, что это ошибка, в главе 8, когда будем рассматривать роль быстрой обратной связи.
Разработчики продуктов часто избегают децентрализованного управления, потому что боятся, что децентрализация приведет к хаосу. Я надеюсь предложить другой взгляд на децентрализацию. Один из самых интересных примеров децентрализации управления без потери согласованности — это способ, которым военные справляются с неопределенностью в условиях войны. Мы изучим их подход в главе 9 и рассмотрим, как его можно применить в разработке продуктов.
Надеюсь, к этому моменту я убедил вас взглянуть на существующую ортодоксию более критически. У нее есть серьезные проблемы, и есть логичные способы их решить. Первый шаг, как и в любом изменении — признать, что существующий порядок вещей необходимо изменить.
