Софт для Windows    Программы для смартфонов и планшетов, мобильный софт    Софт для Линукс, Unix, Linux
 

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

Работа в Интернет | 09:56 26 ноября

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интернетчик отличается умом и сообразительностью
Источник: Деловая неделя Исследование, проведенное Центром коммуникативной политики Университета Калифорнии в Лос-Анджелесе в 14-ти странах мира показало, что имидж пользователя Интернета нуждается в корректировке. Современный пользователь Исследование, проведенное Центром коммуникативной политики Университета Калифорнии в Лос-Анджелесе в 14-ти странах мира показало, что имидж пользователя Интернета нуждается в корректировке
Обзор рынка труда в области Информационных Технологий
На российском рынке труда в области информационных технологий сохраняется значительное превышение нетрудоустроенных специалистов над спросом, предъявляемым компаниями. Это связано с ухудшением конъюнктуры данного сектора и снижением активности ИТ-компаний в конце 2000 г., уходом инвесторов, вкладывавших средства в Интернет разработки, оффшорное программирование
Снова к вопросу интернет-маркетинга
Что такое Интернет? В современной жизни суть этого понятия вполне достойна пера философов, поэтов и сатириков (не говоря уже о политологах и прочих приверженцах социальных оценок). С информационной же точки зрения Интернет это ничто иное, как гигантская по своим масштабам и возможностям Сеть, сформированная миллионами информационных центров, получивших название веб-сайтов. Миллионы сайтов, миллионы пользователей

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

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

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

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

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

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

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

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

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

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

Автор: Платон Днепровский, UIDesign Group
Источник: http://gui.ru/platon/


 

Последние новости

Google раскрыла характер проблем со звуком в Google PixelКоманда поддержки Google подтвердила в ответ на прямое обращение, что проблема с динамиком смартфона Google Pixel носит не программный, а аппар
Microsoft назвала дату прекращения поддержки Windows 7Microsoft объявила, что поддержка операционной системы Windows 7 будет прекращена 14 января 2020 г...
Падение России в рейтинге Bloomberg После подъема в последние годы Россия рухнула сразу на 14 строчек в мировом рейтинге наиболее инновационных стран Global Innovation Index, составляемом агентством
Открытые решения для 'Урожая' Новая торгово-клиринговая система Московской биржи 'Урожай' для продаж зерна была построена на решениях с открытым исходным кодом...
реально достигнуты результаты на уровне 900 млрд часов. Страна занимает сейчас пятую позицию в рейтинге среди продуктов Google Play...

Блог о софте

AVG 2013 Christmas Collection Mega Pack Final Version-FL | 761 MBAVG 2013 Christmas Collection Mega Pack Final VersionYou Have a Complete Collection of AVG 2013 SoftwareMega Pack Contains:AVG Antiviru
О программе:Zoner Photo Studio Pro - приложение, созданное для качественной обработки цифровых снимков...
Sophos Virus Removal Tool - антивирусный сканер проведет диагностику вашего ПК на наличие вирусов, программ-шпионов, руткитов и поддельных антивирусов и удалит их...
Photo Collage Max – программа, которая создает фотоколлажи. Так же создает альбомы, календари и т.п. Содержит в себе множество шаблонов, фигур, масок, фоторамок...
Дизайн Календарей - это доступная и удобная программа для создания красивых календарей с фотографиями на любой год или месяц...