Типичные проблемы и их решение.

Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.

Излишняя доводка кода.

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

Отсутствие отзывов извне.

Если спросить у разработчиков, нужны ли им внешние отзывы при разработке пользовательского интерфейса, в ответ почти всегда можно услышать «Да». И всё же в жизни совсем мало команд получает внешние отзывы о своих проектах, особенно в начале работы. Дело в том, что трудно дать отзыв о том, чего ещё нет. Описанная в этой главе методика позволяет более успешно собирать внешние отзывы.

Лишние нововведения.

Представленные в этой главе идеи чаще всего критикуют за то, что они, якобы, «душат» инновации. А что, если спустя несколько месяцев работы над продуктом возникла замечательная новая идея? Стоит ли вносить изменения, если есть возможность?

Фундаментальная идея этой главы в том, что основные элементы пользовательского интерфейса должны быть «на местах» уже в начале работы над проектом. Их нельзя существенно изменять, если мы хотим уложиться в первоначальный план. Бесспорно, инновации не только возможны, но и необходимы, однако работу с ними нужно завершить на этапе работы с прототипом. Именно поэтому следует быстро проверять и отрабатывать разные варианты. Протестировав прототип заранее, вы избавляете себя от необходимости вносить значительные изменения в будущем. Даже при возникновении новой идеи, представляющей прорыв в данной области, сохранится уверенность в том, что текущие идеи в состоянии удовлетворить потребности рынка, что позволит уложиться в план. Я не говорю, что во время реализации проекта нельзя вносить небольшие изменения. Как правило, во время разработки возникает масса полезных идей, существенно повышающих ценность программы с очень небольшими затратами. Многие из них вполне могут быть реализованы без риска срыва плана или возникновения серьёзных проблем.