Изисквания за функционалност и съдържание на уеб сайт

С ясно чувство за това, което искате и за това, което искат вашите потребители, може да измислите как да удовлетворите всички стратегически цели.

След ниво Стратегия за уеб сайт следва ниво Обхват на уеб сайт, където преобразявате нуждите на потребителите и целите на проекта в специфични изисквания - какво съдържание и функционалност ще предложи уеб сайта на потребителите.

Дефиниране на Обхват на уеб сайт

Правим някои неща, защото процесът ни носи стойност, като бягане за здраве или упражнения по актьорско майсторство. Правим други неща, защото продуктът ни носи стойност, като приготвяне на баница или ремонтиране на автомобил.

„Обхватът на даден уеб сайт представлява ценен процес, който води до много полезен уеб сайт.“

Обхватът обединява и двете.

1) Ценен процес

Процесът е ценен, защото той ви принуждава да адресирате потенциални конфликти и затруднения с уеб сайта докато всичко е все още хипотетично. Вие можете да идентифицирате с какво ще успеете да се справите сега и какво ще трябва да почака до по-късен етап.

2) Полезен уеб сайт

Уеб сайтът е полезен, защото дава на целия екип отправна точка за всичката работа, която е добре да се свърши по време на реализацията на проекта и общ език, на който да се говори за този обем работа. Чрез определяне на вашите изисквания пропъждате двусмислието от процеса на проектиране.

Пречки за стартиране на уеб сайт

Съществуват множество обяснения и отговори защо не можете да стартираме даден уеб сайт.

„Една от най-големите пречки е нежеланието за дефиниране на изисквания.“

Резултатът от подобно бездействие е уеб сайт, който е вечно променящ се миш-маш от функционални спецификации в различни етапи на завършеност.

Всяка нова информация, която някой прочете или всяка нова мисъл, която дойде на ум на някого, докато се забавлява с уеб сайта, вдъхновява друга функция за обсъждане. На лице е един постоянен поток от протичаща работа, но липсват график, достигане до значими ключови постижения при разработка и поставен реалистичен край на проекта.

Ако никой не знае обхвата на проекта, как може някой да знае кога всичката работа е свършена?

Има две основни причини, поради които да се погрижите за дефинирането на изискванията.

Причина #1: Знаете какъв уеб сайт изграждате

Това изглежда някак очевидно, но понякога се проявява като изненада за участващите в проекта. Ако вие ясно изразите точно какво се готвите да изградите всеки ще знае какви са целите на уеб сайта и кога те са били достигнати.

Крайният продукт престава да бъде аморфна картина в главата на продуктовия мениджър и става нещо конкретно, с което всеки от бизнес организацията може да работи.

При липса на ясни изисквания, вашият проект вероятно ще наподобява добре познатата игра „Развален телефон“ - всеки участващ в екипа получава впечатление за продукта чрез предаване на информация от уста на уста и описанието на всички завършва малко по-различно.

Или дори по-лошо. Всеки възприема, че някой друг управлява проектирането и развитието на някой ключов аспект за уеб сайта, а в действителност никой не го прави.

„Разполагайки с определен набор от изисквания, вие можете да разпределите по-ефективно работните отговорности. Виждайки съставен план за целия обхват на уеб сайта ви позволява да узнаете връзките между индивидуалните изисквания, които иначе не биха били така очевидни.“

Например при ранни дискусии поддържащата документация и файловете с функционални спецификации на уеб сайта могат да изглеждат като отделни отличителни черти на съдържание.

Но при дефинирането им като изисквания може да стане очевидно, че съществува доста припокриване и че една и съща група от сътрудници трябва да отговаря и за двете.

Причина #2: Знаете какъв уеб сайт не изграждате

Много функционални спецификации звучат като добри идеи, но те не са непременно приведени в съответствие със стратегическите цели на проекта. Освен това всички видове възможности за функции изплуват след като проектът е в ход.

Наличието на ясно определени изисквания ви предоставя рамка за доразвиване на тези идеи, тъй като те идват в течение на проекта и ви помагат да разберете как (или ако) се вписват в това, на което вече сте се посветили да изградите.

„Знаейки какъв уеб сайт не изграждате също означава, че знаете какъв уеб сайт не изграждате точно сега.“

