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