Шесть мифов о
разработке продукта

Извечная проблема менеджеров по разработке продукта — как завершить проект в срок и в рамках бюджета. Им постоянно не хватает ресурсов, а вышестоящее руководство требует предсказуемых и конкретных результатов. Менеджеры же давят на разработчиков, добиваясь, чтобы те сокращали издержки, составляли детализированные планы и придерживались утвержденного графика. Такой подход годится для оптимизации серийного производства, однако при разработке продуктов от него больше вреда, чем пользы.

Многие компании действительно относятся к разработке как к производству, хотя эти процессы в корне отличаются друг от друга. Суть производства в изготовлении материальных объектов, его задачи цикличны, этапы предсказуемы, а создаваемый продукт в каждый момент времени находится в строго определенном месте. Напротив, при разработке продукта многие задачи уникальны, требования постоянно меняются, а результат — отчасти из-за широкого применения систем компьютерного проектирования, а отчасти из-за интеграции цифровых технологий в физические изделия — представляет собой информацию, которая хранится одновременно в нескольких местах.

Непонимание этих критических различий порождает заблуждения, которые не позволяют эффективно планировать, реализовывать и оценивать проекты по разработке продуктов. Наш совместный опыт — более 50 лет исследований и консалтинга в области разработки продуктов. На протяжении этих лет мы раз за разом сталкивались с упомянутыми заблуждениями в разных отраслях, будь то производство полупроводников, автомобилей, бытовой электроники, медицинского оборудования, ПО или оказание финансовых услуг. В этой статье мы постараемся развенчать распространенные мифы и расскажем, как можно преодолеть проблемы.

Миф первый: высокая загруженность персонала повышает производительность.

Наши исследования и опыт работы в консалтинге показывают, что большая часть компаний пытается по максимуму загрузить разработчиков. Например, проведя опрос слушателей курсов для руководителей в Калифорнийском технологическом институте, один из нас (Дональд) обнаружил, что менеджеры стремятся поддерживать загрузку разработчиков на уровне более 98%. Казалось бы, логика очевидна: проекты занимают больше времени, если люди не задействованы на 100%. И напротив, чем выше загруженность сотрудников, тем быстрее и эффективнее они разрабатывают новые продукты.

Однако на практике эта логика не работает. Мы констатировали, что независимо от квалификации руководителя скорость, эффективность и качество проектов неизбежно снижаются, когда менеджер пытается выжать все соки из разработчиков. Высокая степень загрузки персонала имеет серьезные негативные последствия, которые руководители недооценивают по трем причинам.

Во-первых, менеджеры не в полной мере учитывают вариативность задач. Многие аспекты разработки продуктов непредсказуемы. Проект может начаться когда угодно и включать самые разнообразные задачи. Среди них могут быть и такие, которые разработчики выполняют впервые, что затрудняет оценку сроков. Однако компании, как правило, опираются на опыт серийного производства или рутинной обработки транзакций, где задачи раз за разом повторяются, а сюрпризы случаются редко. Если изменения и происходят, то их последствия легко прогнозировать: увеличиваем объем работы на 5%, следовательно, нам потребуется на 5% больше времени.

Изменчивые процессы требуют совершенно иного подхода. При росте нагрузки затраты времени увеличиваются экспоненциально (см. рис. «Задержки как следствие высокой загруженности персонала»). Пятипроцентный рост объема работ может привести к двойному увеличению сроков. Однако немногие понимают это: по опыту работы с сотнями команд разработчиков мы знаем, что в большей части случаев они сильно перегружены. Некоторым организациям, с которыми мы работали, потребовалось бы как минимум на 50% больше ресурсов, чтобы завершить все проекты в срок и в рамках бюджета.

Несомненно, неравномерность загрузки может быть следствием недостатка дисциплины, а некоторые задачи по разработке продуктов (например, проектирование компонентов для прототипа самолета или проведение клинических испытаний) нужно выполнять достаточно регулярно. Однако даже если часть работы поддается прогнозированию, выполнение других, спонтанно возникающих задач все равно может вызвать проблемы с очередями.

