Франческа Джино - Отвлекающие факторы, или Почему наши планы идут под откос

Как мы и предсказывали, процент участников, одобрявших оценки, был значительно выше в случаях, когда оценки увеличивались постепенно, а не резко. Когда изменения происходили медленно, «проверяющие» «не видели» их. В группе «скользкая дорожка» количество оценок, одобренных в 11–16-м раунде, равнялось в среднем 52 %. В группе с «резким изменением» оно не превышало 24 %. Значит, наши участники с большей готовностью принимали неэтичное поведение других людей, когда нарушения появлялись постепенно, чем когда возникали внезапно.

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

Как и при «слепоте к переменам», участники не заметили небольших изменений, происходящих прямо перед ними. Слишком сосредоточившись на текущем задании, они замечали лишь большие и внезапные изменения.

Подобные типы «неверной фокусировки» при обработке информации и принятии решений встречаются и на уровне организаций. Я имела возможность наблюдать это, работая с различными компаниями. Одна из компаний, Teradyne, – важнейший производитель очень сложного электронного оборудования. Как и у многих фирм, у Teradyne возникли проблемы с затянувшейся разработкой новых продуктов. Проекты, рассчитанные на 3 года, выполнялись за 4 или больше. По мере того как рынок становился все более конкурентным, а потребители – все более требовательными, высшее руководство компании запустило систематическую программу борьбы с задержками. Все планировалось заранее, процесс разработки продукта тщательно обсуждался, выделялись ключевые этапы, на проекты ставились сильные руководители, команды эффективно взаимодействовали, а после завершения проекта процесс обсуждался снова, чтобы извлечь возможные уроки. Проводя полевые исследования в Teradyne в 2006 г., мы с коллегой Гэри Пайзано убедились: руководство компании прилагает много усилий для осуществления программы, привлекая к ней самых активных и опытных топ-менеджеров {30}.

Хотя новая система и улучшила временные показатели по выпуску новых продуктов, опыт компании с одним из главных проектов оказался отрезвляющим. Проект под рабочим названием «Ягуар» был посвящен изготовлению новейшего оборудования для тестирования полупроводников и включал в себя сложнейшие программные и технические разработки. В нем использовались точные методы составления плана работ, основанные на скрупулезном анализе «критических направлений» и текущего состояния проекта. Сложная онлайн-программа ежедневно регистрировала последние данные по проделанным работам и заблаговременно предупреждала пользователей о возможных отклонениях от графика. Команду разработчиков тщательно проинструктировали и обучили пользоваться программой, и руководство проекта возлагало на нее большие надежды. В группу даже ввели дополнительных специалистов – координаторов проекта, собиравших нужные данные, анализировавших их и сообщавших результаты (группа проводила совещание каждую неделю, но разработчики общались друг с другом постоянно).

Результаты сильно смахивали на «Повесть о двух городах» [2]. Та часть проекта, которая была посвящена разработке «железа» (механическим и электронным устройствам), работала как часы. И более того, программа по контролю за графиком работ функционировала точно так, как ожидалось. Если с какой-то частью проекта происходили задержки, программа немедленно показывала, как это может повлиять на весь процесс, – после чего происходило перераспределение ресурсов или изменялся график других работ, чтобы свести ущерб к минимуму. Руководство проекта было удовлетворено системой ранних предупреждений, позволявшей избежать крупных задержек.

В то же время с разработкой программного обеспечения все обстояло совершенно противоположным образом. С самого начала программисты начали отставать; им так и не удалось нагнать разработчиков «железа». Хуже того, график работ был очень плотный, и это только усугубило проблемы программистов. В попытках нагнать график эта часть команды сократила время, отведенное на тестирование, что привело к появлению большего количества багов в коде – а это повлекло дальнейшие задержки. Проект все тянулся, сроки были упущены, и руководству пришлось привлечь к работе дополнительных программистов. Программная часть завершилась с полугодовым опозданием, в результате первые коммерческие поставки систем сорвались.

Во многих сложных, многокомпонентных разработках часто случается так, что одна часть проекта продвигается лучше, чем другие. То, что в описанном случае работа над механикой и электроникой шла согласно плану, а программная часть – нет, можно объяснить организационными способностями руководства проекта, уровнем технических требований и, наконец, просто игрой случая. Однако удивительно, что программа по управлению проектом должна была заранее предупреждать команду о возможных задержках, чтобы разработчики могли действовать соответственно. Все проверки показывали, что программа работала одинаково эффективно для обеих команд. Причем, обсуждая вклад программы в разработку «железа», менеджеры хвалили ее за то, что она делала проблемы более очевидными, давая разработчикам возможность вовремя справиться с ними. Еженедельные рабочие совещания часто приводили к тому, что план разработки «железа» изменялся, позволяя оптимизировать «критические направления». Программа не ставила жестких условий, а снабжала людей информацией, необходимой для оперативного отклика на приходящие извне изменения (например, на требование клиентов поставить оборудование значительно раньше, чем планировалось).

Хотя в обоих случаях программа функционировала по одним и тем же принципам, на команду программистов она оказала прямо противоположное воздействие. Несколько менеджеров заметили, что проблемы с этим сервисом были очевидны с самого начала, но руководство никак не отреагировало. Глава проекта прокомментировал: «Беда не в том, что нам не хватало данных… данные были на экране, но мы ничего не делали». Другой менеджер признался: «Мы позволили программе лгать нам». Сотрудник, отвечавший за эксплуатацию нового сервиса, согласился, что он и остальные члены группы слишком узко подошли к вопросу. Они сосредоточились на том, чтобы программа работала, а не на том, чтобы использовать полученную с ее помощью информацию.