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

Ричард Монсон-Хейфел (Richard Monson-Haefel) — независимый разработчик ПО, соавтор всех пяти изданий «Enterprise JavaBeans» и обоих изданий «Java Message Service» (все книги опубликованы, издательством O’Reilly). Занимается проектированием и разработкой multitouch-интерфейсов, является ведущим специалистом в области корпоративной обработки данных.

Проблема пользовательского признания

Норман Карновейл

Люди не всегда рады появлению новых систем или крупным обновлениям. Это может поставить под угрозу успешное завершение проекта.

Решение о реализации новой системы нередко принимается в штыки — особенно на ранней стадии. Это вполне естественно, и причины хорошо известны. Тем не менее начальная реакция на новую систему создает меньше проблем, чем незатухающая отрицательная реакция.

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

• Люди могут иметь свои соображения о необходимости внедрения новой системы (и сопутствующего вывода из эксплуатации старой). В частности, они могут опасаться утратить ценную функциональность или потерять свое влияние в компании из-за перераспределения ролей.

• Люди боятся новых (непроверенных) технологий.

• Люди стараются избежать дополнительных затрат.

• Люди просто не любят изменения.

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

К числу других эффективных мер относится обучение, запланированные демонстрации системы (на ранних стадиях жизненного цикла проекта) и распространение информации о том, какую пользу принесет новая система.

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

Биография, автора приведена на стр. 57.

О важности консоме

Эбен Хьюит

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

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

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

Многие пропущенные требования и ошибки в программных продуктах возникают из-за размытости, неоднозначности языка. Многократно задавайте клиентам, разработчикам, аналитикам и пользователям одни и те же вопросы, пока они не начнут зевать от скуки. Теперь замаскируйте свой вопрос, чтобы придать ему новый облик. Словно прокурор, выискивающий изъян в алиби, подмечайте все новое, любые различия и противоречия. Фильтруйте снова и снова.

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

Проверяйте утверждения, спрашивая: «Останется ли это утверждение справедливым, если прибавить к нему „везде, всегда и при любых обстоятельствах“?» Люди стараются воздерживаться от подобных безапелляционных формулировок и поэтому начинают более тщательно подбирать слова. Просеивайте представления концепций через лингвистическое сито, чтобы очистить их от примесей. Повторяйте до тех пор, пока у вас не останется только исчерпывающий список простых, поддающихся проверке утверждений, описывающий истинную сущность системы.

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

Биография автора приведена ранее.

Для пользователя интерфейс — это и есть система

Винаяк Хеджд

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

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

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

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