Вступ
Розробка програмного забезпечення (ПЗ) — найгнучкіша галузь виробництва, яка будь-коли існувала в історії. Програми не обмежені у сфері застосування та можуть втілювати у життя будь-які логічні інструменти. Господарі продуктів задоволені – продажі йдуть відмінно, і здається, що немає сенсу міняти щось. Парадокс, але сьогодні ця сфера має цілу армію роздратованих клієнтів. Часто на ринку з’являється «сирий» продукт нового гравця та забирає частку у гігантів. Як це відбувається?
Керівники компаній впевнені, що вся справа у випадкових флуктуаціях ринку або в тому, що вони напихали свій продукт недостатньою кількістю функцій. Насправді ж Силіконова долина опинилася в пастці старих уявлень, придатних для часу, коли комп’ютери займали цілі будівлі.
Програмісти впевнені, що їхні клієнти просто безграмотні і не мають базових навичок поводження з комп’ютерами, а менеджери впевнені, що роблять все можливе, щоб зробити продукт зручним. І ті, й інші не мають рації, насправді індустрії не вистачає лише одного — грамотного проектування, яке робитиметься професіоналами. Професійне проектування починається з клієнта – розуміння істинно цінних для нього речей та їх реалізації у максимально зручній формі.
Ні програмісти, ні керівники, ні маркетологи не розуміють суті проблеми, і це може бути фатально для будь-якої компанії, яка розробляє програмне забезпечення. Покупці не замислюючись змінюють незручний продукт на зручний, навіть якщо другий має меншу кількість функцій. Індустрії настав час повернутися до своїх споживачів особою.
Ось про що книга Алана Купера, адресована не лише програмістам-бізнесменам, а й кожному, хто задумав новий продукт чи проект.
1. Проблема із програмами
Комп’ютери настільки складні і нелогічні з точки зору нормальної людини, що спілкування з ними часто призводить до інцидентів на кшталт втрати важливих документів або неправильних грошових транзакцій. Люди часто відчувають роздратування та гнів при використанні комп’ютерів або інших пристроїв, які оснащені програмним забезпеченням (ПЗ). Однак проблема поганого ПЗ небезпечніша і серйозніша, ніж може здатися на перший погляд. Погані програми не тільки невигідні для бізнесу, але й здатні завдавати шкоди.
Авіакатастрофи, в яких головною причиною падіння називають «людський фактор», найчастіше є результатом надзвичайно складних і погано продуманих інтерфейсів бортової електроніки — мало придатні для використання людиною.
Це часто відбувається з технікою, коли вона схрещується з комп’ютером. Годинники, фотокамери, телефони, автомобілі, банкомати, вбираючи переваги цифрових продуктів, перетворюються на комп’ютери і стають занадто складними у використанні.
В усіх випадках прийнято покладати провину на користувача. Широко поширене словосполучення «комп’ютерна грамотність», і кожен роботодавець вимагає від кандидата працювати «впевненої роботи з ПК». Замість фахівця в предметній галузі компанії тепер шукають спеціалістів по роботі з Microsoft Office, і це нікого не дивує.
Проте джерелом проблем є не природна складність програм і інструменти розробки, а загальноприйнятий, традиційний процес, коли проектування взаємодії програми з користувачем віддається на відкуп програмістам. Це виглядає логічним на перший погляд, але насправді виявляється докорінно невірним. Коли основою інженери — домінує інженерний погляд, а чи не погляд кінцевого користувача.
Цифрові продукти мають свою специфіку через те, що немає фізичного втілення. Коли людина бачить молоток чи музичний інструмент, вона може швидко зрозуміти, як вони працюють — ці речі мають низький когнітивний опір. Програмні продукти, навпаки, приховані, невловимі. Понад те, віртуальні елементи управління можуть змінювати свою поведінку залежно від контексту. Через це зрозуміти, як вони працюють, буває вкрай складно навіть для досвідченого користувача. Ця особливість програмних продуктів викликає те, що називається когнітивним опором.
Когнітивний опір властиво програмам, але не є їхньою невід’ємною властивістю. Навпаки, його можна значно знизити, якщо процесу написання коду передуватиме проектування взаємодії. Але натомість більшість компаній продовжує постачати програми новими функціями, не переймаючись легкістю їх використання. Керівники думають, що покращують продукт, роблячи його «потужнішим», але вони лише підвищують його когнітивний опір, внаслідок чого додатковими функціями люди просто не користуються.
Когнітивний опір ПЗ поділяє людей на тих, хто мириться з їхньою складністю в обмін на можливості, які вони дають, і тих, кому труднощі використання приносять задоволення. Такі люди схильні виправдовувати складність програм і вважають за потрібне спрощувати взаємодію Космосу з ними. Можна умовно назвати ці дві категорії людей «уцілілими» та «апологетами».
Переважна більшість зайнятих у промисловості розробки ПЗ є «апологетами». Саме тому індустрія виявляє сліпоту щодо своїх продуктів. Розробники впевнені, що їхні програми зручні, тому що когнітивний опір для них не є проблемою.
2. Психлікарня в руках пацієнтів
У промисловості розробки програм вигляд та поведінка товарів визначають програмісти. Програмісти пишуть код (інструкції) для комп’ютера, а не користувача, а потреби комп’ютера і користувача суперечливі.
Перед початком написання коду програмісти становлять опис продукту, але він створюється термінах програмістів і у інтересах процесу розробки. Такий опис не можна назвати проектуванням взаємодії – він не бере до уваги інтереси користувача і не повинен цього робити.
Керівники компаній продовжують плутати проектування архітектури програми та проектування користувача. Не можна сказати, що програмісти винні у незручності програм: їм просто доручають роботу, яку вони об’єктивно не можуть і не повинні виконувати.
Програмісти щиро намагаються робити свої програми зрозумілими, але мають дуже своєрідне уявлення про зрозумілість і простоту. Програмісти настільки схильні до професійної деформації, що помітно відрізняються від інших людей.
Для програмістів характерна своя психологія.
1. Програмісти охоче жертвують простотою заради контролю. Їм зручніше поводитися зі складними системами, якщо це дозволяє їм краще контролювати їхню роботу.
2. Програмісти радо змінюють успіх розуміння. Звичайно, поняття успіху і невдачі їм не чужі, але можливість розібратися в механізмі, влаштуванні чогось і отримати нові знання для них дорожче за успіх.
3. Програмісти завжди зосереджені на виняткових ситуаціях. Це зумовлено тим, що якщо програма не передбачатиме виняткових ситуацій, це призведе до збою. Тому для програмістів ситуація, яка може статися в одному випадку з мільйона, не менш важлива, ніж ситуація, що виникає постійно.
4. Програмісти грубі та прямолінійні. Їхня інтелектуальна перевага — це предмет гордості.
Хоча цього не видно, робота програміста дуже емоційно насичена і породжує безліч стійких культурних феноменів, зрозумілих лише програмістам. Характерні риси культури програмістів:
1. Для програмістів величезну цінність є код, написаний таким чином, щоб його можна було легко використовувати в іншій програмі. Важливо не тільки те, що в наступному проекті треба буде менше писати, а й те, що таким «модульним» кодом можна ділитися з іншими розробниками. Це благотворно впливає на роботу програмістів загалом, але часом нарощує програму рудиментарним кодом або незапланованими функціями, які, за логікою, програміста «все одно безкоштовні». Це одна з причин інертності програм — у нових програмах легко з’являються погані патерни поведінки з минулих програм, тому що просто використовується старий код.
2. Програмісти схиляються перед технічними вміннями, авторитетною людиною для них може бути лише більш кваліфікований та талановитий інженер. Ця особливість впливає на сприйняття програмістами дизайнерів та бізнесменів — для них це некомпетентні дурні, їх можна слухати, але робити все одно треба по-своєму, адже вони все одно не розуміють усіх тонкощів написання програм. Така ж доля чекає на проектувальників.
3. Програмісти працюють на самоті та відчувають особисту відповідальність за свою роботу. Програміст завжди віч-на-віч з кодом — навряд чи хтось буде досконально вивчати результат його роботи на чистоту та якість. Водночас він скептично ставиться до порад інших фахівців, бо розуміє, що їх не буде поруч, коли щось піде не так, а відповідатиме він. Така ситуація лише посилює їхнє почуття контролю над продуктом.
Культура та особливості психології програмістів природно створюють навколо них сильний бар’єр, що відокремлює їх від кінцевих користувачів результатів їхньої роботи. Це призводить до того, що часто головний програміст якогось продукту зовсім не представляє свого користувача, його потреб та поведінки.
3. У чому вигода проектування
Неправильний процес розробки – ідеальний спосіб витратити купу грошей марно.
На ринку існує міф про терміновий випуск товару ринку. Нібито що раніше програма буде готова, то краще. Розробку ПЗ прийнято здійснювати з фіксованим терміном здачі. Фактично команда розробників стрімголов кидається в невідомість і весь час працює в атмосфері палаючих термінів. За такого підходу ніхто неспроможна визначити поточний статус готовності проекту, й у результаті ринку виходить сирий необдуманий продукт.
Такий підхід частково зумовлений старими звичками бізнесу, які підходять для продуктів індустріальної епохи. Ці правила не підходять для цифрових продуктів, тому що їм притаманний високий когнітивний опір. Очевидно, цифрові продукти разюче відрізняються від матеріальних.
Змінні витрати з їхньої виробництво або відсутні, або критично малі. Тому потенціал поліпшення програм лежить лише збільшення прибутку, а чи не у зниженні витрат. Немає сенсу економити на виробництві, тому що одного разу створена програма може бути продана незліченну кількість разів. Виходить, що найдешевше коштує програма, яку використовують більше людей, а не та, при розробці якої вдалося заощадити.
Тому в розробці програмних продуктів максимально вигідно вкладатися в якість, покращення продукту. Поліпшити продукт можливо, тільки заздалегідь ретельно продумавши його і спланувавши розробку.
Кожен долар, вкладений у розробку програмного забезпечення на етапі проектування, обернеться величезною економією на етапі програмування. Крах доткомів багато в чому пояснюється тим, що в прагненні за звичкою скоротити витрати творці онлайн-магазинів не подбали про якість своїх сайтів, через що проста поїздка в магазин виглядала набагато привабливішою для клієнта, ніж боротьба з поганим інтерфейсом.
Насправді, якщо програмою зручно користуватися і вона представляє певну цінність для користувачів, то не так важливо, коли вона вийде через рік або через два. У той час, як погано спроектована взаємодія (і, як наслідок, високий когнітивний опір) може призвести до провалу.
Яскрава ілюстрація цього правила – кишенькові комп’ютери. Перші кишенькові комп’ютери Penpoint з’явилися на ринку ще 1990 року, проте не мали успіху. Потім Apple Newton в 1992 і Magic Link в 1994 спіткала та ж доля. А в 1996 році вийшов перший PalmPilot і став хітом продажів, першим успіхом на новому ринку. Аналітики та експерти оголосили про відродження ринку кишенькових комп’ютерів, і ніхто з них не здогадався, що успіх пристрою забезпечено тривалим проектуванням нового пристрою. Порівняно з першим КПК, він запізнився на 6 років.
Через необдуманий підхід до розробки програм навіть стало популярним правило Паркінсона. Воно звучить лякаюче, але з проекту до проекту підтверджується практично. Правило говорить: «90% коду програми забирають 90% часу її розробку, інші 10% коду програми забирають ще 90% часу». Тобто, коли програмісти написали 90% коду, частина роботи, що залишилася, займає стільки ж часу. Навчені менеджери вже звикли, що час розробки треба множити в розумі на два, а то і на чотири .
На противагу зваженому проектуванню, керівникам здається, що гонитва за максимальною кількістю функцій забезпечить успіх продукту. Їх кількість функцій — це спосіб вимірювати цінність товару. Однак той же PalmPilot мав набагато менше функцій, ніж його попередники, що провалилися на ринку. Насправді функції варто сприймати лише як «потенційно корисні», і якщо вони будуть добре спроектовані, вони можуть виявитися дійсно корисними.
Відсутність проектування взаємодії користувача тільки призводить до прихованих витрат. Коли продукт готовий, стає неможливо оцінити, скільки людей не користуються ним через його складність. Розробка поганого ПЗ насправді обходиться значно дорожче, ніж грамотне проектування, якщо брати до уваги упущену вигоду. Хоча на перший погляд може здатися навпаки.
Таким чином, якщо при розробці ПЗ головними орієнтирами в роботі є термін здачі та набір його функцій, навіть своєчасне завершення роботи не зробить продукт успішним і бажаним на ринку. І навпаки, якщо визначати продукт у термінах його якості та реальної корисності для споживачів, то успіх продукту набагато вірогідніший . При цьому розробка дійсно зручної програми та розробка незручної програми мало чим відрізняються з погляду складності інженерних завдань — в обох випадках програмістам доведеться виконати приблизно ту саму роботу, і витрати на розробку не зростуть. Навпаки, ретельно спроектована програма обійдеться дешевше і принесе значно більше грошей.
В силу описаних факторів більшість сучасних програм має такі очевидні недоліки:
1. Програми нічого не пам’ятають про вас — не пам’ятають, де ви зберігаєте свої файли, не пам’ятають, які інструменти ви використовуєте частіше за інших.
2. Програми намагаються догодити користувачеві так, начебто користувач програміст.
3. Програми скупі на інформацію. Часто вони показують користувачеві дані, які насправді нічого не говорять йому, але при цьому приховують справді важливу інформацію.
4. Програми не гнучкі. Вони здатні відтворювати лише чіткі інструкції та не дозволяють користувачам швидко вирішити проблему у нестандартній ситуації.
5. У разі проблем програма повністю покладає провину користувача. Якщо щось пішло не так, програма не візьметься усувати проблему самостійно.
6. Програми напхані діалогами підтверджень, що повністю знімають з комп’ютера відповідальність за неправильні рішення користувача.
Ці очевидні недоліки всіх сучасних програм вважаються нормою, хоча можуть бути легко виправлені правильним підходом розробки продуктів.
Ларрі Кілі з Dolphin Group запропонував модель взаємодії трьох найважливіших факторів у технологічному бізнесі.
За перший чинник відповідають інженери. Він відповідає на запитання «Що можливо створити, які технічні можливості та обмеження комп’ютерів?».
Другий чинник відповідає питанням «Що буде життєздатно над ринком, яке пропозицію здатне забезпечити життя і зростання компанії?». За цей чинник відповідають керівники, бізнесмени. Для програмістів цей аспект розробки перестав бути найважливішим, їм вирішення цікавих завдань важливіше успіху продукту над ринком. Для бізнесменів, навпаки, технічна складність продукту або краса його архітектурного рішення не важлива.
Така суперечність створює тертя у взаєминах цих двох сил, і для успішного симбіозу розробників та бізнесменів працює третя сила — проектувальники, вони відповідають за третю властивість програм — їхню привабливість — і відповідають на запитання «Що приверне людей, що задовольнить їх?».
Проектування створює продукт, який:
а) може бути створений та може добре працювати;
б) може успішно продаватися;
в) який буде справді цінний і корисний.
Проектувальники перевіряють та опрацьовують початкове припущення, визначають дійсні, нагальні потреби клієнтів, визначаючи напрямок та орієнтири для програмістів та бізнесу. Підхід, коли бізнес визначає потреби користувачів і ставить завдання програмістам, не працює, тому що потреба і привабливість — це різні поняття. Споживач може потребувати можливості вирішити свою проблему, але якщо спосіб вирішення його проблеми буде змушувати його почуватися безглуздо, якщо рішення нестиме з собою безліч нових проблем і складнощів, то таке рішення не буде привабливим.
Завдання проектування – розробити привабливий продукт.
Модель Кілі показує, як досягти відданості клієнтів. Лояльність клієнтів, яку приносить хороше проектування продуктів, дозволяє корпорації Apple переносити сильні потрясіння та серйозні помилки управління та економити в інших аспектах виробництва — віддані клієнти готові довго терпіти та багато прощати.
4. Про методи проектування
Для того щоб зробити програми більш людяними, існує низка методик, які використовуються проектувальниками. Головна з них – «персонажі».
Перед початком розробки проектувальники проводять дослідження для виявлення портрета майбутнього користувача. Здається, що правильно було б знайти реального користувача та проектувати для нього. Але такий підхід поганий — не можна знайти середнього користувача, кожна людина має свої індивідуальні особливості, і неможливо підлаштувати програму під всі особливості кожної людини. Натомість набагато ефективніше вигадати користувача із усередненими властивостями. Це не реальна людина, але гіпотетичний архетип. Цей вигаданий користувач і буде персонажем, для якого відбувається проектування.
Процес підбору та опису персонажа окреслює коло майбутніх користувачів, людей, для яких ця програма має бути привабливою. Логіка підказує, що краще вигадати кілька персонажів, проте насправді це призводить до створення продуктів, якими не користуватиметься ніхто. Не можна зробити програму зручною і для офісного працівника, і для літньої домогосподарки – це дуже різні люди. Досвід показує, що насправді буває зворотний процес. Продукт, спроектований одного персонажа, несподівано стає популярним іншим людям.
Так, валізу з коліщатками спочатку придумали для членів екіпажів літаків, але після її створення пасажири літаків швидко оцінили його переваги.
Для ефективного проектування персонаж має бути гранично конкретним, слід описувати його до дрібниць, наче це реальна людина. Чим більше деталей, тим краще. У нього має бути ім’я, ви повинні знати, де він працює, скільки у нього дітей, якою машиною він їде на роботу і так далі. Опис має бути ідеальним, але неодмінно має бути докладним. Подробиці допомагають дійсно зрозуміти, що для персонажа є «зручним».
Переваги введення персонажа:
1. Він дає уявлення реальному рівні підготовленості («комп’ютерної грамотності») споживачів.
2. Персонажі закривають суперечки про функції. У діалозі з програмістом на його запитання «Чому б нам не додати функцію виведення на друк?» проектувальник може відповісти, що персонажу не потрібна друк, і описати причини, через які він так вважає, звертаючись до фактів, що стосуються персонажа.
3. Персонажі дають усім учасникам процесу розробки єдину систему відліку, точку опори. Це дає уявлення про стадії роботи та готовність продукту – продукт можна вважати готовим, тільки коли цілі персонажа задоволені.
Процес проектування має мати чіткі цілі. Проектування без цілей — однаково відсутність проектування. Під метою проектування розуміються цілі персонажа. Цілі (як і персонаж) — це тверда точка опори прийняття рішень під час розробки . Для проектування важливі всі цілі персонажа, як практичні, і особисті.
Процес проектування досягає поставленої мети шляхом вирішення завдань. У той час як цілі незмінні, завдання залежить від технологій, доступних способів вирішення.
Не менш важливо, орієнтуючись на практичні цілі персонажа, пам’ятати, що будь-яка людина в першу чергу не хоче почувати себе дурнем, бути кимось розкритикованою за невміння впоратися з програмою, не хоче відчувати роздратування при використанні продукту — в цьому його особисті цілі. Програмістам властиво ігнорувати особисті цілі користувачів, оскільки не знайомі такі почуття. Типові особисті цілі будь-якої людини при використанні техніки:
• Не почуватись безглуздо.
• Не робити помилок.
• Виконувати адекватний обсяг роботи.
• Розважитись (або хоча б не страждати від нудьги).
Крім особистих і практичних цілей користувача, також існують два інші типи цілей: корпоративні та хибні цілі. Корпоративні цілі ставлять перед професійними програмами, якими користуються співробітники. Типові корпоративні цілі:
• Збільшити прибуток.
• Збільшити ринкову частку.
• Перемогти конкурентів.
• Найняти більше працівників.
• Запропонувати нові продукти та послуги.
Корпоративні цілі не можна ігнорувати, проте їх можна назвати «гігієнічними». Проектування вирішує їх лише побічно, тому що врешті-решт програмами користуватимуться люди, а їх цікавлять практичні та особисті цілі. Можна сказати, що практичні цілі поєднують корпоративні цілі компанії та особисті цілі працівника, який використовуватиме програму.
Хибні цілі – це цілі, поставлені перед проектуванням ПЗ у термінах програмування. На перший погляд такі цілі справді відносяться до кінцевого користувача, проте не варто плутати їх із справжніми цілями проектування, тому що вони сформульовані в термінах архітектури коду та технічних вимог, інакше кажучи, у термінах завдань, а не цілей. Типові приклади хибних цілей:
• Економія пам’яті.
• Поліпшення зовнішнього вигляду.
• Забезпечення цілісності даних.
• Простота в освоєнні.
• Підтримка роботи у всіх браузерах.
• Зменшення потреби в клавіатурі.
Звичайно, при використанні нового пристрою людина неминуче повинна буде докласти якихось зусиль. Щоб зробити цей досвід безболісним, необхідно дотримуватися важливого в проектуванні принципу пропорційності зусиль: людина з радістю докладе зусиль, щоб навчитися користуватися продуктом, якщо бачитиме, що продукт «іде йому назустріч» і «докладає зусиль», щоб допомогти розібратися.
Оскільки люди часто емоційно реагують на «поведінку» програми, аж до ведення словесної розмови з комп’ютером, проектувальникам необхідно робити поведінку програм таким, щоб взаємодія з програмою була схожа на спілкування з приємною (вихованою, чемною) людиною. «Ввічлива» програма відповідає ряду характеристик:
• Цікавиться мною — тим, хто я такий, що мені подобається, запам’ятовує мої попередні переваги.
• Належить до мене шанобливо — пропонує, а не наказує; передбачає, а чи не укладає.
• Ввічлива — вона повинна вибудовувати припущення про мої додаткові потреби, навіть якщо я не спитав про них безпосередньо, якщо це розумно і ймовірно з точки зору людини.
• Поводиться розумно — в інтерфейсі більшості програм затребувані та прості функції розташовані упереміж зі складними налаштуваннями для нечисленних професіоналів.
• Передбачає мої потреби – комп’ютер може легко підготуватися до можливих дій; наприклад, браузер може почати заздалегідь завантажувати сторінки за доступними на поточній сторінці посиланнями, тоді мені не доведеться чекати, коли я натисну на одну з посилань.
• Чуйна – комп’ютер часто може самостійно відреагувати на мої дії і має для цього всі можливості, але не робить цього і змушує мене робити додаткову роботу вручну.
• Не схильна ділитися своїми особистими проблемами — програми часто повідомляють непотрібну мені технічну інформацію: коди помилок, стан пам’яті комп’ютера і так далі.
• В курсі того, що відбувається, програми іноді пропонують скористатися функціями, які виявляються недоступними в даний момент, хоча цього можна було уникнути і не витрачати час користувача.
• Прониклива — наприклад, одні люди вважають за краще використовувати вікна програм розгорнутими на весь екран, інші вважають за краще маленькі вікна, щоб бачити файли на робочому столі; прониклива програма мала б запам’ятати мої уподобання і створювати нові вікна відповідно до них.
• Впевнена в собі — комп’ютеру не слід постійно запитувати у мене підтвердження дій, натомість краще давати можливість скасувати їх, якщо я справді зробив помилку.
• Завжди зосереджена — така програма не ставить зайвих питань, які забирають мене від виконання поточного завдання.
• Покладиста – цифрові системи часто вимогливі до людини, змушуючи вводити точні та повні дані; люди звикли (і це зручно) мати можливість залишити якусь роботу потім або перескочити якийсь крок процесу, залишивши його потім.
• Надає миттєве задоволення — програма не повинна відкладати винагороду користувача на момент, коли він виконає величезну кількість роботи, вона повинна заохочувати людину частіше.
• Їй можна довіряти — ввічлива програма заслуговує на довіру і позбавляє мене від бажання вкотре перевіряти правильність її роботи.
Ще один найважливіший інструмент проектування – сценарії. Сценарії є опис ситуацій і поведінки персонажа в цих ситуаціях . Тут деталізація персонажа грає велику роль – вона допомагає проектувальникам вжитися в роль і створювати реалістичні сценарії. Це схоже на уявну акторську гру в кіно. Сценарії створюються на основі інформації, зібраної в ході початкового дослідження – інтерв’ю та спостереження за майбутніми користувачами. Сценарій повинен описувати процес від початку остаточно. У сценарії не слід включати виняткові ситуації.
Повсякденні сценарії – найкорисніші і найважливіші . Вони описують основні дії, що відбуваються найчастіше. Наприклад, для календаря щоденні сценарії – це додавання нової події та пошук за існуючими подіями. У програм буває не більше 2-3 повсякденних сценаріїв. Ці сценарії потребують найякіснішої взаємодії з користувачем, оскільки робота з ними відбувається найчастіше.
Обов’язкові сценарії – це ситуації використання, які виникають нечасто, але обов’язково мають бути реалізовані у програмі. Кількість обов’язкових сценаріїв зазвичай також невелика, але, як правило, їх трохи більше ніж повсякденних.
Насправді існують виняткові сценарії, і їм чомусь приділяють особливу увагу програмісти. Проте проектувати взаємодію таких сценаріїв можна грубо і ховати їх у глибині інтерфейсу. Програма повинна враховувати виняткові ситуації, але успіх продукту залежить від того, як вона справляється із повсякденними та обов’язковими сценаріями.
Персонажі, цілі та сценарії – це важка артилерія проектування. Ці інструменти використовуються у кожному проекті.
Є ще ряд другорядних інструментів та хитрощів.
• Інтерфейс, що адаптується. У кожний момент часу користувачеві, як правило, потрібні лише деякі функції програми. Хитрість у тому, щоб залежно від контексту приховувати від нього функції, непотрібні на даний момент.
• Під час проектування слід пам’ятати, що переважну більшість користувачів можна вважати «середняками» у поводженні з технікою. Вони рідко бувають новачками чи експертами.
• Корисно уявляти собі ситуації та робити припущення, не думаючи про технічні обмеження. Якщо в процесі проектування спочатку задавати їх, то неможливо буде зосередитися на цілях — ви працюватимете в контексті завдань.
• У процесі проектування всім учасникам проекту слід виробити та конкретизувати свій словник термінів. Поширене явище, коли люди, які працюють над одним продуктом, позначають одними і тими самими словами зовсім різні сутності.
• Якщо в колективі вже склалися якісь внутрішні терміни, слід при роботі з проектування уникати таких слів, а вводити та використовувати нові поняття. Старі поняття можуть нести з собою тягар упередженого розуміння, що народився в іншому контексті або під впливом хибних цілей.
У спробах зробити свої продукти краще компанії часто застосовують у розробці процеси, які, на їхню думку, повинні вдосконалити той чи інший продукт. Багато хто з цих методів справді добре впливають на продукти, але не вирішують проблеми проектування в цілому.
Наприклад, поширена практика юзабіліті-тестування. Готову програму дають у руки реальних користувачів, спостерігають за ними, із спостережень роблять висновки та «доводять» програму відповідно до отриманих даних. Такий підхід не орієнтований на цілі користувачів, а зміни, які вносяться до вже готової програми, навряд чи можуть щось принципово покращити — більшість роботи вже позаду. Тестування вже випущеного продукту допомагає відшліфувати його, але помилки, допущені на самому початку, вже не виправити.
Часто зустрічається практика проектування, коли група проектувальників збирається із представників усіх задіяних у створенні продукту сфер: маркетологів, менеджерів, програмістів, користувачів та тестувальників. Однак такий підхід не вирішує проблему, тому що у всіх учасників «круглого столу» різні інтереси і багато хто з них відрізняється від інтересів користувачів програми. Проектування — це професійна сфера, де мають працювати спеціальні люди.
Ще один шлях покращення програм – використання фокус-груп. У розробці програм — в області з неймовірно високим когнітивним опором — орієнтація на фокус-групи може виявитися не тільки марною, а й призводити до проблем. Учасники фокус-груп у своїх пропозиціях спираються на негативний досвід використання погано спроектованих програм та опиняються у полоні цього досвіду. Вони часто озвучують недалекоглядні та некомпетентні вимоги, а багато хто з них просто бояться пропонувати дійсно цікаві ідеї зі страху здатися дурними.
Належне проектування, виконане на початок програмної розробки, дає керівникам контроль над продуктом. Розробку ПЗ можна порівняти зі створенням фільму — на початку пишеться сценарій і проводиться підготовча робота, і лише коли заздалегідь визначено та описано процес зйомки, починається безпосередньо зйомка. Після зйомок відбувається монтаж та просування на ринку. У розробці можна відповідно виділити стадії проектування, програмування та налагодження. Як у кіно, і у розробці підготовча стадія дозволяє мінімізувати тривалість середньої стадії. В обох випадках перша стадія – це спосіб швидко і дешево уникнути помилок, які на пізніших стадіях можуть коштувати значно дорожче. Проектування допомагає контролювати найнепередбачуваніший процес у розробці — безпосередньо написання коду.
Проектування корисне всім:
• Проектування корисне та вигідне для програмістів, тому що робить їх роботу більш визначеною, знижує рівень стресу. Коли всі від початку орієнтуються на описане і єдине бачення проекту, знижується ймовірність, що доведеться суттєво переписувати код на пізній стадії, а для програмістів це величезний бонус.
• Проектування корисне для маркетингу, оскільки маркетологи можуть орієнтуватися на персонажа, виведеного у процесі проектування. По суті, проектувальник, крім іншого, є сполучною ланкою між маркетингом та програмуванням — він перекладає мову маркетологів мовою програмістів. Також проектування з допомогою роботи з цілями персонажів дає маркетологам розуміння, як слід описати переваги продукту покупцям.
• Проектування допомагає у розробці документації та технічній підтримці. Чим краще проектування — тим простішою буде документація і простішою буде робота технічної підтримки.
• Проектування однозначно корисне керівникам розробки — процес набуває єдину всім учасників площину координат, поєднує термінологію всіх рівнів компанії. Для керівника процес створення програмного продукту та його успіх на ринку стають більш передбачуваними та прогнозованими.
Висновок
Програмні продукти найбільше схильні до когнітивного опору — користувачам важко передбачити їхню поведінку і зрозуміти, як вони влаштовані.
Програми слід робити зручнішими, щоб залучати своїх споживачів.
Для цифрових продуктів підвищення якості значно важливіше, ніж зниження витрат, так як для користувача зручний продукт завжди привабливіше «потужного», але незручного.
Для підвищення якості програм необхідне проектування взаємодії користувача.
При цьому не слід плутати проектування програм та проектування взаємодії. Програмісти пишуть інструкції для комп’ютерів та працюють у контексті, в якому цілі користувачів не враховуються.
Проектування має стати частиною процесу розробки та обов’язково має передувати написання коду.
Проектування корисне всім учасників процесу розробки, оскільки дає єдину систему понять і дозволяє визначити рівень готовності програми.
Програмне забезпечення — найгнуткіший вид продуктів, які колись створювали люди, і йому слід навчитися змінюватись під потреби своїх споживачів.