Поиск по сайту:

GUI.ruВзгляд изнутри

Теория и практика юзабилити: опыт показывает

Платон Днепровский
01.02.2006Платон Днепровский

Комментариев:

19

Техническое задание и дизайн интерфейса

Detrol For Sale Myambutol No Prescription Buy Exelon No Prescription Buy Online Glucophage Buy Nolvadex Online Cardizem For Sale Augmentin No Prescription Buy Plan B No Prescription Buy Online Imitrex Buy Lisinopril Online Lotensin For Sale Hgh No Prescription Buy Phentrimine No Prescription Buy Online Acticin Buy Lopressor Online Ayurslim For Sale Naprosyn No Prescription Buy Azulfidine No Prescription Buy Online Diarex Buy Prograf Online Sumycin For Sale Avodart No Prescription Buy Actos No Prescription Buy Online Glucotrol Buy Xeloda Online

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

Какую задачу ставит перед нами заказчик? В подавляющем большинстве случаев это – проектирование интерфейса в рамках существующего ТЗ. Техзадание, как правило, это объемный подробный документ, где, (по RUP, например) зафиксированы все бизнес-роли, сценарии (use-cases), функции системы. В большинстве случаев – информационная структура, часто прописаны форматы тех или иных данных (длина и тип полей, например). Бывает, что в том или ином объеме даже отрисованы экранные формы.

Но позвольте! Какой интерфейс я могу разработать, действуя в этих рамках? Жонглировать кнопками? Заниматься раскраской экранов? Скорее всего, полноценная работа юзабилити-специалиста выйдет за рамки ТЗ: будут предложены изменения в структуре системы, возможно - , функционале, не говоря уж об экранных формах.

Однако ТЗ – совершенно необходимая часть мало-мальски серьезного проекта. Это перевод неявных и плохоструктурированных ожиданий и «хотений» на четкий и однозначный технический язык. Такой перевод необходим для:

  • Нормального планирования и контроля работы в ходе проекта;
  • Фиксации объемов работ, а значит – сроков и стоимости (во многих проектах составление ТЗ является нулевым этапом и стоит отдельных денег);
  • Формирования контрольного списка условий, по которому заказчик принимает работу.

Ведь что хочет заказчик (не ИТ-директор со стороны заказчика, а именно бизнес-заказчик)? Решения таких-то и таких-то проблем на таких-то и таких-то условиях. Вроде: «С помощью Системы мои сотрудники должны быстро и без ошибок фиксировать все данные по договору, проводить его по жизненному циклу, и создавать ежемесячные отчеты для меня».

Это очень общее и неточное описание, и на основе этого нельзя ни спланировать, ни выполнить работу. Поэтому за дело берутся бизнес-аналитики, системные аналитики, менеджер проекта. На свет появляется ТЗ. И там уже написано: «…Система должна базироваться на такой-то архитектуре, БД – содержать столько-то записей, сущность «договор» - такие-то поля такого-то типа…». ТЗ подписывается сторонами.

Проект закончен. Система сдается. И вдруг начинаются проблемы. Заказчик начинает придираться. Причем, на взгляд разработчиков, совершенно безосновательно. Архитектура соответствует ТЗ? Соответствует! Все вот эти поля есть в системе? Есть! Формата такого? Да, именно такого! Все как в ТЗ, которое согласовано и подписано! Так в чем же дело?

А дело в том, что в процессе перевода «хотений» в ТЗ произошла подмена бизнес-задач, которые должна решать система, ее техническими характеристиками.

Налицо типичная ситуация общения на разных языках. Заказчик, думая о системе, часто представляет те бизнес-процессы, которые она будет автоматизировать, и, некие абстрактные картинки. Разработчик представляет ровно то, что сделано – реализованный функционал.

Один не понимает, что это за непонятная система, которая делает что-то отдаленно похожее на его задумки, и начинает раздражаться. Другой злится: все сделано четко по ТЗ, все функции – вот они, так какого ж ему еще надо!? Такие ситуации я наблюдал множество раз.

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

Как же подружить ТЗ и интерфейс?

Очень просто: разрабатывать интерфейс ДО описания технических параметров проекта в ТЗ.

