Алан Купер - Психбольница в руках пациентов Страница 56

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

Эрни тоже не был абсолютно счастлив, работая с Бетси. Все, что он делал, требовало одобрения Бетси, и она постоянно придиралась по поводу пиксела там, пиксела здесь – к тому, что, по его мнению, никакой роли не играло. Она требовала переделывать уже сделанное по пять-шесть раз, вносить ненужные, как он считал, изменения, прежде чем согласиться, что работа готова. Он хотел получить независимость от Бетси не меньше, чем она желала получить независимость от него.

Проектирование

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

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

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

Теперь Эрни выступает в роли автора инструментов, а не программиста, выполняющего заказы. Он создает подключаемые модули, которые могут становиться частью инструментария Бетси. У его модулей более широкая аудитория, поскольку он может продавать их многим другим Бетси, которые, в свою очередь, будут применять эти модули для многочисленных сайтов.

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

Откат

Разработчики Elemental поначалу решили, что наше решение не сработает, поскольку сразу представили себе ряд вырожденных случаев, когда Бетси все равно понадобятся особые таланты Эрни. «Нельзя совсем исключать Эрни из цикла, – заявили они, – поскольку Бетси может понадобиться решить какую-то особую или сложную задачу».

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

Независимость важна для Бетси, и ради ее достижения она готова на соразмерные жертвы. Drumbeat позволяет ей создавать полноценные сайты без помощи Эрни, и это примиряет ее с небольшими компромиссами в дизайне, открывающими доступ к готовым программам Эрни34. Жертва невелика, поскольку запросы большинства клиентов укладываются в стандартные схемы. Если она получит контракт на создание корпоративной сети для универмагов Wal-Mart или системы оперативного резервирования для отелей Hilton, то определенно задействует человека, обладающего талантами разработчика, чтобы он помог справиться с этими монументальными задачами, но в большинстве случаев это не требуется.

Прочие моменты

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

Участники нашей команды проектировщиков в один голос заявили, что панели назойливы, сложны и совершенно излишни. Разумеется, необходимо обеспечивать доступ к инструментам, но мы знали и более привлекательные способы. Однако каждый раз, когда мы отрицательно отзывались о панелях, программисты (и руководители разработки) тут же заявляли, что панели всем очень нужны.

Наблюдая, как реальные Бетси работают с продуктом, мы скоро поняли, почему плавающие панели были настолько популярны. Изначально программа была спроектирована так, что без панелей было не обойтись. Большинство инструментов каждой панели редко находили применение, но при этом на каждой панели было по меньшей мере два очень полезных и востребованных инструмента. То есть Бетси нужны были все панели для решения самых простых задач. Из-за лишних инструментов каждая панель была чересчур велика, и все панели плавали поверх изображения сайта, находящегося в разработке, поэтому, работая над сайтом, Бетси постоянно приходилось перемещать панели. Альтернативный режим позволял зафиксировать панели вдоль одной из границ экрана, но это означало лишь, что Бетси придется постоянно прокручивать изображение сайта. Бетси попала в безвыходное взаимодействие. Она могла терять время на ненужную прокрутку или на перемещение панелей. Такие ненужные для пользователя действия мы называем «акцизами», и изначально программа была ими насыщена.

Мы понимали, что под рукой должны быть только инструменты, применяемые часто, и для решения проблемы все инструменты лучше поместить в одно место. Иначе Бетси запутается.

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

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

«Drumbeat – продукт уникальный и впечатляющий, его возможности автоматизации сложных веб-задач превосходят все другие присутствующие на рынке решения. Продукт позволяет непрограммистам решать задачи очень просто. Вы сможете создавать огромные профессиональные сайты и даже применять технологию Active Server Pages, не написав и строчки кода.»

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

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

Глава 11

Проектирование для людей

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

Сценарии

По мере детализации проектирования эффективность сценариев повышается. Наши персонажи проходят через эти сценарии, словно актеры, читающие роли, что позволяет проверять корректность проектирования и выдвинутые предположения. Неудивительно, что наш сценарный процесс часто сравнивают с игрой по Станиславскому – актер должен вжиться в роль, знать то, что знает персонаж, чувствовать то, что чувствует персонаж. Мы стараемся думать так, как думает он. Мы забываем о собственном образовании, способностях, подготовке, инструментах и думаем, что обладаем лишь данными и биографией персонажа. Поскольку мы проектировщики, а не актеры, без контекста и конкретных деталей может быть нелегко, поэтому сценарии оказываются большим подспорьем. Зная, к примеру, что Бетси пытается создать сайт для страховой компании, нам проще ставить себя на ее место. И это не так странно, как может показаться. Ведь программисты ставят себя на место своих компьютеров. Программисты привычно описывают действия компьютера от первого лица, они говорят: «Я обращаюсь к базе данных, а затем сохраняю записи в буфере». Человек говорит «я», но всю работу на самом деле выполняет компьютер. В роли компьютера человеку проще симпатизировать потребностям машины в процессе написания кода.