Во-вторых, руководители не понимают, как очереди проектов влияют на экономическую эффективность. Высокая загрузка персонала неизбежно создает очереди проектов. Когда частично завершенная работа простаивает до тех пор, пока не высвободятся нужные специалисты, продолжительность проекта в целом увеличивается. Очереди также замедляют обратную связь, из-за чего разработчики тратят больше времени на бесполезную работу, двигаясь в неверном направлении. Это мешает компаниям адаптироваться к изменяющимся потребностям рынка и вовремя выявлять слабые места продукта. Как ни парадоксально, именно этих проблем менеджеры стремятся избежать, пытаясь максимизировать загрузку команд.

Даже если руководители понимают, что сами создают очереди, они редко осознают их экономические последствия. Хотя эти издержки можно количественно оценить, мы обнаружили, что большая часть компаний этого не делают. Между тем сопоставив расходы, связанные с задержками, и затраты, вызванные низкой загруженностью работников, руководители могут найти оптимальный баланс.

В-третьих, при разработке продуктов неочевиден объем незавершенного производства. Очереди на производстве вполне осязаемы: когда запасы сырья на складе удваиваются, это очевидно. Однако при разработке продукта незавершенные работы по большей части представляют собой информацию, такую как проектная документация, регламенты и протоколы испытаний или инструкции по созданию прототипов. Даже если объем такого незавершенного производства удваивается, видимых проявлений этого нет. Кроме того, по стандартам бухгалтерии большая часть незавершенных опытно-конструкторских работ отражается в балансе с нулевой стоимостью, а значит, в финансовых отчетах отсутствует информация об их чрезмерных объемах.

Бороться с проблемой, которую невозможно увидеть или измерить, чрезвычайно сложно. Рассмотрим ситуацию в одной крупной фармацевтической компании. Несколько лет назад новый руководитель отдела по разработке новых препаратов столкнулся с управленческой дилеммой. Как и другие высшие руководители крупных организаций в сфере НИОКР, он стремился стимулировать инновации. Он справедливо полагал, что его исследователи должны сосредоточиться на экспериментах с перспективными препаратами и на ранних стадиях отсекать те направления, которые ведут в никуда. Однако деятельность отдела тестирования на животных не входила в его компетенцию. Поскольку этот отдел не генерировал выручку, его работа оценивалась исходя из эффективности использования ресурсов, что, разумеется, вело к высокой загруженности персонала. В результате сотрудники отдела разработки лекарств по три-четыре месяца ждали результатов тестов, которые на самом деле занимали чуть больше недели. Таким образом, «эффективное управление» отделом тестирования не позволяло раскрыть потенциал отдела разработки.

Очевидно, что для решения подобных проблем необходимо предоставлять сотрудникам, занятым в непредсказуемых процессах, резерв времени. Некоторые компании давно это поняли. Уже десятки лет компания 3M устанавливает норму рабочего времени для разработчиков на уровне 85% от полной загрузки, а Google славится своими «20% свободного времени» (один день в неделю инженерам позволено работать над чем угодно, то есть в случае отставания от графика всегда можно привлечь дополнительные ресурсы). Тем не менее, наш опыт показывает, что внедрение подобной системы — непростое дело. Как мы увидим, немногие организации могут устоять перед соблазном выжать из персонала все до последнего. Менеджеры рефлекторно ставят новые задачи, как только замечают, что кто-то не загружен до отказа.

Впрочем, существуют и другие действенные подходы, которые мы рассмотрим ниже.

Изменение системы административного контроля. Для упомянутой фармацевтической компании это могло бы означать меры, направленные на то, чтобы гармонизировать цели отдела тестирования и отдела разработки лекарств. Можно было бы, например, поощрять команду тестировщиков за оперативные ответы (измеряя время с момента запроса до выдачи результата), а не за эффективное использование ресурсов.

