Библиотека управления

Мифы о разработке продукта, приводящие к задержкам, подрывающие качество и повышающие издержки

Штефан Томке, Дональд Рейнертсен Глава из книги «Инновационный менеджмент», выпуск серии «HBR: 10 лучших статей»
Издательство «Альпина Паблишер»

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

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

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

Заблуждение 1: высокая степень утилизации повышает эффективность

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

Идея вкратце

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

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

  1. Высокая утилизация ресурсов приводит к повышению эффективности работы.
  2. Обработка больших партий более экономична.
  3. Командам необходимо тщательно следовать плану разработки, минимизируя любые отклонения от него.
  4. Чем быстрее начнется работа над проектом, тем быстрее она завершится.
  5. Чем больше свойств имеется у продукта, тем больше он понравится клиентам.
  6. Проекты будут более успешными, если команды «сделают все правильно с первого раза».

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

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

Они не принимают во внимание изменчивость, присущую деятельности по разработке

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

Процессы с высокой степенью изменчивости ведут себя совершенно иным образом. По мере повышения утилизации значительно возрастают задержки (см. врезку «Высокая утилизация приводит к задержкам»). Стоит вам добавить 5% работы, и для ее завершения может потребоваться на 100% больше времени. Однако мало кто понимает суть этого эффекта. Как показывает наш опыт работы с сотнями команд, занимающихся разработкой продуктов, большинство участников проект берут на себя чрезмерно завышенные обязательства. Для завершения всех проектов вовремя и в рамках бюджета некоторым организациям, с которыми мы работали, требовалось как минимум на 50% больше ресурсов, чем у них было.

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

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

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

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

Высокая утилизация приводит к задержкам

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

Незавершенная работа в процессе разработки продукта чаще всего невидима

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

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

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

Однако есть и другие вполне жизнеспособные решения.

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

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

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

Сделайте заметными объемы незавершенной работы.

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

Заблуждение 2: работа с большими партиями улучшает экономические показатели процесса разработки

Вторая причина возникновения очередей в процессе разработки продуктов связана с размером партии. Предположим, что новый продукт состоит из 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 человек, а бариста обслуживает пять человек в минуту, то вы получите свой кофе через четыре минуты. Вы можете сократить продолжительность цикла, повышая скорость работы или снижая количество необходимых операций. В большинстве случаев единственным практичным вариантом действий остается первый.

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

Заблуждение 5: чем больше свойств будет у продукта, тем сильнее он понравится клиентам

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

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

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

Формулировка проблемы

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

Когда Уолт Дисней планировал концепцию Диснейленда, он даже не пытался максимально расширить набор свойств (точек питания, количество парковочных мест и аттракционов), чтобы переплюнуть другие парки развлечений. Напротив, он задался более масштабным вопросом — каким образом Диснейленд может обеспечить своих посетителей уникальными и волшебными впечатлениями? Конечно же, ответ пришел к нему не сразу; ему потребовались невероятно детальные исследования, постоянное экспериментирование и глубокое понимание то, что именно значит слово «волшебный» для самого парка развлечений и его клиентов. В своей работе IDEO и другие компании используют специальные этапы, в ходе которых сотрудники полностью погружаются в контекст, в котором будут использоваться еще не существующие продукты или услуги. Разработчики компаний знакомятся со всей информацией о рынках, наблюдают за поведением и интервьюируют будущих пользователей, детально изучают предложения, которые будут конкурировать с новым продуктом, и синтезируют все полученные знания в виде иллюстраций, моделей и диаграмм. Результатом становится глубокое понимание желаний клиентов и сбор идей, которые тестируются, улучшаются или отбрасываются в течение всего итеративного процесса разработки.

Как определить, что спрятать и от чего отказаться

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

