Проверка решения на устойчивость. Допустим, человек предлагает архитектуру, которая не расширяемая и не масштабируемая, или еще какая-нибудь не такая. И вы понимаете, что через полгода, когда нагрузка вырастет в.

5 раз, вашей системе наступит кирдык.

Вы можете сказать: "Подожди, она же не выдержит нагрузки", но это может.

включить коммуникативную формулу ЗАТО: "Зато ее можно быстро реализовать!".

Поэтому лучше задать один из вопросов:.

• А как бы нам сделать так, чтобы она выдерживала нагрузку в 5 раз больше. как мы планируем через полгода?.

• Что будет если у нас нагрузка вырастет в 5 раз, как мы планируем через полгода?.

Утверждения включают в человеке желание поспорить. А что у человека включает мозг? Правильно, вопросы.

Проверка решения на устойчивость помогает решение доработать, и при этом это решение по-прежнему вашего собеседника, и он все так же ощущает за него личную ответственность.

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

— Коллеги, есть такая идея: давайте писать юнит тесты!.

— Отличная идея!.

— Вот! Ну, тогда переходим к следующему вопросу.

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

Хорошая форма записи решений: WWW = Who, What, When (Кто, Что,.

Когда). Тут меньше шансов понять по-своему. А далее мы переходим к последнему этапу алгоритма, потому что, как говаривал бывший генеральный директор IBM Лу Герстнер: "People do not do what you expect. They do what you inspect." ("Люди не делают то, что вы ожидаете. Они делают то, что вы проверяете.")