Выборочный ввод дополнительных ресурсов. Ввод дополнительных ресурсов на участках, где уровень загруженности составляет 70% и более, может существенно сократить время ожидания. Усилив ресурсное обеспечение отдела тестирования, фармацевтическая компания значительно увеличила бы скорость выдачи результатов тестов. В областях, где можно тестировать продукты с помощью компьютерного моделирования, увеличить мощности можно за счет относительно низких затрат: достаточно приобрести дополнительные компьютеры и лицензии на ПО.

Ограничение количества активных проектов. Если предположить, что фармацевтическая компания не могла увеличить пропускную способность отдела тестирования, она, тем не менее, могла бы снизить его загрузку, уменьшив количество активных проектов по исследованию новых химических соединений. Введение жестких критериев отбора перспективных разработок помогло бы сосредоточиться на главном и четко расставить приоритеты.

Визуализация объемов незавершенных работ. Один из методов визуализации — контрольные доски. Они могут быть оформлены по-разному — главное, чтобы они содержали элементы для наглядной демонстрации хода работ — например, стикеры (см. рис. «Пример контрольной доски для отслеживания незавершенных работ»). Контрольная доска должна отображать все текущие задачи и статус их выполнения. Она должна занять центральное место в процессе управления, помогая скоординировать усилия и оценить продвижение работы на ежедневной 15-минутной «летучке».

Миф второй: обработка крупных партий повышает экономические показатели.

Вторая причина образования очередей задач в процессе разработки продукта — это размеры партий. Допустим, новый продукт состоит из 200 компонентов. Можно разработать и изготовить все 200 деталей, прежде чем начать тестирование. Однако, если приступить к тестированию, разработав и изготовив только 20 компонентов, то размер партии будет на 90% меньше. Это сильно сократит время ожидания, поскольку средняя длина очереди прямо пропорциональна размеру партии.

Сокращение размеров партий — ключевой принцип бережливого производства. Небольшие партии позволяют производителям уменьшить количество незавершенных работ и ускорить получение обратной связи, что помогает снизить продолжительность циклов, одновременно повысив качество и эффективность. Такой подход тем более оправдан, если речь идет о разработке продуктов, но лишь немногие специалисты осознают его несомненные преимущества.

Одна из причин — особенности процесса разработки. Продукт — это информация, объем которой сложно себе представить. Это затрудняет оценку размеров партий. Кроме того, разработчики подвержены стереотипу, предполагая, что большие партии помогают сэкономить за счет объема.

В оптимально отлаженном процессе размер партий сбалансирован с учетом операционных затрат и стоимости хранения (см. рис. «Как определить оптимальный размер партии?»). Это все равно что покупать яйца в продуктовом магазине. Если вы разом закупитесь на целых 12 месяцев, снизите операционные издержки, но большая часть яиц испортится, соответственно, потребуются либо дополнительные затраты на хранение, либо на закупку новой партии. Если же вы приобретете запас на один день, уровень порчи будет низким, но зато подскочат операционные расходы. Интуитивно вы пытаетесь найти оптимальный баланс.

Компании, которые понимают, как это работает, используют преимущества информационных технологий для оптимизации размеров партий, нередко достигая поразительных результатов. Некоторые компании-разработчики ПО, которые раньше тестировали большие отрезки кода каждые 90 дней, теперь проводят тестирование значительно меньших фрагментов несколько раз в день. Производитель периферийного оборудования, применив подобный подход в группе разработки ПО, сократил длительность цикла тестирования ПО на 95% (с 48 до 2,5 месяцев), повысил эффективность на 220% и снизил количество дефектов на 33%. Экономия вдвое превзошла ожидаемые показатели. Хотя столь исключительных результатов добиваются не все, мы обнаружили, что уменьшение размера партий значительно повышает результативность большей части проектов в сфере разработки. В то же время благодаря средствам компьютерного моделирования производители материальных продуктов значительно оптимизируют издержки, уменьшая размер партий опытных и тестовых образцов.

Миф третий: у нас отличный план, надо просто его придерживаться.

