Разработка и тестирование
-> Главное - поэтапньш контроль •* Обратная связь с посетителями •* Компромиссы необходимы везде •* Как оценивать проделанную раЕюту? «* В состав комиссии по приемке входят... -* Устранение недоделок •> Если есть претензии... •* Оформляем и подписываем акт •> Специфические ошибки •* Выводы
ЕСЛИ после проектирования и размещения у подрядчика заказа на создание интернет-сайта вы планировали расслабиться, можете забыть об этом: работа только начинается. В первую очередь вам необходимо требовать от исполнителей строгого соблюдения оговоренных контрактом сроков. Предложения подрядчика сдать работу целиком в подавляющем большинстве случаев неприемлемы. При составлении договора (см. часть 3) вы должны были указать поэтапную сдачу работ, и единственными причинами, которые мо-гут препятствовать соблюдению сроков, являются пожар, наводнение, землетрясение и прочие форсмажорные обстоятельства.
Разработка интерфейсов, кодирование, создание архитекруры Данных неоднократно описывалось в специальной методической литературе. Мы не станем вас утомлять технологическими подробностями — они не для менеджера проекта. В этой части речь пой-AST об основных процессах управления ходом разработки.
Есть расхожее мнение, что, только завершив какую-нибудь ра-
ОТУ, понимаешь, как нужно было ее делать с самого начала. Уже
Процессе изготовления интернет-сайта хочется многое улучшить,
Исправить, изменить. Как в этом случае найти решение, устраи-
вающее и вас, и исполнителей? Ответы на эти вопросы вы найде-
Те в данной части.
Напомним, что существует два метода проектирования и реализации интернет-проекта, которыми могут руководствоваться разработчики программного средства: спиральный и каскадный. В предыдущей части мы уже говорили о различии между этими методами. Каждый из них предполагает последовательное выполнение определенных работ.
Очень трудно рекомендовать какой-то общий алгоритм, поскольку в создании интернет-сайта большое значение имеет специфика решаемой задачи. Порядок работ, ведущихся в соответствии с классическими принципами разработки программного средства по международному стандарту ISO 12207:1995 и отечественному ГОСТ 34.601-90.
Этот перечень может показаться излишне подробным, поэтому в простых проектах стоит ограничиться работами, помеченными «звездочкой» (").
Технологическая документация (проектная и рабочая) в наибольшей степени должна отражать процессы жизненного цикла программного средства (сайта) и регламентировать требования к нему. Технологическая документация определяет:
• структуру и содержание исходных и отчетных документов по этапам разработки, испытаний и сопровождения сайта;
• логическую структуру программных и информационных компонентов базы данных;
• спецификации на внутренние интерфейсы компонентов прикладных программных средств и на интерфейсы со внешней средой;
• язык и правила программирования, идентификацию компонентов, комментарии к текстам программ и описаний данных;
• методы тестирования, испытаний и аттестации компонентов и сайта в целом;
• оформление, форматы и обозначения отчетных документов.
Для контроля возможных изменений и отклонений от плана заказчик и исполнитель еще на этапе подписания договора должны предусмотреть и согласовать специальный документ, регламентирующий правила применения и корректировки номенклатуры документов сайта, а также их содержание и адресность.
На сегодняшний день не существует единых стандартов качества для оценки работ по созданию сайтов. Разные компании выходят из этой ситуации по-разному. Одни руководствуются официальными стандартами, другие разрабатывают свою методику, третьи используют CASE-технологии. Между тем контроль качества — одна из ключевых процедур в технологической цепочке разработки интернет-ресурса. Цель такой процедуры — выявление всех возможных ошибок и неточностей в дизайне, верстке и функционировании программного обеспечения. Помочь в осуществлении такого контроля может план реализации, подготовленный при составлении ТЗ, и технологическая документация. Каково содержание этих документов и насколько подробными они должны быть?
Любой контроль хорош до тех пор, пока в нем есть необходимость. Чрезмерное внимание заказчика к исполнителю и его работе может вызвать у последнего нервозность.
Не стоит безотрывно наблюдать за исполнителями, это не ускорит процесс разработки. Более того, в вопросах и решениях, напрямую не влияющих на предполагаемый бизнес в Интернете,
Сроки
Степень детализации плана реализации интернет-проекта определяется сложностью самого проекта, а содержание плана зависит от его (проекта) характера. Но в любом случае вам понадобятся два плана:
• базовый календарный, определяющий этапы проекта и комплексы работ на каждом этапе;
• краткосрочный календарный, включающий детальный перечень и объемы работ, сроки их начала и окончания, фамилии ответственных лиц.
Контроль фактического выполнения работ по проекту осуществляется с помощью отчетных документов. Информация о выполнении работ и затратах должна поступать от разработчиков, сверяться с плановыми заданиями для внесения корректив. Здесь необходимо отметить, что контроль над созданием сайта состоит не только в поддержании хода работ в соответствии с планом, но при необходимости и в корректировке самого плана. Необходимость вносить изменения в план можно спрогнозировать для любого проекта с высокой степенью вероятности, и вы должны быть готовы к этому заранее.
Существует два способа внесения корректив в план реализации проекта:
• перераспределение имеющихся ресурсов для выполнения существующего плана. Как правило, это приводит к необходимости пересмотреть объемы финансовых и трудовых затрат;
• разработка нового плана от текущего момента до момента завершения проекта. Чаще всего это сопряжено с изменением сроков и временных интервалов, отведенных на каждый этап.
Качество
Контроль качества выполнения работ необходимо осуществлять не при общей приемке работ, как ошибочно считают многие заказчики, а на каждом конкретном этапе разработки. Это связано в первую очередь с тем, что исправление некоторых ошибок или
Порядок контроля
полнителя несколько минут, в то время как на более поздних этапах в процесс исправления ошибок и неточностей, возможно, придется вовлечь всех субподрядчиков, работающих над проектом. Для типового сайта существуют следующие точки сдачи работ:
• утверждение общего оформления (дизайна) и структуры сайта;
• тестирование программного обеспечения;
• интегрирование программного обеспечения и оформления;
• первичное наполнение сайта;
• общее тестирование работ по сайту на рабочем оборудовании.
Чтобы оценить качество на каждом этапе, необходимо предварительно определить его критерии и документально оформить их как Приложения к договору (или технологическую документацию) и определить методику тестирования.
Для небольших проектов критерии качества могут определяться следующим образом: достаточно оценить такие показатели, как время загрузки страницы, предельно допустимую нагрузку, отработку поисковых запросов, реакцию пользователей на увеличение базы данных. Если же вы курируете крупный проект, то необхо-
всю разработку целиком. Возможно, что незначительное, на первый взгляд, изменение в системе навигации по веб-службе, может повлечь за собой пересмотр всех технических средств производства системы навигации, изменение спецификации проекта, изменение плана разработки и сроков реализации проекта.
Таким образом, на этапе разработки необходимо учитывать следующие аспекты:
• профессиональные качества менеджера проекта в области планирования и организации рабочих процессов;
• умение лидера рабочей группы поставить и контролировать задачи;
• профессиональные качества всех сотрудников, принимающих участие в разработке.
Итак, независимо от того, ведется ли разработка собственными силами или заказывается в студии, планирование, создание рабочей группы, менеджмент разработки являются залогом успешной реализации проекта.
Как контролировать сроки
Любая разработка начинается с планирования. При планировании разработка разбивается на этапы, для каждого из которых создается рабочая группа. При составлении плана необходимо общее планирование трудозатрат. Любая рабочая группа нуждается в управлении. Очень часто менеджмент проекта строится на взаимодействии профессионального менеджера и лидера группы.
Менеджер отслеживает ведение разработки в соответствии с планом, нагрузку на сотрудников, этапы разработки. Лидер группы принимает непосредственное участие в разработке, формирует задания для участников, осуществляет контроль выполнения поставленных задач.
При внесении изменений в разработку нужно учитывать объем этих изменений и их влияние на
димо проверять не только качество результатов, но и качество проведения работ, получаемых документов. Для этого разрабатывается так называемый профиль программного средства: перечень документов (стандартов и т.п.), регламентирующий качество проекта на каждом этапе.
Известно, что у многих программистов особый склад ума. Отсюда их нестандартные взгляды на интерфейсы и организацию взаимодействия с посетителем сайта. Важно добиваться от программистов выполнения именно ваших требований по внешним и внутренним интерфейсам. Вместе с тем логику построения внутренних взаимосвязей различных программных продуктов необходимо оставить на их усмотрение. Стоит прислушиваться и к их мнению по поводу конфигураций аппаратной платформы и операционных систем.
Эффективная система взаимодействия, налаженная между заказчиком и исполнителем, позволит первому быть в курсе происходящего, влиять на процесс построения сайта и вместе с тем не подчинять свой рабочий распорядок только этому делу.
Осуществление оперативной двусторонней (или обратной) связи между заказчиком и исполнителем — крайне важное для успешной реализации проекта условие. При удаленной разработке проекта, да еще и силами нескольких подрядчиков оно может показаться трудновыполнимым. Конечно, можно устраивать постоянные личные встречи и вести бесконечные телефонные переговоры, но посредством телефона невозможно продемонстрировать функциональные возможности программного обеспечения или дизайн, а организовывать встречи по поводу каждого изменения утомительно и бесперспективно. Представьте себе 30—40 встреч в течение времени разработки (а именно столько изменений и поправок вносится в среднестатистический сайт на этапе его создания), и вам станет понятна актуальность встающей задачи.
Решить проблему взаимодействия можно несколькими способами:
1. Создать общее рабочее пространство. На время разработки можно организовать рабочие места исполнителей у вас в офи-
зволит вам в реальном режиме времени осуществлять контроль над этапами разработки вашего проекта, в оперативном режиме проводить совещания и согласования. Разумеется, это потребует дополнительных затрат на организацию труда и дополнительных офисных площадей.
2. Устраивать регулярные (например, еженедельные) встречи с разработчиками и в ходе таких встреч как согласовывать работы, так и обсуждать вносимые изменения. В определенной степени это решение может помочь вам координировать работу подрядчиков, однако оно несомненно увеличит сроки разработки проекта в целом, поскольку темпы принятия решений по оперативным вопросам будут снижены.
3. Назначить ответственного за решение оперативных вопросов, представляющего интересы вашей компании. Этот сотрудник должен будет контролировать проводимые работы, встречаться с исполнителями. Он должен занимать достаточно высокую должность в вашей фирме, чтобы принимать решения в кризисных ситуациях и брать на себя ответственность за них. Сам по себе этот вариант взаимодействия с подрядчиком достаточно неплох, но в большинстве случаев вы не сможете оторвать от производственного процесса сотрудника со столь высоким статусом.
4. Вспомнить, что вы начинаете работу в сфере высоких технологий и поставить эти технологии себе на службу с первых минут. Поскольку вы создаете сайт для пользователей и пытаетесь достичь его максимальной работоспособности, поскольку вы хотите устроить виртуальный офис или магазин и наверняка стремитесь к тому, чтобы пользователю было приятно посещать ваш ресурс, неплохо бы примерить на себя ту одежку, которую вы собираетесь предложить другим. Посредством Интернета вполне можно управлять разработкой сайта, для этого существуют такие формы общения, как почта и групповые листы рассылок, веб-форумы и ICQ. В режиме виртуального управления вы можете:
• контролировать степень готовности каждого этапа;
• передавать исполнителям свои пожелания и требовать внести исправления;
• проводить коллективные обсуждения;
• согласовывать последовательность действий.
Этот вариант контроля и управления сторонними исполнителями хорош и тем, что затраты на его воплощение в жизнь практически равны нулю, а эффективность достаточно высока.
Какой из вариантов контроля выбрать, решать вам, но одно можно сказать с уверенностью: если вы хотите получить от исполнителя именно то, что заказывали, вести поэтапный контроль работ необходимо.
Здесь уместно напомнить уже приводившееся ранее утверждение о том, что, выбрав исполнитей работы по профессиональным качествам, старайтесь прислушиваться к их профессиональному мнению. Не опасайтесь задавать вопросы. Профессионал всегда сможет простыми словами объяснить свое решение. Настаивать на своей точке зрения имеет смысл тогда, когда вы не услышали профессионального ответа на вопрос.
В один прекрасный день подрядчики сообщат вам о завершении работ по созданию сайта. Казалось бы, самое время раскупоривать шампанское? Не тут-то было. Впереди— один из ответственных этапов: приемка работ. Здесь решаются две задачи:
• оценка качества выполненных работ;
• проверка соответствия готового проекта требованиям ТЗ.
Придется скрупулезно исследовать все разделы и подразделы вашего сайта, «просмотреть» его при помощи разных браузеров и операционных систем, на мониторах с разными разрешениями и размерами. При больших объемах тестирования вам даже может понадобиться помощь привлеченных экспертов.
В состав комиссии по приемке сайта должны входить в первую очередь не программисты, а специалисты, имеющие представление об интернет-коммерции, интернет-маркетинге, и просто здравомыслящие люди, не понаслышке знакомые с Интернетом.
Ни в коем случае нельзя принимать недоделки, пускай даже и с обещанием в скором времени все исправить. Устранение не^ доделок собственными силами или силами других исполнителе выльется в отдельные, зачастую немалые суммы денег и горазД большие усилия, чем те, которых от вас потребует занятие жест
о подписывать, только убедившись, что работает все «до послед-него винтика».
Оценить качество выполнения работ можно только при помо-и последовательного тестирования, сама же оценка, в сущности, сводится к методичному исследованию всех страниц на предмет удобства их использования.
Пригодность любой системы (будь это интернет-сайт или циркулярная пила) для использования определяется по нескольким компонентам. ISO DIS 9241-11 (редакция Найджела Бевана) указывает 11 таких компонентов:
• удобство и простота использования (usability);
• качество рабочей системы в применении (quality of a work system in use);
• эффективность, результативность (effectiveness);
• оперативность, продуктивность (efficiency);
• удовлетворенность (satisfaction);
• контекст (обстоятельства) использования (context of use);
• рабочая система (work system);
• пользователь (user);
• цель (goal);
• задача (task);
• продукт (product).
Одним словом вам нужно получить ответы на ряд вопросов: может ли человек использовать сайт максимально эффективно, может ли сайт «делать» что-либо, что нужно людям? Если система совершает какие-либо не относящиеся к делу операции, но не мо-*ет решить основной задачи, для решения которой она создана, °гда не имеет значения, удобно ли ею пользоваться. Эта система плоха.
«Правило, которое подтвердило себя на практике: чтобы полу-
Ть достаточно объективную оценку вашего пользовательского
НтеРфейса, нужно попросить 5—10 человек попробовать восполь-
атъся им, — пишет обозреватель интернет-сайта Clickz.Com
РОН Хает. — Если у вас есть время протестировать большее ко-
ество людей, это поможет вам получить более подробные ре-
Льтаты' однако, как правило, добавочное тестирование редко вы-
ет значительные проблемы, которые не были замечены
Итак, что же такое юзабилити (англ, usability) ? Четкого определения, с которым согласны все, равно как и однозначного перевода понятия на русский язык не существует. Приблизительно этот термин можно перевести как «удобство и простота использования, практичность»; из уже устоявшихся в русском языке иностранных слов ближе всего по смыслу к нему стоит термин «эргономич-ность». Однако понятие usability, как нам представляется, имеет свой специфический смысл; кроме того, именно оно утвердилось в качестве термина среди западных, а теперь и российских консультантов в области интернет-технологий.
Вот какое определение этому понятию дает самый известный американский специалист по usability Якоб Нильсен: «Usability — это качество пользовательского опыта при взаимодействии с чем-либо, будь то интернет-сайт, программное обеспечение или любое устройство, с которым пользователю приходится работать. Например, юзабилити водопроводного крана можно определить, ответив на такие вопросы: можете ли вы сразу понять, как поворачивать кран, чтобы добиться нужного результата? Обожгли ли вы себе руки при первой попытке им воспользоваться?» Известные определения usability принадлежат также Б. Шекелу, X. Хендрику и некоторым другим ученым. Например, Н. Беванв книге «Руководство по юзабилити» определяет usability как «рамки (пределы), в которых продукт может быть использован определенными категориями пользователей для эффективного, оперативного, приносящего удовлетворение достижения конкретных целей при заданных обстоятельствах использования».
На Западе тестирование юзабилити интернет-проектов уже давно превратилось в отдельную область IT-консалтинга. Тестирование юзабилити, проводимое внешними консультантами, обычно стоит около $30,000 (в Америке) и занимает по меньшей мере несколько недель. В России цены на услуги консультантов, к счастью, не так высоки, но профессиональных специалистов по юзабилити, к сожалению, пока практически нет. Конечно, и в нашей стране уже сформировался круг людей, профессионально занимающихся созданием интернет-проектов. За определенную плату они могут указать на ваши очевидные ошибки. Конечно, большую часть информации, которую вы получаете от таких исследований, можно собрать своими силами и бесплатно. Привлечение консультаН-
утверждение: «Если человек заболел, то доктор и сосед, возможно, зададут одинаковые вопросы, но выписывать лекарство лучше доверить первому». Основная проблема тестирования заключается не в том, чтобы найти человека, заставить его работать с системой и затем задать вопросы, а в том, чтобы отобрать из его ответов самые важные данные, систематизировать их и, главное, сделать по ним верные выводы.
Но где же найти подопытных кроликов или, как называет их Якоб Нильсен, «бета-тестеров»? Есть несколько источников поиска подходящих для тестов людей, то есть таких, которые согласятся потратить час своего времени, работая с вашим интернет-сайтом за коробку шоколадных конфет. Здесь нужно помнить одно общее правило: бета-тестерами должны быть потенциальные пользователи интернет-сайта, представители целевой аудитории.
Например, к тестированию юзабилити можно привлечь служащих вашей компании. Если ваша компания достаточно крупная, то последние десять человек, которых вы нанимали на работу, скорее всего, знают о ней не больше тех, кого вы могли бы просто остановить на улице. Тест по юзабилити можно обязать проходить всех новых служащих или даже кандидатов на рабочее место в вашей компании во время собеседования. Для тестирования корпоративного сайта или интернет-магазина как нельзя более подойдут секретари, бухгалтеры, работники отдела кадров и даже охранники офиса.
Второй вариант — обратиться к служащим соседних компаний. Если соседи тоже занимаются интернет-бизнесом или информационными технологиями, они будут более чем рады протестировать ваш продукт и проведут час за этим занятием в обмен на то, что тоже смогут рассчитывать на вас в будущем, если им понадобится подобная помощь. К тому же это неплохой способ ненавязчиво проинформировать окружающих о ваших новых возможностях или услугах.
Еще один источник — существующие потребители или клиенты. Как ни странно, многие потребители (особенно в сфере розничной торговли и услуг) получают удовольствие, когда их задействуют в процессе разработки. В обмен на футболку или порцию пиццы они "Удут рады посетить ваш офис и поработать, как нужно, около часа. Кроме того, после подобного знакомства с вашей компанией у посетивших вас потребителей прибавится доверие к вам.
И наконец, не забывайте о тех, кто всегда рядом и готов помочь: АРузья и семья. Хотя, скорей всего, по демографическим показате-
лям бабушка и не подходит на роль вашего среднестатистического клиента, она может стать лучшим критиком юзабилити вашего продукта. Если вы сможете создать интерфейс, который понятен человеку с минимальным опытом работы в Интернет, значит, вы ориентируетесь на 99% населения. Однако это может обернуться для вас непредсказуемыми последствиями: возможно, вам придется провести целый час, объясняя, как пользоваться мышкой.
Итак, предположим, что вы уже потратили время на поиски субъектов исследования и договорились о том, что переговорная в назначенное время будет свободна. Вы можете потратить еще час или два, чтобы убедиться в собственной готовности. Избегайте импровизированного тестирования. Вот несколько советов относительно того, как приготовиться к тестированию.
Заставьте пользователей решать конкретные задачи. Создавая сайт, вы уже запланировали, как посетители будут его использовать. Попросите «подопытных» выполнить несколько определенных задач, возможность выполнения которых подразумевается на сайте. Пусть они попытаются купить что-либо из вашего каталога, зарегистрироваться для получения новой услуги, найти по поиску определенную вещь, изменить способ оплаты счета, подписаться на рассылку и т.п.
Попросите пользователей рассказать, о чем они думают при работе с интернет-сайтом. Вы можете многое понять, просто наблюдая, как кто-то пытается использовать ваш сайт. Однако результаты вашего тестирования будут намного точнее, если вы попросите испытуемых говорить вслух обо всем, о чем они думают во время своих попыток. Это хороший способ избежать построения догадок по поводу того, почему пользователь не пошел по изначально запланированному для него пути. Случайно вы даже можете услышать замечание, которое изменит ваш взгляд на дизайн сайта. И главное: пока пользователь тестирует ваш сайт, старайтесь ничего не говорить. Ведь ваша задача состоит не в том, чтобы продемонстрировать собственную осведомленность; к тому же в дальнейшем вы вряд ли сможете сидеть рядом с каждым посетителем вашего сайта и давать ему замечательные советы.
Старайтесь, чтобы в процессе тестирования был занят не один, а несколько человек из вашей команды, разрабатывавшей пр°' дукт. Это уменьшит вероятность того, что вы неправильно истол
'-ЭТО
куете какие-нибудь действия или комментарии испытуемых. -~>1 особенно важно, если результаты тестирования могут принципй ально изменить путь развития продукта: вы можете быть сильй
ограничены во времени и просто не захотите увидеть, что сайт нуждается в глобальных изменениях, или сработает ваше эго, которое «привязалось» именно к такой функции или расположению страниц. Тестирование можно записать на видео; впоследствии запись просматривается и обсуждается всеми членами команды разработчиков.
Протестируйте весь продукт. Если уж вы потратили время на «отлов подопытных кроликов», выжимайте из них все, что они могут вам дать. Попытайтесь получить их мнение не только по поводу отдельных особенностей вашего продукта, расположения кнопок и страниц. Спросите, что они думают о маркетинговых страницах интернет-сайта, что они ожидают от общения по электронной почте с менеджерами после того, как испытали продукт, оцените их реакцию на разные ценовые стратегии и т.п.
Предусмотрите разные возможности ваших будущих пользователей. При проведении тестирования учитывайте, что посетители будут по-разному оснащены технически. Сделайте так, чтобы ваш интернет-сайт оценили и при работе с «медленным» компьютером, старым монитором и минимальным разрешением экрана. Наверняка в вашем офисе имеется выделенная линия для подключения к Интернету. Поэтому будет полезно, если скорость загрузки страниц вашего интернет-сайта кто-нибудь проверит с dialup-соедине-ния. Очень часто дизайнеры, привыкшие к быстрой связи, чрезмерно перегружают интернет-сайт графикой, которая вместо того, чтобы доставлять удовольствие, отравляет жизнь простым домашним пользователям.
Совершенству, как известно, предела нет. Поэтому юзабилити вашего интернет-сайта желательно протестировать не один, а несколько раз в процессе создания, каждый раз исправляя обнаружившиеся ошибки и проводя тест заново. Последний тест должен вестись уже на полностью готовой и рабочей версии, наполненной информацией. В ходе этого теста необходимо учитывать все попадания пользователя на ошибочные страницы и невозможность найти реально присутствующую на интернет-сайте информацию.
Б. Шекел (в 1991 г.) и Я. Нильсен (в 1993 г.) описали подход к из-еРению юзабилити, используя пять разных шкал, не включа-полезность:
task time — время выполнения задачи. Если пользователь уже научился работать с системой, то как быстро он сможет при бе помощи выполнить необходимую задачу?
• errors — ошибки. Как часто пользователь может допускать ошибки? Насколько серьезны могут быть последствия этих ошибок (остановка работы атомной станции серьезнее, чем обнуление счетчика на интернет-сайте для онлайновых игр) и как легко можно устранить их?
• learning— изучение (познание). Как быстро пользователь который никогда раньше не видел данного интерфейса (программы, интернет-сайта) или устройства, научится с ним работать достаточно хорошо для выполнения основных задач?
• relearning — переподготовка. Если посетитель когда-либо уже работал с системой, то сможет ли он в следующий раз вспомнить достаточно, чтобы использовать ее более эффективно, или ему придется каждый раз учиться все делать заново?
• satisfaction — удовлетворение. Насколько посетителю нравится использовать эту систему?
Каждая система обладает всеми пятью характеристиками, и все они должны учитываться при разработке. Но в некоторых случаях одни характеристики становятся важнее других. Например, для сайта наиболее актуальной является простота изучения, так как посетители очень редко проводят на одном интернет-ресурсе достаточно времени, чтобы стать экспертами в его использовании. Также критическим для интернет-сайта является фактор субъективной удовлетворенности, ибо в Сети пользователь легко может уйти куда угодно, лишь один раз щелкнув мышью. Пользовательские ошибки не так критичны для большинства интернет-сайтов, исключая интернет-магазины: здесь пользователь должен заказать именно то, что хочет, и правильно ввести номер своей кредитки и адрес доставки.
Интерфейс приложений, предназначенных для использования в Intranet, в свою очередь, должен быть ориентирован на максимальную эффективность, так как предполагается, что с его помощью будут работать одни и те же люди (которым компания к тому *е платит деньги). В интерфейсе для Extranet должно быть сведено к минимуму количество пользовательских ошибок, так как такие сети часто используются для проведения крупных транзакции.
Итак, основные принципы юзабилити, казалось бы, просты (как все гениальное): делай так, чтобы твоему пользователю было ма симально удобно и комфортно работать с продуктом, и ты завою ешь его доверие. Однако на деле все оказывается не так гладк множество устройств, программ и интернет-сайтов
огорчать пользователей бестолковым расположением кнопок, непонятным интерфейсом и ничего не объясняющим разделом «по-
могць»-
Вполне закономерно, что недовольство пользователей приводит
компанию, производящую продукт или предоставляющую услугу, постепенной потере клиентов. И если в реальном мире этот процесс не так заметен (я, например, уже несколько лет пользуюсь очень неудобным по расположению кнопок пультом дистанционного управления от телевизора Phillips, а один мой знакомый так и не собрался поменять модель мобильного телефона с плохим, по его мнению, интерфейсом на другую), то в Интернете, благодаря практически неограниченной свободе выбора и возможности мгновенно его осуществить, раздраженный клиент уходит сразу и чаще всего навсегда.
пользования продукта. Таким образом, юзабилити и качество использования определяется не только продуктом, но и взаимодействием пользователя, продукта и среды. Здесь сразу же встают нехарактерные для традиционной разработки программ вопросы: определить группы пользователей, которые могут решать конкретные задачи в особых условиях. В этом смысле узкое определение юзабилити не решает задачу, поскольку решение зависит не только от простоты использования, но и от утилитарности (заложены ли в систему необходимые функции), эффективности (времени работы и реакции системы), надежности (вероятности ошибок системы и того, может ли человек восстановить систему после ошибок), удовлетворенности (субъективного показателя) и пр. В таком более широком смысле юзабилити было определено еще в 1988 г. Вайтсайдом, Беннеттом и Холзблатгом. Как отмечал Найджел Беван, автор стандарта ISO 9241, в этом более широком смысле юзабилити оказывается синонимом «качества использования», то есть наивысшим уровнем определения качества, которое позволяет продукту не про- j сто соответствовать спецификациям, но и позволит ; человеку работать с ним в реальных условиях.
Из разницы этих двух взглядов возникает и разница в подходах к тестированию юзабилити. В соответствии с первым, более узким подхо-
Юэабилшпи программного продукта
Существует два основных взгляда на юзабилити. В первом предполагается, что юзабилити является одним из качеств, которые наряду с функциональностью, эффективностью, надежностью могут быть воплощены в продукте. Этот взгляд подразумевает, что юзабилити — это внешнее дополнительное качество продукта. Такой подход использует Нильсен. С этой позиции можно говорить о системе с отличным показателем юзабилити (великолепным простым интерфейсом), но при этом совершенно бесполезной.
На мой взгляд, это не самый лучший путь определения понятия, поскольку юзабилити в этом смысле ничего не говорит о конечном качестве иуспехе продукта в реальном мире. Более широте Распространение получает второй взгляд на юзабилити, где этим термином определяется, сможет ли человек решить свою задачу, используя Р°ДУкт. В этом ключе сформулировано определение ISO 9241-11, к этой идее идет и ISO 9126, Дополнив определение юзабилити в последней ВеРсии стандарта упоминанием о контексте ис-
Из всего вышесказанного следует, что тестирование юзабили-ти — это обязательная операция, которая должна предшествовать запуску любого проекта в Интернете.
дом, юзабилити измеряется как набор показателей, не связанных напрямую с особенностями использования данного продукта. Для этого используются такие методы, как руководства (guidelines), представляющие собой набор рекомендаций, следуя которым можно сделать продукт более удобным. Отрицательной чертами такого подхода является то, что в конкретном случае не все рекомендации следует использовать — иногда лучшее решение им противоречит. Тем не менее их применение позволяет сделать продукт более удобным, основная проблема лишь в том, чтобы найти рекомендацию, наиболее соответствующую данной ситуации. В рекомендации могут входить такие пункты: элементы интерфейса должны быть сделаны в едином стиле; нагрузка на кратковременную память должна быть минимальной; пользователь всегда должен иметь возможность отменить свое действие; пользователь должен иметь представление о состоянии процесса, которым он руководит и т.п.
Другим методом в этом подходе может быть привлечение экспертов по эргономике только на последнем этапе проектирования, когда вся функциональность уже спроектирована и реализована и вопрос стоит только о том, как лучше оформить продукт или какие незначительные изменения можно сделать. В соответствии со вторым, более широким взглядом юзабилити измеряется тем, насколько эффективно пользователь может выполнять свои задачи. Другими словами, юзабилити здесь вносит вклад в конечное качество продукта и в успех продукта на рынке. Однако для того, чтобы использовать этот метод, необходима перестройка процесса проектирования - ориентирование его не на то, чтобы с помощью продукта теоретически можно было выполнять набор действий, а на то, чтобы определенные пользователи могли выполнять свои задачи в конкретных условиях. Для этого необходимо определить особенности пользователей, методы их работы, четко представлять задачи, стоящие перед ними, и среду, в которой они работают, что требует детального анализа деятельности и контекста, в котором она осуществляется. Далее устанавливаются параметры эффективности и экономичности
работы, а также удовлетворенности пользователя, которым продукт должен соответствовать Таким образом, привлечение эксперта по эргономике необходимо уже на этапе постановки задачи. Кроме того, следует учитывать очень широкий набор параметров — эргономических, психологических, социальных, культурных, организационных и пр.Этотчеловекоориентированный подход идет вразрез с традиционным методом проектирования, ориентированным на продукт, в котором определяется функциональность системы, составляются спецификации. Преимуществом данного метода является то, что готовый продукт будет подходить под конкретную деятельность реальных пользователей. Особенностью его является частое повторение процесса «исследование деятельности пользователей — создание модели его деятельности — построение на ее основе прототипа - его проверка пользователями», а также более глубокое вовлечение пользователя в процесс проектирования (эргономика участия).
Тестирование проходит с привлечением пользователей, перед которыми ставятся задачи, определенные на первом этапе при анализе деятельности. Важной особенностью является то, что у пользователей, участвующих в тестировании, должна быть мотивация достичь цели. В качестве мотивации в тестировании часто используется оплата. Это даже не этический вопрос оплаты труда, а вопрос эффективности и достоверности тестов. Одно дело, когда человек бесцельно бродит по сайту и через полчаса высказывается, что все довольно красиво, ему понравилось. Совсем другое, когда он пытается проделать конкретную работу за определенную мзду. Таким образом, необходимо оценить все плюсы и минусы, прежде чем бесплатно приглашать на тестирование сотрудников своей или соседней фирмы.
Я использую в работе второе, более широкое определение юзабилити и следующие из него методы работы. Ни один из методов не дает гарантированно успешного продукта, но данный подход позволяет построить разработку на основе того, какую деятельность необходимо помогать осуще-ствлять пользователям. В итоге продукт востребован реальными людьми, ведь именно исходя из их потребностей он и создавался.
соответствия техническому заданию
оажнейший этап приемки интернет-сайта — его тестирование на предмет соответствия требованиям технического задания (ТЗ). Испытания могут быть как автономными, так и комплексными.
Автономные испытания охватывают отдельные составляющие интернет-сайта, их проводят по мере готовности (см. часть 6). Что касается комплексных испытаний, то их проводят для всего сайта в целом. В зависимости от вида требований, изначально предъявляемых к интернет-ресурсу, в процессе испытаний проверяют:
• комплекс программных и технических средств;
• качество выполнения оформительских и композиционных работ;
• грамотность и правильность первичного наполнения сайта.
Интернет-ресурс не стоит испытывать на компьютерах исполнителя, поскольку на них эти испытания уже наверняка были проведены в процессе изготовления. Как показывает практика, большинство ошибок в работе интернет-сайтов выявляется при попытках доступа к нему с разных компьютеров. Строго говоря, это даже не ошибки в полном смысле слова, а результат несогласованности между разными операционными системами и программами просмотра HTML-страниц. Но эти несоответствия можно свести практически к нулю, если, конечно, вовремя их заметить.
Испытания проводят в соответствии с заранее подготовленным графиком испытаний, в котором указывают:
• перечень объектов для испытаний и требований, которым должны соответствовать объекты (со ссылкой на пункты ТЗ).Сюда могут быть включены HTML-страницы, графика, программное обеспечение и т.п.;
• средства для проведения испытаний. Например, необходимо указать, что для проведения испытаний требуются компьютеры с операционными системами Windows 95, Windows 2000, Mac OS и Linux, а в качестве программ просмотра HTML-страниц должны быть использованы браузеры IE 4.*, IE 5.*, NN 5* и т.д. при разрешениях монитора 840x680, 1024x800, 1200x840. Прежде чем составлять такой список, вы должны узнать, какими операционными системами и версиями браузеров пользуется ваша целевая аудитория. Лучше сделать это еще на этапе анализа интернет-аудиторий, в начале подготовки проекта;
Фамилии лип. ответственных за поовеление испытаний.
Протоколы испытаний объектов по всей программе обобщат в едином протоколе, на основании которого делают заключени о соответствии интернет-ресурса требованиям ТЗ и возможност оформления акта приемки сайта в постоянную эксплуатацию ра боту завершают оформлением акта сдачи-приемки.
Технологический аудит
Технологический аудит, или комплексная диагностика сайта, — это получение независимого, квалифицированного и аргументированного заключения о качестве работы интернет-ресурса. Заключение о качестве работы сайта делается на основе анализа следующих параметров:
• скоростных характеристик сети;
• характеристик сетевого трафика;
• характеристик работы веб-сервера;
• скорости загрузки самого интернет-сайта;
• времени реакции прикладных программ;
• результатов взаимной корреляции указанных выше параметров.
Как видно из данного списка, критерии оценки можно разделить на объективные, не имеющие прямого отношения к сайту (сеть, сетевой трафик) и субъективные (работа веб-сервера, сайта, прикладных программ). Необходимо четко отделять субъективные и объективные критерии оценки друг от друга, и такое разделение, равно как и технологический аудит в целом, могут произвести только профессионалы в области интернет-технологий.
Технологический аудит не является обязательной процедурой и нужен только в случае вашей неудовлетворенности скоростью или качеством работы сайта. Например, если разработчик утверЖ дает, что медленная работа интернет-сайта и возникновение оШ бок являются следствием внешних факторов (низкое качество У луг интернет-провайдера, плохое оборудование и т.д.) и такая то ка зрения не совпадает с вашей, то технологический аудит, выпо ненный независимой компанией, позволит подтвердить или Р веять ваши подозрения.
Необходимо помнить, что итогом технологического ауАй
ото функционирования интернет-сайта, но и, в обязательном по-ядке, пути решения возникших проблем.
Одна из обязанностей заказчика по договору — принять результаты работ от исполнителя. Заказчик должен осмотреть выполненную работу (результаты) и при обнаружении несоответствия результатов установленным в договоре и техническом задании критериям заявить об этом исполнителю.
В договоре необходимо четко установить сроки, в течение которых происходит тестирование результатов заказчиком, их принятие или же выставление мотивированного возражения, исправление выявленных недостатков исполнителем.
Законодатель установил правило, согласно которому, если эти сроки не будут четко закреплены в договоре, приемка результатов и исправление недоработок может производиться в «разумные сроки». Но согласитесь, понятие «разумные» достаточно абстрактно, и можно потратить много времени в суде, устанавливая его точную величину для конкретного вида работ. Поэтому необходимо:
• установить все сроки в договоре в численном выражении рабочих дней;
• определить степень ответственности каждой из сторон за нарушение сроков выполнения своих обязательств.
Это будет стимулировать вас и вашего контрагента к четкому ВьШолнению условий договора.
Вторая сторона с момента получения претензии обязана жить свою позицию по указанным принципиальным вопроса и послать свой ответ по регулярной и электронной почте (в д0г воре надо прописать, в течение какого срока сторона должна п слать ответ на выставленную претензию и с какого момента отсчи тывается этот срок: с момента получения текста претензии по ре гулярной или электронной почте).
Если сторона, считающая, что ее права и интересы нарушены в ходе исполнения договора другой стороной, не удовлетворяется полученным ответом или не получает его по регулярной почте в течение 60 дней со дня отправки первой претензии, то претензионная процедура разрешения споров считается исчерпанной, а спор подлежит рассмотрению в арбитражном суде. Стороны могут и не прибегать к претензионному порядку, а сразу же обратиться в арбитражный суд, однако это абсолютно неэффективный способ, и на практике он обычно не применяется.
Хочется отметить еще один момент. Стороны могут избрать для разрешения споров обращение в третейский суд. Для этого необходимо заложить соответствующее условие в договор, иначе спор будет рассматриваться в обычном арбитражном порядке.
Составление акта сдачи-приемки работ
Подписание акта сдачи-приемки работ по производству интернет-сайта — это констатация вами факта выполнения всех работ и основание для проведения окончательных рассчетов между заказчиком и подрядчиком. При этом необходимо следить за выполнением всех процедур приемки работ, отмеченных в договоре, их полнотой и комплектностью.
Поспешность заказчика, вызванная сжатыми сроками или вполне понятным желанием побыстрее «запустить проект», может при вести к отрицательным результатам. Если деньги уплачены, а ак сдачи-приемки работ, в котором указано, что качеством работ з казчик удовлетворен, уже подписан, то выставить претензии ФИР ме-изготовителю довольно сложно.
Поэтому стоит проявить еще немного терпения и вниматель рассмотреть все этапы выполнения работ на предмет соответ
вия их выполнения техническому заданию. Какими силами и
в к3' этой
приемки работ стороны составляют акт с перечнем необхо-доработок и сроков их выполнения.
кой последовательности производить эту проверку, описано в • части. В случае мотивированного отказа заказчика от подписи
На этапе разработки чаще всего возникают следующие ошибки:
• заказчик единожды встречается с исполнителем, передает ему техническое задание, высказывает дополнительные пожелания, и стороны больше не контактируют до момента сдачи работ. Пустив работы над проектом на самотек, вы в лучшем случае рискуете получить не совсем то, что заказывали, а в худ-шем — совсем не то, что нужно вашей целевой аудитории. Регулярный мониторинг и коррекция выполнения работ необходимы при создании любого корпоративного интернет-сайта;
• работы проводятся без календарного плана, а только на основе договоренности и технического задания. Отсутствие четкого разбиения работ на этапы препятствует пониманию степени готовности интернет-сайта в процессе его производства. Более того, в таких условиях заказчик не может в полной мере оценить трудозатраты подрядчика, что зачастую приводит к их недооценке или переоценке;
• при планировании работ не учитываются всевозможные риски. Процесс создания интернет-сайта зачастую подвержен внешним и внутренним рискам. Их планирование позволяет вам продумать оперативные шаги в возможных кризисных ситуациях еще до того, как они наступят, а значит, встретить кризисную ситуацию во всеоружии;
• не организована оперативная связь между разработчиками и заказчиками. Это может серьезно повлиять не только на сокращение сроков разработки, но и на общую стоимость управления ей. Существует много способов реализации такой связи, и конкретный выбор должен осуществляться на основе реалий вашего бизнеса;
заказчик осуществляет чрезмерное давление на разработчика по объективно непринципиальным вопросам. При разработке проекта вы должны исходить из одного правила: принятие решений по всем вопросам, которые напрямую не влияют на взаимодействие интернет-сайта с потенциальными его посетителями, нало лелегивовать исполнителю. Дшггими ело-
вами, если вы не можете аргументированно ответить на в прос, чем ваше видение интернет-сайта (его оформления, на полнения, интерактивных элементов, интерфейсов и т.д.) От личается от того, что предложил вам исполнитель, то претензий к последнему у вас быть не может;
• оценка качества и соответствия производится единожды, по завершении всех работ. Работа должна приниматься поэтапно. В противном случае вы рискуете оказаться в ситуации когда несоответствие или ошибка, допущенные на ранних сроках разработки, вынудят переделывать весомую часть интернет-сайта. Теоретически в этой ситуации вы можете доказать неправоту подрядчиков и потребовать переделки и возмещения убытков. Но даже тогда упущенное время вам вернуть не удастся;
• оценка качества продукта силами программистов или сотрудников фирмы, участвовавшей в разработке сайта. В идеале проверять работоспособность интернет-ресурса необходимо с помощью представителей вашей целевой аудитории, которые весьма поверхностно знакомы с Интернетом и компьютером вообще. Если такой человек не будет теряться при виде первой страницы вашего интернет-сайта и сам без труда и дополнительных объяснений найдет информацию, которую вы планировали до него донести, значит, работы были проведены успешно. А разработчики интернет-сайта или опытные компьютерные пользователи могут счесть очевидными вещи, которые можно назвать таковыми с очень большой натяжкой;
• осуществление проверки качества работ на компьютерах исполнителя. Как уже говорилось выше, большинство ошибок выявляется при попытке работы с интернет-сайтом на компьютерах, программное и аппаратное обеспечение которых отличается от того, что установлено у разработчика. Разум6 ется, разработчик должен сам обратить на это внимание и про вести подобное тестирование до сдачи продукта заказчику' но, как показывает практика, подобные проверки производят ся далеко не всегда;
проведение бессистемных мероприятий по проверке ^ ва работ. Все работы по проверке качества интернет-саИ должны быть регламентированы и включены в акт сдачи-пр емки работ (последнее необязательно, но желательно) . Это
зволит провести детальную последовательную проверку всего интернет-сайта и минимизировать возможность появления ошибок, пропущенных на этапе эксплуатации.
выводы
Сайт, да простят нам такое сравнение, подобен торту, в котором исполнитель слой за слоем наращивает на общую структуру:
• оформление;
• программное обеспечение;
• интерактивные элементы и пользовательские интерфейсы;
• тексты и графические материалы.
В данной части было подробно рассказано, как проделать такую работу. Залогом ее успешности являются два условия:
• полноценная концептуальная модель будущего сайта;
• контроль над этапами разработки.
Последнее условие важно еще и потому, что в таком сложном Деле, как бизнес, очень трудно заранее предусмотреть все возможные нюансы, существенная роль которых обнаруживается уже в реальной работе готового интернет-сайта. Очень часто даже са-МУЮ идеальную концептуальную модель приходится корректировать с учетом этих практических обстоятельств. При этом заказ-Чик должен понимать, что зачастую его просьба изменить какую-либо незначительную (как ему кажется) деталь интернет-сайта п°хожа на просьбу заменить тесто, из которого выпечен торт. Потому приступать к изготовлению интернет-ресурса, не определившись с тем, из чего именно он будет состоять, не только неразум-°, но и просто невыгодно.
Очень важно соблюсти баланс между контролем за ходом ве-Ния работ и предоставлением свободы разработчикам. Вдос-*ении такого баланса полезно руководствоваться правилом: ^ ли видение разработчика не противоречит общей концепции нарушает процесса взаимодействия с потенциальными по-гелями интернет-сайта, с ним нужно согласиться. Вместе , когда речь заходит о психологии и поведении целевой ауди-Т°РИи
ределенное, последнее слово должно оставаться за представителями заказчика.
И наконец, о тестировании и опытной эксплуатации. М. Ж.ва-нецкий замечательно сказал о том, что «ремонт нельзя закончить — его можно только прекратить». То же утверждение справедливо и по отношению к сайту: его можно совершенствовать и доводить до идеального состояния бесконечно. Но, как только вы поймете что ваш интернет-ресурс в состоянии выполнять возложенные на него бизнес-задачи, необходимо открывать к нему доступ посетителей, а все усовершенствования и дополнительные сервисы «надстраивать» в процессе работы.
Этап тестирования интернет-сайта может стать первой маркетинговой акцией в плане продвижения вашего детища. Привлечение потенциальных клиентов к «полевым испытаниям» позволяет выявить сильные и слабые стороны сайта, к тому же информация о нем начинает распространяться среди ваших будущих клиентов и/или партнеров. Пожалуй, Интернет — это единственная среда, в которой возможна открытая и массовая оценка качества создаваемого продукта силами его будущих пользователей. Глупо не использовать такую возможность.
Однако не стоит принимать как руководство к действию любые пожелания пользователей. Если вы будете проводить подобное тестирование и зададите вопрос «что еще вы хотели бы увидеть на нашем интернет-сайте?», гарантируем вам массу ответов, содержащих слово «чат». Вместе с тем вы не увидите ни одного сайта, которому упомянутый чат помогал бы решать бизнес-задачи. Так что тестеров лучше спрашивать об удобстве и функциональности существующего сайта, а не о том, каких разделов ему не хватает.
И наконец, не спешите подписывать акт сдачи-приемки работ, по крайней мере до тех пор, пока не удостоверитесь, что интернет-сайт функционирует нормально. Если же у вас возникнут сомнения по этому поводу, прибегните к услугам фирм, профессио нально проводящих оценку и технологический аудит интернет-ресурсов. Если ваши сомнения подтвердятся, то затраты на при влечение таких фирм оплатите не вы, а исполнитель работ по из готовлению вашего интернет-сайта. Разумеется, это произоид только в том случае, если вы серьезно и ответственно подриде к составлению всех сопроводительных и договорных документе