Защита головной компании

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

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

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

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

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

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

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

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