Не создавайте законченные прототипы — это мешает творчеству

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

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

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

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

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

После создания более или менее полной версии ПО разгорелись жаркие споры. «Все возмущались, почему программа не может того или этого», — вспоминал один участник проекта. Так продолжалось не один год.

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

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

Источник : hbr-russia.ru