Необходимо до перевода на язык технических характеристик сделать перевод на язык пользовательского интерфейса. Ведь интерфейс – это отнюдь не только красивые картинки. Это и количественные характеристики, важные и ПОНЯТНЫЕ для заказчика (скорость работы, например), это и описание поведения системы при работе с ней, и, в конце концов – визуализация, овеществление будущей системы. И представить финальный результат, имея перед собой прототип интерфейса, значительно проще, чем по ТЗ.

ТЗ, конечно, необходимо. Но часто бизнес-заказчику оно ни к чему, для него оно – филькина грамота. И теоретически оно вообще может ему не показываться.

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

Но абсолютного счастья нет. Какие минусы у данного подхода? Вот два самых явных:

  1. Увеличивается начальная стадия проекта – время до окончательной фиксации условий работ;
  2. Возрастает стоимость «нулевого» этапа – за счет внедрения процесса разработки интерфейса.

Время и деньги – одни из самых критичных параметров проекта, и, не смотря на то, что ОБЩИЕ затраты на проект ПРАКТИЧЕСКИ ВСЕГДА снижаются, необходимость сразу же платить больше и ждать дольше (первых результатов) редко вызывает положительные эмоции у заказчика.

Противопоставить этому можно следующее:

Во-первых, взывать к логике заказчика, и расписывать ему все прелести юзабилити вообще и данного подхода в частности. Практика показывает, что это работает отнюдь не всегда: плюсы – оно, конечно, хорошо, но и денег СРАЗУ надо давать, а польза все же не очевидна. Ситуация медленно меняется с ростом общей «юзабилити-грамотности» населения: желание взять денег за интерфейс уже редко считают попыткой «развести». И здесь хорошо работают «success stories», особенно подтвержденные количественными данными.

Во-вторых, нужно выпячивать те «вкусности», которые заказчик лично получит в течение проекта. Это – чёткое представление о будущей системе и ее визуализация – в виде прототипа(ов), либо отдельных шаблонов (и/или документации). А это – очень важный момент и для разработчиков в том числе. Этим мы добиваемся согласованности ожиданий от результатов проекта, и практически избавляемся от разговора на разных языках при его сдаче.

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

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

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

Публикнуть: Добавить на News2.ru Добавить на Newsland.ru Добавить на Хабрахабр Добавить на Moikrug Заложить: Забобрить эту страницу! Добавить на Memori.ru Добавить на Delicious

Комментарии (19)

RSS feed for comments on this post | TrackBack URI

Егор Гилев03.02.2006 22:39
1

Готов подписяться кровью!
Вставлю свои две копейки как бывший программист и руководитель проекта. Взгляд со стороны разработчиков, в некотором роде.
По моему (по большей части отрицательному, в виде граблей) опыту, писать ТЗ, откладывая проектирование интерфейса на потом - просто мука мученическая. Мало того, что клиент не понимает, что подписывает, так ведь и ты сам не уверен, что куски мозаики, описанные в ТЗ, при разработке должным образом сложатся вместе.

2

Есть несколько вопросов:

1. Если интерфейс делается на “нулевых” стадиях проекта, до ТЗ, и является для него входной работой, то что явялется “входом” для самого интерфейса? На основании чего он проектируется - устных заявлений заказчика и договора на 3 страницы?

2. “В нашей практике есть примеры, когда интерфейс делался еще до определения подрядчика на его реализацию, и являлся ТЗ уже для разработчиков”.
Почему вы противопоставляете термины “проектировщик интерфейса / взаимодействия” и “разработчик”, разве первый не является также разработчиком системы?

Платон Днепровский06.02.2006 16:54
3

Денис,

1. Входом для разработки интерфейса является множество собираемых данных - так же как и для ТЗ. Описание целей системы, бизнес-процессов, контекста работы, особенностей ЦА, критериев качества и прочее. Так же как и при написании “традиционного” ТЗ работа начинается со сбора и анализа данных, различается лишь “угол зрения” и формат результатов. И, конечно, часть собранных данных и сделанных выводов прямиком пойдут в ТЗ, часть работы одинакова.

2. В данной заметке это было сделано для упрощения. Конечно, интерактивный дизайнер такой же разработчик, вы совершенно правы. Просто писать “разработчик, занимающийся проектированием и созданием технических аспектов системы” или как-то похоже - неуклюже, ди и перегрузит статью. Здесь я противопоставлял не разработчиков и интерактивных дизайнеров, а, скорее, старый и новый подходы к созданию ТЗ и согласованию ожиданий от деятельности всех разработчиков.

