• Мятая одежда. Вроде бы незначительная деталь и при ближайшем рассмотрении не так уж важная для определения качества дня (если, конечно, не назначена встреча с крупным клиентом), но скольким из нас доводилось испытывать подобный ненужный стресс по утрам? Если бы она привела одежду в порядок заранее, то попала бы в квадрат 2, но вместо этого оказалось в квадрате 1, пытаясь на скорую руку подобрать что-нибудь в одном стиле.
• Завтрак на бегу. Хотя многие из нас довольствуются на завтрак кофе и рогаликом, есть более приемлемые пути получения физической и ментальной энергии в течение дня. Это важно, поскольку энергия необходима для поддержания способности делать что-либо. Забота о себе несомненно является делом из квадрата 2.
• Материалы для совещания. Кива намеревалась подготовить данные заранее, но срочный запрос Карла сорвал ее планы. Поскольку неизвестно, был ли запрос важным или хотя бы срочным, нельзя сказать, могла ли Кива отложить его или даже отказаться. Методы, описанные в этой главе, могли бы помочь ей заниматься важными делами вместо реагирования на срочные запросы.
Несмотря на то что Кива не сумела как следует подготовиться и попала в квадрат 1, она переложила задачу на Келли. К счастью, та выручила ее на этот раз.
• Так называемый внештатный преподаватель-гуманитарий. Действительно ли он полное ничтожество по сравнению с суперзанятой Кивой? Или это просто организованный человек, который может позволить себе спокойно ехать на работу? Если это так, то именно он находится в квадрате 2, а Кива – скорее в квадрате 1.
• Своевременное выполнение проекта. При поверхностном рассмотрении это похоже на успешное выполнение задачи из квадрата 2. Реализация проекта идет согласно графику, а исполнители делают то, что нужно. Не имея дополнительной информации, будем исходить из наилучших предположений.
• Проблемный разработчик. Конечно, иногда встречаются попросту некомпетентные разработчики. Однако разве взаимоотношения с разработчиком нельзя скорректировать, если использовать подход, ориентированный на квадрат 2? А может оказаться так, что члены команды Кивы не удосужились как следует оценить сетевой компонент проекта, в результате чего разработчик не сумел определить реальную цену? Разве нет такой модели коммуникации, которая позволяет сделать процесс разработки беспроблемным? Возможен ли такой вариант, что команда Кивы просто реагирует на действия других участников проекта и соглашается со всеми предложениями независимо от того, как это отразится на объемах работ и графике?