Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

• Документация, электронная справка и дополнительные материалы

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

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

• контроль хода работы над пользовательским интерфейсом, как текущий, так и по завершении каждого существенного этапа работы над проектом;

• консультации и санкционирование мелких изменений пользовательского интерфейса;

• создание или поиск элементов графического оформления продукта;

• надзор за созданием упаковки, лицензионного соглашения и формирование первоначального впечатления от продукта (см. выше);

• внутренняя и внешняя проверка ПО: хотя для крупных изменений может не остаться времени, небольшие изменения могут быть вполне возможны — это поможет лучше подготовиться к работе над следующим выпуском;

• визуальный контроль за ПО для обеспечения соответствия стандартам платформы, для которой ПО создано.

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

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

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

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

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