Алексей07.02.2006 11:23
4

Мысли и комментарии:
1.
Не понимаю, если вам дают работу, где надо покрасить кнопки в коричневый цвет, а она вам не по душе и заказчика не убеждают доводы пользы UI, почему не отказываетесь от нее? Вы же потом под ней не захотите подписываться?

2.
Чтобы не быть голословным при общении с заказчиком, нужно иметь не только примеры картинок “как было - как стало”, но и описание причин такого оформления. Без них картинки воспринимаются как … как картины художников для непосвященных, вроде нравится, но почему - не знают. Поэтому и валят на магическое “вдохновение” и считают, что сделать это - пара пустяков. Нужно развеивать и посвящать.

3.
Создание UI - итерационный процесс, это процесс сбора информации и реализации решений. Закравшаяся ошибка/недосмотр на самом первом этапе не редко влияет на всю концепцию UI. И не смотря на поговорку “не ошибается тот, кто ничего не делает”, весь процесс должен быть коллективным, чтобы в разборе задач принимали участие все аналитики и заказчик. Иначе в конце окажется, что трепетно разрабатываемый ui пойдет коту под хвост из-за пропущенного требования.

Платон Днепровский07.02.2006 16:03
5

Алексей,
Ответные мысли и комментарии:

1. Я не скажу, что мы однозначно отказываемся или однозначно беремся. Бывает, что нас зовут тогда, когда остается лишь “покрасить губы свинье”. И мы беремся за работу, хотя, конечно же, общий результат далек от идеала. Но мы в рамках ограничений максимально оптимизируем интерфейс - пусть он будет и не идеален, но куда как лучше, чем до нас. Даже если мы всего лишь “пожонглировали кнопками”. Бывает, что и отказываемся, и рекомендуем заказчику не тратить ресурсы на ПИ сейчас - так как это бесполезно (с учетом конкретной ситуации).

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

3. Да.

Стас Стрекач07.02.2006 23:31
6

ППКС.

Aka Bob08.02.2006 10:02
7

На самом деле для систме разного уровня могут быть приемлемы разные подходы.

Варинты:

1. Крупная промышленная система с 5-20 АРМами. Сроки и суммы большие, организация управления проектом сложная. Вряд ли заказчик будет с вами о чем-то разговаривать до подписания ТЗ, кроме так о формировании проектной группы. Тем более что проектирование UI в таких проектах составляет меньше сотой части бюджета.

2. Система средней “тяжетси” с 2-5 АРМами. Вот тут стоит показать UI заказчику до подписания ТЗ. Т.к.требования к техническому решению должны быть задокументировны тщательно… Соглашусь с Вашим методом.

3. Мелкая системка с 1 АРМом, информационно-презентационный веб-сайт. Требования достаточно описать прецедентами максимально безотносительно UI. Таким образом UI можно спокойно проектировать и после подписания ТЗ.

Другое дело, что программистам-проектировщикам прецеденты писать “не удобно”. Им проще описать модель будущей системы (классы, АРМы, развертку), а не бизнес-модель, где пользователи взаимодействуют с “черным ящиком” системы.

Платон Днепровский08.02.2006 13:48
8

Aka Bob,
1. В этом случае имеет смысл выступать одновременно с техническими разработчиками - либо как субподрядчик, либо как параллельный подрядчик. При этом ПИ должен быть частью ТЗ. И разрабатываться в плотном взаимодействии с техразработчиками.
Иногда заказчик будет и разговаривать, и сам искать юзабилити-специалистов. В том случае, если кто-то из принимающих решение сотрудников заказчика мотивирован. Такие примеры у нас есть - сам заказчик представлял необходимость выделенной разработки ПИ. Ну и процент затрат на ПИ постоянно растет - не из-за стоимости услуг, а из-за роста доверия и проведения процесса проектирования по все более полному циклу. И перекидывания части работ от технических компаний в юзабилити-компании.
Даже в милионных ($) проектах он, бывает, достигает 10-15%.

2…

3. Да, может быть и так - если стоимость редизайна минимальна. Бывает и совсем наоборот: технология настолько очевидна (тот же веб), что интерфейс - основная характеристика продукта. И он разрабаьывается до выбора технологического подрядчика, как я уже и писал.

