Вторая причина возникновения очередей в процессе разработки продуктов связана с размером партии. Предположим, что новый продукт состоит из 200 компонентов. Один вариант работы состоит в том, чтобы спроектировать и создать все 200 частей, а затем заняться их тестированием. Если бы вы вместо этого создали и построили перед началом тестирования всего 20 компонентов, то размер партии был бы на 90 % меньше. Это оказало бы огромное влияние на продолжительность пребывания в очереди, поскольку средний размер очереди прямо пропорционален размеру партии.
Уменьшение размера партии – важнейший принцип бережливого производства. Небольшие партии позволяют производителям резко снизить объемы незавершенного производства и ускорить обратную связь, которая, в свою очередь, улучшает показатели продолжительности цикла, качества и эффективности. Более того, небольшие партии позволяют заметно улучшить качество разработки продуктов, однако мало кто из разработчиков понимает силу этого метода.
Одна причина связана с природой их рабочих процессов. Поскольку создаваемая ими информация практически не видна, они не замечают и размера партий. Во-вторых, разработчикам часто присуще определенное предубеждение в пользу больших партий – возможно, из-за того что они ошибочно верят в то, что большие партии приводят к экономии на масштабах производства.
В хорошо управляемом процессе размер партии позволит сбалансировать транзакционные издержки и издержки владения (см. врезку «Как определить оптимальный размер партии»). Это чем-то напоминает покупку яиц в магазине. Вы можете купить за один визит годовой запас яиц, однако большинство из них со временем испортится, в результате чего у вас вырастут издержки владения. С другой стороны, если вы каждый раз покупаете запас на один день, яйца не испортятся, однако вырастут ваши транзакционные издержки (поскольку вам придется чаще ходить в магазин). Интуитивно вы пытаетесь установить верный баланс между этими двумя вариантами.
Компании, которые понимают, как это работает, уже сейчас используют передовые методы информационных технологий для снижения размера партии – причем зачастую с потрясающими результатами. Некоторые производители программного обеспечения, которые прежде тестировали крупные куски программ каждые 90 дней, теперь тестируют намного меньшие партии по нескольку раз в день. Один производитель периферийных компьютерных устройств, использовавший такой подход, смог снизить продолжительность цикла тестирования программ на 95 % (с 48 до 2,5 месяца), повысить эффективность на 220 % и снизить количество дефектов на 33 %. Экономия оказалась в два раза выше, чем ожидала компания. Хотя эти результаты и можно считать исключительными, мы обнаружили, что снижение размера партии позволяет значительно улучшить состояние большинства исследовательских проектов. Аналогичным образом, инструменты компьютерного моделирования позволили значительно снизить оптимальный размер партии экспериментов и тестирования в компаниях, разрабатывающих физические продукты.
Изменения в размере партии влияют на два основных вида издержек: транзакционные издержки и издержки владения. По мере увеличения размера партии растет средний размер складских запасов, а следовательно, и издержки владения. Однако в то же самое время снижаются транзакционные издержки, поскольку вам нужно меньше транзакций для удовлетворения спроса.
Оптимальный размер партии – это точка, в которой общие издержки (сумма транзакционных издержек и издержек владения) оказываются наименьшими. Когда компания работает на уровне, близком к этой точке, небольшие отклонения имеют небольшое влияние. К примеру, если компания работает на уровне, на 20 % большем или меньшем оптимального размера партии, общие издержки растут менее чем на 3 %. Поэтому даже грубая оценка позволяет компании извлекать значительные экономические преимущества.
Заблуждение 3: наш план разработки прекрасен, и нам нужно просто придерживаться его
За все время нашей исследовательской и консультационной работы нам никогда не доводилось видеть проект по разработке продуктов, требования к которому не менялись бы в ходе процесса работы. Однако многие организации глубоко верят в свои планы, причем без особых оснований. Любые отклонения от плана они объясняют плохим управлением или реализацией. А чтобы минимизировать влияние этих проблем, они тщательно сравнивают результаты каждого шага с промежуточными целями. Такое мышление отлично подходит для деятельности с высокой степенью повторяемости в устоявшихся производственных процессах. Однако оно может привести к плохим результатам в инновационных процессах, связанных с разработкой продуктов, где постоянно появляется новое знание и постоянно меняются условия.
Гибкую природу исследовательской работы можно увидеть на примере классического исследования, проведенного Томасом Алленом из МТИ. Он обнаружил, что инженеры, разрабатывавшие одну аэрокосмическую подсистему, создали ряд альтернативных решений и только потом выбрали из них одно, которое посчитали лучшим. По ходу работы у них часто менялись предпочтения, поскольку они постоянно тестировали и уточняли конкурировавшие между собой технические решения. Это вполне типично для инновационных проектов – тестирование и эксперименты позволяют увидеть, что работает, а что нет. И в ходе работы часто оказывается так, что нам приходится отказываться от своих изначальных предположений относительно издержек и ценности того или иного решения.
Зачастую в самом начале работы над проектом бывает сложно определить точные потребности клиентов. Если задуматься, то в этом нет ничего удивительного – клиентам довольно непросто рассказать о своих потребностях в отношении еще не существующих решений. Более того, знакомство с уже имеющимися атрибутами продукта помет помешать человеку четко выразить свои потребности в отношении новинок. Предпочтения клиентов могут сильно меняться в процессе разработки, как из-за действий конкурентов, предлагающих альтернативные решения, так и из-за изменения общих тенденций в поведении потребителей.
Вследствие всех этих причин попытки любой ценой придерживаться изначального плана – вне зависимости от идеальной концепции или умелого исполнения – могут привести к катастрофе. Мы не хотим сказать, что совершенно не верим в планирование. Разработка продукта – это набор довольно сложных действий, требующих тщательной координации и внимания к мельчайшим деталям. Однако к плану надо относиться как к изначальной гипотезе, которая постоянно уточняется по мере появления новых свидетельств, изменения экономических предположений и переоценке идеи (см. статью «The Value Captor’s Process», Rita Gunther McGrath and Thomas Keil, HBR, May 2007).
Заблуждение 4: чем быстрее начнется работа над проектом, тем быстрее она будет завершена
Как мы уже обсудили выше, многие менеджеры подвергают анафеме саму идею свободного времени. Они склонны использовать каждую минуту и зачастую затевают с этой целью новые проекты. Даже если задача не может быть выполнена из-за того, что люди должны возвращаться к предыдущему проекту, менеджеры считают, что любая работа, проделанная на новом проекте, – это работа, которой не придется заниматься потом. Такое мышление заставляет компанию запускать больше проектов, чем она может потянуть. В итоге возникает размывание ресурсов.
И это размывание очень опасно. Если компания запускает проект при отсутствии достаточных ресурсов, то в какой-то момент в процессе разработки наступит коллапс. И проблема здесь состоит в том, что результаты в процессе разработки продукта имеют очень короткую жизнь – любые наши предположения относительно технологии и рынка могут быстро устареть. Чем медленнее развивается проект, тем выше вероятность, что нам придется изменить его направление. К примеру, военные специалисты обнаружили, что отставание от графика и рост затрат пропорциональны (в четвертой степени) продолжительности проекта. Иными словами, когда срок работы над проектом увеличивался в два раза относительно изначального, затраты и отставание от графика вырастали в 16 раз.
Контрольные панели превращают прежде невидимую работу в видимую, поскольку позволяют четко понять, на каком этапе находится каждый проект. В процессе создания панелей большинство команд ограничивают количество задач на каждой стадии для предотвращения задержек. На данной простой панели приведены данные о проекте по разработке программного обеспечения, над которым работает команда из 6–10 человек.
Важность снижения объемов незавершенной работы становится довольно очевидной, когда мы смотрим на одну из классических формул теории очередей – так называемый Закон Литтла. Согласно ему, продолжительность цикла в среднем пропорциональна частному от деления размера очереди на скорость обработки. Таким образом, если перед вами в очереди в Starbucks стоит 20 человек, а бариста обслуживает пять человек в минуту, то вы получите свой кофе через четыре минуты. Вы можете сократить продолжительность цикла, повышая скорость работы или снижая количество необходимых операций. В большинстве случаев единственным практичным вариантом действий остается первый.
Для некоторых разработчиков продуктов решение было связано с тщательным контролем над скоростью, с которой они начинают работать. Затем они сравнивают эту скорость со скоростью, с которой завершается работа над проектом; тщательно управляют количеством проектов в работе; они проверяют, чтобы на запущенном в работу проекте работало достаточное количество человек вплоть до его завершения; а кроме всего прочего, они сопротивляются искушению забирать ресурсы у проекта в работе и переключать их на новые.