За все годы, что мы занимаемся консалтингом и исследованиями в области разработки, мы ни разу не встретили проект, в котором требования к продукту оставались бы неизменными от начала и до конца. Тем не менее, многие организации свято верят в необходимость следовать плану. Любые отклонения от него считаются признаком плохого управления или некомпетентности исполнителей, и, чтобы их минимизировать, руководство внимательно следит за выполнением промежуточных целей по каждому этапу. Такой подход оправдан для цикличных производственных процессов, операции в которых раз за разом повторяются. Однако, когда речь идет о проектах по разработке инновационных продуктов, где каждый день возникают новые идеи, а условия то и дело меняются, такая стратегия может быть пагубной.

В своем классическом исследовании, посвященном решению технических проблем, профессор MIT Томас Аллен делает акцент на изменчивости процесса разработки. Он отмечает, что инженеры, работавшие над одной из подсистем в аэрокосмическом проекте, всегда предлагали и оценивали несколько вариантов решения, прежде чем выбрать наилучший из них. В процессе проектирования их предпочтения часто менялись, по мере того как они тестировали и усовершенствовали альтернативные варианты конструкции. Для инновационных проектов это типично: тестирование и эксперименты показывают, какие решения работают, а какие нет, так что исходные предположения о затратах и гипотезы о ценности продукта могут быть пересмотрены.

Определить потребности заказчика на начальном этапе проекта — тоже непростая задача. В этом нет ничего удивительного: заказчику сложно описать требования к решению, которого еще не существует. На самом деле, знание характеристик существующих продуктов тоже может помешать заказчику точно сформулировать свойства чего-то принципиально нового. К тому же предпочтения клиентов могут резко меняться, когда конкуренты анонсируют новые продукты и возникают новые тенденции.

Поэтому, каким бы совершенным ни был первоначальный план и сколь бы искусно он ни исполнялся, стремление неотступно следовать ему может довести до катастрофы. Это не означает, что мы не верим в планирование. Разработка продукта — это сложный набор действий, требующих тщательной координации и внимания к мельчайшим деталям. Однако план следует рассматривать как начальную гипотезу, которая постоянно пересматривается по мере появления новых данных, изменения экономических оценок и конъюнктуры.

Миф четвертый: быстрее начнем — быстрее закончим.

Мы уже упоминали о том, что менеджеры как огня боятся простоя сотрудников. Стоит им заметить, что кто-то загружен не полностью, они тут же начинают новый проект, причем даже тогда, когда понимают, что довести его до конца нет никакой возможности. Они рассуждают так: все, что мы успеем сделать сейчас, не придется делать позже. В результате компании начинают больше проектов, чем могут осилить, и без толку распыляют ресурсы.

Эта тактика опасна. Начиная разработку продукта, несмотря на нехватку ресурсов, компания вступает на долгий и мучительный путь. Проблема усугубляется еще и тем, что результат труда разработчиков — весьма скоропортящийся продукт: технологии быстро устаревают, а рынок стремительно меняется. Чем медленнее идет проект, тем выше вероятность того, что его придется пересмотреть. Например, одно военное ведомство обнаружило, что затраты на оплату услуг разработчиков возрастают в экспоненциальной зависимости от продолжительности проекта. Другими словами, когда первоначальный срок проекта удваивался, расходы увеличивались в 16 раз.

Важность сокращения объемов незавершенных работ очевидна, если взглянуть на одно из классических уравнений теории очередей: закон Литтла. Суть его в том, что среднее время цикла пропорционально длине очереди, деленной на скорость обработки заказов. Проще говоря, если вы стоите в очереди в Starbucks, перед вами 20 человек, а бариста обслуживает пять человек в минуту, вас обслужат через четыре минуты. Вы можете сократить время цикла, увеличив скорость обслуживания или уменьшив количество выполняемых задач. В большинстве случаев на практике осуществимо только последнее.

