Компромисс — это самое слабое из всех решений. Но что может быть хуже, чем пойти на компромисс?

Ещё хуже — капитулировать, то есть не пытаться разрешить, преодолеть силой или даже хотя бы как‑то сгладить противоречие. В нашей волчье‑овечьей метафоре — смириться с полной потерей овец.

Если вы решите повернуть назад, это и будет капитуляция.

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

Рассмотрим суть противоречия:

Наша задача — попасть в пункт назначения. Полезное действие связано с дальнейшим движением. В бытовой задаче это очевидно. Не менее очевидны провал и разочарование, если повернуть назад. Поэтому первое, что мы попытаемся сделать — найти объезд или убрать бревно.

Мы занимаем в противоречии сторону, связанную с полезным действием. За бревном мы видим свою цель.

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

Разберём противоречия, как на примере с бревном:

После такого анализа становится ясно, что все три решения из примеров — преждевременная капитуляция. Каждое из них связано с препятствием, а не полезным действием.

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

Менеджер сайта видит проблему: непрозрачность расходов. Разве нельзя сделать их прозрачными, например сменив сеошника? Сайт имеет хорошие позиции в поиске, а решение менеджера никак не связано с их сохранением, наоборот, подвергает их риску.

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

Для каждого платья на сайте свадебного салона «Мэри Трюфель» дизайнер бюро задумал лаконичную страницу с фотографией и информацией о платье:

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

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

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

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

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

Эскиз нарисовали за пять минут и внедрили на следующий день.

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

Анализ решения начинается с «полезной» стороны противоречия: