Игра для того, чтобы победить – для меня всегда доставляет удовольствие смотреть, как играет баскетбольная команда UCLA Джона Вудена (John Wooden). Как правило, эти ребята выходят из поединка победителями. Однако даже тогда, когда игра близка к завершению, ребята из UCLA уверены, что они играют для того, чтобы победить. Конечно же, до этого они уже были победителями много-много раз. Они несколько расслаблены. Однако при этом они делают все для того, чтобы выиграть. И они выигрывают вновь.
Я вспоминаю игру баскетбольной команды из Орегона, которая была ярким контрастом. Орегон сражался с Аризоной, команда которой обладала национальной номинацией. Четыре игрока из Аризоны играли в национальной сборной NBA. Однако на половине матча неожиданно для всех Орегон оказался впереди на целых 12 очков. Игроки из Аризоны не могли ничего с этим поделать. Защита Орегона постоянно отражала их атаки. Однако после перерыва Орегон снизил темп игры и стал играть, экономя силы. Они закрывали глаза на медленно сокращающуюся разницу в счете, так как поставили перед собой задачу – просто удержать победу. И, конечно же, эта стратегия не сработала. Аризона немедленно воспользовалась своим преимуществом в опыте и выиграла игру.
Отличие состоит в том, что в одном случае команда играет для того, чтобы выиграть, а в другом случае – для того, чтобы не проиграть. Большинство игроков в мире разработки программного обеспечения, с которыми мне приходилось иметь дело, играют для того, чтобы не проиграть. Изводится масса бумаги. Проводится огромное количество совещаний. Каждый пытается разрабатывать в строгом соответствии с общепринятыми правилами (по книжке) не потому, что в этом есть смысл, а потому, что в конце работы они получат возможность сказать, что это не их вина в том, что все кончилось так плачевно.
Если разработка программного продукта осуществляется для того, чтобы победить, каждый член команды делает все, чтобы помочь команде выиграть и не делает чего-либо такого, что может помешать этому.
Надежное экспериментирование – каждый раз, когда вы принимаете решение и не тестируете его, существует вероятность, что принятое вами решение неправильно. Чем больше таких решений вы принимаете, тем выше становится эта вероятность. Именно так увеличивается риск. Чтобы снизить риск, результатом сеанса проектирования должен стать не завершенный дизайн, а серия экспериментов, отвечающих на вопросы, которые возникли у вас в процессе проектирования. Результатом обсуждения требований также должна стать серия экспериментов. Каждое абстрактное решение должно быть протестировано.