Некоторые разработчики успешно справляются с этой проблемой. Они строго следят за тем, чтобы темпы выполнения работ сохранялись на первоначальном уровне, а количество одновременно реализуемых проектов не превышало разумных пределов. Начиная проект, они обеспечивают его персоналом вплоть до завершения и не выдергивают людей из текущих проектов, чтобы заткнуть дыры в новых.

Миф пятый: чем больше у продукта опций, тем больше он понравится потребителю.

Многие разработчики, похоже, убеждены, что ценность продукта для потребителя заключается в количестве функций: чем их больше, тем лучше. Наверное, поэтому нам приходится ломать голову, чтобы разобраться с неимоверным количеством кнопок на пультах дистанционного управления, тратить часы на настройку компьютера, а в наших автомобилях так много ручек и выключателей, что они напоминают кабины самолетов. В наши дни даже скромный тостер оснащен ЖК-дисплеем и поставляется с руководством по эксплуатации.

Однако некоторые компании опровергают миф о том, что больше значит лучше, создавая продукты, которые отличаются элегантностью и простотой. Bang & Olufsen, датский производитель аудиотехники, телевизоров и телефонов, понимает, что далеко не всем доставляет удовольствие возиться с эквалайзером, балансом каналов и другими настройками, чтобы послушать музыку с оптимальным качеством звука. Высокотехнологичные акустические системы Bang & Olufsen делают все это сами, а их владельцам остается лишь выбрать громкость воспроизведения.

Сломать стереотип о том, что навороченные продукты привлекательнее для потребителя — непростая задача, так это требует от компаний нового взгляда на две важные области разработки продукта, о которых речь пойдет ниже.

Определение проблемы

Неумение сформулировать проблему, которую предстоит решить при разработке инновационного решения, — ахиллесова пята многих компаний. Как правило, этому уделяют слишком мало времени и внимания. Однако этап постановки задачи чрезвычайно важен, ведь он помогает разработчикам четко понять цели и сформулировать гипотезы, которые можно проверить и уточнить посредством экспериментов. Качество постановки задачи определяет способность команды сосредоточиться на тех аспектах продукта, которые действительно имеют значение.

Проектируя Диснейленд, Уолт Дисней не стремился перещеголять все прочие парки развлечений по количеству аттракционов, кафе или парковочных мест. Он начал с гораздо более общего вопроса: как создать для посетителей атмосферу волшебства? Конечно, ответ пришел не сразу: для этого потребовались тщательные исследования, постоянные эксперименты и глубокое понимание того, что именно означает «волшебство» для самого Диснея и его клиентов. Такие компании, как IDEO, полагают, что погружение в контекст — полноценный этап разработки продукта или услуги. Их разработчики собирают информацию о рынках, наблюдают за будущими пользователями, беседуют с ними и изучают предложения потенциальных конкурентов. Эти сведения, обобщенные в виде графиков, моделей и диаграмм, ложатся в основу обоснованных предположений о запросах потребителя, которые проверяются, корректируются или отбрасываются в процессе разработки.

Что следует скрыть или исключить?

У разработчиков часто возникает искушение поразить коллег и руководство, выставив напоказ свои блестящие технические решения. Однако потребители зачастую предпочитают продукт, который просто эффективно работает и не требует дополнительных усилий. Им нет дела до технических ухищрений, которыми так гордятся разработчики.

