Глава 10
Користувачі, їхнє робітниче середовище
і задачі
Одна з головних причин створення невдалих продуктів полягає в недостатньої вовлеченности користувачів у проект. Не менше значення мають і наслідку недостатньо активної участі користувачів у проекті, зокрема відсутність глибоких знань про реальних користувачів продукту, середовищу використання розробки і рівня застосування тих чи інших задач. Деякі продукти відрізняється досить конкретним колом користувачів і досить визначеним середовищем використання і задачами. Для інших продуктів сукупність користувачів відрізняється великою розмаїтістю поряд зі значними відмінностями в середовищах і задачах. Незалежно від того, чи зіштовхується проектна бригада з однорідною чи різнорідною безліччю користувачів, середовищ і задач, існує визначеного роду інформація, що відіграє важливу роль при створенні продукту.
Детальна інформація про користувачів, середовища і задачі допомагає установити рамки, у яких повинне здійснюватися проектування ПІ продукту і забезпечуватися його практичність. Є трохи дуже корисних методів, застосовних для збору важливої інформації про користувачів, середовища і задачі.
Поряд з вимогами до ПІ і практичності критична інформація про користувачів, середовища і задачі допомагає бригаді розроблювачів виділити ті особливості продукту, що бажають бачити реальні чи користувачі в який вони бідує. Інформація про користувачів і їхні потреби важлива для відповідного вибору методів створення ПІ і підходів до проектування загального стилю додатка.
У цій главі розглядаються наступні питання.
" Користувачі продукту, їхня робота і середовище: спроба аналізу.
" Методи.
" Приклади питань.
" Обробка результатів аналізу.
" Продовження обговорення проекту: користувачі, задачі і середовища.
Користувачі продукту, їхня робота і середовище:
спроба аналізу
Аналогічно будь-яким іншим взаєминам, у яких бере участь користувач, він привносить у своє відношення до комп'ютера і програмного забезпечення властиві йому особливості, навички і думки. От приклади найбільш помітних характеристик користувача в зв'язку з його роботою на комп'ютері і з його відношенням до програмного забезпечення.
" Попередні знання і досвід, використовувані в області апаратного і програмного забезпечення.
" Попередні знання і досвід, що стосуються підтримки задач прикладної області.
" Фізичні й індивідуальні характеристики.
" Фізичні і соціальні особливості робітничого середовища.
Рис. 10.1. Користувачі, середовища і задачі в орієнтованій на користувача розробці продукту
Навіть якщо ви розробляєте ПО для єдиного користувача, що працює в одній і тім же середовищі, задовільний облік усіх факторів залишається нелегкою проблемою. Завдяки величезному розкиду індивідуальних характеристик користувачів розробка для великого колективу користувачів у межах одного середовища являє собою ще більш пугающую задачу.
Корисне правило. Усім догодити неможливо. Програмний продукт і його ПІ не можуть цілком пасувати всім користувачам.
Бригада розроблювачів продукту прагне спроектувати і розробити систему, що задовольняє вимогам і відрізняється достатнім обсягом функцій і гнучкістю, щоб забезпечити потреби організації, основні запити окремого користувача, відомі вимоги і домогтися всього цього при задовільному відношенні користувача. З цього погляду орієнтована на користувачів бригада розроблювачів продукту повинна усвідомити, що собою представляє безліч передбачуваних користувачів, середовища, у яких користувачі мають намір працювати із системою, а також робота, що користувачі планують виконувати за допомогою системи.
Порівняльні Приклади. Легко допустити, що велика частина кола користувачів однорідна по своїх навичках і перевагам. Також неважко припустити, які якості користувачі бажають бачити в продукті. Приведемо кілька прикладів, щоб показати відмінності цих особливостей.
1. Розглянете характеристики дітей дошкільного віку, що проживають у США. Проаналізуйте ключові особливості подібного кола пользовате-лей, що впливають на проектування простої комп'ютерної гри, розрахованої на традиційний ПК у приміщенні школи. Проаналізуйте характеристики дітей з інших країн, які з цих характеристик впливають на проектування цієї ж комп'ютерної гри?
2. Розглянете характеристики людей похилого віку, що проживають у будинках преста-релых чи лікарнях. Проаналізуйте ключові особливості подібного кола користувачів, що впливають на проектування комп'ютерної гри, що призначена для перевірки гостроти зору і слуху.
3. Розглянете характеристики груп користувачів, описаних у п.1 і п.2 при-менительно до тому самому додатка, розробленому для підтримки електронної пошти і телефонного спілкування на основі ПК.
4. Розглянете характеристики конторських службовців у США у віці від 18 до 65 років разом з великою кількістю працівників, що займаються підробітком, у віці від 14 до 17 років. Проаналізуйте ключові особливості подібного кола користувачів, що впливають на проектування офісного додатка для звичайних ПК.
5. Розглянете характеристики виробничих працівників в усьому світі, вік яких коливається від 10 до 75 років, а рівень утворення - від 4 класів середньої школи до аспірантури. Тут у гру вступає розмаїтість мов і різні культурні фактори.
" Проаналізуйте ключові особливості подібного кола користувачів, що впливають на проектування додатка, призначеного для видачі інструкцій зі зборки, а також спостереження за якістю на виробничій площадці й в управлінських офісах.
" Для подальшого аналізу припустите, що додаток виконується звичайному ПК і спеціалізованому устаткуванні, а що збирається продукци] конкурує на ринку з високою ціновою чутливістю, крім худий* процес зборки значно залежить від робочих операцій.
Корисне правило. Не будуйте занадто багато припущень у зношена! якої-небудь групи користувачів, а також фізичних і соціальних умов так роботи.
Вплив розглянутих факторів на проектні рішення.
Зіставляючи групи користувачів, їхнього середовища і задачі, легко прийти до висновку що чим більш однорідно користувачів і робітниче середовище, тим більше визначеними можуть бути вимоги до проекту. Чим великою розмаїтістю відрізняється коло користувачів і робітничі середовища, тим більше проблематичними стають висновки у відношенні проектних рішень.
Корисне правило. Більш загальний характер кола користувачів, робітничого середовища і задач, що повинні підтримувати додаток, безпосередньо впливають на планування таких характеристик продукту, як гнучкість і можливість на будівництва.
Вплив розмаїтості задач і середовищ на проектні рішення аналогічні (тобто чим більше розмаїтість, тим більше воно впливає на проект). Однак, як говориться попереджений - значить збройний. Планування таких характеристик продукту, як гнучкість і можливість настроювання, має критичне значення навіть для ПО, орієнтованого на продуктивність. Нижче приводяться приклади проектних можливостей, що можуть бути необхідними, але не супутніми.
" Інтерфейс для новачків, випадкових користувачів і фахівців.
" Поступове розкриття можливостей.
" Кілька методів підтримки продуктивності.
" Можливості вибору користувальницьких переваг.
" Множинні представлення.
Іншими словами, для підтримки широкого кола користувачів з більш різноманітними задачами потрібно виконати більший обсяг роботи, особливо у випадку пред'явлення строгих вимог у відношенні ПІ, практичності й інших факторів. Це суперечить тому, що звичайно розуміється під досвідом розробки Web додатків, в основі якого, як правило, лежить підхід "стригти усіх під одну гребінку".
Загальні характеристики користувачів
Кінцеві користувачі не являють собою однорідних колективів з аналогічними характеристиками. Кожен користувач - це особистість з унікальними навичками, поглядами і знаннями про роботу апаратного і програмного забезпечення комп'ютера. Крім того, кожному користувачу властиві індивідуальні переваги, схильності й антипатії. Виробленню проектних рішень повинне передувати вивчення розходжень у користувальницьких навичках, поглядах, а також аналіз цільового ринку, що передбачається обслуговувати.
Наприклад, крім таких характеристик користувачів, як утворення і досвід роботи, критична інформація про користувачів включає статистичні розподіл для наступних характеристик.
" Знання і досвід роботи з комп'ютерними системами і ПО програмними додатками для комп'ютерів, а також у прикладній області, для підтримки якої розробляється ПО.
" Відношення до роботи, бізнесам-процедурам і виконуваним задачам.
" Відношення до підтримки апаратного і програмного забезпечення компью-теров.
" Фізичні й особистісні характеристики.
" Характеристики соціального і фізичного робітничого середовища.
Однак при вивченні користувачів з погляду розроблювального ПО варто брати до уваги й інших факторів, деякі з них приведені нижче.
" Утворення.
" Основна мова.
" Навички введення даних і навички використання покажчика миші.
" Зорові, слуховые, мовні й інші види фізичних обмежень при-менительно до використання апаратних пристроїв комп'ютера.
" Вік і підлога.
" Переваги і стиль навчання.
" рівень навичок, Що Відчувається, і досвіду використання комп'ютерного обору-дования і ПО.
" Мотивація.
Переважно знати розподіл цих факторів, оскільки знання який - або окремої чи цифри навіть діапазону значень недостатньо для того, щоб охарактеризувати різнорідний колектив користувачів. Наприклад, рівень досвіду працівників може варіюватися від новачка до експерта, а частота використання системи може змінюватися від епізодичного до регулярного. Якщо переважна більшість користувачів - новачки, що використовують систему нечасто, бригаді розроблювачів продукту може знадобитися сформулювати проектні рішення, орієнтовані на новачків. Якщо число користувачів від новачків до експертів підкоряється нормальному розподілу, а система повинна використовуватися часто, можливо, буде потрібно вироблення більш гнучких проектних рішень.
Опису фізичного середовища
Аналогічно користувачам існує набір визначених властивостей, що характеризують робітниче середовище в термінах фізичних факторів. Приклади фізичних факторів включають фізичний робочий простір користувача, схему робочих площ організації, висвітлення, шум, фактори, що відволікають увагу, і інші эргономические елементи фізичного характеру, що позначаються на взаємодії користувача з комп'ютерною системою і її ПО. Орієнтована на користувачів бригада розроблювачів продукту повинна розуміти і брати до уваги будь-які фізичні фактори, що можуть уплинути на досягнення цілей, зв'язаних із забезпеченням практичності і створенням ПІ. От приклади подібних факторів.
" Заводський робітник може використовувати додаток в умовах робочої седц отличающейся високим рівнем шуму.
" Працівник офісу може використовувати аналогічне ПО в стаціонарної шц мобільному середовищі.
Існуюча робітниче середовище і робітниче середовище в майбутньому можуть значно відрізнятися. Робота виконується на централізованих робочих місцях у приміщеннях компанії, у мобільному і домашнім середовищі. Підтримка задач користувачів у кожнім середовищі може значно відрізнятися. Наприклад, співробітник, що працює в офісі, може користатися перевагами високошвидкісної локальної обчислювальної мережі, у той час як у розпорядженні співробітника, що працює далеко від офісу, може бути тільки відносно низкоскоростной модем. Навіть у межах однієї і тієї ж бізнес - середовища технологія підтримки користувачів звичайно неоднакова. Відповідні ключові перемінні варто вивчити і врахувати при проектуванні.
Опису соціального середовища. Робітниче середовище в термінах соціально-психологічних факторів можуть бути охарактеризовані визначеними наборів властивостей. До прикладів подібних властивостей відносяться психологічна близькість з іншими співробітниками, рівень конфіденційності виконуваної роботи, можливості переривання процесу виконання задач, а також ступінь вовлеченности в роботу, виконувану співробітником, інших службовців. Проектна бригада повинна розуміти і брати до уваги будь-які фізичні фактори, що можуть уплинути на досягнення цілей, зв'язаних із забезпеченням практичності і створенням ПІ. Bот приклади подібних факторів.
" Представнику компанії по обслуговуванню клієнтів необхідно взаємодіяти з зовнішніми клієнтами за допомогою телефонної головної гарнітури в середовищі, де потрібно, але неможлива конфіденційність.
" Іншому представнику компанії по обслуговуванню клієнтів необхідно спілкуватися з одним чи декількома помічниками, у той час як клієнту приходиться чекати щонайменше один раз.
Масштаб змін у бізнес - процесах і комп'ютерних системах являє собою ще один важливий фактор, якому варто вивчити і врахувати в процесі проектування. Те, наскільки комфортно будуть себе почувати користувачі при виникненні змін, також підлягає вивченню. Існують і інші соціально - соціологічні фактори, деякі з них приведені нижче.
" Натиск і вимоги при здійсненні бізнесів-процесів.
" Тиск із боку керівництва, майстрів, помічників і замовників.
" Групова динаміка й організаційне поводження.
" Очікувана кількість робочого часу.
" Переривання задач.
" Загальна атмосфера робітничого середовища, мотиваційні фактори і способи виміру успіху.
І знову, як і у випадку фізичних факторів, непогано установити розподіл відповідей працівників, майстрів і керівників на питання, зв'язані з перерахованими вище факторами.
Опис задач
Наступним видом критичної інформації, яку необхідно одержати в ході аналізу, є конкретні знання про роботу, виконуваної чи користувачем групою користувачів. Задачі кінцевих користувачів необхідно належним чином описати, крім того, необхідно установити розподіл частоти їхнього виконання. Наприклад, задачі можна описати і класифікувати за допомогою правила 80/20": близько 20% задач займають приблизно 80% часу і саме в розрахунку на них здійснюється оптимізація системи у відношенні продуктивності роботи кінцевих користувачів і ступеня їхньої задоволеності. Інші схеми класифікації
можна використовувати для оцінки і порівняння задач по важливості.
Крім знання виконуваних користувачами задач необхідно розібратися в процедурах, яким випливають кінцеві користувачі при здійсненні своїх робочих цілей. З процедурами зв'язані протоколи кінцевих користувачів. Протоколи - це соціальні звичаї й угоди, що впливають на спосіб виконання роботи. Програмний ПІ і програмні системи повинні відповідати протоколам так само, як процедурам і задачам.
Задачі відрізняються дискретними крапками початку і закінчення. Утім, задачам властиві й інші особливості, деякі з них перераховані нижче.
" Відносно коротка тривалість ( чисекунди хвилини) - у той час як інші досить довгострокові ( чимісяці роки).
" Істотна структурованість- у той час як інші взагалі носять незапланований характер.
" Детерминированный і лінійний характер- тоді як результати інших непередбачені.
" Виконуються однією людиною - у той час як інші задачі виконуються кількома людьми.
" Постійний характер - тоді як інші відрізняються сезонністю.
Перелік відмінностей задач між собою досить великий, однак незалежно від ситуації знання задачі є істотним. Нижче приведені приклади інших факторів, якими характеризуються задачі.
" Мети, частота, важливість, обмеження і витрати.
" Критерії початку і завершення.
" Підготовка, робоча підтримка і засоби.
" Залежність від знань і навичок користувача.
" Вхідні і вихідні дані, а також джерела інформації.
" Ступінь ризику і результуюче вплив на користувачів, клієнтів і організацію.
" Ступінь схильності помилкам і результуюче вплив на користувачів, клієнтів і організацію.
" Порядок виконання кроків (етапів) роботи.
" Взаємодія з іншими чи людьми якими-небудь успадкованими системами.
" Ступінь задоволеності.
Здійснення повного аналізу користувальницьких задач вимагає значних і дорогих зусиль, до яких більшість організацій не готові. Однак для конструювання належних засобів для виконання задач, що задовольняють відповідним вимогам, необхідне нагромадження деякої критичної маси знань про ці задачі.
Корисне правило. Вартість виконання аналізу користувачів продукту, їхнього фізичного середовища, соціального середовища і задач порівняно невелика стосовно загальної вартості всіх задач, виконуваних протягом усього часу роботи.
Методи
Існує ряд корисних методів збору інформації про користувачів, робітниче середовище і задачі. Ці методи необов'язково складні чи дорогостоящи, тому використовувати їх - значить випливати здоровому глузду, однак у сьогоднішній індустрії програмних засобів застосування подібних методів не завжди очевидно. Проте старанне застосування описуваних методів дає можливість одержати необхідну інформацію.
Використання даних методів дозволяє чи підтвердити скорегувати відому інформацію, отриману на інтуїтивному рівні, а також знайти потенційні можливості для удосконалення бізнес - чи процесу розширення програмних функцій. Чи керівники користувачі чи забувають не почувають цих можливостей, чому є ряд причин. От деякі приклади подібного роду.
" При виконанні визначених робіт користувачі можуть вести нефор-мальные чи записи журнал для відстеження чи роботи взаємодії з клієнтами, і цей факт може не знайти документального відображення в жодному з бізнес - процесів. Неформальна задача користувачів може полягати в підрахунку щоденних чи контактів у звертанні до своїх записів про попередні контакти з клієнтами.
" Користувач може часто звертатися до чи записів журналу і згодом поповнювати їхньою додатковою інформацією.
" Програмна підтримка роботи може підвищити ефективність цього не-формального аспекту задачі, що ніде не зафіксований документально.
Корисне правило. Основна мета аналізу полягає в тім, щоб подивитися, що відбувається в робітничому середовищі, і визначити, у чому може полягати реальна допомога з боку програмної системи.
Методи залучення користувачів у проект. Попросите членів проектної бригади і користувачів, що беруть участь у проекті, виконати самооцінку навичок, знань і досвіду. Ефективний метод- використання запитальника, що ранжирует відповіді на ключові питання.
Додатковий метод полягає в тому, щоб члени бригади розроблювачів і користувачі, що беруть участь у проекті, "відгадали", які ймовірні відповіді можна екати від усієї безлічі користувачів. Реальні відповіді, отримані з використанням інших методів, допомагають сформувати представлення про дійсні навички, знання і роботу, виконуваної користувачами.
Метод спостереження. Поряд з опитуванням орієнтована на користувачів бригада розроблювачів продукту може скористатися дуже ефективним методом спостереження за декількома реальними користувачами, що виконують реальну роботу, виступаючи при цьому в різних ролях. Спостереження доповнює зведення про користувачів, середовище і задачі, отриманих на основі запитальників. Для багатьох середовищ метод непомітного спостереження за роботою користувачів дуже корисний і практичний. Запитальники також зручні для ранжирування самооцінок користувачів разом зі спостереженням за цими користувачами.
Корисне правило. Спостереження за реальними користувачами, що виконують реальну роботу, варто проводити із самого початку проекту.
На практиці в розроблювачів продукту формується свій власний погляд на користувачів, вони не дивляться на користувачів з погляду бригади. Для того щоб зафіксувати істотні моменти реальної взаємодії користувача із системою при виконанні конкретних задач, а також загальне робітниче середовище, створюються спеціальні протоколи і форми збору даних. Протоколи збору даних описують образ дій спостерігача при упорядкованій і послідовній взаємодії з користувачами, а також інформацію, що передбачається збирати. Форми збору інформації використовуються для одержання даних упорядкованим і послідовним образом.
Крім іншого в процесі спостереження реєструється наступна інформація.
" Найменування, опис і тривалість задачі.
" Сприйманий рівень навичок і роль користувача.
" Фактичні кроки роботи користувача, включаючи застосування систем, принтерів, факсимільних апаратів і копіювальних пристроїв.
" Функції системи, екрани і додаткова використовувана підтримка роботи.
" Інформаційні потреби.
" Труднощі з існуючими процесами і системою, можливі помилки.
" Продуктивність і надійність існуючої системи.
" Існуючий рівень задоволеності.
" Додаткові питання. '
" Відповіді на питання, що задаються для кращого розуміння частоти, з яким виконуються ті чи інші задачі, що відчуваються труднощів, а також ужитих заходів і їхнього обґрунтування.
" Приклади вхідних наборів даних, копії екранів, а також проміжні кінцеві продукти, одержувані при виконанні роботи.
Задачі, що піддаються спостереженню, служать як проектні чи орієнтири тестових прецедентів (test case) і дозволяють перевірити вірогідність первинних припущень у відношенні потреб користувачів. По можливості задачі відтворюються в процесі вироблення проектних рішень, а також у тестовому середовищі, щоб упевнитися в реальності поліпшень, рішенні проблем і задоволенні вимог.
Метод опитування. Ретельно продумані й об'єктивні запитальники - відмінний засіб для збору істотної інформації від великої кількості користувачів. Поряд з конкретними питаннями, відповіді на який представлені у виді дискретної і ранжированной шкали, звичайно передбачаються і питання, що допускають необмежене число відповідей, щоб з'ясувати користувальницькі припущення у відношенні потенційного удосконалення ПО, систем і процедур. На подібний запитальник можна відповісти протягом 15 хвилин, він може поширюватися у твердій чи копії в електронному виді.
Нижче приводяться загальні вказівки для вибору і структурування запитальника.
" Задавайте тільки ті питання, відповіді на який невідомі і дійсно необхідні.
" Не задавайте навідних і тенденційних питань.
" Задавайте питання в ясній, простому і легені для читання стилі.
" Формулюйте питання таким чином, щоб вони допускали відповіді в числовому виді.
Якщо поширення запитальника серед усього колективу користувачів чи нереально занадто дорого, застосовується статистична вибірка користувачів, що повинна бути достатньої для того, щоб охопити всі значимі групи користувачів.
Корисне правило. Поряд з реальними користувачами опитаєте інших учасників проекту, що виконують комплекс чи задач входять у робітниче середовище ( чикерівників реальних клієнтів).
Запитальники варто проаналізувати, побудувати на їхній основі статистичні розподіли для факторів, а звіти з інтерпретацією результатів опитування направити орієнтованої на користувачів бригаді розроблювачів продукту й інших зацікавлених осіб.
Метод індивідуальних інтерв'ю. Ще один корисний метод збору інформації про користувачів, середовища і задачі- неформальні інтерв'ю з реальними користувачами. Іноді реальна робота користувача супроводжується його розповіддю про те, що саме робиться і чому. В іншому випадку користувач може спочатку виконати роботу, а потім пояснити її. Іноді інтерв'ю під час виконання реальної роботи неможливо. Альтернативний підхід полягає в тім, щоб зареєструвати взаємодія з клієнтом, а потім продовжити інтерв'ю з користувачем. Аналогічно підходу на основі опитування складаються протокол і форма по зборі даних для послідовного й упорядкованого одержання інформації.
Метод групового інтерв'ю. Інший корисний метод збору інформації про користувачів, середовища і задачі полягає у формальних чи неформальних інтерв'ю з чи бригадою групою реальних користувачів. У більшості випадків під час групового інтерв'ю реальна робота не поводиться, однак їсти можливість виявити розходження в методах керування, бізнес - правилах, обмеженнях, а також в інших підходах до роботи, орієнтованих на той чи інший чи стиль зв'язаних з визначеними перевагами. Природно, орієнтована на користувачів бригада розроблювачів повинна враховувати ці розходження в продукті.
Інші джерела інформації. Поряд із залученням користувачів до участі в проекті відповіді на багато ключових питань можна одержати в підрозділах по керуванню людськими чи ресурсами навчанню персоналу, що входять до складу багатьох великих організацій. Деякі питання, наприклад, що стосуються чи віку підлоги, можуть сприйматися як недоречні в чуттєвих до них середовищах.
Корисне правило. Ніщо не може замінити першоджерело!
Непогане джерело одержання порівняльної інформації- галузеві видання, звіти, дослідження і т.д. Однак необхідно відзначити, що інші джерела тільки доповнюють інформацію, що збирається безпосередньо від користувачів.
Аналіз і результати. Усі члени орієнтованої на користувачів бригади розроблювачів продукту беруть участь у зборі даних індивідуально. Спільно
бригада працює в ході обміну отриманими результатами і їхнім аналізом. Окремі запитальники і форми реєстрації спостережень збираються і результати узагальнюються на нарадах бригади. При цьому мета полягає в тім, щоб зрозуміти користувачів, їхні середовища і задачі.
Результати підсумкового аналізу включають наступні основні компоненти по-ставки продукту.
" Розподіл навичок користувачів.
" Ясно виражений опис соціального і фізичного середовища.
" Описи і статистичні розподіли, що стосуються задач.
Задачі, кроки роботи і робітники продукти представляються в термінології кінцевих користувачів і бізнесів-процесів незалежно від існуючих систем. Прикладом звичайної і часто виконуваної задачі може бути щомісячний звіт про стан справ. Подібна задача припускає збір даних, спілкування з колегами, перегляд списку справ, написання чернетки, печатка і редагування чернетки і, нарешті, поширення й архивирование звіту. При цьому важливо знать, як задача зв'язана з існуючою системою, оскільки багато методів роботи повинні бути перенесені в нову систему. Істотні задачі користувачів варто описувати чітко. Потенційні взаємодії з майбутньою системою знаходять висвітлення у виді прецедентів (use case), що після завершення аналізу користувачів, задач і середовищ обновляються.
Корисне правило. Проведіть спостереження й інтерв'ю з реально працюючими мі користувачами існуючих систем і проробіть разом з ними основні
потоки задач і процеси.
Приклади питань
Необхідно одержати великий обсяг інформації, однак може знадобитися зібрати й уточнити її поетапно, по ходу виконання проекту. При створенні чи запитальника спробах зрозуміти, що собою представляють користувачі, середовища і задачі, неважко сформулювати понад 50 різні питання. Існує більш 100 питань до користувачів, на які варто одержати відповідь. Приклади питань, що стосуються користувачів, їхнього робітничого середовища і роботи, приводяться нижче.
Питання про користувачів.
Як би ви оцінили ваш досвід роботи з комп'ютером?
Нижче приведені три питання, що стосуються використовуваних систем, частоти їхнього застосування і відносини до них користувача.
Які комп'ютери ви використовуєте і наскільки часто? Щодня__Щодня__Щотижня__Рідко__Ніколи__
Настільна система___ Портативний____ Ручний___ Інші____
Яку операційну систему ви використовуєте? Як часто? Щогодини__Щодня__Щотижня__Рідко__Ніколи__
X____ Y_____ Z____
Наскільки ви задоволені вашою існуючою системою?
Нижче приведені три питання у відношенні робітничого середовища.
Дуже гучна Нейтральна Тиха
1 2 3 4 5 6 7
Як би ви могли описати ваше робітниче середовище?
Питання, що торкаються роботу.
Нижче приведені три питання про роботу, які можна задати користувачам.
Як часто зустрічається ця задача? Щогодини___ Щодня___ Щотижня___
Рідко___Ніколи___
Наскільки важка ця задача?
Дуже важка Нейтральна Дуже легка
1 2 3 4 5 6 7
Наскільки ви задоволені тим, як виконується ця задача?
Дуже Невизначене Дуже
незадоволений відношення вдоволене
1 2 3 4 5 6 7
Питання, що допускають різні тлумачення.
Які зміни в комп'ютерних системах могли б зробити вашу роботу більш; легкої чи більш ефективної?
Які зміни в бізнесах-процесах полегшили б вашу чи роботу зробили б її більш ефективної?
Оформлення і поширення результатів аналізу
Вчасно завершення збору первинних даних накопичується великий обсяг інформації для аналізу. Форми по зборі первинних даних, а також форми і мітка^-за-мітки, отримані в результаті інтерв'ю, архивируются разом з підсумковою документацією. Підсумки доводяться до зведення усіх відповідних облич і бригад. При цьому непогано забезпечити зворотний зв'язок з організаціями, що беруть участь у спостереженні й інтерв'ю.
Корисне правило. Аналіз варто продовжувати безупинно, постійно уточнюючи його висновки і результати.
Аналітична робоча книга повинна містити розділи для опису середовищ, робочих процесів і потоків, користувачів і окремих задач. У підсумкову частину включаються специфічні сценарії, а також викладу подій, що мають особливий інтерес.
Результати використовуються для перевірки вірогідності прецедентів і інших документів, розроблених під час збору вимог. У документацію по вимогах включаються потреби в нових функціональних можливостях чи системи удосконаленнях, що не були розкриті під час збору вимог.
Продовження обговорення проекту:
користувачі, задачі і середовища
Лідер проекту ввійшов у ваш офіс і повідомив, що наради по стані проекту по - колишньому проходять успішно і вище керівництво продовжує усе більше вникати в методи орієнтованого на користувача проектування. У результаті в міру нарощування вимог до продукту інтерес до нього ростуть і слухи про довідкову систему по конференціях досягли інших потенційних замовників. Коло користувачів продукту помітно розширився.
Виявили цікавість до продукту й інші конференції, при цьому не усі відвідувачі були користувачами апаратного і програмного забезпечення комп'ютерів, як передбачалося спочатку. Наприклад, у число нових основних конференцій і заходів, що вимагають підтримки календарного планування для нарад, увійшли такі об'єднання, як Ярмарок Техаса (State Faіr of Texas), Асоціація американських робітників-електриків (Electrіcal Workers of Amerіca), Американська медична асоціація (Amerіcan Medіcal Assocіatіon), Асоціація вивчення людських факторів (Human Factors Assocіatіon) і Американська асоціація пенсіонерів (Amerіcan Assocіatіon of Retіred People - AARP). Надійшов навіть запит від основного Європейського авіаційного шоу, що проводилося в країні, де не переглядалися основні стандарти ПІ. Помітимо, що деякі з цих нових заходів уключали великий обсяг зовнішньої діяльності.
Вище керівництво зажадало провести презентацію для розвитку представлень про користувачів, середовища і задачі, що повинний підтримувати продукт. Спершу передбачалося, що ті самі базові задачі застосовні у випадку різних конференцій і потенційних користувачів, однак вищі керівники вирішили перевірити, наскільки цю думку обґрунтовано у відношенні задач і продукту стосовно до заданих груп користувачів. Крім того, вище керівництво зажадало провести інформаційна нарада з однієї з груп користувачів (з тими, хто виробляє календарний план заходів і здійснює адміністрування системи).
Лідер проекту сказав, що у вас тепер небагато більше часу - наступне нарада з вищим керівництвом повинне відбутися післязавтра. Однак через інші обов'язки у вашому розпорядженні є біля двох годин для опису наступних аспектів проблеми.
o Ймовірні групи користувачів.
o Задачі.
o Середовища.
o Висновки для продукту.
Крім того, лідер проекту визнав, що у вас небагато часу для роботи над одержанням інформації з користувачів і задач. Він висловив побажання, щоб на презентації перед вищим керівництвом було розглянуте питання про способи одержання, перевірки й аналізу більш деталізованої інформації. Варто також обговорити питання про те, яким образом разом з реальними користувачами ви мають намір перевіряти інформацію в середовищі виконання задач. Щоб представити всю цю інформацію, у вас близько 15 хвилин.
Проведіть пошук інформації в Іnternet, щоб зорієнтуватися в питаннях: аналізу й оцінки користувачів, задач і робітничих середовищ.
Питання?
Посилання
Beyer H., Holtzblatt К. Contextual Desіgn, Morgan-Rauffman: San Francіsco, 1998.
Mayhew D. Software User Іnterface Desіgn, Prentіce-Hall: Englewood Clіffs, NJ, 1992.
Nіelsen J. The Usabіlіty Engіneerіng Lіfe Cycle, Computer Magazіne, Mar. 1992.