PM09.03.2006 15:09
9

Платон,
в общем и целом со статьей согласен.

Однако, ряд моментов хотелось бы уточнить.
Вы описали минусы модели Задумка - ТЗ - Реализация и предложили модель Задумка- Дизайн ПИ- ТЗ - Реализация.

А как быть с этапом “концепции” (vision)?

Т.е. если есть модель Задумка – Концепция – ТЗ - Реализация, куда “воткнуть” дизайн ПИ - до концепции или после?

Будите отвечать, заметьте, что зачастую концепцию пишут одни подрядчики (т.н. “консультанты”), а ТЗ и реализацию - другие (а число связей растет квадратично - когда стороны 3 /заказчик, ПИшник, Разработчик/, связей 3, а когда стороны 4/Заказчик, Консультант, ПИшник, Разработчик/ - уже 6).

Короче, у Вас был практический опыт встраивания в процесс, где работают “бизнес-консультанты” (синоним - интеграторы, генподрядчики)? Если да, как решали конфликты интересов с ними (ИМХО, тут конфликт посильнее чем с разработчиками-программерами)?

10

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

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

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

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

PM13.03.2006 15:32
11

Платон,
правильно ли я понял Ваш ответ, что вы собираетесь выходить на рынок “классического” консалтинга, оставляя разработку и оценку ПИ как один из его видов?

Также все-таки попрошу уточнить:
был ли у Вас опыт не подмены бизнес-консультанта и генподрядчика, а работа ВМЕСТЕ с бизнес-консультантом серьезного уровня?

12

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

Да, у нас был такой опыт - с тем же Росгосстрахом. Заказчиком был сам РГС, консалтером - Akriform (эстонская компания-консалтер по страхованию), исполнителем - TopsBI. Причем к работе нас привлекли именно консалтеры, а не заказчики или разработчики.

Илья Ванявкин08.08.2006 16:23
13

Все подобные комментарии и наставления - масло по яйцам (когда уже прошлись серпом). Реально :)

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

Так что - идеальное - пусть останется иделальным, а реальные проекты - реальными проектами. А у тех, кому удалось В РАМКАХ КОНКРЕТНОГО проекта сделать так, чтобы хватило времени на проектирование взаимодействия сначала, а потом уже были описаны структуры таблиц базы данных и создана и реализована информационная инфраструктура - молодцы, рад за вас. Вот только не так часто бывают такие проекты.

14

[…] Нежелание суетиться без видимой причины. ак я уже говорил, удобство – неочевидная характеристика системы для «банкиров» и разработчиков, тогда зачем дергаться, если и так все неплохо: система функционирует, все по плану. А что клиенты не пользуются – так мало ли, почему. Тем более, что здесь, как, впрочем, и в других отраслях, ответственность за достижение бизнес-результата подменяется ответственностью за четкую реализацию перечня функций (см. статью про ТЗ). […]

Андрей Петров29.01.2007 07:30
15

Извините, Платон - но Вы построили ветряную мельницу (полностью неадекватное ТЗ) и бросились на нее в атаку с соломенным копьем (”правильное” ТЗ).

Фактически, Вы предлагаете расширить ТЗ описанием интерфейса (ваши представления о том что такое ТЗ мы сейчас обсуждать не будем, хотя они сами по себе достаточно анекдотичны).

Настоящая проблема в том, что самое правильное, самое полное ТЗ никак не поможет Вам справиться с ИЗМЕНИВШИМИСЯ требованиями заказчика.

В общем, Вам не удалось ни идентифицировать источник проблем - ни предложить решение.

16

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

Alenko02.04.2007 15:42
17

Нормальная практика в ТЗ обрисовывать интерфейс и всю навигацию, что зачем следует… т.е. суть такова чтобы в ТЗ как заказчик так и разработчик видели весь проект - заказчик видел все интерфейсы и навигцию, что зачем идет, а разработчик какой функционал должны эти интерфейсы реализовывать

Maya02.04.2007 18:30
18

Хорошее ТЗ - это практически половина сайта. Но часто ТЗ редактируется по мере тестирования уже готовых частей проекта и “на выходе” мы получаем все равно “Франкенштейна”

Doloroza10.04.2007 15:29
19

Реально клиент в большинстве случаев вообще не способен объяснить, чего хочет.

Оставить комментарий

Anti-Spam Image