Apple — одна из тех компаний, где осознали этот факт. Она известна множеством инновационных продуктов, стильным дизайном и искусным маркетингом, но главная ее сила, пожалуй, заключается в способности докапываться до сути проблемы. (См. статью Уолтера Айзексона «Вся правда о Стиве Джобсе», https://big-i.ru/150ideas/leader_rules/812793/.) Стив Джобс говорил: «Когда, начиная размышлять над проблемой, вы понимаете, что она очень проста, вы просто не понимаете ее сложность. Как следствие, ваши решения слишком примитивны. Затем вы вникаете в проблему и осознаете ее запутанность. Теперь вы предлагаете крайне мудреные решения... Вот здесь-то большинство людей и останавливается». Но только не Apple. Сотрудники компании продолжают напрягать мозги. «По-настоящему великие люди бьются над проблемой до тех пор, — говорил Джобс, — пока не найдут ее суть и не смогут предложить красивое, элегантное решение, которое будет работать».

К сожалению, многие компании, стремясь прослыть инновационными, перегружают свои продукты всевозможными «наворотами», забывая о таких важных факторах, как ценность для потребителя и простота использования. Если они и отказываются от некоторых запланированных функций, то обычно делают это вынужденно, пытаясь сократить затраты, наверстать отставание от графика или исправить просчеты в работе команды.

Наш совет менеджерам — целенаправленно задумайтесь над тем, нельзя ли улучшить продукт, удалив из него что-нибудь ненужное и тем самым позволив команде сфокусироваться на том, что действительно порадует потребителя. Определить востребованность той или иной функции можно, рассматривая каждую предполагаемую потребность пользователя как гипотезу и проверяя ее в быстрых, коротких экспериментах с потенциальными покупателями. Разработчики часто полагают, что продукт готов, если в его функционал уже не втиснуть дополнительные опции. Возможно, их логика должна быть обратной: продукт приближается к совершенству, когда ни одну из его функций нельзя удалить. Леонардо да Винчи говорил: «Простота — наивысшая степень утонченности».

Миф шестой: мы добьемся большего успеха, если с первого раза все сделаем правильно.

Многие проекты в сфере разработки продуктов не укладываются в сроки, выходят за рамки бюджета и не справляются с техническими задачами. Несомненно, просчеты в планировании, косность процедур и неумелое руководство влияют на конечный результат. Однако еще одна причина неудач, которую часто упускают из виду, заключается в том, что менеджеры хотят, чтобы команда сделала «все как надо с первого раза». Такое требование подталкивает разработчиков в сторону наименее рискованных решений, даже если они не ведут к значительным усовершенствованиям с точки зрения потребителя. Что еще хуже, это убивает в разработчиках стремление к инновациям.

Опасаясь ошибок, команда неукоснительно следует этапам проекта: постановка задачи, проектирование, разработка, тестирование, масштабирование, запуск. Каждый из этапов завершается точкой контроля, и работу над следующим нельзя начинать, пока не согласован предыдущий. Чем дальше продвигается проект, тем большие обязательства взваливает на себя команда, а затраты на их выполнение нарастают как снежный ком. Успешные испытания на поздних этапах вызывают всеобщее ликование, зато любые неожиданные результаты, как бы ценны они не были, воспринимаются как провал. К сожалению, такой линейный подход чреват перерасходом бюджета: обратная связь от тестировщиков запаздывает, и команда непозволительно долго движется в неправильном направлении. Когда же приходит время корректировать курс, оказывается, что стоимость изменений непомерно высока.

Предоставить разработчикам «право на ошибку» на первом этапе — более эффективная стратегия, при условии, что они быстро перестраиваются и извлекают уроки из своих ошибок. Современные технологии симуляции и быстрого прототипирования существенно облегчили и удешевили работу в таком режиме.

Рассмотрим, результаты нашего исследования, в котором участвовали более 390 команд разработчиков специализированных микросхем. Те из них, кто применял итеративный подход и проводил частые тесты на ранних этапах, допускали больше ошибок. Однако благодаря использованию низкозатратных технологий прототипирования они тратили меньше времени и усилий, чем команды, которые пытались достичь идеального результата с первого раза. Командам, применявшим более затратные методы создания прототипов, пришлось вложить больше усилий в согласование техзаданий, разработку и приемочные испытания. Кроме того, начав тестировать продукты значительно позже и, соответственно, проведя гораздо меньше итераций, они с опозданием выявляли критические проблемы.

Быстрые и частные эксперименты, цель которых на практике проверить как можно больше рабочих гипотез, — ключевой элемент инновационных проектов. Разумеется, эксперименты выявляют несостоятельность многих новаторских идей. Но на раннем этапе эти неудачи полезны: они позволяют команде вовремя отсечь тупиковые направления и сосредоточиться на перспективных. Не беда, если краш-тест выявляет изъяны в системе безопасности автомобиля, многообещающий препарат по результатам теста оказывается токсичным, а пользовательский интерфейс программы сбивает участников эксперимента с толку. Напротив, это можно считать удачей, при условии, что отрицательные результаты получены на ранних стадиях разработки, когда потрачено не так много ресурсов и вы все еще можете кардинально поменять траекторию проекта и опробовать другие решения.

Учиться на ошибках — эффективная стратегия. Подтверждение тому — памятная победа команды Новой Зеландии в регате на Кубок Америки 1995 года. Работая над усовершенствованием конструкции киля, новозеландцы использовали две практически идентичные яхты: одну из них модифицировали по результатам экспериментов, а вторую — контрольную — оставляли без изменений. Ежедневно команда создавала компьютерные симуляции на локальной графической станции. Наиболее многообещающие из них воплощались в конструкции киля экспериментальной яхты. Затем ее ходовые характеристики сравнивали с контрольной и анализировали результаты. Соперники новозеландцев — команда Денниса Коннера — имели доступ к более мощным вычислительным мощностям (суперкомпьютерам Boeing). Они разрабатывали симуляции крупными сериями каждые несколько недель, а затем проверяли перспективные решения на одной лодке. В итоге победила команда Новой Зеландии, которая провела гораздо больше экспериментальных циклов и раньше отказалась от неудачных идей.

Надеемся, что теперь наша мысль понятна: эксперименты, приводящие к неудачам, не следует считать неудачными. Благодаря им генерируются новые неожиданные данные. Чем интенсивнее проводятся эксперименты, тем больше информации можно собрать и включить в последующие циклы, отрабатывая новые смелые гипотезы. При таком подходе сотрудники не опускают руки перед лицом неудач, приветствуют работу, требующую напряжения сил, и, как следствие, превосходят своих боязливых конкурентов.

Однако реализовать это на практике не так-то просто: эту тему исследовала Эми С. Эдмондсон из Гарвардской школы бизнеса в статье «Учиться на ошибках — это стратегия». Неудачи нередко приводят работников в замешательство, указывают на пробелы в знаниях и могут подорвать самооценку и статус человека в организации. Будем откровенны, менеджеры нечасто получают повышение (а их команды — вознаграждение) за то, что добиваются закрытия бесперспективного проекта на ранней его стадии, даже если это позволяет вовремя перераспределить драгоценные ресурсы и приносит пользу компании. Тем более, если речь идет об организациях, где культивируется «нулевая терпимость к неудачам» или «безошибочная среда» (6 сигм).

Томас Эдисон как никто другой понимал важность экспериментов, и в его знаменитых лабораториях были созданы самые благоприятные условия для экспериментаторов. Мастерские для строительства моделей располагались неподалеку от помещений, где работали исследователи, чтобы они тесно сотрудничали с инженерами и квалифицированными рабочими. В лабораториях были богатейшие библиотеки для быстрого поиска информацию, а по соседству с ними находились склады со всеми необходимыми материалами. Эдисон стремился к тому, чтобы продуктивные идеи ученых незамедлительно воплощались в рабочих моделях и прототипах. «Настоящее мерило успеха — это количество экспериментов, которые можно провести за 24 часа», — говорил он.

Прогресс в сфере информационных технологий, таких как компьютерное проектирование, моделирование и симуляция, уже сейчас позволяет компаниям обходить конкурентов, создавая превосходные продукты с меньшими затратами времени и денег. Тем не менее, многие менеджеры пока не раскрыли истинный потенциал этих инструментов: управленческое мышление развивается не так быстро, как технологии. Руководители по-прежнему не видят разницу между динамичными проектами по разработке продуктов, результатом которых является информация, и массовым производством. По мере развития ИТ откроется все большие возможностей для оптимизации процесса разработки. Однако будут расти и риски для компаний, не осознавших, что процесс разработки продукта существенно отличается от серийного выпуска продукции.