Вторая причина возникновения очередей в процессе разработки продуктов связана с размером партии. Предположим, что новый продукт состоит из 200 компонентов. Один вариант работы состоит в том, чтобы спроектировать и создать все 200 частей, а затем заняться их тестированием. Если бы вы вместо этого создали и построили перед началом тестирования всего 20 компонентов, то размер партии был бы на 90 % меньше. Это оказало бы огромное влияние на продолжительность пребывания в очереди, поскольку средний размер очереди прямо пропорционален размеру партии.
Уменьшение размера партии – важнейший принцип бережливого производства. Небольшие партии позволяют производителям резко снизить объемы незавершенного производства и ускорить обратную связь, которая, в свою очередь, улучшает показатели продолжительности цикла, качества и эффективности. Более того, небольшие партии позволяют заметно улучшить качество разработки продуктов, однако мало кто из разработчиков понимает силу этого метода.
Одна причина связана с природой их рабочих процессов. Поскольку создаваемая ими информация практически не видна, они не замечают и размера партий. Во-вторых, разработчикам часто присуще определенное предубеждение в пользу больших партий – возможно, из-за того что они ошибочно верят в то, что большие партии приводят к экономии на масштабах производства.
В хорошо управляемом процессе размер партии позволит сбалансировать транзакционные издержки и издержки владения (см. врезку «Как определить оптимальный размер партии»). Это чем-то напоминает покупку яиц в магазине. Вы можете купить за один визит годовой запас яиц, однако большинство из них со временем испортится, в результате чего у вас вырастут издержки владения. С другой стороны, если вы каждый раз покупаете запас на один день, яйца не испортятся, однако вырастут ваши транзакционные издержки (поскольку вам придется чаще ходить в магазин). Интуитивно вы пытаетесь установить верный баланс между этими двумя вариантами.
Компании, которые понимают, как это работает, уже сейчас используют передовые методы информационных технологий для снижения размера партии – причем зачастую с потрясающими результатами. Некоторые производители программного обеспечения, которые прежде тестировали крупные куски программ каждые 90 дней, теперь тестируют намного меньшие партии по нескольку раз в день. Один производитель периферийных компьютерных устройств, использовавший такой подход, смог снизить продолжительность цикла тестирования программ на 95 % (с 48 до 2,5 месяца), повысить эффективность на 220 % и снизить количество дефектов на 33 %. Экономия оказалась в два раза выше, чем ожидала компания. Хотя эти результаты и можно считать исключительными, мы обнаружили, что снижение размера партии позволяет значительно улучшить состояние большинства исследовательских проектов. Аналогичным образом, инструменты компьютерного моделирования позволили значительно снизить оптимальный размер партии экспериментов и тестирования в компаниях, разрабатывающих физические продукты.
Заблуждение 3: наш план разработки прекрасен, и нам нужно просто придерживаться его