Одной из компаний, понявших это, была Apple. Она известна благодаря множеству вещей — инновационным продуктам, стильному дизайну и толковому маркетингу, — однако, возможно, самая сильная ее сторона заключается в способности добраться до сути проблемы (см. статью «The Real Leadership Lessons of Steve Jobs» Уолтера Айзексона в нашем апрельском выпуске). Покойный Стив Джобс объяснял: «Когда вы начинаете смотреть на проблему и она кажется вам простой, вы на самом деле не понимаете всей ее сложности. И вы находите слишком упрощенные решения, которые не работают. Затем вы погружаетесь в проблему и видите, что она на самом деле сложная. И вы придумываете запутанные решения... на этом этапе останавливаются большинство людей». Но только не Apple. Она продолжает двигаться вперед. «По-настоящему великий человек пойдет дальше, — говорил Джобс, — и поймет. ключевой и основополагающий принцип проблемы, а затем предложит прекрасное, элегантное и работающее решение».

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

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

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

Заблуждение 6: наши проекты будут более успешными, если все получится правильно с первого раза

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

Для того чтобы избежать ошибок, команды следуют линейному процессу, в котором каждый этап (формулировка задачи, дизайн, создание, тестирование, масштабирование, запуск в производство) тщательно отслеживается на этапе «ворот». Работа над следующим этапом не может начаться до тех пор, пока проект не пройдет через очередные ворота. В процессе развития проекта компания берет на себя все более масштабные обязательства, а реагирование на вновь появляющуюся информацию обходится на порядки дороже. Успешные тесты на поздних стадиях получают всеобщее одобрение, а неожиданности, пусть и невероятно ценные, воспринимаются как проблемы. К сожалению, подобный линейный процесс может привести к росту затрат, поскольку обратная связь по итогам тестов задерживается, команды дольше держатся за неудачные идеи, а проблемы не всплывают на поверхность до тех пор, пока их решение не становится слишком дорогостоящим.

Практическое руководство по борьбе с распространенными заблуждениями

Вот как может выглядеть контрольный список для менеджеров по разработке продуктов.

  1. Сделайте визуально понятными очереди и потоки информации.
  2. Проведите количественную оценку издержек, связанных с задержкой работы, и примите ее во внимание в процессе решения.
  3. Создайте запас ресурсов на участках с самой высокой утилизацией.
  4. Измените направление концентрации своих контрольных систем с повышения эффективности на снижение времени отклика.
  5. Сократите транзакционные издержки с тем, чтобы иметь возможность работать с меньшими партиями и быстрее получать обратную связь.
  6. Экспериментируйте с небольшими партиями; если это не сработает, вы всегда можете вновь вернуться к большим партиям.
  7. Воспринимайте план развития как гипотезу, которая будет меняться по мере появления новой информации.
  8. Начинайте свои проекты только тогда, когда вы готовы полностью себя им посвятить.
  9. Ориентируйтесь на простоту -поймите, от каких свойств можно отказаться, а не какие можно добавить.
  10. Начните заниматься экспериментами как можно быстрее, делайте их быстро и часто. Используйте компьютерное моделирование и физические прототипы. Работайте в контролируемых условиях и в естественной для клиентов среде.
  11. Обратите внимание на то, чтобы процессы пересекались между собой и были итеративными - а не линейными.
  12. Концентрируйтесь не на успехе с первой попытки, а на быстром получении обратной связи.

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

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

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

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

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

Однако создать подобную среду непросто. Этому вопросу была посвящена статья Эми С. Эдмондсон из Гарвардской школы бизнеса «Strategies for Learning from Failure» (HBR, April 2011). Неудача может привести к смятению и выявить пробелы в знаниях, подрывающие самооценку сотрудника и влияющие на его положение в организации. Как часто менеджеры награждают команды за любое заблаговременное выявление неудач, способных привести к смерти проекта, — особенно когда они расходуют на своем проекте ценные ресурсы компании? Описанные выше ситуации особенно типичны для организаций, склонных к «нулевой терпимости к неудачам» или работе в условиях среды «нулевых ошибок» (например, по методу «шести сигм»).

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

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