Реалната стойност в събирането на всички тези велики идеи идва от намирането на подходящи начини да ги впишете във вашите дългосрочни планове. Чрез установяване на конкретни групи от изисквания и запас от заявки, които не се вписват като възможности за бъдещи версии, можете да управлявате целия процес по по-съзнателен начин.

Ако съзнателно не управлявате вашите изисквания ще се озовете в страховит „обхват на пълзене“. Това, с което може да бъде сравнен този сценарий е снежна топка, която се върти напред сантиметър по сантиметър и обира малко допълнителен сняг с всеки ход, докато не бъде бутната надолу по хълма, стане по-голяма и по-трудна за спиране по целия път надолу.

По същия начин всяко допълнително изискване може да не изглежда, че коства много допълнителна работа. Но обединете всички заедно и ще имате проект „търкалящ се извън контрол, смачкващ срокове и бюджети“ по пътя си към неизбежна окончателна катастрофа.

Функционалност и съдържание

На ниво Обхват на уеб сайт, започвате от абстрактния въпрос „Защо правите този уеб сайт?“, с който се справихте още на ниво Стратегия за уеб сайт, и го надграждате с нов въпрос: „Какво ще правите?“

Разделението между уеб сайта като средство за функционалност и уеб сайта като информационен източник започва да влиза в употреба на ниво Обхват на уеб сайт.

От гледна точка на функционалност, вие сте загрижени какво ще обхваща набора от функции на софтуерния продукт.

От гледна точка на информация, вие си имате работа със съдържание, традиционната област на редакционните и маркетинговите екипи за комуникация.

При разработка на софтуер, обхватът е определен чрез функционални изисквания или функционални спецификации.

Някои организации използват тези термини, за да означат два различни документа: изисквания в началото на проекта да се опише какво трябва да прави системата и спецификации в края, където да се опише това, което всъщност прави. В други случаи спецификациите са разработени скоро след изискванията, посочвайки детайли за изпълнение.

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

„Функционалните спецификации се използват при споменаване на самия документ, а под функционални изисквания се има предвид съдържанието на този документ.“

Езикът, който се използва в тази публикация, е най-вече езикът на разработка на софтуер. Но концепциите тук се прилагат еднакво и за съдържание.

Разработчик на съдържание ще седне и ще говори с хората или ще обмисли внимателно изходния материал, независимо дали това е база данни или чекмедже пълно с изрезки от новини, за да определи каква информация трябва да бъде включена в уеб сайта, който се разработва.

Процесът за определяне на изисквания за съдържание всъщност се състои в провеждане на среща между технолози и заинтересовани страни, където се осъществява брейнсторминг за набелязване на функции и се преглежда съществуваща документация. Целите и подходите са едни и същи.

Изискванията за съдържание често имат функционални последици. В днешно време уеб сайтове, боравещи предимно с чиста информация, обикновено се управляват чрез система за управление на съдържанието (Content Management System или CMS).

Тези системи идват в различни форми и размери, от много големи и сложни системи, които динамично генерират страници от дузина различни източници на данни до олекотени инструменти, оптимизирани за управление на един специфичен вид съдържание по най-ефективният начин.

Можете да решите да:

• Наемете софтуер за управление на съдържанието (Software as a Service, SaaS).
• Използвате една от многото софтуерни алтернативи с отворен код (Open Source Software, OSS).
• Изградите такъв софтуер от нулата.

Във всеки от гореспоменатите случаи, ще отнеме известно време и усилия да приспособите системата към целите и нуждите на вашата организация, и вашето съдържание.

Функционалността, от която имате нужда във вашата система за управление на съдържанието ще зависи от естеството на съдържанието, което ще управлявате.

• Ще поддържате ли съдържанието на няколко езика или формати на данните? Системата ще трябва да бъде в състояние да се справя с всички тези видове елементи на съдържание.
• Трябва ли всяко съобщение до медиите да бъде одобрено от шест изпълнителни заместник-председатели и адвокат? Системата ще трябва да потвърди този вид процес на одобрение в своя поток на работа.
• Елементите на съдържанието ще се рекомбинират ли динамично според предпочитанията на всеки потребител или хардуерно устройство, което използват? Системата ще трябва да бъде в състояние да постигне това ниво на комплексност.

По същия начин, функционалните изисквания на всеки технологичен продукт имат подразбираща се нужда от съдържание.

• Ще има ли инструкции за настройка на предпочитания при конфигурация на екрана?
• Какво ще кажете за съобщения за грешки?

Някой трябва да ги напише. Всеки път, когато видите съобщение за грешка на един уеб сайт като „Null input field exception“, знайте, че някои несъзнателно се е съгласил това съобщение да се появи в крайния продукт, защото никой не е посочил, че това съобщение за грешка е изискване за съдържание.

Както се твърди безброй технически проекти биха могли да са неизмеримо подобрени, ако разработчиците просто са отделили време да открият някой, който да разгледа приложението с поглед насочен към съдържанието.

Дефиниране на изисквания

Някои изисквания се прилагат спрямо уеб сайта като цяло. Изискванията за търговската марка са един общ пример за това. Определени технически изисквания, като поддържани браузъри и операционни системи, са друг пример.

Някои изисквания се прилагат само за една конкретна функция. През повечето време, когато хората се позовават на изискване, те мислят за кратко описание на дадена функция, която се изисква уеб сайтът да има.

Нивото на детайлност във вашите изисквания често ще зависи от специфичния обхват на проекта. Ако целта на проекта е да приложи една много сложна подсистема, може да се наложи много високо ниво на детайлност, въпреки че обхватът на проекта свързан с по-голям сайт може да бъде доста малък.

Обратното, много мащабен проект включващ голям обем информация може да „влече след себе си“ толкова хомогенна база от съдържание (като голям брой функционално идентични PDF документи на продуктови ръководства), че изискванията за съдържание могат да бъдат само много общи.

„Най-продуктивният източник за изисквания винаги ще са самите потребители.“

Но по-често, вашите изисквания ще дойдат от заинтересованите страни (акционери, изпълнителни директори, шефове и т.н), хората във вашата организация, които имат нещо за казване относно това, което се включва във вашия продукт.

И в двата случая най-добрият начин да разберете какво искат хората е просто да ги попитате. Техниките за проучване на потребители могат да се използват, за да ви помогнат да получите по-добро разбиране за вида на функциите, които потребителите искат да видят във вашия продукт.

Независимо дали сте определили изискванията с помощта на заинтересованите страни във вашата организация или работите директно с потребители, изискванията, които произлизат от процеса ще попаднат в три основни категории.

1. Неща, които хората казват, че искат.

Някои от тях са много ясни, добри идеи и ще намерят своето място във финалния продукт.

2. Неща, които хората казват, че искат, но не са нещата, които действително искат.

Когато хората срещат затруднения с процес или продукт не е необичайно да си представите решение. Понякога това решение е неприложимо или насочено към симптом, а не основната причина за проблема.

Чрез изследване на тези предложения можете понякога да достигнете до напълно различни изисквания, които решават реалния проблем.

3. Функции, които хората не знаят, че искат.

Когато подтикнете хората да говорят за стратегически цели и нови изисквания, които могат да помогнат за изпълнението им, понякога те ще попаднат на по-големи идеи, които не са хрумнали на никого по време на текущата поддръжка на продукта.

Тези функции често се появяват на бял свят след провеждане на упражнения от тип „мозъчна атака“ (brainstorming), когато участниците имат шанс да преговорят и проучат възможностите за проекта.

По ирония на съдбата понякога хората, участващи най-дълбоко в процеса по създаване на уеб сайт и работа с него, са тези, които най-малко могат да си представят нови посоки за неговото развитие. Когато прекарвате цялото си време потопени в поддържане на съществуващ уеб сайт можете често да забравите кои от вашите ограничения са реални и кои произтичат от исторически избори.

Поради тази причина провеждането на групови сесии от тип „мозъчна атака“, които обединяват хора от различни части на организацията или представляват различни потребителски групи могат да бъдат много ефективни инструменти за отваряне на съзнанието на участниците за възможностите, които те няма да са взели предвид преди.

Събирането на инженер, отговорник от отдел „Обслужване на клиенти“ и ръководител на отдел „Маркетинг и реклама“ заедно в една стая, за да говорите за един и същ уеб сайт може да бъде поучително за всеки. Изслушвайки непознати перспективи, и имайки възможността да отговорите на тях, насърчава хората да мислят в по-широк план за проблемите, касаещи разработването на уеб сайта и възможните решения.

Независимо от устройството, за което проектирате, или ако проектирате самото устройство, вашия набор от функции ще трябва да вземе предвид също и хардуерни изисквания.

• Устройството има ли камера?
• Има ли GPS?
• Жироскопични сензори за ориентиране?

Тези съображения ще уведомят и ограничат вашите функционални възможности.

Генерирането на изисквания често е въпрос на намиране на начини за премахване на препятствия. Например да приемем, че имате потребител, който вече е решил да закупи продукт - той просто не е решил дали вашият продукт е този, който ще купи. Какво може да направи вашият сайт, за да направи този процес, първо избирайки вашия продукт и след това закупуване на вашия продукт, по-лесен за тях?

В предишна публикация разгледахме техника за създаване на персони, наречени измислени герои, които да ви помогнат да разберете по-добре нуждите на потребителя.

При определяне на изискванията можете да използвате тези персони отново чрез въвеждане на вашите измислени герои в малки истории, наречени сценарии.

„Сценарият е кратък, опростен разказ описващ как една персона може да опитва да удовлетвори една от тези потребителски нужди.“

Като си представите процеса, през който могат да преминат вашите потребители, можете да се досетите за потенциални изисквания, за да отговорите на техните нужди.

Можете също да потърсите вдъхновение от вашите конкуренти.

Някой друг в същия бизнес е почти сигурно да се опитва да отговори на същите потребителски нужди и вероятно се опитва да постигне подобни цели касаещи уеб сайта.

• Съществува ли конкурент, който е намерил особено ефективна функция, която да отговаря на една от тези стратегически цели?
• Как e подходил към едни и същи разминавания и компромиси, пред които сте изправени?

Дори и продукти, които не са преки конкуренти могат да послужат като плодородни източници за възможни изисквания.

Някои платформи за игри, например, предлагат на потребителите възможност за създаване на социални групи от „колеги“ играчи. Приемането или уповаването на техния подход, когато обхващате подобна функция за вашата видеоигра, може да ви даде предимство пред вашата пряка конкуренция.

Функционални спецификации

Функционалните спецификации притежават нещо като лоша репутация в определени кръгове. Разработчиците често мразят спецификации, защото спецификациите са склонни да бъдат ужасно „смотани“ и времето, прекарано в четенето им е време, отнето от действията по писане на код.

Като резултат, спецификациите остават непрочетени, което от своя страна засилва впечатлението, че съставянето им е загуба на време. Което си е точно така! Лошият подход към спецификациите се превръща в самоизпълняващо се пророчество.

Едно оплакване от функционалните спецификации е, че те не отразяват действителния уеб сайт. Нещата се променят по време на изпълнението. Всеки разбира това. Това е естеството на работа с технология.

Понякога нещо, което сте мислели, че ще работи, не работи. Или по-вероятно не работи точно по начина, по който сте си мислели. Това обаче не е основание да приравните записването на спецификации към графа загубена кауза. Вместо това то подчертава значението на спецификациите, които действително работят.

Когато нещата се променят по време на изпълнението, отговорът не е да вдигнете ръце и да обявите записването на спецификации за безсмислие. Отговорът е да олекотите достатъчно процеса по определяне на спецификации, така че спецификациите да не се превърнат в страничен проект, отделен от развитието на самия уеб сайт.

„С други думи, документацията няма да реши проблемите ви. Определянето на спецификата на проблемите може да доведе до тяхното решение. Не става въпрос за обем или детайлност. Става въпрос за яснота и точност.“

Спецификациите не е нужно да въплъщават в себе си всеки аспект на продукта, само тези, които се нуждаят от дефиниция, за да се избегне объркване в процеса на проектиране и разработване. Спецификациите не е нужно да уловят някое идеализирано бъдещо състояние на уеб сайта - просто решенията, които са били взети в процеса на неговото създаване.

Записване на спецификации

Без значение колко голям или сложен може да бъде проектът, няколко общи правила се прилагат за писане на изисквания от почти всякакъв вид.

Позитивизъм

Вместо да описвате нещо лошо, което системата не трябва да прави, опишете какво ще направи, за да се предотврати това лошо нещо.

Например, вместо това: „Системата няма да позволи на потребителя да закупи принтер, ако той не е добавил резервна тонер касета към поръчката си.“

Това би било по-добре: „Системата ще насочи потребителя към страница за избор на резервни тонер касети, ако потребителя се опита да купи само принтер.“

Специфичност

Оставяйки възможно най-малко отворени въпроси за интерпретация е единственият начин, по който можете да определите дали дадено изискване е изпълнено.

Сравнете тези примери:

a) „Най-популярните видео клипове ще се отличават.“
б) „Видео клипове, които са събрали най-много гледания през изминалата седмица, ще се позиционират на първите три места в списъка.“

Първият пример изглежда идентифицира ясно изискване, но си проличава нуждата от допълнителен анализ, за да започне изпълнението на задача:

• Какво се смята за толкова популярно?
• Видео с най-много коментари?
• Видео с най-много харесвания?
• Какво означава „ще се отличават“?

Вторият пример определя вашата цел в конкретни детайли. Определя какво разбирате под популярни и описва механизъм за отличаване.

Избягвайте субективен език

Това е друг начин да бъдете специфични и да премахнете неяснотите от изискванията и следователно възможността за неправилно тълкуване.

Ето пример за силно субективно изискване: Сайтът ще има модерен, бляскав стил.

„Изискванията трябва да бъдат фалсифицируеми: Би трябвало да бъде възможно да се покаже кога едно изискване не е изпълнено.“

Трудно е да се демонстрира дали субективни качества като модерен и бляскав са били изпълнени. Вашите представи за модерно вероятно не съвпадат с тези на потребителите и най-вероятно изпълнителният директор има изцяло друга идея.

Това не означава, че вие не можете да изисквате вашия сайт да бъде модерен. Просто трябва да намерите начини да определите кои критерии ще се прилагат:

„Сайтът ще отговори на очакванията за модерно на Петьо Петков, човекът разнясящ пощата.“

Петьо обикновено няма да има какво да каже за уеб сайта, но вашият спонсор на проекта ясно уважава неговото чувство за модерно. Надяватe се, че това е същото усещане, което имат вашите потребители.

Но изискването все още е доста произволно, защото разчитате на одобрението на Петьо вместо на критерии, които могат да бъдат по-обективно определени.

Така че може би така формулирано това изискване ще бъде най-доброто от всички:

„Оформлението на страницата и визуалния дизайн ще отговарят на ръководните принципи и насоки за брандиране посочени в служебен документ на компанията.“

Концепцията за модерно сега е изчезнала изцяло от изискването. Вместо това имате ясна и недвусмислена препратка към приети ръководни принципи. За да се уверите, че принципите за брандиране на компанията са достатъчно модерни, вицепрезидентът по маркетинг може да се консултира с Петьо Петков, човекът разнасящ пощата, или да се консултира с дъщеря си, която е тийнейджърка. Тя дори може да се консултира с някои научни проучвания за потребителско поведение. Зависи от нея. Но сега можете да кажете окончателно дали изискването е изпълнено.

Можете също да премахнете субективността чрез количествено определяне на някои изисквания. Точно както показателите за успех правят стратегическите цели измерими количествено, определянето на изискване в количествено отношение може да ви помогне да определите дали сте отговорили на изискването.

Например вместо да изисквате системата да притежава високо ниво на производителност, вие можете да изискате системата да бъде предназначена да поддържа най-малко 1000 потребители едновременно. Ако крайният продукт позволява поддържане само на трицифрени номера за броя на потребителите, можете да кажете, че изискването не е изпълнено.

Изисквания за съдържание

През голяма част от времето, когато говорите за съдържание, вие имаме предвид текст. Но изображения, аудио и видео могат да бъдат по-важни от придружаващия текст. Тези различни типове съдържание също могат да работят заедно, за да изпълнят едно изискване.

Например една отличителна черта на съдържание, което обхваща спортно събитие, може да бъде придружаващата я галерия със снимки и видео клипове.

Идентифицирането на всички типове съдържание, свързани с една функция на уеб сайта, може да ви помогне да определите какви ресурси ще са ви необходими за създаване на съдържанието (или дали то може да се създаде въобще).

„Не бъркайте формата на съдържанието и неговата цел.“

При обсъждане на изискванията за съдържание със заинтересованите страни, едно от първите неща, което един дизайнер на потребителско изживяване обикновено чува е: „Трябва да имаме секция с Често задавани въпроси (ЧЗВ).“

Но терминът ЧЗВ наистина се отнася само до формата на съдържанието: просто поредица от въпроси и отговори. Реалната стойност на Често задавани въпроси за потребителите е, че тя осигурява бърз достъп до често необходима информация. Други изисквания за съдържание могат да изпълнят същата тази цел. Но когато фокусът е върху формата самата цел може да бъде забравена.

Очакваният размер на всяка една от вашите отличителни черти на дадено съдържание има огромно влияние върху решенията касаещи потребителското изживяване, които ще трябва да вземете.

Вашите изисквания за съдържание трябва да предоставят приблизителни изчисления за размера на всяка отличителна черта:

• Брой думи за текстови отличителни черти.
• Рразмери на изображения или видео в пиксели.
• Размери на файлове за сваляне.
• Самостоятелни елементи на съдържание като аудио файлове или PDF документи.

Тези изчисления за размер не трябва да бъдат точни, приблизителни е добре. Вие само трябва да съберете основната информация необходима за разработване на подходящо комуникационно средство за това съдържание.

Проектирането на уеб сайт да предоставя достъп до малки миниатюри е различно от проектирането на сайт да предоставя достъп до снимки на цял екран.

Знаейки предварително размера на елементите на съдържанието, които трябва да поберете, ви позволява да вземете умни, информирани решения по пътя.

Възможно най-рано определете кой ще бъде отговорен за всеки елемент от съдържанието.

Веднъж след като това бъде валидирано спрямо вашите стратегически цели, всяка отличителна черта на конкретно съдържание неизбежно звучи като една наистина добра идея стига някой друг да е отговорен за създаването и поддържането й.

Ако стигнете твърде дълбоко в процеса на развитие без да идентифицирате кой ще отговаря за всяка изискваща се отличителна черта на съдържанието, вие вероятно ще оставите зейнали дупки във вашия сайт, защото тези функции, които всички обичат когато те са хипотетични, се оказват твърде много работа за всеки, който действително поеме задачата.

„Това, което хората често забравят при разработването на изисквания е, че: Съдържанието е упорита работа.“

Може да успеете да наемете външен човек на договор (или, по-вероятно, възложете работата на някой от маркетинговия отдел), за да създадете съдържанието на време за първоначалното стартиране на уеб сайта, но кой ще го поддържа актуално.

Ефективното съдържание изисква постоянна поддръжка. Подхождайки към съдържанието с презумпцията, че веднъж след като го публикувате всичко е приключило, води до сайт, който с течение на времето влошава драстично потребителското изживяване, тъй като вече не отговаря на нуждите на потребителя.

Ето защо за всяка отличителна черта на едно съдържание трябва да посочите колко често ще бъде актуализирана тя. Честотата на актуализации трябва да бъде извлечена от стратегическите цели за сайта:

• Въз основа на целите на вашия продукт, колко често искате потребителите да се връщат?
• Въз основа на нуждите на вашите потребители, колко често те очакват актуализирана информация?

Въпреки това имайте предвид, че идеалната честота на актуализации за вашите потребители („Искам да знам всичко веднага, 24 часа на ден!“) може да не бъде практична за вашата организация. Ще трябва да се спрете на честота, която представлява един разумен компромис между очакванията на вашите потребители и вашите налични ресурси.

Ако сайтът ви обслужва няколко аудитории с различни нужди, знаейки коя част от съдържанието за коя аудитория е предназначена, може да ви помогне да вземете по-добри решения за това как да представите това съдържание. Информация предназначена за деца изисква различен подход в сравнение с информация предназначена за техните родители. Информация предназначена за двете групи потребители се нуждае от по-специфичен подход.

За проекти, които включват работа с голям обем съществуващо съдържание значителна част от информацията, която ще захрани вашите изисквания се записва в инвентар с налично съдържание.

Описвайки цялото съдържание на вашия съществуващ сайт може да изглежда като досаден процес и то обикновено е.

Но да разполагате с инвентар (обикновено приема формата на опростен, макар и много голям файл с електронна таблица) е важно по същата причина, поради която е важно да имате конкретни изисквания: така че всеки в екипа знае точно върху какво трябва да работи при създаване на потребителското изживяване.

Приоритизиране на изисквания

Събирането на идеи за възможни изисквания не е трудно. Почти всеки, който редовно влиза в контакт с даден продукт независимо дали е в бизнес организацията или извън нея, ще има поне една идея за дадена функция, която може да бъде добавена.

Сложната част е да разберете какви функции трябва да бъдат включени в обхвата на вашия проект.

Всъщност доста рядко може да видите една проста взаимна корелация между стратегическите ви цели и вашите изисквания. Понякога едно изискване може да се приложи към множество стратегически цели. По същия начин, една цел често ще се свързва с няколко различни изисквания.

Тъй като обхватът е изграден върху стратегията вие ще трябва да оцените възможни изисквания въз основа на това дали те отговарят на стратегическите ви цели (цели на продукта и нужди на потребителя).

В допълнение към тези две съображения определянето на обхвата добавя трето: До колко реално ще бъде осъществим този проект?

Някои функции не могат да бъдат приложени, защото те са невъзможни технически - например все още няма начин, който да позволи на потребителите да помиришат продукти в интернет без значение колко много може да желаят тази възможност.

Други функции (особено при съдържание) не са осъществими, защото те ще изискват повече ресурси, човешки или финансови, отколкото имате на разположение. В други случаи, това е само въпрос на време: функцията ще отнеме три месеца за имплементиране, но вие имате изрично изискване функцията да бъде имплементирана за два.

В случай на ограничено време можете да пренасочите функции към последващ ключов етап от проекта. При ограничени ресурси, технологични или организационни промени могат понякога да намалят тежестта на функцията, позволявайки й да бъде допълнена. Обаче невъзможни неща за имплементиране ще си останат невъзможни.

Малко отличителни черти съществуват във вакуум

Дори отличителни черти на съдържание на уеб сайт разчитат на такива около тях да информират потребителя как най-добре да използва предоставеното съдържание. Това неизбежно води до конфликти между отличителни черти. Някои отличителни черти ще изискват компромиси спрямо други, за да изготвят съгласувано, логическо цяло.

Например потребителите може да искат процеса на завършване на онлайн поръчка на продукт да бъде изцяло на една страница, а не на три, четири или пет стъпки - но плетеницата от наследени бази данни, които сайтът използва, не може да побере всички данни наведнъж.

За предпочитане ли е да продължите с процес на завършване на поръчка в няколко стъпки или трябва да преработите системата от база данни?

Това зависи от вашите стратегически бизнес цели.

Ослушвайте се за предложения за отличителни черти, които индикират възможни смени в стратегията и не са били явни по време на разработването на документа за функционални спецификации.

Всяко предложение за отличителна черта, което не съответства на стратегията за проекта е, по дефиниция извън обхват. Но ако предложена отличителна черта, която попада извън обхвата не се вписва в някои от типовете ограничения и все още звучи като добра идея може да искате да преразгледате някои от вашите стратегически цели.

Ако се усетите, че правите равносметка за много аспекти от стратегията си, обаче, вероятно сте скочили в определяне на изискванията прекалено рано.

Ако вашата стратегия или визуален документ идентифицира ясна йерархия на приоритетите сред стратегическите ви цели, тези приоритети трябва да бъдат основните фактори при определянето на приоритета на предложени отличителни черти.

Понякога обаче, относителното значение на две различни стратегически цели не е ясно. В тези случаи дали отличителни черти попадат в обхвата на проекта твърде често зависи от корпоративни политики.

Когато заинтересованите страни говорят за стратегия те обикновено започват с идеи за отличителни черти и след това трябва да бъдат придумани обратно към основните стратегически фактори.

Тъй като заинтересованите страни често имат проблеми с разделяне на отличителни черти от стратегия, определени черти често ще бъдат защитавани.

По този начин процесът по дефиниране на изискванията става въпрос на преговори между мотивирани участници.

Управлението на този процес на преговори може да бъде трудно.

„Най-добрият подход към решаване на конфликт между заинтересованите страни е да се обърнете към вече определената стратегия. Съсредоточете се върху стратегически цели. Не предлагайте средства за осъществяването им.“

Ако можете да убедите заинтересованите страни, които държат на определена отличителна черта, че стратегическата цел, която тази отличителна черта е предназначена да изпълни, може да бъде разгледана по някакъв друг начин, то страните няма да „страдат“, че нейните съставни елементи са пренебрегвани.

Вярно е, че често е по-лесно да се каже, отколкото да се направи

Показвайки съпричастие с нуждите на заинтересованите страни е от съществено значение за разрешаване на конфликти свързани с отличителни черти на един уеб сайт.

Кой казва, че корпоративните служители в сферата на технологиите не се нуждаят от умения за работа с хора?