Чтобы вы могли полностью понять результаты, нужно рассказать о схеме оплаты эксперимента. Во-первых, «оценщикам» было выгодно завышать оценки в первой части эксперимента – они получали 8 % от каждой одобренной «проверяющим» оценки, и ничего, если «проверяющий» оценку отвергал. Во-вторых, и «проверяющие» получали больше, пропуская завышенные оценки, но при этом им грозил штраф, если оценка будет завышена чрезмерно. «Проверяющие» получали 4 % от каждой одобренной суммы и ничего не получали за отвергнутые оценки. Однако им сообщили, что компьютер будет проверять каждую десятую оценку в случайном порядке и налагать на «проверяющих» штраф в размере 5 долларов, если оценка окажется за пределами 10-процентного отклонения от истинной суммы.
Как вы, должно быть, заметили, схема оплаты в общих чертах напоминает ту, по которой оплачивается работа аудиторов, отвечающих за проверку финансовых отчетов организаций. Аудиторам грозит такой же конфликт интересов: поскольку им выгодно угодить тем, чьи отчеты они проверяют, они могут закрыть глаза на небольшие погрешности. Однако если аудиторов поймают на том, что они допускают значительные нарушения, им светит огромный штраф.
Как мы и предсказывали, процент участников, одобрявших оценки, был значительно выше в случаях, когда оценки увеличивались постепенно, а не резко. Когда изменения происходили медленно, «проверяющие» «не видели» их. В группе «скользкая дорожка» количество оценок, одобренных в 11–16-м раунде, равнялось в среднем 52 %. В группе с «резким изменением» оно не превышало 24 %. Значит, наши участники с большей готовностью принимали неэтичное поведение других людей, когда нарушения появлялись постепенно, чем когда возникали внезапно.
Могут ли наши результаты объясняться тем, что «проверяющие» подыскивали оптимальную стратегию для получения большей прибыли? В последующих экспериментах мы с Максом добавили контрольную группу, участники которой не получали никакого денежного поощрения при одобрении завышенных оценок. И все же результаты повторились: уровень одобрения завышенных оценок в случае «скользкой дорожки» был выше, чем при «резком изменении». Это позволяет предположить, что люди находят более приемлемым постепенное отклонение в сторону аморального поведения.
Как и при «слепоте к переменам», участники не заметили небольших изменений, происходящих прямо перед ними. Слишком сосредоточившись на текущем задании, они замечали лишь большие и внезапные изменения.
Подобные типы «неверной фокусировки» при обработке информации и принятии решений встречаются и на уровне организаций. Я имела возможность наблюдать это, работая с различными компаниями. Одна из компаний, Teradyne, – важнейший производитель очень сложного электронного оборудования. Как и у многих фирм, у Teradyne возникли проблемы с затянувшейся разработкой новых продуктов. Проекты, рассчитанные на 3 года, выполнялись за 4 или больше. По мере того как рынок становился все более конкурентным, а потребители – все более требовательными, высшее руководство компании запустило систематическую программу борьбы с задержками. Все планировалось заранее, процесс разработки продукта тщательно обсуждался, выделялись ключевые этапы, на проекты ставились сильные руководители, команды эффективно взаимодействовали, а после завершения проекта процесс обсуждался снова, чтобы извлечь возможные уроки. Проводя полевые исследования в Teradyne в 2006 г., мы с коллегой Гэри Пайзано убедились: руководство компании прилагает много усилий для осуществления программы, привлекая к ней самых активных и опытных топ-менеджеров
{30}.
Хотя новая система и улучшила временные показатели по выпуску новых продуктов, опыт компании с одним из главных проектов оказался отрезвляющим. Проект под рабочим названием «Ягуар» был посвящен изготовлению новейшего оборудования для тестирования полупроводников и включал в себя сложнейшие программные и технические разработки. В нем использовались точные методы составления плана работ, основанные на скрупулезном анализе «критических направлений» и текущего состояния проекта. Сложная онлайн-программа ежедневно регистрировала последние данные по проделанным работам и заблаговременно предупреждала пользователей о возможных отклонениях от графика. Команду разработчиков тщательно проинструктировали и обучили пользоваться программой, и руководство проекта возлагало на нее большие надежды. В группу даже ввели дополнительных специалистов – координаторов проекта, собиравших нужные данные, анализировавших их и сообщавших результаты (группа проводила совещание каждую неделю, но разработчики общались друг с другом постоянно).
Результаты сильно смахивали на «Повесть о двух городах»
[2]
. Та часть проекта, которая была посвящена разработке «железа» (механическим и электронным устройствам), работала как часы. И более того, программа по контролю за графиком работ функционировала точно так, как ожидалось. Если с какой-то частью проекта происходили задержки, программа немедленно показывала, как это может повлиять на весь процесс, – после чего происходило перераспределение ресурсов или изменялся график других работ, чтобы свести ущерб к минимуму. Руководство проекта было удовлетворено системой ранних предупреждений, позволявшей избежать крупных задержек.
В то же время с разработкой программного обеспечения все обстояло совершенно противоположным образом. С самого начала программисты начали отставать; им так и не удалось нагнать разработчиков «железа». Хуже того, график работ был очень плотный, и это только усугубило проблемы программистов. В попытках нагнать график эта часть команды сократила время, отведенное на тестирование, что привело к появлению большего количества багов в коде – а это повлекло дальнейшие задержки. Проект все тянулся, сроки были упущены, и руководству пришлось привлечь к работе дополнительных программистов. Программная часть завершилась с полугодовым опозданием, в результате первые коммерческие поставки систем сорвались.
Во многих сложных, многокомпонентных разработках часто случается так, что одна часть проекта продвигается лучше, чем другие. То, что в описанном случае работа над механикой и электроникой шла согласно плану, а программная часть – нет, можно объяснить организационными способностями руководства проекта, уровнем технических требований и, наконец, просто игрой случая. Однако удивительно, что программа по управлению проектом должна была заранее предупреждать команду о возможных задержках, чтобы разработчики могли действовать соответственно. Все проверки показывали, что программа работала одинаково эффективно для обеих команд. Причем, обсуждая вклад программы в разработку «железа», менеджеры хвалили ее за то, что она делала проблемы более очевидными, давая разработчикам возможность вовремя справиться с ними. Еженедельные рабочие совещания часто приводили к тому, что план разработки «железа» изменялся, позволяя оптимизировать «критические направления». Программа не ставила жестких условий, а снабжала людей информацией, необходимой для оперативного отклика на приходящие извне изменения (например, на требование клиентов поставить оборудование значительно раньше, чем планировалось).
