Джефф указывает, что есть реальная опасность увлечься «анализом ради анализа». При обилии данных может быть интересно поиграть с ними, изучая так и этак. Но если все это не направлено на то, чтобы подтвердить или опровергнуть вашу гипотезу, вы тратите время впустую.
Правильно расставьте приоритеты. Когда к заключению требуется прийти в сжатые сроки, а ресурсы для решения проблемы ограниченны, нужно разобраться, какие виды анализа жизненно необходимы, а какие – просто «гарнир». Здесь, как и в самом начале работы, вы должны разобраться, чего не надо делать. Когда направление задано гипотезой, вы легко избежите лишней работы.
Это особенно верно для малых компаний с ограниченными ресурсами. Они не могут позволить себе пытаться «вскипятить океан». Об этом свидетельствует Боб Бухсбаум, ныне СЕО компании по продаже художественных материалов Dick Blick Holdings:
Ищите путь наименьшего сопротивления – в этом вам помогут гипотезы; делайте предположения и получайте ответы, которые верны по своему направлению. У нас в McKinsey говорили: «Данных и времени всегда не хватает», и я всегда понимал это как «Не медлите». Компания у нас небольшая (доходы составляют $90 млн.), и мы не можем пренебрегать этими уроками. Я снова и снова не даю людям разработать «объединяющую теорию» компании.
Как мы уже говорили в предыдущей части этой главы, у людей с навыками аналитического мышления возникает огромное искушение выполнять неактуальные, но интересные виды анализа. Подавляйте это стремление в своей команде, а особенно – в себе.
Далее вы должны разобраться, какие виды анализа принесут быструю победу, то есть легко выполнимы и при этом способны сделать большой вклад в подтверждение или опровержение начальной гипотезы. Иными словами, срывайте низко висящий фрукт. (На эту тему мы еще поговорим в главе 7.) Яркий пример такого мышления можно увидеть в рассказе Чакко Сонни из Savage Entertainment о том, как его команда выполняет важный этап в разработке любых компьютерных программ – поиск ошибок:
Несомненно, устранение ошибок – главный принцип обеспечения качества программ на ранних стадиях их тестирования. Мы не можем допустить, чтобы в выпускаемом продукте их осталось 20%, но правило «80/20»[10] действительно применимо в данном случае. Одна и та же ошибка в коде может вызывать ряд самых различных симптомов. Мы отслеживаем не абсолютно все проявления серьезной ошибки, а лишь 80% – этого достаточно для того, чтобы понять причины происходящего и решить проблему. На раннем этапе мы пытаемся выловить важнейшие ошибки, имеющие значительные последствия. А к концу процесса находим оставшиеся 20% проблем, что позволяет нам скорректировать продукт для продажи.
Сосредоточившись на самых выигрышных видах анализа и избегая ненужных, вы сможете многое успеть за краткий срок.
Забудьте об абсолютной точности. Мы подчеркиваем важность анализа фактов в принятии бизнес-решений. Поэтому может показаться, будто мы противоречим самим себе, говоря, что вам не нужна точность результатов анализа. Но правда в том, что бизнес по большей части не точная наука, в отличие от физики или математики. Чтобы решить, открывать ли новую фабрику, не нужен такой же уровень точности, как при открытии новой субатомной частицы. Более того, в большинстве случаев стремление к научному уровню точности для управленческих решений может стать помехой эффективной работе. Вы потратите слишком много времени и усилий и в результате можете даже перейти от правильного в целом ответа к неправильному. Помните об этом, определяя задачи анализа для своей проблемы.