Bankovní institut vysoká škola, a. s. Katedra matematiky, statistiky a informačních technologií
Vývoj a rizika internetových projektů s následným e-marketingem Diplomová práce
Autor:
Bc. Zdeněk Kosina Informační technologie a management
Vedoucí práce:
Praha
PhDr. Ing. Antonín Pavlíček, Ph.D.
Duben, 2012
Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a s pouţitím uvedené literatury. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Jablonci nad Nisou dne 10. 4. 2012
Bc. Zdeněk Kosina
Poděkování Chtěl bych poděkovat vedoucímu diplomové práce panu PhDr. Ing. Antonínu Pavlíčkovi, Ph.D. za cenné rady a náměty. Dále děkuji firmě MITON CZ, s.r.o. za příleţitost aktivně se podílet jako projektový manaţer na mnoha skvělých projektech, mezi něţ patří také v této práci popsaný automobilový portál. Děkuji téţ mnohokrát své přítelkyni Petře za trpělivost a její věcné postřehy. .
Anotace Tato diplomová práce se zabývá metodikami vývoje internetových projektů, popisem jejich technologií. Dále popisuje trendy moderních internetových projektů. Krátce rozebírá problematiku komunikace v týmu a stylu vedení. Věnuje se moţným rizikům, jejich analýze a protiopatření. Rozebírá také marketingovou online propagaci. V praktické části pak popisuje vývoj reálného projektu s aplikací teoretických poznatků. Klíčová slova Vývoj internetových projektů, metodiky vývoje, rizika projektů, online propagace. Annotation This thesis deals with methods of web development projects, a description of their technologies. It also describes trends in modern web projects. Briefly discusses the issue of team communication and leadership style. It deals with potential risks, their analysis and countermeasures. It analyzes the online marketing promotion. The practical part describes the development of a real project with the application of theoretical knowledge. Keywords Web development, web methodologies, web risks, online promotion.
Obsah ÚVOD .................................................................................................................................. 8 1
ZVOLENÉ METODY ZPRACOVÁNÍ ................................................................................. 10
2
INTERNET A JEHO STRUČNÝ VÝVOJ DO DNEŠNÍ PODOBY ............................................ 11
3
4
2.1
INTERNETOVÉ PROTOKOLY A JEJICH POUŽITÍ............................................................................ 11
BEZPEČNOSTNÍ RIZIKA V INTERNETOVÝCH PROJEKTECH.............................................................. 70
8.7
ZÁKAZNÍK JAKO RIZIKOVÝ FAKTOR ......................................................................................... 72
VHODNÉ FORMY PROPAGACE ..................................................................................... 74 9.1
ROZVOJ A VÝHODY INTERNETOVÉHO MARKETINGU .................................................................. 74
9.2
PROČ JE PROPAGACE NA INTERNETU DŮLEŽITÁ? ...................................................................... 75
9.3
MOŽNOSTI A TYPY PROPAGACE ............................................................................................ 76
9.4
NEVHODNÉ A PODVODNÉ TECHNIKY ..................................................................................... 82
10 POUŽITÍ V PRAXI ......................................................................................................... 84 10.1
OBECNÝ ÚVOD DO PROJEKTU ........................................................................................... 84
10.2
ÚVODNÍ ANALÝZA A ZAČÁTEK PROJEKTU ............................................................................. 85 6
10.3
VÝVOJ PROJEKTU ........................................................................................................... 87
10.4
PROJEKTOVÉ PRÁCE ....................................................................................................... 94
10.5
KOMUNIKACE S VÝVOJOVÝM TÝMEM A VEDENÍ PROJEKTU ...................................................... 96
10.6
RIZIKA BĚHEM PROJEKTU A JEJICH ŘEŠENÍ ........................................................................... 98
10.7
E-MARKETINGOVÁ PROPAGACE PROJEKTU ........................................................................ 100
10.7.1 10.8
Další použité formy propagace ....................................................................... 102
DALŠÍ MOŽNÝ VÝVOJ PROJEKTU ...................................................................................... 105
ZÁVĚR A POZNATKY ........................................................................................................ 107 SEZNAM POUŽITÉ LITERATURY ........................................................................................ 110 SEZNAM POUŽITÝCH OBRÁZKŮ ....................................................................................... 116 SEZNAM POUŽITÝCH TABULEK ........................................................................................ 118 PŘÍLOHY .......................................................................................................................... 119
7
Úvod Prostředí internetu, které lze v jistém kontextu chápat jako neustále se rozrůstající mnoţinu webových stránek a aplikací, je prostředí vysoce konkurenční. Kaţdý komerční internetový projekt, jenţ má ambice se v tomto prostředí prosadit a uspět, musí mít svůj jasně definovaný cíl, řízený vývoj a stanovené metriky pro jeho vyhodnocení. Tato diplomová práce je zaměřená na komplexní shrnutí teoretických poznatků nutných pro vývoj internetových projektů, od úvodních obecných definic a podstaty samotných projektů, po vývojové metodiky internetových projektů, aţ po jejich následný online marketing. Svým obsahem tedy do patřičné hloubky rozebírá celou ucelenou problematiku tvorby moderních webů. Cílem této práce je poskytnout ucelený rámec informací, pomocí něhoţ lze úspěšně realizovat i náročnou internetovou aplikaci. V teoretické rovině jsou rozebírány jednotlivé důleţité kroky vývoje a je upozorňováno na klíčové atributy, kterým je nutno věnovat náleţitou pozornost, aby byl projekt úspěšně dokončen. V praktické části jsou pak implementovány teoretické poznatky a konfrontovány s realitou. Praktická část je psána z pohledu projektového manaţera, který má více jak 10 let praxe i v oblasti přímého vývoje a tvorby internetových aplikací. Tyto cenné znalosti byly vyuţity v projektovém řízení, neboť důkladná znalost technických částí projektu je podkladem pro další rozhodování a řízení samotného projektu. Jak jiţ bylo uvedeno, úvodní část práce se krátce věnuje základním definicím projektového řízení, na které navazuje část věnovaná vývojovým metodikám. V této kapitole jsou popsány jak sofistikované postupy, tak i postupy, které jsou procesně řízeny méně, ale nacházejí své vyuţití při vývoji aplikace. Na metodiky navazuje popis nejčastěji pouţívaných technologií, jeţ slouţí k vývoji internetových aplikací. V další kapitole jsou krátce uvedeny trendy vývoje moderních internetových aplikací a problematika komunikace, která se na úspěšné realizaci podílí také svou podstatnou částí. Kaţdý projekt má své hrozby a moţná rizika. Tato část je podrobně rozvedena v kapitole rizik, kde je věnována samostatná menší kapitola riziku ze strany zákazníka resp. riziku ohledně bezpečnosti, jeţ má u internetových aplikací existenciální důleţitost. Další nedílnou součástí kaţdého většího a významnějšího projektu je jeho propagace. Kapitola věnovaná online marketingu popisuje základní prvky komunikačního mixu 8
a rozebírá povolené i nepovolené optimalizační techniky pro vyhledávače. Analyzuje také jejich vhodnost či nevhodnost. Nezapomíná také na vyuţití populárních sociálních sítí. Praktická část popisuje úspěšně realizovaný portál většího rozsahu, který je zaměřen na prodej nových vozů. V této části jsou popsány jeho vývojové fáze, pouţité technologie, rizika, propagace i jeho další moţný vývoj. Vybrané kapitoly jsou v závěru hodnoceny, ať jiţ z pohledu pozitiv, tak i negativ. Praktická část je téţ doplněna o názorné obrázky a ukázky aplikace, které vhodně doplňují popisovanou oblast řešení. V závěru práce je popsáno vyuţití teoretických poznatků v praxi, které je vhodné pouţít a jaký postup při vývoji internetové aplikace se ukázal jako efektivní a čeho se vyvarovat. Také je zde krátce shrnut vývojový trend internetových aplikací.
9
1 Zvolené metody zpracování Vymezená doména problematiky vývoje internetových projektů byla dekomponována na jednotlivé dílčí celky se zachováním integrity a rovnoměrnosti popisovaných suboblastí. Dekompozice byla provedena, jak v teoretické, tak analogicky v praktické části, kde byla analýza problematiky doplněna o empirické prvky. V určité oblasti byla vzhledem k rozsáhlosti domény pouţita abstrakce ve smyslu vyloučení méně podstatných elementů a vazeb. Vymezené segmenty pak byly podrobeny následné analýze. Zvolená dekompozice s určitou mírou abstrakce se ukázala být pro konkrétní popis problematiky dostatečná. Dekompozice v popisované oblasti musela být stanovena jen do určité hloubky vazeb zejména v korelaci s rozsahem práce. Metody pozorování byly vybrány převáţně logické s doplňující empirickou částí.
10
2 Internet a jeho stručný vývoj do dnešní podoby Internet jako technologický i informační rámec se neustále vyvíjí a do jeho rozvoje a zejména obsahu jsou investovány nemalé prostředky. V současné době neexistuje médium, které by mohlo internetu konkurovat, co se týče rychlosti sdílení informací v reálném čase.
2.1 Internetové protokoly a jejich pouţití Protokol je standardizovaný souhrn pravidel. Tato pravidla jsou definována normou RFC (Request For Comment) a jsou veřejně přístupná. Internet je tvořen hned několika takovými protokoly. Kaţdý protokol má na starosti svůj definovaný okruh působnosti a komunikuje zpravidla na svém specifickém portu. Všechny protokoly dohromady pak tvoří komplexní celek s víceúčelným pouţitím. Stručný přehled základních internetových protokolů: Název protokolu IP (Internet Protokol) TCP (Transmission Control Protocol) DNS (Domain Name System)
Význam protokolu Protokol síťové vrstvy. Zajišťuje směrování jednotlivých paketů optimální cestou.
Port –
Protokol transportní vrstvy. Rozkládá zprávu na jednotlivé pakety, které na cílové stanici opět
Příjem elektronické pošty. Zprávy „fyzicky“ zůstávají
Protocol)
na serveru.
SMTP (Simple Mail Tranfer Protocol)
Odesílání elektronické pošty.
Tabulka 1: Základní protokoly internetu
11
80 21 143 25
2.2 Sluţba WWW Ve svém počátku internet slouţil jako akademická sít pro vědecké účely. Postupně se však jeho význam a moţnosti začaly přesouvat i do komerční sféry. Zaslouţil se o to zejména systém zaloţený na hypertextových odkazech vyvinutý v roce 1989 ve švýcarském výzkumném ústavu CERN. Pro tento systém navrhl jeho autor Tim Berners Lee zkratku WWW (World Wide Web). Pro tvorbu WWW napsal nejen jednoduchý program, ale je i autorem celé hypertextové koncepce, která v sobě zahrnuje přenosovou část HTTP (HyperText Tranfer Protocol), obsahovou část HTML (Hypertext Markup Language) a identifikační část URL (Uniform Resource Locator). Jednou z výhod takového systému je úplná nezávislost na hardwarové a softwarové platformě počítače, na kterém je WWW sluţba spuštěna. Začaly vznikat první prohlíţeče a na stránkách se postupně objevovala i jednoduchá grafika.
2.3 Vývojové verze HTML Předchůdce HTML byl v 80. letech vyvinutý jazyk SGML (Standard Generalized Markup Language). SGML je ve své podstatě obecný značkovací metajazyk, jehoţ další definicí vznikly substráty v podobě XML (Extensible Markup Language) a zejména HTML. Ukázka SGML viz níţe: <poem>The SICK ROSE <stanza> Has found out thy bedOf crimson joy:And his dark secret loveDoes thy life destroy.1
První verze HTML, označená jako 0.9, byla vydána v roce 1991 a neobsahovala podporu pro grafiku. Tu podporuje aţ verze 2.0, která byla vydaná o 3 roky později. Tato verze podporuje v omezené míře i webové formuláře. Další verze, která byla relativně průlomová, byla označena jako 3.2 a umoţňovala tvorbu tabulek a pokročilejší formátování textu. V dnešní době se pokročilé formátování textu plně přesunulo z HTML do CSS (Cascading Style Sheets) stylů. Standard byl vydaný jiţ
1
ERJAVEC, Tomaz. Standards for Language Encoding. Natural Language Server [online]. 2000-09-01 [cit. 2011-11-26]. Dostupný z WWW: 12
pod hlavičkou W3C (World Wide Web Consortium), které má na starosti současný i budoucí vývoj HTML standardu. Verze 4.0 z roku 1997 ještě více rozvíjí myšlenku oddělování formátování stránek od základního obsahu. Zavádí prvek frames, který se stane na dlouhou dobu nešvarem při nevhodné tvorbě layoutu stránek. Dále však převládají jiţ klady v podobě detailnější specifikace tabulek a formulářů, které díky skriptovacím jazykům nabírají na důleţitosti. Verze 4x jsou bez zásadních obměn pouţívány nejdéle ze všech verzí, a to skoro celých 10 let. HTML verze pod označením 5 konečně odsouvá zastaralé čtyřkové verze do ústraní a nastupují tak nové moţnosti v podobě Web Applications 1.0 a Web Forms 2.0, které dávají vývojářům další nástroje pro technologický rozvoj webových aplikací a posouvají tak hranice vyuţití (X)HTML zase o krok dále.
13
3 Internetový projekt obecně Internetové projekty se stávají čím dál více rozsáhlejšími a nákladnějšími záleţitostmi. Jejich správné řízení vyţaduje nemalé úsilí, dovednosti a schopnosti v mnoha oborových disciplínách.
3.1 Co to je projekt Značná část lidské činnosti můţe být charakterizována jako projekt. Projekt je i náš ţivot jako takový. Avšak ne vše, co projektem nazýváme je projekt i ve skutečnosti. Co tedy projekt ještě je a co jiţ není? Projekt má mnoho definic. Jedna z nich dle ISO 10006: „Projekt je jedinečný proces sestávající z řady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný pro dosažení cíle, který vyhovuje specifickým požadavkům, včetně omezení daných časem, náklady a zdroji.“2 Nebo ve zkrácené variantě: „Projekt je dočasné úsilí s cílem vytvořit unikátní produkt nebo službu.“3 Kaţdý projekt je jedinečný v čase a prostoru, má začátek, konec a hranice působnosti. Vţdy je nutno počítat s individuálními podmínkami, které mohou nepříznivě ovlivnit úspěšnou realizaci projektu. Nevhodné podmínky resp. okolnosti v podobě rizik se mohou vyskytnout ve všech ţivotních fázích projektu. Diametrálně rozdílné podmínky mohou nastat i u projektů, které jsou si funkcionálně velmi blízké. Vţdy tedy hraje velkou roli zkušenost projektového manaţera, jako vedoucího projektu, který dokáţe rizika na základě svých znalostí a dovedností eliminovat nebo v lepším případě jim předcházet, aby vůbec nenastaly.
3.2 Ţivotní cyklus projektu Jak jiţ bylo uvedeno, projekt má svůj začátek a konec. Mezi těmito krajními body ale existují další dělící intervaly, které projekt dekomponují na kratší časové části. Zpravidla se projekt dělí na tyto prvky: 1. Proveditelnost Provádí se studie proveditelnosti, strategie, SWOT analýza. Formuluje se rámcové technické řešení, přínos a udrţitelnost projektu, propagace, rizika apod.
2 3
Co je projekt a jaké má vlastnosti. Project Management - Řízení projektu Tamtéţ. 14
2. Plánování a návrh Detailní rozpracování projektu na jednotlivé milníky, zdroje, kalkulace, harmonogram, smluvní podmínky díla apod. 3. Zavedení a spuštění Realizace díla a jeho dodání, včetně instalace a jeho otestování. 4. Uzavření Předání díla po finálním otestování, potvrzení předávacího protokolu a moţnosti další podpory díla.4
Obrázek 1: Ţivotní cyklus projektu, (zdroj: Ţivotní cyklus – fáze projektu. ADMINISTRÁTOR. Project Management)
3.3 Charakteristika internetových projektů Internetový projekt se můţe zdát stejný jako projekty z jiných oblastí, jejichţ výsledky jsou fyzicky uchopitelné a změřitelné. Ovšem jen na první pohled. Rozdíly mezi projekty jsou velmi značné. Je to dáno právě oblastí realizace internetových projektů. Specifickou oblastí je právě v tomto případě internet. Z pohledu vývojářské firmy, resp. zhotovitele má tvorba téměř nulovou reţii. Kromě softwarového vybavení pro tvorbu aplikace nejsou většinou potřeba ţádné další relativně velké investiční náklady.
4
Ţivotní cyklus - fáze projektu. ADMINISTRÁTOR. Project Management - Řízení projektu [online]. 2005-0919 [cit. 2011-11-27]. Dostupný z WWW: 15
Z druhé strany, tedy z pohledu zákazníka resp. zadavatele je kompletní výsledek projektu umístěn „někde” v internetové síti. Zákazník tak víceméně musí důvěřovat i webhostingové firmě, která aplikaci provozuje a to ve smyslu, ţe bude o jeho investici dobře postaráno a vše je dostatečně zálohováno. K dispozici je mnoho aplikací, které dokáţou v internetovém prostředí změřit mnoho parametrů (např. návštěvnost, účinnost reklamy, atd.). Vše je tedy měřitelné a také řiditelné. Můţe se tak porovnat předpokládaná metrika se skutečnou a vyvodit z toho jednoznačné závěry. Další specifikace internetového projektu je jeho okamţitá dostupnost z prakticky jakéhokoliv místa na světě. To má pochopitelně své nesporné výhody, i kdyţ k potřebné propagaci je potřeba zvolit i odpovídající e-marketingové nástroje. Globální dostupnost má samozřejmě také nevýhody spočívající v nutnosti mít dobře napsaný kód z hlediska bezpečnosti a kvalitní optimalizaci aplikace. Musí se také počítat s rozdílným uţivatelským nastavením v tomto globálním měřítku. Výstupem bývá zpravidla grafická část aplikace, jejíţ zobrazení přejímá klient (např. Google Chrome, Mozilla Firefox, Internet Explorer atd.). Jelikoţ kaţdý klient pouţívá jiné vykreslovací jádro, je nezbytně nutné optimalizovat a otestovat vzhled a funkčnost aplikace pod různými klienty a jeho verzemi. V nutných případech je moţno pouţít tzv. „hacky” (pomocné výhybky v kódu), které řeší nedodrţování standardů předepsaných W3C konsorciem. S těmito souvislostmi a mnoha dalšími okolnostmi, které stojí nemalé investice, je nutno počítat, pokud má být projekt úspěšný a obstát v konkurenčním prostředí, jakým internet bezpochyby je.
16
4 Metodiky vývoje a jejich fáze Pro vývoj softwaru, potaţmo internetových aplikací, je k dispozici mnoho sofistikovaných metodik, ověřených postupů a doporučení. Tyto podpůrné mechanismy vznikaly několik desetiletí a neustále se rozvíjejí a upřesňují. Mnohdy se vyvíjejí velmi rychlým tempem. Udrţet si přehled o nových technologiích, jeţ je nutné znát pro jejich správné nasazení i řízení není snadné. Informační technologie proto patří mezi ty obory, kde je nutné neustálé vzdělávání a otevřený přístup, který dokáţe stále přijímat a zpracovávat nové trendy.
4.1 Modely vývoje softwaru Soubor zkušeností a znalostí s vývojem software se během let postupně sofistikoval a usměrňoval do metodik a standardů. Vzniklo několik tzv. modelů, pomocí kterých je vhodné postupovat při realizaci softwarového projektu. Kaţdý model má své výhody i nevýhody a je tedy jen na zkušenostech projektového manaţera, který za vývoj zodpovídá, jaký model bude vzhledem k situaci a okolnostem nasazen. Modely samotné podléhají dalším vývojům a trendům a je moţné je modifikovat vzhledem k situaci. Nelze tedy brat vývojový model jako závazné dogma.
4.1.1 Vodopádový model Jedná se o nejstarší vývojový model (autor Winston W. Royce, který ho uveřejnil v roce 1970), který se skládá z následujících částí: specifikace poţadavků, návrh, implementace, integrace, testování, instalace, údrţba. V tomto pořadí se následně postupuje. Jde tedy o sekvenční (postupný) model. K následující fázi je moţné přistoupit, aţ kdyţ je kompletně připraven předchozí krok. Pokud jsou úvodní kroky tohoto modelu perfektně a bezchybně navrţeny, lze ušetřit v dalších fázích čas a náklady na projekt. Je vţdy levnější odhalit chybu v raném stádiu tvorby, neţ aţ v pokročilém stavu. Věnuje se tedy velké úsilí a čas na odladění návrhů a poţadavků jiţ v úvodu. Jedna z výhod tohoto modelu je jeho jednoduchost a přímočarost ve vývoji. Zároveň však klade velké nároky na disciplinovanost vývojářů a na bezchybné výstupy úvodní fáze. V praxi se však mnohdy povaţuje za nevhodný. Sekvence můţe být doladěna k dokonalosti jedině ve spolupráci se zákazníkem. Zákazník můţe své poţadavky často měnit a další sekvence tak výrazně ohrozit a to i vzhledem k tomu, ţe mohou nastat další technické komplikace vyvolané změnou ze strany zákazníka a je nutno se k předchozí sekvenci vrátit.
17
Tento model se při vývoji internetových aplikací jiţ nepouţívá pro svou koncepční zastaralost z hlediska pruţnosti a efektivity.5
4.1.2 Spirálový model Tento model vznikl v roce 1986 (autor Barry Boehm) a odstraňuje největší nedostatky vodopádového modelu. Spirálový model pracuje s riziky ve velké míře. Další fáze nenastane, pokud nemáme zachycení či předcházení rizik dostatečně podchyceno. Model je tedy zaloţen na práci s riziky a je vhodný spíše na větší projekty, kde se můţe vyskytnout rizik opravdu mnoho a je na ně vyhrazena dostatečná reţie. Během vývoje je stavěno na kvalitních základech a opakovaném testování. Pokud to okolní podmínky dovolí je doporučeno, aby zákazník byl během vývoje vţdy přítomen. Koncepce spirálového modelu počítá s následujícím ţivotním cyklem projektu: Určení cílů, alternativ, omezení. Vyhodnocení alternativ, identifikace a řešení rizik. Vývoj a verifikace další úrovně produktu. Plánování následujících fází. Těmito modelově se opakovanými událostmi vývoj projektu finalizuje aţ do konečné podoby.
Spirálový model vývoje je ideální pro realizaci internetových aplikací a softwarových projektů obecně. Počítá s riziky a jednotlivé vývojové fáze pracují s ohledem na ověřování postupu a jeho následné kontinuální plánování, coţ je silnou stránkou tohoto modelu.6
4.1.3 Prototypový model (přístup) Tento model sniţuje riziko neúspěchu projektu tím, ţe se vytvoří pouze funkčně omezený prototyp. Zákazník je těsně zapojen do spolupráce na vývoji a jsou mu předkládány menší vývojové přírůstky. Dílo tak plně odpovídá představě zákazníka. Často se však jedná o prototyp, který ale můţe mít za následek plně funkční internetovou aplikaci. Model se vyuţívá u internetových aplikací jen zřídka. Je-li však k němu časový i finanční prostor, můţe být velmi uţitečný pro svou názornost výsledku.
4.1.4 Přírůstkový model (přístup) Přírůstkový (inkrementální) model opět rozděluje projekt na menší segmenty a umoţňuje tak lepší reakce na změny v procesu vývoje a na případná rizika během projektu. Jednotlivé přírůstky jsou dělány v malých krocích a jsou realizovány principem vodopádu. V případě, ţe je velká pravděpodobnost vzniku rizik, např. ze strany zákazníka resp. mnoţstvím změn, které 6
z jeho strany mohou vyplynout je moţno přírůstkový přístup vhodně vyuţít. Internetový projekt lze takovýmto postupem poměrně bezpečně realizovat.
4.1.5 RAD metodika Rapid Application Development je taková metodika vývoje softwaru, která je zaloţena na spojení rychlého vývoje s kvalitně definovanými poţadavky a maximálního vyuţití opakovaně pouţitelných komponent. Model je lineárně sekvenční a je rozdělen na malé segmenty. Jednotlivé fáze RAD modelu spočívají vmodelování obchodních procesů, datových struktur, procesního modelování, generování kódu a testování. Více se vyuţívá aktivního zapojení zákazníka a jeho poţadavků na systém spolu s nasazením automatizovaných nástrojů na vývoj. Mezi tyto nástroje se dají zahrnout CASE (Computer Aided Software Engineering) nástroje, systémy řízení báze dat, generátory zdrojového kódu a grafického rozhraní GUI (Graphical User Interface). Některé prvky internetové aplikace je moţno takto vyvinout, ale spíše u „šablonovitých“ (opakovaně pouţitelných vzorech) a nenáročných řešení.7
4.1.6 RUP metodika Rational Unified Process je metodika pro vývoj softwaru vytvořená společností Rational Software Corporation. Tato metodika vychází z osvědčených praktik a postupů (best practises). RUP rozděluje proces vývoje na jednotlivé iterace. Po skončení iterace by měla být připravená spustitelná verze. Je v zásadě pouţitelná na různě rozsáhlé projekty a lze tuto metodiku přizpůsobit individuálním potřebám projektu. RUP vyuţívá k modelování modelovací jazyk UML, který přináší zejména standardizovaný prostředek pro komunikaci v rámci týmu i se zákazníkem. Metodika klade velký důraz na analýzu, plánování, testování, snadné zapracování změn, vyuţití komponent a dokumentaci. Je proto vhodná pro větší týmy na rozdíl od metodiky extrémního programování, které je vhodné pro menší týmy i projekty. RUP metodika je v případě vývoje internetových projektů spíše teoretickým návodem, i kdyţ její hlavní nástroj, kterým je jazyk UML je u větších internetových aplikací nezbytnost. Častěji se u těchto aplikací vyuţívají spíše agilní metodiky.8
4.1.7 Agilní metodika Metodika je kompromisem mezi zavedenými metodikami a neřízeným přístupem. Jako klíčová část dokumentace se bere přímo zdrojový kód aplikace. Reakce na příslušné změny se 7
RAVINDRAN, Cinoy. Rapid Application Development Model (RAD). Submit your high-quality, original articles for more exposure, credibility and traffic back to your website 8 BENEŠ, Michal. Metodiky a Notace-RUP. Objektová analýza, návrh a programování 20
dějí relativně rychle a počítají se změnami v procesech. Neexistují detailní plány na delší období. Agilní metodika počítá se silnějším zapojením zákazníka a změnami jeho poţadavků. Vývoj aplikace je prováděn tak, aby se mohly změny snadno implementovat do stávajícího stavu. V oblasti vývoje internetových aplikací lze říci, ţe se jedná o jednu z nejčastěji pouţívaných metodik.9
4.1.8 Extrémní programování Označuje se zkratkou XP. Jedná se o agilní přístup k vývoji softwaru. Tato metoda vznikla koncem 90. let. Hlavní myšlenkou je lépe se přizpůsobit změně v poţadavcích ze strany zákazníka
a
snaha
dodávat
vyšší
kvalitu
softwaru.
Extrémní
programování
je
charakterizováno těmito principy: Komunikace – významný spojovací prvek mezi vedoucím projektu a zákazníkem. Je důleţité, aby software splňoval poţadavky od zákazníka, tj. aby byly správně implementovány. Jednoduchost – programový kód se vytváří jen takový, který je nezbytně nutný, nevytváří se tedy takový kód, který by se sice mohl někdy hodit, ale momentálně je nepotřebný. Zpětná vazba – programový kód vzniká za neustálých testů, takţe je zde jistota, ţe vše funguje správně. Dále se často provádí akceptační testy se zákazníkem, který ověří, zda je dílo pro něj vyhovující. Odvaha – v případě, ţe programátor nalezne lepší algoritmus či narazí na chybu, je nutné toto rychle řešit i za případ ztracení delší práce, pokud se nový kód jeví jako efektivnější a vyloučí se další následné chyby.10 V případě, ţe zákazník je dostatečně zapojen do projektu a má alespoň základní analytické myšlení a dokáţe konkrétně popsat své poţadavky, je tento způsob pro vývoj internetových aplikací velmi dobře pouţitelný.
4.2 MDA (Model Driven Architecture) Správně navrţená architektura internetové aplikace je jedním z klíčových prvků pro úspěšnou realizaci a provoz aplikace. Pro splnění všech poţadavků, které jsou na systém kladeny, je nutno při jeho návrhu a vývoji dodrţovat k tomu určené metodiky a procesy. Všechny postupné kroky vedoucí k realizaci musejí mít svůj účel a logiku. Modelem řízená 9
architektura zavádí do vývoje software sofistikované nástroje a postupy pro dosaţení poţadovaných cílů. Jedná se o koncept vývoje zavedeným konsorciem OMG (Object Management Group) v roce 2000. Model je navrţen v rámci tří na sebe navazujících krocích, které lze v ideálním případě modifikovat pomocí reverzního inţenýrství. Modelem řízená architektura počítá s vyuţitím programovacích technik OOP (objektově orientovaným programováním) a modelovacího jazyka pro popis systému UML (Unified Modeling Language). Návrhové kroky při modelování: 1.
CIM (Computational Independent Model) Jedná se o tzv. doménový model, který popisuje byznys procesy aplikace. Jsou zde definovány poţadavky, které vznikly na základě poţadavků zákazníka a jejich interpretace byznys analytiky. Problematika je popsána v obecné rovině bez technických a logických detailů. Důleţité je dostatečně podrobně specifikovat poţadavky na aplikaci.
2.
PIM (Platform Independent Model) V tomto modelu (nazývaný téţ konceptuální) jsou jiţ popsány technické procesy a algoritmické úlohy systému, které se dají implementovat pomocí informačních technologií. Byznys procesy jsou převedeny a popsány IT analytiky. Navrhují se zde entity (objekty), vztahy mezi entitami a atributy entit (vlastnosti) apod. Model je nezávislý na technologické platformě a lze ho tedy později aplikovat na libovolné technologii, která bude pro systém nejvhodnější.
3.
PSM (Platform Specific Model) Transformací předchozího modelu je získán Platform Specific Model. Tento model je jiţ závislý na pouţité technologii a popisuje podrobnou logiku a relaci v systému. Je proto nazýván také jako logický či relační model. Rozšiřuje konceptuální model o další podrobnosti, pro jiţ konkrétní prostředí. Zahrnuje v sobě zejména datové typy (např. řetězec, číslo, atd.), integritní omezení (nutné pro zachování konzistence dat) a detailní vazby mezi objekty. V tomto modelu je návrhový vzor.
4.
Code (fyzický kód) Poslední transformací je převedení logického modelu do fyzického kódu. To, co je popsáno v logickém modelu se plně transformuje do zdrojového kódu. Následně se tedy můţe vytvořit jiţ samotná databázová vrstva a implementovat na ní taktéţ vygenerovaný zdrojový kód. Fyzický kód je konkrétní technologie, v níţ je aplikace napsána. Jsou 22
preferovány zejména objektově orientované jazyky (Java, .NET), jejichţ převod z logického modelu je integrován jednotlivými vývojovými nástroji relativně nejlépe. Dobře je také podchyceno vyuţití reverzního inţenýrství, kdy na základě změny ve fyzickém kódu se nám tyto změny propíší i do modelu logického resp. konceptuálního, kde je můţeme dále rozvíjet dle potřeby.11 MDA je velmi nadějná metodika. V oblasti vývoje dnešních internetových aplikací je zatím spíše jako doplňkový či experimentální nástroj. Nikoliv však nedůleţitý, neboť má značný potenciál pro svůj růst i nasazení. Pro vyuţití v oblasti internetových aplikací a zejména u sloţitých algoritmů je zatím tedy její nasazení spíše nevyhovující. Neexistují odpovídající softwarové nástroje pro kvalitní transformaci do zdrojového kódu. Zejména pro rozšířený jazyk PHP, které vyuţívá velká část internetových firem, je generování kódu na základě modelu téměř nulové. Pokud však budou existovat v blízké budoucnosti opravdu kvalitní generátory zdrojového kódu na takové úrovni, jeţ by vytvořil zkušený programátor, bude metodika MDA resp. nástroje této metodiky nepostradatelným a značně efektivním pomocníkem, který v budoucnu ušetří vývojářům mnoho času.
4.3 UML (Unified Modeling Language) – nástroj pro modelování Unified Modeling Language (dále jen UML) je široce pouţitelný unifikovaný modelovací jazyk, jehoţ vznik lze datovat rokem 1995, kdy byla zveřejněna jeho verze 0.8. Za autory jsou povaţováni metodici Booch, Rumbaugh. Tato verze sjednotila odlišné modelovací prvky a metodologie, které byly do té doby nejednotné a měly různou sémantiku, coţ přispívalo k značné nepřehlednosti. Postupně se jazyk vyvíjel a v roce 1997 vznikla verze 1.0, která byla svěřena skupině OMG (Object Management Group), aby ho dále rozvíjelo. Současné verze nese označení 2.0.12 UML je velmi komplexní nástroj a lze díky němu namodelovat různé specifikace systému dle potřeby. Od jednoduchých koncepčních diagramů pro znázornění jednoduché úlohy aţ po velmi detailní popis rozsáhlých systémů. Grafická notace jazyka je podporována
11
RICHTA, Karel. Modelem řízený vývoj. Co můţe přinést modelem řízený vývoj pro ladění a testování aplikací 12 BENEŠ, Michal. Notace UMl. Metodiky a Notace-UML 23
nezávislým meta modelem, který umoţňuje navrhovat i popisovat systémy s vyuţitím objektově orientované metodiky s mnoha výhodami, jenţ tento objektový přístup nabízí.13 Jeho syntaxe je názorná a přehledná a lze úspěšně vyuţít jako prostředek pro popis systému. Zároveň je snadno pochopitelný i na straně zákazníka. UML je charakterizováno několika různými diagramy, z nichţ kaţdý má své specifické pouţití a zápis vztahů a atributů, které jsou jejich nedílnou součástí a slouţí k zachycení popisu a chování dílčích prvků systému.14 V současné době je standard UML 2.0, který se skládá z následujících čtyř částí: UML 2.0 SuperStructure – syntaxe jazyka (obsahuje jednotlivé diagramy). UML 2.0 Infrastructure – sémantika jazyka (popisuje význam jednotlivých diagramů). UML 2.0 Object Constraint Language (OCL) – představuje jazyk pro specifikaci omezení týkající se jednotlivých diagramů. UML 2.0 Diagram Interchange – specifikace formátů a struktur pro výměnu modelů mezi různými vývojovými nástroji.15 UML ve své poslední verzi 2.0 obsahuje jiţ relativně hodně diagramů. Tyto diagramy můţeme rozdělit do následujících tří hlavních skupin dle vhodnosti pouţití diagramů: Diagramy struktur Zachycují statickou strukturu systému. Popisují prvky a jejich vztahy, ze kterých je model sloţen. Tuto skupinu tvoří následující diagramy: Diagram tříd. Diagram objektů. Diagram komponent. Diagram sloţených struktur (nový diagram v UML 2.0). Diagram balíčků. Diagram nasazení. Diagram sloţených struktur (vnitřní struktury) je velmi komplexní. Obsahuje v sobě mnoho prvků (třídy, komponenty, rozhraní, porty atd.). Zajímavý je prvek port, který vyjadřuje externí interakci s okolím.
Diagramy chování Popisují dynamické chováni systému. Jeho moţné stavy a následné akce. Mezi tyto diagramy patří: Diagram případů uţití. Diagram aktivit. Stavový diagram. Diagramy interakce Tato skupina je odvozena od obecných diagramů chování a zahrnuje zejména tyto diagramy: Sekvenční diagram. Diagram komunikace. Diagram časování. Diagram přehledu interakcí.16 Diagram časování – zavádí explicitní práci s časem do UML. Zobrazuje změny stavů, podmínky či role vztaţené k časovému toku. Diagram přehledu interakcí – syntaxe digramu je podobná s diagramem aktivit. Velkou výhodou tohoto diagramu je názorné znázornění větvících a paralelních procesů v systému. Diagram časování i diagram přehledu interakcí byly uvedeny ve verzi UML 2.0. Díky jazyku UML lze popsat velmi názorně i sloţitou problematiku. UML slouţí jako mocný nástroj pro interní potřeby vývojového týmu i pro přesnější specifikaci řešení, kterému dokáţe porozumět i méně technicky zdatný zákazník. Jak jiţ bylo uvedeno, UML obsahuje mnoho diagramů, které se dají vyuţít na odlišné oblasti nasazení. 16
Ne všechny diagramy se pochopitelně vyuţívají stejně často. Pro svou názornost a časovou nenáročnost zhotovení je u internetových projektů pouţíván zejména diagram případů uţití, stavový diagram resp. diagram aktivit. Velmi vhodný je pro rámcový popis diagram objektů a pro detailnější popis rozsáhlejší struktury se vyuţívá diagram tříd.
4.4 Obecný postup vývoje internetových projektů Kaţdý internetový projekt je jedinečný. Záleţí proto na mnoha okolnostech, které určují metodiku jeho vývoje, stanovení kapacitních zdrojů, cenového odhadu, pouţité technologie apod. V podstatě můţeme internetové projekty rozdělit na prezentace a aplikace. Internetová prezentace můţe být charakterizována jako mnoţina statických stránek, které mají pro návštěvníky především pasivní informační hodnotu. Převládá textový obsah spojený s dalšími vizualizačními prvky (videa, animace, obrázky). Typickým příkladem internetové prezentace je firemní web, který zpravidla obsahuje úvodní stránku, nabídku sluţeb s fotogalerií, vize a mise firmy, kontaktní stránku a další potřebné statické obsahy. Naproti tomu internetovou aplikaci lze chápat jako implicitní algoritmický prvek, jehoţ výstupem je reakce na uţivatelský vstup. Navenek se aplikace tváří jako prezentace, ale její hlavní prvek je pro uţivatele skrytý a tvoří nosnou část celého díla. Internetová aplikace můţe být reprezentována sofistikovaným multikriteriálním vyhledávačem, generátorem online dokumentů či editorem obrázků v reálném čase nebo moderními hrami v prostředí prohlíţeče apod. Základem je tedy interaktivita s uţivatelem a propracovaný algoritmus na pozadí aplikace. Mnohdy se však tyto skupiny prolínají. Názvosloví je tak čistě orientační, nikoliv striktně dané. Níţe bude popsána realizace internetových stránek, které mohou v sobě obsahovat aplikaci menšího významu, např. vyhledávací formulář o několika poloţkách. V obecné rovině lze vývoj internetových stránek rozdělit na následující základní kroky:
Sběr poţadavků od zákazníka Rozhodne-li se zákazník realizovat webové stránky, je potřeba od něj získat jejich základní představu. Na základě komunikace se zákazníkem se tyto poţadavky postupně sestaví do uceleného rámcového popisu. Následně je doporučeno si tento soupis úvodních poţadavků potvrdit od klienta, aby se předešlo případným nedorozuměním. V této úvodní fázi je to velmi důleţité. Dále je vhodné alespoň rámcově klienta seznámit s postupem tvorby webu a vysvětlit základní pouţívanou terminologii. 26
Soupis specifikace poţadavků spolu s klíčovými prvky prezentace Je-li k dispozici úvodní soupis, připraví se na základě zkušeností a znalostí detailní soubor jednotlivých stránek prezentace a jaký je jejich doporučený obsah. Tento popis by měl být dostatečně podrobný, aby zadavatel nemohl v průběhu projektu zadání snadno měnit, coţ by mohlo vést k ohroţení projektu. Podrobná a přesná specifikace slouţí také k vytvoření harmonogramu projektu, stanovení jeho finanční náročnosti i k plánu moţných hrozeb. Tyto plány se stanovují kombinací více technik v podobě dekompozice problematiky na menší části. Další technikou je vyuţití váţeného průměru, kde jednotlivé prvky mají svou váhu. Techniky by měly být ještě validovány na základě zkušeností a znalostí projektového manaţera, který můţe stanovit další „bezpečnostní“ koeficienty pro navýšení časového vývoje webu či rozpočtu apod. V prezentaci by měly být hlavně zdůrazněny klíčové atributy firmy, která bude web vyuţívat. Pro oslovení potenciálního zákazníka je nutné tuto konkurenční výhodu zviditelnit a snadnou a pochopitelnou formou předloţit na stránkách. Často se na tuto oblast zapomíná a stránky nedokáţou splnit svůj účel, který spočívá v transformaci potenciálního zákazníka na reálného.
Cílová skupina návštěvníků prezentace a konkurence Cílová skupina uţivatelů stránek silně ovlivňuje strukturu i grafickou část stránek. Značný rozdíl je připravovat stránky, jeţ mají být určeny pro mladistvou cílovou skupinu, kde je moţno pouţít odváţnější grafiku v podobě kombinace barev, odváţnějších grafických křivek netradičně zvolenou navigaci stránek apod. V přiměřené míře lze pouţít doprovodných animačních prvků ve flashy a celkovou „hravost“ a „veselost“ stránek. Naopak pokud jsou stránky cíleny na starší uţivatelskou skupinu a mají působit seriozním a důvěryhodným dojmem, je lépe se drţet tradičního rozloţení prvků a decentní grafiky. Snadnost dohledání údajů a přehlednost zde hrají důleţitou roli, stejně jako zvýraznění pozitivních prvků firmy. Existují-li jiţ tematicky podobné konkurenční stránky, zejména od renomovaných tvůrců, je moţné v určité míře čerpat inspiraci odtud. Dobře zmapovaná konkurence je nutností. Je moţné vyvarovat se tak chyb a pouţít ověřené řešení. Důleţité je však pouţívat vlastní ověřené kreativní řešení.
27
Návrh struktury a navigace stránek Správně navrţená struktura spolu s přehlednou navigací je základ úspěchu kaţdé webové prezentace. Nenutit uţivatele zbytečně tápat a maximálně mu zjednodušit cestu k informacím, které potřebuje. Návrhem struktury by měl být pověřen odborník, nejlépe UX (User Experience) designér. Jeho cílem je navrhnout uţivatelsky přívětivý web, kde by tedy uţivatel našel vše podstatné bez zaváhání. Pro zhotovení drátěných modelů existuje mnoţství nástrojů od volně dostupných pro plně profesionální, které v sobě obsahují i konkrétní formulářové prvky (zaškrtávací pole, výběrové pole, …), takţe lze pomocí těchto prvků velice věrně nasimulovat jejich reálný vzhled. Z těchto drátěných modelů lze pak vytvořit „klikatelný“ model sestavený z navrţených struktur. Takto navrţený model je ještě více názorný a lze při něm odladit další návrhové prvky. Jelikoţ na strukturu navazuje tvorba grafické části, která je finančně náročná, pouţívají se pro návrh struktury tzv. drátěné modely (wireframes). Podstatou drátěných modelů je názorné zobrazení rozvrţení prvků na stránce bez zavádějící grafiky. Grafika se tak nemusí pokaţdé pracně předělávat, pokud se změní či přesune nějaký prvek na stránce. Návrh pomocí těchto modelů je důleţitý zejména pro umístění základního menu, obsahové části, struktury formulářů apod. Drátěné modely se zhotovují jen na komplikovanější stránky se sloţitější strukturou. Tyto klíčové návrhové stránky mohu být reprezentovány např. výpisem produktů či jeho detailem. V obou těchto případech je mnoho prvků, které by měly tvořit přehledný a jednolitý celek. Není tedy nutné zhotovit drátěný model na podstránky, kde bude pouze uţivatelsky vkládaný text s případnými obrázky. Na obrázcích 5 a 6 je znázorněn návrh drátěného modelu, resp. navigační struktura webové prezentace.
28
Obrázek 5: Návrh drátěného modelu
Drátěný model na obrázku 5 zachycuje rozvrţení prvků na stránce a jejich základní strukturu. Model je doplněný i o realistické formulářové prvky a doplňující komentář k určitému prvku. Celkovou strukturu v hierarchickém pojetí pak ukazuje následující obrázek 6. Struktura začíná na úvodní (hlavní) stránce a postupně se větví do dalších podsloţek.
Obrázek 6: Hierarchická struktura
29
Návrh funkčních prvků na stránce Funkční prvky na stránce představují mnoţinu funkcionalit, které obstarávají konkrétní procesy. Jako funkční prvek na stránce můţe být prezentován vyhledávací filtr, registrační formulář s interními vazbami a závislostmi, proces vloţení zboţí do košíku apod. U funkčních prvků je důleţitý jejich přesný a detailní popis, který dokáţe vývojář realizovat do zdrojového kódu tak, jak byl popsán. Popis můţe být čistě textový či doplněný jednoduchým schématem nebo propracovaným UML diagramem. Jelikoţ jsou funkční prvky na vývoj náročnější, je vhodné je dostatečně finančně ohodnotit a konzultovat stanovený odhad ceny ještě s vývojáři. Funkční prvky by měly být navrţeny flexibilně s ohledem na jejich další moţné úpravy a rozšíření bez nutnosti předělání značného mnoţství jejich zdrojového kódu. Měly by být téţ optimalizovány na rychlost a bezpečnost.
Grafické řešení Grafický návrh se aplikuje dle předem zhotovených drátěných modelů. Zákazník by měl mít moţnost se vyjádřit k barevnému pojetí a případnému stylu grafiky. Zda má být střídmá či naopak je moţno vyuţít více grafických detailů a prvků. Webová prezentace
nejvíce
morálně
zastarává
zejména
na
úrovni
grafické
části.
Na průměrných webech je to znát jiţ po 1 roce, na těch špičkových přibliţně od 3 let výše. Grafika velmi podléhá trendům, které se mění opravdu rychle a neúprosně. Nevýrazná či nevhodně zvolená grafika dokáţe webovou prezentaci znehodnotit, nejen co se týče přehlednosti, ale i s ohledem jakým působí na návštěvníka stránek. Na návštěvníka určitě zapůsobí pečlivě zvolená a provedená grafika, která v něm vyvolá úvodní pocit solidnosti firmy, jejichţ sluţeb se chystá vyuţít. Firma by měla dbát na svoji internetovou vizitku a kvalitní grafika je jedna ze silných nástrojů jak na potencionálního zákazníka zapůsobit.
Technické řešení Zvolení správného programovacího jazyka, databázové stroje, prezenční vrstvy a dalších komponent webu je otázka mnoha faktorů. Záleţí na jeho architektuře, předpokládané zátěţi, rychlosti zpracování apod. Často se pouţívají kombinace programovacích jazyků s ohledem na jejich silné stránky. Technické řešení by mělo respektovat modularitu systému a jeho snadný další rozvoj a správu. Samozřejmostí je v dnešní době mít takové řešení, které podporuje bezpečnost a stabilitu celého 30
webového projektu a poskytuje případné opravné mechanismy. Bezpečnost technického řešení by měla být na prvním místě bez ohledu na vyšší cenu.
Testování Důkladné otestování vizuálního, uţivatelského, technického či funkčního řešení webového projektu je nezbytně nutné pro profesionálně odvedenou práci. Mnohdy však na testování není čas či finanční prostředky a prezentace působí nedodělaným dojmem. Pečlivé testování by mělo vycházet z testovacích scénářů a mělo by testovat i takové stavy aplikace, jeţ mají minimální pravděpodobnost vzniku. Testování lze provádět interními testery, u velkého a plošně cíleného projektu je moţno poskytnou odladěnou verzi (tzv. betu) i široké veřejnosti. Analýzou zpětné vazby od těchto uţivatelů lze získat velmi dobré výsledky pro moţné úpravy. Webová aplikace tak bude s vysokou pravděpodobností odladěna dle většiny jejich uţivatelů.
Spuštění a propagace stránek Při spuštění webové prezentace by měla být dohodnuta její další technická podpora a rozvoj, zejména v podobě kontinuální SEO optimalizace, která je u webových projektů jedna z finančně nejnáročnějších poloţek. Důleţitým prvkem pro spuštění internetového projektu je také vhodný název domény, který by měl vystihovat jeho obsah. Pokud doména není volná, lze uvaţovat o jiné doméně nejvyššího řádu tzv. TLD (Top Level Domain). V případě nutnosti je moţné obsazenou doménu odkoupit. U lukrativních názvů jsou to zpravidla nemalé částky. Je tedy nanejvýše vhodné nakoupit doménu a její varianty ještě před započetím samotného projektu. Spuštění projektu do rutinního provozu by mělo souviset také s jeho následnou propagací.
Existuje mnoho marketingových nástrojů, jak docílit povědomí o webu pro jeho cílovou skupinu. Propagace stránek můţe být v řádů tisíců aţ několika miliónů korun v případě dlouhodobější propagační akce. Profesionálně působící a rozsáhlou propagaci projektu by měla řešit dostatečně velká a kreativní mediální agentura, která dokáţe zacílit a oslovit velké mnoţství uţivatelů internetu. V mnoha případech jsou jednotlivé kroky detailnější (zvláště pokud se jedná o sloţitější strukturu a budoucí progresivní rozvoj stránek), ale mohu být i kratší (tvorba grafiky i technického řešení ze šablon apod.). Postupy i nástroje pro tvorbu internetových projektů se
31
neustále vyvíjejí. Pokud se chce firma v tomto oboru drţet na špičce, je nutné tyto trendy sledovat a prakticky aplikovat.
32
5 Technologie Technologie jsou základním stavebním prvkem kaţdého softwarového projektu a určují jeho charakteristiku a budoucí rozvoj. Kaţdá technologie má své výhody a nevýhody, proto se mnohdy technologie vzájemně doplňují v jeden optimalizovaný funkční celek.
5.1 Vývoj technologií pro webové aplikace Jak roste uţivatelská náročnost na rychlost a dynamiku aplikací spolu se vzrůstající rychlostí připojení uţivatelů k internetu, rozvíjejí se i technologie, které dokáţou toto všechno nabídnout a mnohdy ještě mnohem více. Pryč jsou doby, kdy uţivatel byl pouhý pasivní konzument webových stránek, tvořených převáţně textem a jednoduchou grafikou bez moţnosti cokoliv na stránkách ovlivnit. Současné technologie nabízejí real-timově zpracování uţivatelských poţadavků v dostatečné rychlosti, efektivitě a uţivatelské přívětivosti, která byla dříve nemyslitelná. Během posledních patnácti let technologického vývoje několik jazyků zaniklo či přestaly být oficiálně podporovány (např. ASP od Microsoftu). Některé nové a nadějné technologie (AJAX, WebGL) či jazyky naopak vznikly (např. Ruby on Rails či Dart od společnosti Google). Vývoj jde mocnými kroky dopředu, i co se týče formátovacích prvků. Ty mají na starosti vizuální podobu stránek, zde stojí za zmínku kaskádové styly ve své třetí verzi označované jako CSS3 a také „značkovací“ jazyk HTML 5. Méně ideální situace v oblasti nových technologií souvisí s podporou nových technologií mezi prohlíţeči, kde nejlépe si vede v implementaci novinek prohlíţeč Chrome od společnosti Googlu, následovaný prohlíţeči Mozilla Firefox, Safari a Operou.
5.2 Programovací jazyky 5.2.1 PHP PHP (dříve označovaný jako Personal home Page, nyní jako Hypertext Preprocessor) je široce pouţitelný skriptovací jazyk. Vkládá se přímo do HTML a je vykonávaný na straně serveru. Od první verze udělalo PHP mnoho výrazných kroků a stalo se postupně velmi oblíbeným programovacím jazykem na statisících webových projektů. Jeho syntaxe je jednoduchá, účinná a intuitivní. PHP v sobě implementuje mnoho knihoven pro práci s databázovými stroji, adresáři, práci s textem, cookies, LDAP a mnohé další. Vývoj v tomto jazyce je rychlý 33
a jednou z jeho výhod je, ţe lze v něm psát jak strukturálně, tak objektově. PHP sice není tak objektově koncipováno jako např. Ruby on Rails nebo Java, ale v podpoře objektového přístupu se v PHP udělalo mnoho změn a v tomto trendu vývojová skupina, která se stará o rozvoj PHP, pokračuje.17 Následující ukázka názorně ukazuje jednoduchost a filosofii jazyku PHP: $to = "pří[email protected]"; $subject = "Testovací email"; $body = "Text v těle emailu"; $headers = "From: [email protected]\n"; $sent = @mail ($to,$subject,$body,$headers); if ($sent == 1) echo "Email byl úspěšně odeslán na adresu: $to";18
5.2.2 Java Java je objektově (i kdyţ ne úplně) orientovaný jazyk s mnoha oblastmi vyuţití jak v mobilních telefonech, desktopových aplikacích, tak v prostředí internetu. Její výhodou je multiplatformost (nezávislost na operačním systému), bezpečnost či podpora vícevláknových operací. Nevýhodou je pak náročnost na paměť systému a pomalejší prvotní start aplikace, neboť při inicializaci aplikace se musí program přeloţit do mezikódu a pak se teprve spustí. Oblast Javy resp. její část, která je určena pro tvorbu webových aplikací nese označení Java EE (Enterprise Edtition). Součást platformy Java EE jsou pak tyto oblasti: Java Servlets Java Servlety jsou vhodné pro komunikaci s protokolem HTTP na straně serveru. Je tedy moţné pokládat serveru dotazy a očekávat od něj příslušné odpovědi. Objekt, který má na starosti HTTP poţadavky, obsahuje např. tyto třídy: getServerName() – DNS jméno webového serveru getProtocol() – verze protokolu getRequestedSessionId() – identifikátor session19 Java Server Pages Jedná se o pouţití Javy přímo do HTML kódu, podobně jako v případě PHP. Vloţení Javy se uvozuje i končí speciálními značkami, které oddělí kód napsaný v Javě od ostatního, zpravidla formátovacího kódu. 17
GILMORE, Jason W. Velká kniha PHP a MySQL 5: kompendium znalostí pro začátečníky i profesionály, s. 34. 18 Jiný dokument – vlastní úprava 19 JavaServlets. Wiki FI MUNI 34
JSP <% // uvození Java Server Pages if(request.getMethod().equals("POST")) { %> Formulář byl odeslán metohodu POST <% } %>20
Java Server Faces Java Server Faces je zaloţen na architektuře MVC (Model View Controller). MVC rozděluje aplikaci na datový model, uţivatelské rozhraní a řídící logiku. Princip Java Server Faces je v tom, ţe pracuje s webovou stránkou rozdělenou na jednotlivé elementy nikoliv jako s celým rámcem.21
5.2.3 Ruby On Rails Tento framework („vývojový rámec“) je zaloţen na skriptovacím plně objektově (vše je zde objektem) orientovaném jazyku Ruby. Programovací jazyk Ruby v sobě kombinuje prvky z jazyků Perl a Smatalk. Ruby On Rails slouţí k efektivnímu pohodlnému vytváření webových aplikací, je zaloţen opět na architektuře MVC, na které je aplikace postavena Názorná ukázka kódu je uvedena zde: <% if @books.blank? %>
5.2.4 ASP.NET ASP.NET je technologie od společnosti Microsoft a je součástí skupiny NET. Framework. ASP.NET nemá se starším a jiţ několik let nepodporovaným ASP (Active Server Pages), které bylo téţ určeno pro vývoj webů téměř nic společného. Nová technologie .NET umoţňuje vývojářům si přímo zvolit programovací jazyk, který chtějí při vývoji webové aplikace pouţít. V úvahu připadají zejména tyto programovací jazyky:
20
Jiný dokument – vlastní úprava Java Server Faces. Wiki FI MUNI 22 Rails Views - ActionView. Tutorials point [online]. 2012 [cit. 2012-01-10]. Dostupný z WWW: 35 21
Visual Basic.NET, JScript.NET, C# a Managed C++. Aplikace v ASP.NET je kompilovaná, běh aplikace je tedy velmi sviţný. Díky unifikovatelnosti přístupu k řešení vývoje, lze relativně snadno přecházet mezi jednotlivými prostředími (desktopová či webová aplikace). Výhodou je také nezávislost na typu webového serveru. 23
5.2.5 Python Python je skriptovací jazyk, objektově orientovaný, ale lze v něm psát čistě strukturovaně dle vhodnosti situace. Tento jazyk je velmi citlivý na odsazení v kódu. Na odsazení zpravidla pouţívá tabulátory. Python je často nasazován pro svou rychlost zpracování i pro relativní rychlost vývoje aplikace samotné. Jeho syntaxe je čistá, jednoduchá a díky nutnosti odsazování kódu velmi dobře čitelná. Následující krátký a názorný kód demonstruje filosofii tohoto zajímavého jazyka: import MySQLdb db= MySQLdb.connect(host="localhost", user="python-test", passwd="python", db="python-test") cursor = db.cursor() stmt = "SELECT * from books" cursor.execute(stmt) rows = cursor.fetchall () for row in rows: print "Row: " for col in row : print "Column: %s" % (col) print "End of Row" print "Number of rows returned: %d" % cursor.rowcount
5.2.6 JavaScript JavaScript je jednoduchý skriptovací jazyk, který je vykonáván na straně klienta. Je tedy odlišný od všech výše uvedených programovacích jazyků. Nicméně pro tvorbu moderní webové aplikace je nepostradatelný. V posledních několika letech se opravdu mocně prosazuje, zejména v AJAXových aplikacích či v tagu canvas v HTML 5 apod. Pomocí objektovému modelu dokumentu DOM (Document Object model) lze velmi efektivně přistupovat k jednotlivým atributům, z kterých se webová stránka skládá. Struktura DOM je znázorněna na obrázku 7.
Obrázek 7: Struktura DOM
Zde je uveden jednoduchý příklad vyuţití DOM: 25
JavaScript je velmi rozšířený a efektivní v pouţití. Lze ho nasadit např. na validaci vyplněných formulářových prvků, ještě před odesláním dat na server (uţivatel tak má ihned 24
zpětnou vazbu na svou činnost), na práci s obrázky či jednoduché efekty. Záleţí, s jakou další technologií je provázán. Momentálně je rychlost zpracování javascriptového kódu v prohlíţečích velmi klíčová sledovaná hodnota, neboť ţádná moderní aplikace se bez pouţití JavaScriptu téměř neobejde. Navíc obsah javascriptového kódu na webových stránkách opravdu mocně narůstá. Naštěstí existuje mnoho frameworků, které usnadňují kóderům práci, aby nemuseli vţdy pracně psát znova stejný kód od základů, ale vyuţili jiţ předpřipravené knihovny a postupy řešení. Mezi oblíbené frameworky patří především Prototype či jQuery.
5.3 Doplňující technologie 5.3.1 AJAX Webová technologie AJAX (Asynchronní JavaScript a XML) byla poprvé uveřejněna v roce 2005. Jak jiţ zkratka napovídá, jedná se o asynchronní zpracování poţadavků vyuţívajících programovacího jazyka JavaScript a strukturovaných dat v podobě XML. Filosofie této technologie spočívá v poskytnutí dat uţivateli bez znovunačtení stránky. Tato vlastnost je velmi uţitečná například při procházení výpisu produktů např. v eshopu, při hlasování v anketě a podobných událostech, které dříve byly podmíněny opětovným načtením stránky, coţ bylo časově a zvláště uţivatelsky nepříjemné. AJAX vyuţívá knihovny v JavaScriptu, která dokáţe pracovat na pozadí se serverem, který pak vrací stavové události i samotný poţadovaný obsah události. Samotná logika aplikace, můţe být napsána v libovolném jazyce, běţícím na straně serveru. Kromě JavaScriptu a XML pracuje také s dynamickým HTML a kaskádovými styly. AJAX je tedy kolekcí několika technologií. Velkou výhodou také je asynchronní chování AJAXU – prohlíţeč nemusí čekat na odpověď serveru, ale průběţně zpracovávat i ostatní data.26 Nevýhodu AJAXu je moţno spatřovat např. v nemoţné identifikaci obsahu stránky pomocí URL, která zůstává stejná, i kdyţ pomocí AJAXu je obsah stránek vrácen rozdílný v závislosti na poţadavku. Názorná koncepční ukázka jak AJAX funguje je zobrazena na následujícím obrázku 8.27
26 27
HOLZNER, Steven. Mistrovství v Ajaxu, s. 22. AJAX Intorduction. W3Schools 38
5.3.2 Web services (webové sluţby) Webové sluţby jsou velmi uţitečné pro výměnu dat mezi různými aplikacemi, které spolu komunikují na pozadí uţivatelských aplikací. Tyto sluţby je vhodné pouţít, pokud druhé straně nechceme poskytnout např. z obchodních důvodů celý obsah databáze, ale jen dílčí části na vyţádání dané aplikace. Webové sluţby jsou zaloţeny na vzdáleném volání procedur pomocí strukturovaných dat. Pro strukturovaná data je vhodné vyuţít formátu XML. Přenos pak probíhá v rámci protokolu HTTP. Webové sluţby jsou sloţeny z těchto částí: Protokol pro volání procedur SOAP (Simple Object Access Protocol) – HTTP přenese data v XML. V těle XML je umístěn namespace (jmenný prostor s „poţadavkem“). Odpovědí serveru je opět XML jiţ s odpovědí na „poţadavek“. Jazyk pro popis sluţeb WSDL (Web Services Description Language) – WSDL je zaloţeno na XML a popisuje dostupné operace, návratové hodnoty, protokol apod. Obsahuje několik hlavních tagů, které definují komunikační strukturu. Mezi tagy patří např. message, port. Message popisuje poţadavek/návrat funkce, tag port pak typ komunikačního portu. Kontrolu dostupnosti pomocí sluţeb UDDI (Universal Description, Discovery, and Integration a WSIL (Web Services Inspection Language) – specializované mechanismy pro nalezení sluţeb.28
28
KUBA, Martin. Co jsou webservices. Tutoriál Web Services z Europen 2005 39
5.3.3 HTML 5 a tag canvas HTML 5 je prozatím poslední a přímo revoluční verzí „značkovacího“ jazyka určeného pro základní
stavbu
webových
stránek.
HTML
5
přináší
řadu
novinek.
Jedna
z nejzajímavějších je tag (značka) canvas. Element canvas se zapisuje jako klasický párový tag . Jeho potenciál je ukryt v programovacím jazyku JavaScriptu, který tvoří veškerý logický i zobrazovací obsah vázaný na tag canvas. U zrodu tagu canvas stála společnost Apple, která tuto funkcionalitu vyuţila ve svém operačním systém Mac OS X. JavaScript je mezi vývojáři velmi vyuţívaný a dobře známý. Lze tak snadno vyvíjet moderní aplikace bez nutnosti se učit další programovací jazyk. Za pouţití vykreslovacích funkcí lze snadno pracovat s bitmapovou grafikou od základních obrazců aţ po efektivní animace. V ukázce níţe je vykreslen červený kruh za pomocí tagu canvas a JavaScriptu. <script type="text/javascript"> var c=document.getElementById("myCanvas"); var ctx=c.getContext("2d"); ctx.fillStyle="#FF0000"; ctx.beginPath(); ctx.arc(70,18,15,0,Math.PI*2,true); ctx.closePath(); ctx.fill(); 29
Z kódu jasně vyplývá, jak se s prvkem canvas pracuje. V JavaScriptu se odkáţe na identifikátor myCanvas, který je obsaţen v uvozovacím tagu canvas a poté jiţ následuje práce s vykreslovacími funkcemi v JavaScriptu. Pokud prohlíţeč prvek canvas nepodporuje, jednoduše se to vypíše mezi uvozovací a uzavírací tag. Uţivatel je tedy explicitně informován a můţe to řešit buď instalováním patřičného pluginu do prohlíţeče nebo pouţitím jiného prohlíţeče. Samozřejmě lze snadno do uvedeného kódu přidávat další prvky a efekty. Pomocí animací lze nahradit v určitých případech technologii Flash, která je datově náročnější a nečitelná 29
pro vyhledávací roboty. Navíc lze pracovat nejen v 2D dimenzi ale téţ s 3D prvky, které dávají doslova a do písmene tomuto elementu další rozměr v moţném vyuţití. Jako nevýhodu lze momentálně spatřovat v chybějící podpoře zatím stále ještě hodně vyuţívaného prohlíţeče Internet Explorer ve verzích 7 a 8. Teprve aktuální verze 9 tuto podporu má. Pro niţší verze lze zvolit plugin, který ale není vţdy spolehlivý. Ostatní prohlíţeče jako jsou Mozilla Firefox, Chrome, Safari a další jiţ tuto podporu nabízejí relativně dlouho.
5.3.4 WebGL WebGL (Web-based Graphics Library) je rozšíření (grafická knihovna) pro programovací jazyk JavaScript, pomocí něhoţ lze vykreslovat hardwarově akcelerované 3D prvky. Toto rozšíření je opět spojeno s HTML 5 prvkem canvas. Grafická knihovna přímo spolupracuje s grafickým procesorem umístěným na samostatné grafické kartě nebo s grafickým jádrem umístěným v procesoru. Aplikace je tak vykonávána opravdu rychle. Ovšem tento přímý přístup ke grafické kartě lze označit jako bezpečnostní riziko, neboť ho lze zneuţít, protoţe ovladače nedokáţou zaručit maximální bezpečnost. WebGL podporuje zejména společnost Google, která WebGL zatím experimentálně implementovala do svých Google Maps. Další zajímavý projekt, který nastiňuje moţnosti této technologie
je
interaktivní
„filmová”
aplikace
s
názvem
ROME
dostupná
na http://www.ro.me/. Jistou nevýhodou zůstává podpora v prohlíţeči Internet Explorer, který WebGL z důvodu zmíněné bezpečnosti zřejmě pouţívat nebude.
5.3.5 Dart Programovací jazyk Dart uvedený v roce 2011 od společnosti Google je dalším programovacím jazykem přímo vyvinutým pro psaní webových aplikací. Dart je objektově orientovaný a jeho syntaxe je podobná k programovacímu jazyku C. Samotný kód v Dartu pak můţe vypadat například takto: main() { String tradingSecrets = "High Frequency Trading requires extremely fast computers"; int latency = 10; String message = "Google Dart language"; print('Hello world in ${message }'); print("This is String literal just like Java"); print( '${tradingSecrets}'); } 41
Výstupem toho kódu je tento text: Hello world in Google Dart language This is String literal just like Java High Frequency Trading requires extremely fast computers30
Kód Dartu lze přeloţit přímo do JavaScriptu, coţ je pro vývojáře velká výhoda. Na druhou stranu překlad není ještě plně optimalizován a takto přeloţený zdrojový kód je v JavaScriptu o několik řádů větší neţ jeho zdroj v Dartu. Cílem Dartu je být konkurencí pro JavaScript, který existuje sice jiţ od roku 1995, ale za tu dobu se stal velmi oblíbený a rozšířený. Nový jazyk Dart bude mít alespoň z počátku těţké prosazení mezi vývojáři.31
5.3.6 Mikroformáty Mikroformáty jsou menší části kódu v HTML, které nesou ale silnou a strukturovanou vypovídací hodnotu. Reprezentují většinou doplňující informace k okolnímu textu. Tyto strukturované informace jsou vyhledávacími roboty snadno indexovatelné a ve výsledcích hledání se uţivateli jiţ tyto údaje zobrazují. Mikroformátů existuje poměrně hodně (hResume, hAtom, hCalendar, …) a vztahují se k nějakému oboru činnosti či stavu. Zajímavý je mikroformát hCalendar, který je určen pro strukturované zapsání zápisu časových událostí. Vše se zapisuje pomocí tříd, které specifikují data v nich. <span class="vevent"> <span class="summary">The microformats.org site was launched on <span class="dtstart">2005-06-20 at the Supernova Conference in <span class="location">San Francisco, CA, USA. 32
Tento mikroformát v sobě nese obecné informace o akci, jeho začátku a místa konání akce. Mikroformáty jsou pro svou nenáročnost implementace a přínos pro uţivatele velmi uţitečné, i kdyţ jejich nasazování je prozatím pozvolné.33
30
JAVIN, Paul . Google Dart Program Example Tutorial. In: TIBCO RV FIX PROTOCOL JAVA TUTORIAL [online]. 2011-10-15 [cit. 2012-01-17]. Dostupný z WWW: 31 MALÝ, Martin. Google Dart přichází. In: Zdroják 32 HCalendar 1.0. Microformats [online]. 2012-03-12 [cit. 2012-03-15]. Dostupný z WWW: 33 SLÁDEK, Jan. Kódujme sémanticky s mikroformáty: úvod. In: Zdroják 42
6 Trendy a vize Bez vizí, které se následně transformují do trendů, by neexistoval ţádný progresivní vývoj softwarových aplikací. Vize boří hranice nereálnosti a vytyčuje další směr. Je to naděje, víra, myšlenka v hlavě vizionáře, která se stává postupně realitou. Kaţdý moderní internetový projekt, který chce v dnešní době uspět na velmi silném konkurenčním trhu v prostředí internetu, musí mít jako jeden ze svých nosných pilířů flexibilní informační systém, který rychle reaguje na potřeby trhu a umoţňuje rychlý rozvoj dílčích prvků systému.
6.1 Trendy moderních internetových projektů Současná webová prezentace se skládá z mnoha propojených technologií, které se neustále vyvíjejí a zlepšují a vytlačují tak desktopové aplikace, které se postupem doby stávají více omezené a nepouţitelné nejen v podobě sdílení dat odkudkoliv a kdekoliv. Moderní doba si ţádá přístupnost k datům okamţitě a to bez ohledu na místo i čas. Navíc existuje mnoho nových zobrazovacích zařízení neţ dříve a i na ně je nutno pamatovat. Vývoj, kvalita i typy zobrazovacích zařízení, jako jsou monitory či notebooky se širokoúhlým displejem, moderní tablety a mobilní telefony v podstatě diktují rozměrové charakteristiky webové prezentace. Po dlouhá léta bylo ustáleným zobrazením 800x600 obrazových bodů. Nyní jsou zpravidla stránky optimalizovány na 1280x1024. Důleţité je počítat se širokoúhlými displeji (zejména notebooků) neboť u nich převládá šířka nad výškou ve spojení s menší zobrazovací plochou a uţivatel je pak nucen více při čtení stránky rolovat obsah směrem dolů. Z tohoto důvodu je dobré graficky zpracovat niţší hlavičku prezentace a mít důleţitý obsah alespoň částečně viditelný bez nutnosti rolování obsahu. Trendem u moderních aplikací je mít dostatečně velké písmo, zpravidla 16 pixelů i více. Uţivatel tak má text dostatečně velký bez nutnosti manuálního zvětšování v prohlíţeči. Velikost písma se dá nastavit i na relativní hodnotu dle rozlišení obrazovky. Vhodné je také dodrţovat vhodné odřádkování, aby řádky nebyly těsně na sobě, coţ je pro delší text velmi nepříjemné. Důleţité prvky, jeţ souvisí s kontextem stránek, a uţivatel by je neměl přihlédnout, se navrhují dostatečně a někdy aţ nadprůměrně velké. Pro takové zvýraznění je hodný zejména 43
takový prvek, jako je textové pole pro vyhledávání nebo vyhledávací formulář. Na obrázku 9 je patrné, jakou výraznou oblast vyhledávací formulář pokrývá.34
Dostatečně velké písmo a nadprůměrně výrazné prvky, které mají pro uţivatele klíčové vlastnosti, mají pro své rozměry rozhodně opodstatnění. Co je potřeba zdůraznit, ať je zdůrazněno. V moderní prezentaci nelze jinak neţ potřebné, byť i nadprůměrné, vhodné zvýraznění doporučit. V současné době to není zatím ještě pravidlem, ale jiţ jsou internetové společnosti, které vyuţívají pro stavbu stránek jen HTML 5. Jak jiţ bylo uvedeno výše, tato verze je zatím poslední verzí tohoto značkovacího jazyka, pomocí jehoţ nových vlastností se webová aplikace obejde např. při přehrávání videa či jednoduché animace bez technologie Flash, která je relativně nestabilní, datově náročná a není plně zabezpečená proti moţným útokům. Důleţité je i u moderních aplikací stále optimalizovat vzhled pro různé prohlíţeče, které mají své vlastní standardy a mnohdy je pro ně nutno pouţít různé výjimky. Profesionální stránky jsou plně odladěné a zachovávají zpětnou kompatibilitu i s niţšími verzemi prohlíţečů. Uţivatelsky velmi oblíbené se stalo vyhledávání pomocí rozsáhlejších formulářů bez nepříjemného načítání stránek po kaţdém upřesnění dotazu či běţné uţivatelské akci jako je hlasování v anketě či přihlášení odběru newsletteru, procentuálního progresu nahrávaného souboru apod. Tuto oblíbenost si vyslouţila technologie AJAX, která je u moderních aplikací standardem. Výrazně usnadňuje a zlepšuje uţivatelský komfort při uţívání webových aplikací. Co se týče grafických prvků, je trend spíše v jednoduchosti a přehlednosti. Křiklavá grafika a barevné provedení s různými blikajícími či samovolně posuvnými texty jsou dávnou 34
Honzova hypotéka. Honzova hypotéka 44
minulostí. V dnešní době by vzbudili spíše úsměv či v horším případě pocit nesolidnosti a laciného dojmu. Grafika stránek je realizována v jpg či png formátech. Obrazový typ gif je obecně pouţíván v dnešní době jen na jednoduché bannerové animace. S grafickým provedením souvisí i struktura stránek. Zde opět platí pravidlo, ţe v jednoduchosti je síla. V poslední době se objevuje trend mít webové stránky opravdu velmi stručné a obsahově více cílené na uţivatele. Dlouhé textové obsahy na jednotlivých stránkách společně se sloţitou aţ překombinovanou strukturou se stávají minulostí. Opět ale záleţí na charakteru obsahu stránek a na cílové skupině uţivatelů, pro které je určena. V komerční sféře se však jiţ uplatňuje střídmost a snaha poskytnout jen takový obsah, který je pro potenciálního zákazníka opravdu důleţitý a „nezahltit“ ho tak zbytečně přemírou detailních a méně potřebných informací. Zachování přehlednosti u velkých webových prezentací je velmi náročná disciplína a je nutno rozloţení prvků velmi dobře promyslet a nechat otestovat prověřenými uţivateli několik prototypů. Uţivatel se musí na stránkách rychle a přehledně orientovat a musí se dostat tam, kam je autorem stránek zamýšleno. Pokud se jedná např. o internetový obchod, musí potenciální zákazník snadno vyhledat poţadovaný produkt a během několika málo kroků přehledně a intuitivně dokončit celý nákup. Pokud si během celého nákupního procesu vloţí do elektronického košíku další produkty, které původně ani nechtěl, tím lépe. Stejně důleţité je pro autora stránek resp. provozovatele docílit toho, aby se uţivatel na stránky opět vrátil a stal se z něj věrný zákazník. Čím dál více je nutno provázat skutečné poţadavky uţivatele stránek s návrhem a funkcionalitami webových stránek, aby byly v dnešní době úspěšné. Moderní webové prezentace se čím dál více propojují se sociálními sítěmi. Mezi nejpouţívanějšími u nás patří Facebook, Twitter a relativně nově i Google+. Tyto sociální sítě umoţňují uţivatelům vzájemně sdílet své záţitky od textové podoby, po fotografie, videa či webové stránky apod. V jednoduché formě se propojí do stránek tzv. „lajkovacími tlačítky“ nebo odkazem na stránky vytvořené v prostředí sociálních sítí. Zajímavější je však propojení stránek a sociálních sítí v pokročilejší formě integrace. Nejdále je v tomto Facebook, pomocí jehoţ mnoha pluginů lze internetový obchod propojit pomocí XML s obchodem na Facebooku. Zákazník si tak můţe dohledat zboţí na Facebooku a zboţí poté nakoupit jiţ klasicky na webových stránkách poskytovatele.
45
Eshop v prostředí Facebooku ukazuje následující obrázek 10.35
Obrázek 10: Eshop v prostředí Facebooku
Další moţností je pouţití přímo Facebookového diskuzního fóra na webových stránkách. Tato diskuze se opět implementuje formou pluginu a opět má tato moţnost své výhody a nevýhody. Mezi výhody lze zahrnout jednoduchou implementaci, odstranit nevhodné příspěvky či relativně značné odhalení anonymity přispěvatelů apod. Mezi nevýhody patří závislost na podpoře a dalším vývoji pluginu ze strany Facebooku, zatěţování serveru a špatné indexaci příspěvků vyhledávači. Také lze na stránkách zobrazit novinky z Facebooku a ostatní uţivatele, včetně jejich fotografií, kterým se stránky líbí. To vše přispívá k budování komunity kolem stránek a jejich obecného povědomí mezi ostatními uţivateli sociálních sítí. Webové prezentace rychle podléhají moderním trendům, které jsou neúprosné vzhledem k datu vzniku prezentace. Časový interval zavádění novinek se neustále zkracuje. Stránky tak velmi rychle morálně zastarávají a na webové prezentaci, která je stará více neţ 5 let je to zpravidla velmi znát. V mnoha případech pomůţe grafický či částečný technický update. Někde však nepomůţe ani on. Pokud stránky vyuţívají zastaralý či vhodně navrţený CMS (Content Management System) systém pro správu obsahu, je nutno upravit i ten. To často není jednoduché ani levné. Vhodné je potom začít znova na „zelené louce“, neţ upravovat zastaralý systém. Zákazníka to přijde v konečné fázi i mnohem levněji. Je proto vhodné vţdycky promýšlet o moţném rozšíření funkcionalit i do budoucna.
35
Ráj čokolády. In: Facebook 46
6.2 Web 2.0 a jeho moţný nástupce Současný web, tak jak je známý dnes, nese označení web 2.0. Tomuto označení logicky předcházelo označení 1.0 a v blízké budoucnosti bude současné označení vystřídáno termínem web. 3.0. Prvotní verze označená 1.0 nebyla odborníky ani laickou veřejností nijak zaregistrována. Populární a široce marketingově proklamovanou verzí se stala aţ ta následující. Web jako takový se rozvíjí velmi rychle a bylo vhodné mu dát další označení, které by nový trend popsalo a zachytilo. Důleţité bylo také odlišení od předchozího vnímání webových sluţeb. Další označení tedy bylo na spadnutí. Bere se obecně v úvahu, ţe verze 2.0 platí pro webové aplikace uvedené od roku 2004 do současnosti. Dnešní označení, tedy web 2.0 v sobě obsahuje celý rámec technologií i filosofii dnešního vyuţívání webových aplikací. Zahrnuje v sobě zejména tyto oblasti: Aktivní podílení uţivatelů na obsahu webu, který jimi není vlastněn. Větší míra interakce v podobě chatů, diskuzí a sociálních profilů. Uţivatel se stává součásti konkrétní komunity. Personifikace webových stránek. Veřejné sdílení dat. Interakce webu s uţivatelem v časově spojitém intervalu (AJAX).36 Rozdíl mezi webem 1.0 a 2.0 ukazuje následující obrázek 11.37
Obrázek 11: Web 1.0 vs. Web 2.0, (zdroj: AMBROŢ, Jan. Web 2.0: bublina, nebo nový směr webu?. In: Lupa)
36 37
AMBROŢ, Jan. Web 2.0: bublina, nebo nový směr webu?. In: Lupa Tamtéţ. 47
Na obrázku je velmi patrný rozdíl v tvorbě webového obsahu uţivateli mezi jednotlivými verzemi. U verze 2.0 je snadno viditelný velký mrak, který je tvořen „skupinovou inteligencí“, která sdílí své zkušenosti, poznatky i emoce. Jedná se v podstatě o globální souhrn chápání okolního světa dílčích uţivatelů. Tento mrak tak odráţí hodnotovou a morální vyspělost či naopak nedostatky tvůrců tohoto obsahu. Mezi charakteristické projekty webu 2.0 je moţné povaţovat zejména tyto:
Wikipedie Otevřená encyklopedii z mnoha oborů lidské činnost. Kaţdý uţivatel internetu se můţe dobrovolně podílet na jejím obsahu. Wikipedie tak slouţí jako rozsáhlý populárně naučný informační zdroj. Pokud je vyuţíván k odbornějším článkům jako citační zdroj, je nutné si ověřit informace i u jiného zdroje. Texty na Wikipedii jsou zpravidla moderovány a odborně korekturovány, ne vţdy ale dostatečně. Obsah Wikipedie má svou váhu i u vyhledávačů. Je proto vhodné umístit na ni potřebné informace, které chceme zviditelnit, pokud to je ovšem koreluje s pravidly Wikipedie. Vznikají i různé humorné verze encyklopedie, které na první pohled vypadají věrohodně, ale obsah je tvořen nadsázkovým typem. Příkladem toho je např. Necyklopedie dostupná na http://necyklopedie.wikia.com. I toto však vypovídá o významu projektu, jehoţ obsah tvoří svobodně a dobrovolně jeho uţivatelé pro pobavení.
Youtube Největší a nejrozsáhlejší databáze zaměřená na sdílení uţivatelských videí na internetu. Youtube bylo zaleţeno v roce 2005 a o rok později tento nadějný a jeden z nejrychleji rostoucích projektů koupila společnost Google za nevídanou sumu 1,65 miliardy amerických dolarů. Youtube i po odkoupení Googlem zůstalo vývojově nezávislé včetně obsazení zaměstnanců. Coţ byl velmi dobrý krok. Google si prozíravě uvědomil, ţe něco měnit na úspěšně rozjetém projektu by bylo jen k horšímu. Na Youtube se objevila relativně brzy kontextová reklama, zobrazující se během přehrávání videa. Další forma reklamy se objevila v podobě zvýraznění promo videí od komerčních společností. Reklama slouţí Youtube jako jeden z hlavních příjmů. Denně jsou na server nahrávány desítky tisíc dalších videí a přehraje se jich několik miliard za den. Youtube se více propojilo se sociální sítí Google+ a nabízí na úvodní stránce videa ostatních uţivatelů z této sítě. Youtube také nabízí přehrávání videí bez 48
podpory flashe, který by v budoucnu neměl být dle Googlu jako primární technologie pro přehrávání videí na internetu.
Facebook Nejpouţívanější sociální síť pro sdílení dat mezi uţivateli na internetu. Slouţí ke vzájemné komunikaci, získávání nových kontaktů a udrţování stávajících. Sdílení nových poznatků, názorů, multimediálních dat a zábavy. Je plně přeloţen do několika desítek jazyků a počet aktivních uţivatelů se blíţí k jedné miliardě. Facebook byl zaloţen studentem Markem Zuckerbergem, který byl původně vyuţíván pouze studenty Harvardu. Postupně se však začal otevírat i ostatním uţivatelům. Také do tohoto systému se postupem dostala reklama a to formou obrázku a krátkého textu. Výhodou reklamy na Facebooku je přímé cílení na uţivatele dle pohlaví, věku, oboru zájmu apod. Taková to cílená reklama má pak velmi dobrou zpětnou vazbu. Pro firmy je vhodná moţnost zaloţení si vlastní oficiální stránky a komunikovat se svými fanoušky. Facebook nabízí mnoho funkcionalit, mezi ty hlavní patří zejména: o Profil – nastavení informací o své osobě, zaměstnání, koníčky, datum narození, pohlaví a řada dalších údajů, které mají vypovídající hodnotu o uţivateli profilu. Důleţité je pamatovat na viditelnost dat a sdílet důvěrnější informace jen mezi blízkými přáteli. Na Facebooku můţe mít profil i komerční charakter v podobě firemního profilu. Jak takový profil můţe vypadat, je patrné na obrázku 12 níţe.38
Obrázek 11: Komerční profil firmy na Facebooku, (zdroj: Miton CZ. In: Facebook) 38
Miton CZ. In: Facebook 49
o
Zeď – stěţejní část Faecebooku. Uţivatelé zde mohou napsat své příspěvky, odkazy na videa apod. Na zeď můţe napsat příspěvek i jiný uţivatel, který je označen jako přítel. Zeď slouţí jako hromadný výpis všech veřejných aktivit přátel. Reakce na osobní příspěvek od ostatních přátel se objeví jako upozornění. Je tedy moţno opět reagovat komentářem na příspěvky přátel a vést diskuzi.
o
Události – moţnost pozvat přátelé na plánovanou akci. Akci lze doplnit o vizuální prvky. Soukromé zprávy a chat. Jedná-li se o soukromou resp. důvěrnou zprávu, která je určena přímo příjemci je zde moţnost posílat a číst vzájemné interní zprávy. Pro komunikaci v aktuálním čase pak slouţí chat, který můţe být i hromadného typu mezi více uţivateli.
Jelikoţ se sociální sítě staly mezi uţivateli velmi oblíbené, spustila v roce 2011 svou vlastní síť i společnost Google nazvanou Google+. Je zde moţnost rozdělit obor svých blízkých a známých do mnoţin nazvaných kruhy. Nechybí zde vytvoření firemní stránky apod. Zatím na Google+ převládají lidé z oboru informačních technologií, neboť byla dříve Google+ pouze na doporučení a toto doporučení bylo rozšířeno zejména mezi lidmi z oblasti IT. Zatím Google+ není tak rozšířená a příspěvky se pohybují spíše ve formální odborné úrovni. Výrazné ohroţení Facebooku konkurenční sítí Google+ se zatím nekonalo. Na trh má ale vstoupit další silný hráč a to společnost Microsoft. Uţivatel tak bude mít další moţnost volby. Spravovat však jiţ tři profily na sociální síti by bylo časově náročné, proto je moţné se domnívat, ţe silní hráči, kteří budou bojovat o přízeň u uţivatelů, zůstanou maximálně dva.
Google Docs Technologicky velmi vyspělé kancelářské aplikace převedené pro vyuţívání v prostředí internetu. Obsahují editor pro psaní textů, tabulkový procesor, vytváření prezentací apod. Aplikace jsou kompatibilní s tradičními desktopovými od společnosti Microsoft. Na Google Docs je velmi silně patrné, jak webové aplikace dokáţou postupně nahrazovat klasické desktopové programy. Navíc se tyto dokumenty snadno sdílejí a upravují a jsou dostupné odkudkoliv a kdykoliv. Google Docs jsou pro běţnou kancelářskou práci plně dostačující a navíc jsou poskytovány zdarma. Po technické stránce i svou filosofií sdílení jsou Google Docs jedním z pilířů současného webu, označovaného jako web 2.0.
50
Vývoj však neúprosně pokračuje dál a uţivatelé od internetu i více očekávají. Budoucí nástupce webu 2.0 se logicky nabízí pod označením web 3.0. V dnešní době mnoha miliard internetových stránek se i přes nesporné zvyšující se kvality vyhledávačů přeci jen ztrácí původní význam sluţby World Wide Web. A tím je sémantický web. Tim Bernes Lee, jako autor této sluţby, na tento význam poukazoval jiţ před mnoha lety. Sémantický („obsahově významový“) web by obsahoval o svých elementech podrobné a strukturované údaje, které by ho jasně identifikovaly. Nevýhodou sémantického webu lze spatřovat v podobě sloţitějšího dotazování na straně uţivatele. Nástupce webu 2.0 by však jiţ mohl plně pracovat i rozvíjet princip mikroformátů, které sémantiku podporují. Pokud by se uţivatelské dotazování mělo podřídit sémantice webu, byl by to krok zpět. Trendem je naopak uţivatelské rozhraní co nejvíce zjednodušit a usnadnit uţivateli práci. V současné době jsou tyto prvky zastoupeny např. našeptávači či nápovědami při překlepu ve slově. Vyhledávání by se mělo plně přizpůsobit lidskému způsobu myšlení při dotazování. Eliminovalo by tak sloţité vymýšlení kombinací klíčových slov. Bude však také důleţité jednotlivé prvky webu od sebe sémanticky oddělit a identifikovatelně popsat, aby přirozené vyhledávání bylo co nejvíce efektivní. Nástupce webu 3.0 se bude více propojovat s „bio“ informacemi ze sociálních sítí. Reklama bude ještě více cílená a bude vyuţívat i jisté prvky umělé inteligence, stejně jako algoritmus pro vyhledávání dat. Data se stanou ještě cennějšími a jejich dohledání v co nejkratší časem se bude stále více projevovat jako velká konkurenční výhoda. S vyhledáváním také souvisí bezpečnost, na kterou bude kladen největší zřetel. Čím dál větší objem sdílených informací a jejich dohledatelnost, resp. zneuţitelnost bude velmi silným hráčem při navrhování budoucích zabezpečených aplikací v rámci internetové sítě. Dalším moţným trendem, který se naplno uplatní v další „verzi“ webu 3.0 bude přesunutí zábavního průmyslu v odvětví počítačových her do prostředí prohlíţeče. Dnešní 3D aplikace jiţ jasně ukazují, jakou má technologie WebGL potenciál. Vyuţití nebude platit jen pro herní průmysl, ale i pro vědecké účely, jako je např. namodelování 3D objektů v reálném čase na základě vstupních údajů a jejich další poţadovanou simulaci. Uţivatel bude mít webové aplikace plně přizpůsobitelné dle svých preferencí. Aplikace tak bude plně flexibilní a bude se plně přizpůsobovat uţivateli a nikoliv naopak, jako je běţné
51
v dnešní době. Současné aplikace mají většinou společný vzhled i funkcionality pro všechny uţivatele bez rozdílu. Vzhledem k nárůstu vyuţívání internetu v tabletech, chytrých mobilních zařízeních apod., je často nutné převést internetové aplikace pro tato zařízení a vhodně je graficky i technologicky optimalizovat. Zatím jsou aplikace pro tyto zařízení velice drahé a časově nákladné, ale je jen otázkou času, kdy se to díky vývojovým nástrojům a sílící konkurenci změní. Webové prezentace se tak moţná postupně změní na „mobilní“ prezentace běţně ovládané nejen dotyky ale i vzdálenými gesty sledovanými čidly (např. moţné rozšíření stávajícího Microsoft Kinect) či lidským hlasem. Vzhledem k další unifikaci se pak jiţ vypustí z kontextu i označení mobilní. Můţe se v budoucnu stát, ţe zprostředkování informací bude obstarávat nezávislý a komplexní informační celek. Tento systém by dokázal na základě své umělé inteligence sám vyhodnotit a zprostředkovat takové uţivatelské informace a nasimulovat individuální uţivatelské rozhraní, které by odvodil z uţivatelských vstupů ze sociálních sítí a dalších aktivit uţivatele.
52
7 Komunikace v týmu a nástroje Komunikace v týmu je naprostý základ pro úspěch kaţdého projektu. Od komunikace se odvíjejí další souvislosti. Komunikace můţe být prospěšná, ale také velmi škodlivá. Záleţí na účastnících komunikace a jejich přístupu k předávání dat. V dnešní době existuje mnoho komunikačních kanálů, díky kterým se dá komunikovat i na velké vzdálenosti bez citelné ztráty přenosové kvality. Jednotliví účastníci vývojového týmu tak mohu být z různých zemí i kontinentů.
7.1 Co je komunikace a proč je důleţitá? Existuje mnoho definic komunikace. Jednou z nich můţe být následující:39 „Komunikace je obousměrný proces, jak dosáhnout vzájemného porozumění. Účastníci komunikace si nejen vyměňují informace, ale také vytvářejí a sdílejí jejich význam“. Z definice vyplývá, ţe jedním z klíčových atributů komunikace jsou informace a účastníci komunikace. Informace jsou však následkem jiţ předchozího procesního zpracování, jak ukazuje následující obrázek 13.40
Obrázek 12: Zpracování informace
Na začátku sdělení se nacházejí data. Data mají určitou míru entropie. Aby data byla správně vyuţita, musí být transformována do informací. Tato transformace se nazývá capta (capture of data). Doslova se jedná o zachycení dat. Data jsou selektována v toku času. Následkem čehoţ je sniţována empirie dat, aţ do poţadovaného stavu, ve kterém se zcela exaktně nacházejí informace. Logickou interpretací se nabývají znalosti. Získané znalosti se dalším aplikováním s okolními podmínkami a analýzou získaných znalostí stávají v časovém intervalu moudrostí. Moudrost lze tedy definovat jako vhodně aplikované znalosti na základě zkušeností, které vyplývají z interpretace znalosti. Moudrost ale není jasně definovaným stavem. Důleţitost komunikace je zřejmá. Bez ní se nedá na jakémkoliv větším projektu pracovat, tak aby byl dodán v odpovídající kvalitě a termínu. Vedoucí pracovník i členové týmu musí umět mezi sebou komunikovat, sdělovat si své zkušenosti, společně řešit daný problém apod. 39 40
Communication. In: Business Dictionary Informační zahlcení. TARA-V-UH. Informatika 53
Bez komunikace by vládl informační chaos a nikdo by nevěděl v jakém stavu projekt je a co se musí ještě řešit. Také získání informací o stavu či technickém řešení projektu by bylo časově náročnější, nehledě na moţný špatný odhad na základě interpretace dat. Komunikace tak slouţí i k utřídění si a ověření vstupních dat mezi členy týmu.
7.2 Komunikace a její vývoj v pracovním týmu Správně nastavená a funkční komunikace v týmu je záleţitostí projektového manaţera. Manaţer musí umět vhodně se svými podřízenými komunikovat. Umět řešit konflikty v týmu a v případě nutnosti pouţít svoji autoritu. Komunikace by měla být účelná a vyuţívána přiměřeně. Jak jiţ bylo uvedeno, komunikace je základním stavebním kamenem pro fungování týmu. Komunikace probíhá různě dle typu pracovního týmu. Týmy mohou být následujícího typu: Nestrukturované týmy (dělba práce dle jejího objemu) Osamělí vlci. Horda. Demokratická skupina. Strukturované týmy (dělba práce dle profese) Chirurgický tým. Tým hlavního programátora. Vícetýmová organizace.41 Kaţdý tým má svůj vývoj a spolu s týmem se vyvíjí i jeho komunikace. Vývoj v týmu probíhá v jednotlivých fázích: 1. Formování – úvodní setkání vývojového týmu. Pracovníci se neznají a seznamují se mezi sebou navzájem i s danou úlohou. V této fázi převládá úzkost členů a nejistota z hlediska jejich úkolu ve skupině. Typickým znakem je počáteční orientace ve skupině. 2. Bouření – vyjednávání pozic v týmu, procesů komunikace a struktury. Jednotlivý členové se snaţí prosadit a docílit, aby skupina uspokojovala jejich osobní potřeby. Vznikají první konflikty. Typickým znakem je konflikt a emocionalita.
41
ŠIMERDA. Organizace pracovních týmů. In: Projektování Softwarových Systémů - UML 54
3. Normování – shoda na základních normách týmu. Snaha o překonání konfliktů. Vytváření společných hodnost a snaha o dosahování cílů a hodnot. Typickým znakem jsou soudrţnost a sdílená komunikace. 4. Optimální výkon – tým má nejvyšší výkon. Členové kooperativně pracují a dosahují společných cílů. Dílčí vztahy jsou stabilizovány a zaměřeny na prospěch celku. Typickým znakem je chování členů dle své role, produktivní řešení konfliktů, skupinová práce. 5. Ukončení – tým ukončuje svoji činnost. Členové se uvolňují ze svých sociálně-emocionálních vazeb a z aktivit zaměřených na činnost týmu.
7.3 Styl komunikace a vedení týmu V týmu musí být definovány jednotlivé role členů a jejich zodpovědnosti. Téţ musí být vyjasněny komunikační toky, jejich ověřování a reakce na ně. Pokud je to moţné, měl by si vedoucí manaţer určit sloţení svého vývojového týmu. Dle sloţení týmu a okolnostem v průběhu realizace projektu by měl vhodně volit i styl svého vedení. Autokratický styl – strohé příkazy, zákazy a nařízení. Jsou přesně dány pravidla pro fungování týmu. Styl zaloţený na silném autoritativním vedení týmu. Tým je pod stresem a napětím. Projevují se tendence v týmu zalíbit se nadřízenému. Tento styl vedení je nutný pro udrţení ochabující disciplíny, nebo pokud je tým v časovém ohroţení a je nutno prosadit další kroky silou. Liberální styl – v týmu vládne uvolněný styl, který má za následek chaos a anarchii. Tento styl je zejména patrný u firem s neformálním řízením, kde neexistuje či není dodrţována podniková hierarchie. Výkonnost týmu časem klesá a dochází k časovému prodlení a chybovosti. Z počátku spokojenost u podřízených se postupem času mění na nespokojenost. Nutnost řízení manaţerem, který má dostatečnou autoritu. Demokratický styl – styl zaloţený na vzájemné profesní i lidské úctě. Časté jsou názorové diskuze a vyjadřování vlastních názorů pracovníků v týmu. V diskuzích se hledá vzájemná shoda. Členové týmu jsou dostatečně motivování i morálně kvalitní jedinci. Manaţer jen zaujímá otevřený postoj a nechává dostatečnou míru volnosti v rozhodování svým podřízeným. Tento styl je ideálním.42 Manaţer by měl správně zvládat svoji komunikaci s podřízenými a měl by být jak profesním tak charakterovým vzorem. Důleţitá je verbální i neverbální komunikace se členy týmu. 42
PETŘÍKOVÁ, Jana. Malé sociální skupiny. In: Lide.uhk.cz 55
7.3.1 Verbální komunikace Jedná se o manaţerův mluvený projev. Zde je nutné dbát zejména na rétoriku, ale i na vhodnou volbu slov, jejich skladbu a srozumitelnost sdělení. Verbální komunikace je důleţitá neboť stejně jako psaný projev vyţaduje kaţdodenní pouţití. Na rozdíl od psané formy však tato komunikace vyţaduje schopnost rychle a pruţně reagovat. Musí být přiměřená situaci a působivá. Podřízený se musí cítit při verbální komunikaci dobře a byl tak ochoten komunikovat. Komunikace tak bude mít výsledný efekt pro manaţera i podřízeného. Důleţité také je potvrdit si vzájemně závěry z komunikace.
7.3.2 Neverbální komunikace Nazývá se téţ jako nonverbální, nebo mimoverbální komunikace. Její podstatou jsou gesta, charisma a ostatní mimoslovní chtěné či nechtěné aktivity při komunikaci. Manaţer musí působit přirozeně, cílevědomě a přitom uvolněně. Zvyšuje tak nonverbálně svou autoritu. Důleţité je mít gesta pod kontrolou a pouţívat je s rozmyslem. Kaţdý podřízený si je můţe vyloţit po svém. Zvládnutí neverbální komunikace je obtíţná disciplína, neboť je z velké části řízená podvědomě. Její zvládnutí můţe trvat i několik let. Zároveň je to však silný nástroj a měl by být vyuţíván s citem k dané situaci. Zkušený manaţer pouţívá kombinaci obou metod a pokud moţno přistupuje ke kaţdému podřízenému individuálně na základě zkušeností z předchozích jednání s dotyčným. Zároveň rozvíjí své komunikační dovednosti ve prospěch řízení celého projektu. Lze těţko posoudit, zda manaţer vede komunikaci správně. Správný manaţer by to měl umět rozpoznat a případně přijmout adekvátní opatření pro zlepšení komunikace.43
7.4 Nástroje pro týmovou komunikaci Pro týmovou komunikaci se vyuţívá několika nástrojů. Kaţdý takovýto komunikační nástroj je vhodný na různé účely dle svých parametrů a dle moţností vyuţití v momentální situaci. Komunikace v týmu můţe probíhat nejen verbální či neverbální formou, ale také formou písemnou. 1. Elektronická pošta Jedna z nejpouţívanější písemných forem komunikace. Také zde se musí pro komunikaci dodrţovat určitá pravidla.
43
HOŘICKÝ, Jakub. Komunikace jako přednost i slabina manaţerů. In: Mít vše hotovo 56
V případě více příjemců rozlišit primárního příjemce od ostatních příjemců, kteří mají být pouze informováni. Nečeká se od nich reakce, a proto je vhodné umístit je do kopie.
Předmět emailu by měl vystihovat podstatu sdělení v těle emailu.
Samotné sdělení v emailu má být strukturované, pokud moţno stručné a jasně pochopitelné pro druhou stranu. V případě pouţití zkratek je vhodné uvést jejich význam. Pokud je očekáváno seznámení příjemce se zprávou, nastaví se „potvrzení o přečtení“. Potvrzení samo o sobě nezaručí přečtení zprávy, ale slouţí spíše jako kontrolní mechanismus v komunikaci.
Důleţité je si při elektronické komunikaci potvrdit vzájemné pochopení problematiky sdělené v emailu. Některé sdělení můţe být pochopeno různými způsoby. Vyuţití elektronické pošty je velmi efektivní pro běţnou komunikaci v týmu. Pokud jsou přenášena větší data nebo detailnější informace k projektu, je vhodné zvolit jinou formu komunikace.
Vhodné
je
umístění
jednotlivých
příloh
emailových
zpráv
do centralizovaného úloţiště. 2. Instant messaging Komunikace slouţí pro psaní krátkých textů, kdy je potřeba znát určitý názor nebo stav věci. Existuje mnoho softwarových programů. Mezi nejpouţívanější patří Skype, ICQ, XMPP. Výhodou je rychlost komunikace. Odesílatel zřetelně identifikuje, ţe příjemce je online a tedy, ţe přijímá zprávy. Příjemce je navíc o zprávě ihned vizuálně informován. Instant messaging je vhodným nástrojem pro krátkou a rychlou komunikaci. Obsahově spíše méně zásadního charakteru. Důleţité projektové věci by se takto řešit neměly, ačkoliv existuje historie komunikace. Tato historie však není explicitní jako historie zpráv v emailové schránce. Jako doplněk komunikace lze tento typ komunikace doporučit. 3. Sdílení dokumentů V případě většího mnoţství dokumentů je vhodné zvolit centrální úloţiště, které poskytne dostatečně rychlé a zabezpečené zprostředkování poţadovaných dokumentů. Výhodou sdílení dokumentů je jejich aktuálnost a dostupnost pro vývojový tým. Kaţdý člen týmu vidí jednotlivé úpravy od ostatních vlastníků dokumentů. Dokumenty jsou navíc přístupné na jednom místě a nemusí se tedy sloţitě přeposílat. Mezi populární nástroje toho typu patří Google Docs, Dropbox apod. 57
8 Rizika internetových projektů Kaţdý projekt nese v sobě určitou míru rizika. Důleţité je riziko včas podchytit a reagovat na ně. Nejzávaţnější rizika resp. jejich dopad je u rizik, která nejsou predikována, ţe by mohla vůbec nastat. Neexistuje tak jejich popis ani proces řešení. Dalším nebezpečím je riziko, které nelze lidskou ani jakoukoliv jinou činností ovlivnit, lze jen utlumit jeho následek. Riziko však není nutno brát jako zlo. Je to přirozená součást kaţdého počínání. Je ovšem třeba s rizikem počítat vţdy a všude. V celém ţivotním cyklu projektu. Tento svědomitý a ostraţitý přístup je jedním z předpokladů, jak moţnému riziku čelit.
8.1 Co to je riziko? Riziko je označení pro určité ohroţení či ztrátu. Riziko můţe být definováno a chápáno mnoha způsoby. Jak můţe být riziko obsáhle, naznačují jeho moţné specifikace: Pravděpodobnost jakéhokoliv výsledku, odlišného od výsledku očekávaného. Situace,
kdy
kvantitativní
rozsah
určitého
jevu
podléhá
jistému
rozdělení
pravděpodobnosti. Variabilita moţných výsledků nebo nejistota jejich dosaţení. Moţnost, ţe specifická hrozba vyuţije specifickou zranitelnost systému. Nebezpečí chybného rozhodnutí. Obecně lze riziko definovat jako míru pravděpodobnosti, ţe nastane konkrétní jev, který se liší od předpokládané skutečnosti či vývoje. Riziko nelze popsat jen kvantifikačně. Důleţitý je popis rizika i ve vztahu k ostatním objektům, majícím s rizikem globálně-korelační základ. S rizikem souvisí pojem neurčitého výsledku, který můţe nastat. Jsou rozeznávány alespoň dvě varianty řešení. Jedna z variant je ve svém výsledku neţádoucí a je výsledkem neřízeného přístupu k riziku. Druhá varianta naopak s rizikem počítá a limitně se blíţí k výsledku ţádoucímu. Na riziko je nutno reagovat změnou. Pojem změna je tomto kontextu nutno chápat jako pozitivní či negativní odchylku od očekávaného výsledku. Je to v čase kontinuální a měnící se proces.44 Nelze však uvádět jen negativní stránky rizika. Určitá míra rizika můţe být pro projekt motivující. Zejména to platí pro zavádění nových produktů či sluţeb na trhu. V případě, ţe se 44
Co je to riziko a analýza rizik. In: BusinessInfo 58
očekávaná rizika neprojevila, je moţné získat konkurenční výhodu a dále ji rozvíjet. Riziko tak bylo pouze v rovině hypotetické. Překonání tohoto typu rizika je důkazem velkých zkušeností, znalostí, ale i jistou mírou odvahy. Riziko, jehoţ následky můţou být nad rovinu přijatelnosti, mohou zapříčinit v pozitivním smyslu, změny, které byly dávno odkládány a explicitně se projevily aţ následkem drtivého rizika. Nenastane-li poučení z chyby, můţe být další dopad mnohem horší a rizika ještě více nepodchytitelná. Důleţité je se z této situace poučit a v dalším procesu na tuto událost pamatovat a přijmout protiopatření. Dopady rizika tak nejsou jen negativní. Záleţí, jak jsou chápana a jak je s nimi dále naloţeno. Aţ potom je můţeme vyhodnotit jako negativní či pozitivní.
8.2 Moţné rozdělení rizik Rizika mohu nabývat různých podob v závislosti na doméně projektu a dalších okolnostech. Jejich dělení je proto moţné rozdělit dle mnoha různých atributů. Jedno z moţných dělení je rozdělení rizik na rizika známá a neznámá. Tedy dle moţnosti riziko poznat a reagovat na ně nebo naopak na rizika, jejíţ výskyt nemůţeme dopředu odhadnout. 1. Rizika známá Rizika, se kterými je moţno počítat. Jsou relativně dobře popsatelná a vyhodnotitelná. Mezi známá rizika je moţné uvést tyto:
Nedostatečné specifikace projektu.
Nestabilita členů týmu.
Chybná architektura systému.
Nevhodně zvolená kombinace softwaru a hardwaru.
Havárie hardware.
2. Rizika neznámá Předem nepředvídatelná a málo ovlivnitelná rizika. Většinou mají silný dopad na projekt. Neznámá rizika mohou obsahovat následující oblasti:
Ţivelná událost.
Legislativní změny.
Bankrot investora.
59
Neznámá rizika se zpravidla hodnotí navýšením finančního a časového plánu v rozmezí 10 aţ 20 %.45 Další moţné rozdělení rizik je dle situací, pozic vzhledem k hranicím systému, ve kterých mohou nastat apod. Rozdělení rizik do jednotlivých skupin se můţe prolínat s dalšími typy rozdělení rizik. Náhled na rizika lze definovat také z těchto dělících pohledů: 1. Komunikační rizika – rizika vyplývající z nedostatečné či podceněné komunikace v rámci projektového týmu i např. ve spojení se zákazníkem. 2. Sociální rizika – demotivovanost pracovníků, nedostatečná kvalifikace, chybné zvolení pracovníků, to vše patří do skupiny sociálních rizik. 3. Technologická rizika – ztráta dat či poškození funkčnosti systému z důvodů špatného zabezpečení nebo zvolení nevhodných technologických komponent či postupů. 4. Externí rizika – daňové a politické změny, ceny na trhu práce. 5. Interní rizika – špatně definována či chybějící podniková strategie podniku.46 Jak jiţ bylo zmíněno lze rizika rozdělit dle mnoha kriterií. Záleţí na typu projektu a potenciálních rizik s ním spojených. V kaţdém případě je však nutné mít moţná rizika vhodně rozdělena, popsána a mít připraveny variantní scénáře rizik a hrozeb.
8.3 Globální příčiny rizik Nejen v průběhu vývoje a implementace internetových aplikací lze obecně sledovat opravdu mnoho různých příčin rizik. Níţe bude uvedeno a popsáno alespoň několik z nich. Příčiny těchto rizik jsou společné jak pro internetové projekty, tak pro projekty, které jsou mimo internetové prostředí. Mnoho oblastí pro příčiny rizik však mají společné. Povrchní specifikace poţadavků Velmi časté a opakující se riziko. Jak má aplikace správně plnit svou roli, pokud nejsou specifikace systému důkladně popsány? Velmi těţko. Takto vyvinutý nebo zakoupený systém je zcela neefektivní. Dalšími vzrůstajícími náklady na provoz se systém jen prodraţuje, proto musí být na začátku jasně stanovené cíle, přínosy, způsoby vyhodnocení funkčnosti a další metriky, které jednoznačně budoucí systém specifikují.
Nejen podcenění specifikace má za následek následující čísla, které zveřejnilo ministerstvo obrany USA. Týká se projektů, které tento úřad zadal: o
1,5 % projektů bylo pouţito tak, jak byly dodány,
o
3 % projektů bylo pouţito po modifikacích,
o
29 % projektů bylo pouţito a opuštěno,
o
47,5 % projektů rezultovalo v tzv. shelfware (software objednaný, dodaný, ale nikdy nepouţitý),
o
29 % projektů skončilo tzv. vapourware (software objednaný, často i zaplacený, ale nikdy nedodaný nebo dokonce nenapsaný).
Tato čísla jsou aţ hrozivá, nicméně, odráţejí skutečnost. Podcenění specifikace IS je opravdu velké a závaţné riziko. Navíc je relativně časté, proto by mu měla být věnována značná pozornost. Vývoj aplikace bez jednotné koncepce Jsou-li stanoveny cíle i poţadavky na jednotlivé aplikace systému, není ještě zaručeno, ţe bude toto dodrţeno dle předpokladu. Rizikem je v tomto případě chybějící koncepce výstavby a rozvoje výsledného produktu. Bez jasné koncepce můţe nastat mnoho problémů, které mohou navíc v čase narůstat. Celý systém je pak pouze různě poskládaný nehomogenní celek bez logiky a očekávané transparentní funkčnosti. Postupně se můţe čím dál více rozpadat integrace dat v této aplikaci, nastat ztráta efektivity, komplikovanost údrţby či bezpečnostní rizika, nemluvě o sloţitosti dalšího vývoje pro vývojáře i pouţití pro koncové uţivatele. Nepruţná architektura systému Architektura aplikace musí být natolik pruţná, aby dokázala včas a za přiměřené náklady reagovat na poţadované změny či rozvoj. Statická a těţkopádná architektura systému se v dnešní době díky globalizaci stává brzdou rozvoje firemních plánů. Riziko podcenění architektury můţe mít za následek zastarávání cenných informací, které je nutné mít stále aktuální. Neaktuální data mohou zkreslovat informace o zákaznících, situaci na trhu, stavu konkurence apod. Dobře promyšlená a pruţně navrţená architektura aplikace dokáţe odpovídající formou eliminovat případná rizika vzniklá i relativně častými a rychlými změnami poţadovanými ze strany zadavatele. 61
Nedůsledné řízení projektu Znalosti a zkušenosti projektového manaţera, zodpovědného za úspěšnou realizaci projektu, jsou naprosto klíčové prvky, které dokáţou odbourat či sníţit mnohá rizika. Projektový manaţer musí téţ disponovat patřičnými pravomocemi, aby mohl moţné negativní okolnosti projektu ovlivnit. Měl by mít přirozenou autoritu, schopnost vyjednávání s podřízenými, zvládat stresové situace a mnoho dalších vlastností. Nezkušení manaţeři často chybují v odhadech časových, finančních i odhadu na potřebné kapacity lidských zdrojů. Neumí vhodnou formou vytknout, pochválit či motivovat své podřízené. Důleţitou vlastností, kterou přinesou aţ po delší dobu získávané zkušenosti, je umění předvídat moţný výskyt rizik v různých částích projektu. Takový projektový manaţer je pak velmi cenným firemním článkem, který firmě dokáţe ušetřit mnoho nečekaných finančních výdajů i zvýšit profesionální pověst firmy. Chybné odhady časové a finanční náročnosti Riziko spojené se špatným časovým odhadem, zejména u větších internetových projektů, je velmi časté. Málo projektů je dodáno v čas a v odpovídající kvalitě dle plánu. Důvodů můţe být hned několik: o
Malá angaţovanost vrcholového vedení podniku na realizaci projektu.
o
Neodpovídající kvalifikace projektového týmu vzhledem k náročnosti projektu.
o
Nedostatečně robustní pouţití modelovacích a vývojových nástrojů.
V rámci včasného dodání díla, které je navíc vázáno např. sankcemi za nedodrţení smluvních podmínek, je produkt často zhotovený s horší kvalitou kódu či přímo s bezpečnostními dírami. S chybným odhadem časové náročnosti přímo souvisí i stanovení finanční náročnosti projektu. Finanční stránka projektu můţe být podceněna nezkušeností projektového týmu nebo podhodnocena záměrnou snahou prosadit se cenou mezi konkurencí. Je pak na zváţení, jaká cena je ještě pro firmu únosná a zda přinese zprvu niţší cena další příjmy nebo je úvodní niţší cena jiţ nepřiměřené riziko. Časové i finanční plány je vhodné u velkých projektů dekomponovat na menší části a dle jejich specifikace určit následně časový resp. finanční odhad. K těmto odhadům existuje mnoho metodik a nástrojů. Výstupy z těchto pomůcek by měly slouţit jako doprovodné informace, neboť konečné posouzení náročnosti je na projektovém manaţerovi, který dokáţe posoudit i netechnické parametry související s doménou projektu. Jedním 62
z takových rizikových parametrů můţe být i nerozhodný zadavatel, často měnící své poţadavky apod. Chyby v odhadech provozních nároků Samotným provozem internetové aplikace teprve začíná hlavní ţivotní cyklus díla, kde se naplno projeví moţná rizika, která byly během analýz, vývoje a testování přehlédnuta. Provoz aplikace je časově dlouhodobou záleţitostí. Chybné odhady provozních nákladů mohu mít příčiny v těchto oblastech: o
Špatně definovaný odhad rozvoje softwaru vzhledem k narůstajícím uţivatelům a jejich poţadavkům.
o
Chybné odhady v uţivatelské zatíţitelnosti systému.
o
Podceněný nárůst datových bází v relativně krátkém čase.
o
Špatně přidělená uţivatelská práva a z nich vyplívající nutně větší podpora pro systém.
o
Nesprávně odhadnutý poţadavky na aplikace a jejich grafické zpracování a výkon vzhledem k rychlému vývoji trendů v IT.
o
Nedostatečně specifikovaná distribuce výpočetních a datových zdrojů.
Vzhledem k moţným rizikům během provozu díla, by měly být podmínky provozu ve všech jeho souvislostech definovány v servisní smlouvě o úrovni poskytovaných sluţeb tzv. SLA (Service Level Agreement). V SLA by měl být co nejpřesněji definován rozsah sluţeb, jejich úroveň a časová intenzita. Touto smlouvou se mohou pokrýt jednotlivá úskalí provozu systému mezi zadavatelem a dodavatelem a omezit tak i komunikační rizika. Zahlcení vývojového týmu Nemá-li vývoj aplikace vyhrazenou prioritu, která má přednost před ostatními projekty, můţe se stát, ţe vývojoví pracovníci budou zahlceni ostatními projekty. Tím dojde ke ztrátě koncentrace na jasný cíl a také se zvýší na riziko opoţdění realizace a předání díla zadavateli. V určení priority projektu se bere v úvahu jeho rozsáhlost, finanční přínos či důleţitost zadavatele. Projektový manaţer musí pro své podřízené připravit takové podmínky, aby v maximální míře umoţnily kvalitní a pokud moţno ničím jiným nerušený vývoj aplikace.
63
Chybně sestavený vývojový tým Toto riziko můţe být výsledkem nezkušenosti projektového manaţera, který dostatečně předem neodhadl jednotlivé kvalifikační předpoklady u pracovníků, nebo nejsou dostatečné kapacity a výběr je tak omezen na pracovníky s menší kvalifikací. Můţe se však stát, ţe vývojový tým je sestaven ze špičkových odborníků, ale uvnitř tohoto týmu neprobíhá dostatečně kvalitní komunikace nebo existuje jakýsi konkurenční boj. Tým nevystupuje jako jednotný celek, ale spíše jako soubor individuálních jedinců, kteří spolu nespolupracují. Dobře fungující a dostatečně komunikující tým je jedním z předpokladů pro úspěch. Nedostatečný přehled o stavu projektu Projektový manaţer zodpovídající za bezproblémový vývoj aplikace musí mít vţdy přehled o aktuálním stavu projektu. Stav projektu lze snadno zjistit při pravidelné komunikaci s podřízenými, vizuální kontrolou stavu aplikace nebo obdrţením reportů o stavu. Je však doporučeno se na reporty příliš nespoléhat a brát je spíše jako rámcové. Nejlépe je ověřit si skutečný stav projektu prakticky a osobně. Manaţer projektu také musí předvídat i další vývojový stav v projektu a být na něj připraven. Je však dobré mít stálé povědomí i o celé historii projektu jiţ od jeho vzniku. Pokud manaţer nemá o reálném stavu projektu dostatečné povědomí, hrozí, ţe projekt se nebude ubírat podle plánu. Následkem této hrozby je nesplnění termínu, zvýšení nákladů a nespokojenost zadavatele. To můţe mít pro firmu i fatální důsledek. Navíc je důleţité mít přehled o projektu i z důvodů komunikace se zadavatelem zvláště, kdyţ můţe kdykoliv nahlédnout do vývoje projektu a informovat se na jeho progresi. I v případě, ţe si zadavatel nevyţádá informace o průběhu projektu je doporučeno zaslat alespoň stručné informace o stavu a být tak se zadavatelem v kontaktu a projevit iniciativu.47
8.4 Proces řízení rizik Proces řízení rizik, označovaného také jako risk management, by měl být nedílnou součástí kaţdého důsledně řízeného projektu. Řízení rizik je kontinuální a opakující se proces vhodně implementovaný do projektového řízení. Mezi základní sloţky procesního řízení rizik patří:
47
VOŘÍŠEK, Jiří. Kritické faktory úspěchu a rizika informačních systémů. In: VŠE Praha - katedra informačních technologií 64
1. Identifikace rizik Základní předpoklad identifikace rizik spočívá v mnohdy netriviálním určení rizik, která mohu projekt ovlivnit. Takto určená rizika je nutné popsat a zdokumentovat tak jejich charakteristiky. Zdrojem pro identifikaci rizik mohou být výsledky minulých analogických projektů, brainstorming v rámci projektového týmu, analýza s vývojáři. Důleţité je včas moţná rizika identifikovat a pokračovat v této identifikaci i nadále a na všech úrovních projektu. 2. Ohodnocení rizik Posouzení a ohodnocení rizik je subjektivní činnost, která souvisí s vyhodnocováním rizik. Oborem činnosti je tedy určení rizikových událostí, na které bude třeba reagovat. Ohodnocení rizika je ovlivněno řadou dalších faktorů, neboť jednotlivá rizika mohou být mezi sebou provázána a ovlivňovat proměnnou formou další rizika. Při analýze rizik se hodnotí zejména následující oblasti:
Pravděpodobnost vzniku rizika.
Potenciální dopad rizika na projekt.
Závaţnost rizika.
Časový interval, kdy se riziko můţe objevit.
Po analýze se rizika setřídí hierarchicky dle závaţnosti. Těm nejzávaţnějším by měla být věnována největší pozornost spolu s rozborem jejich dalších potenciálních souvislostí v projektových fázích. Doporučeným pomocníkem při takovém třídění závaţnosti je tzv. matice rizik. V matici resp. tabulce je zaznamenána pravděpodobnost výskytu, škodlivost dopadu apod. 3. Strategie zvládnutí rizik Strategie obsahuje vypracované plány různých variant řešení, která jsou přiřazena jednotlivým zodpovědným osobám. Probíhá soustavná kontrola tohoto plánu. Kaţdé riziko je moţné řešit několika různými způsoby. Jako nejvhodnější způsob řešení se jeví samozřejmě prevence před riziky. Rizikům je tak včas předcházeno. V případě, ţe k rizikům přesto dojde, je moţné je dle plánu eliminovat a dopad rizika na projekt tak můţe být minimální. Rizika vţdy ovlivňují více faktorů projektu, proto je vhodné v projektu s riziky takto počítat a vytvořit si v daných oblastech příslušné rezervy (např. upravit časový či finanční plán). Při zvolení strategického zvládnutí rizik hraje roli zejména fáze projektu, velikost, dostupnost zdrojů, časová naléhavost, uspokojení 65
zadavatele. Je však nutno pamatovat, ţe vţdy mohou nastat rizika, která jsou mimo kontrolu. 4. Monitorování rizik Plán protirizikových opatření musí být stále monitorován a vyhodnocován. Je to nutné z důvodu moţnosti vzniku dosud nepopsaného rizika. Pokud tato situace nastane, je doporučeno opakovat základní cyklus: identifikace, ohodnocení a zvládnutí rizika. Při identifikaci nových rizik je nutné přehodnotit strategii a zvládání rizik společně s aktualizací dokumentace rizik a souvisejících plánů. Projektový manaţer pravidelně konzultuje plán rizik se svým projektovým týmem, zadavatelem a dalšími procesními sloţkami projektu.48
8.5 Detailní analýza rizik Ohodnocení resp. analýza rizik patří mezi nejsloţitější disciplíny v risk managementu. Navazuje bezprostředně na identifikaci rizik. Kvalitně provedená analýza dokáţe rizika detailně popsat a vyhodnotit. Následkem toho se můţe s riziky dále pracovat a zhotovit pro ně potřebné strategické plány. Analýza rizik můţe probíhat v uzavřeném kruhu po navazujících fázích, jako je znárodněno na obrázku 14 níţe.49
LOSKÁ, Šárka a Petra KUBÁLKOVÁ. Řízení projektových rizik. In: Ikaros KVASNIČKA, Jan. Analýza rizik internetového projektu. In: IInvest 66
Atributy kruhu: Aktivum – prvek projektu, který má pro něj určitou hodnotu a je proto vhodné, aby byl dostatečně chráněn. Hrozba – definuje situaci, která můţe narušit dostupnost, integritu aktiva. Zranitelnost – jedná se o slabou část aktiva, která můţe být ohroţena hrozbou. Riziko – pravděpodobnost, ţe zranitelnost aktiva bude hrozbou vyuţita. Opatření – cílem opatření je sníţit zranitelnost a chránit aktivum před případnou hrozbou. Na začátku kruhu existuje důleţitý prvek projektu, zvaný aktivum, který je nutno chránit, neboť je ohroţen hrozbou. Hrozba dokáţe zneuţít zranitelnost aktiva, čímţ dojde k ohroţení, které představuje riziko. Musí se proto pouţít taková opatření, jeţ zmírňující dopad rizika a chrání tak aktivum. Důleţité je také si uvědomit, ţe jedna hrozba můţe mít za následek více rizik. Hrozba vyuţívá zranitelnosti aktiva, ale není to ještě riziko. Teprve, kdyţ je zranitelnosti vyuţito, dochází k ohroţení, resp. vzniku rizika.50 K provedení analýzy rizik můţeme přistupovat dle několika způsobů: Základní přístup – neprovádí se ţádná analýza rizik. Vybere se a následně implementuje jen vzorová základní sada opatření. Neformální přístup – tento postup je charakteristický svým věcným a rychlým přístupem. Provádí se orientační analýza rizik, která jsou zaloţená na zkušenostech expertů v projektovém týmu s následným vyhodnocením moţných hrozeb. Formální přístup – filosofie toho postupu je v pečlivé a detailní analýze rizik. Provádí se hodnocení aktiv, hrozeb a zranitelností. Často se vyuţívají sofistikované modely a nástroje na bázi matematických výpočtů. Kombinovaný přístup – dle orientační analýzy rizik, kdy byla jasně identifikována kritická aktiva či procesy, se následně provede detailní analýza rizik. Je-li projekt značně rozsáhlý a komplexní, je vhodné analýzu rizik pojmout také jako projekt. Jak bylo jiţ uvedeno, analýza rizik má analogicky k projektu své fáze. Z pohledu projektového řízení se mohou tyto fáze nazvat i jako milníky.51
Na základě identifikace resp. analýzy vzniku rizik, která byla odvozena např. expertními znalostmi, analýzou příčin a následků, SWOT analýzou, či Ishikawovým diagramem se musí tato data také vhodně sestavit a popsat. Analyticky popsaná rizika je doporučeno pro větší názornost zaznamenat do tabulky (matice). Tabulka můţe obsahovat mnoho atributů, které popisují jednotlivá rizika. V níţe uvedené tabulce 2 jsou rizika popsána dle kategorie výskytu, pravděpodobnosti vzniku, dopadu a jejich stručného řešení.52 S touto tabulkou je moţno v průběhu projektu dále pracovat a upřesňovat ji v závislosti na nově vzniklých rizicích v čase. Její aktualizace se stanovuje dle specifikace projektu.53
Jsou-li známy hodnoty aktiv, stanoveny pravděpodobnosti hrozeb a míry zranitelnosti, je moţno vyjádřit rizika. V případě, ţe byla provedena kvantitativní analýza rizik, vyjádří se
51
Analýza rizik: Jemný úvod do analýzy rizik. In: Clever and Smart KVASNIČKA, Jan. Analýza rizik internetového projektu. In: IInvest 53 Seznam a řízení rizik. In: Projectman 68 52
výše rizika v peněţních jednotkách. Pokud byla provedena analýza rizik kvalitativní, pak se vyjádří hodnota rizika ve stupních.54 Kvantitativní analýza rizik Kvantitativní analýza spočívá v náročném úkolu v podobě vyjádření hodnot aktiva po finanční stránce. Je proto náročnější na zdroje a trvá déle neţ kvalitativní analýza. V peněţních částkách vyjadřuje i moţnou škodu v případě realizace hrozby. Takto vyjádřené hrozby však usnadňují rozhodování ve fázi zvládání rizik, neboť se pod nimi skrývají konkrétní finanční částky. Snadno tak lze porovnat moţnou výši škody oproti výši protiopatření. Kvalitativní analýza rizik Aktiva u této analýzy není třeba vyhodnocovat v peněţních částkách. Je tedy méně náročná na zdroje. To má však za následek horší kontrolu nákladů ve fázi zvládání rizik, kdy se vybírají vhodná protiopatření. Tato analýza slouţí spíše pro rychlé zhodnocení a určení rizika. Poté je moţno rizika detailně zkoumat. Pro detailní analýzu se vyuţívá kvantitativní metodika. Obě metodiky tak nestojí proti sobě, ale doplňují se v jednotlivých analytických fázích. Nelze také zapomínat, ţe to jsou pouze metodiky a reálné výsledky mohu být od výsledků metodik i značně vzdálené. Některé výhody a nevýhody obou metodik popisuje následující tabulka 3.55 Kvantitativní analýza
Kvalitativní analýza
Výhody
Výhody
+ lepší kontrola nákladů + časově nenáročná + poměrně přesná
+ celkově levnější
Nevýhody
Nevýhody
- časově velice náročná
- horší kontrola nákladů
- celkově draţší
- méně přesná
Tabulka 3: Kvantitativní vs. kvalitativní analýza rizik, (zdroj: Analýza rizik: kvantitativní vs. kvalitativní. In: Clever and Smart)
54 55
Analýza rizik: Jemný úvod do analýzy rizik. In: Clever and Smart Analýza rizik: kvantitativní vs. kvalitativní. In: Clever and Smart 69
8.6 Bezpečnostní rizika v internetových projektech Kaţdá významnější a rozsáhlejší internetová aplikace se můţe stát cílem útoku. Jelikoţ je internetová aplikace závislá nejen na kvalitě a bezpečnosti zdrojového kódu, ale i na samotném hardwaru, na kterém běţí, je o to náročnější celý systém zabezpečit. Server je nutné mít pravidelně aktualizovaný, vyhodnocovat jeho síťový provoz apod. Svou hlavní úlohu zde hraje přístup a znalosti administrátorů serveru, na kterém aplikace běţí. Tento lidský faktor je nejrizikovější. Útoky jsou stále cílenější a propracovanější jak po technické stránce, tak organizační. Nezřídka jsou útočníci špičkoví profesionálové, kteří jsou systematicky vedení. Čím je cíl zajímavější pro svá cenná data, všeobecnou známost či proklamovanou bezpečnost, tím je cíl pro útočníky lákavější. Bezvýznamné či malé aplikace jsou relativně v bezpečí. Mohou být napadeny či zneuţity spíše pro různá bezpečnostní testování a varianty útoku. Administrátoři takových webů útok zpravidla nezaznamenají ani za několik měsíců. Z pragmatického hlediska se napadení takových webů z časových resp. finančních důvodů nevyplatí. Některé útoky jsou v současné době opravdu velkého rozsahu. Měřítko útoků můţe být takřka mezinárodní, neboť na pozadí za některými útoky můţe být i konkrétní stát. Aplikaci je moţno napadnout různými typy útoků a jejich kombinacemi. Níţe jsou uvedeny základní druhy útoků. D.o.S Název D.o.S je zkratka pro Denial of Service (odepření sluţby). Tento typ útoku má za následek znepřístupnění či narušení dostupnosti cílového serveru resp. sluţby. Útoky D.o.S stojí firmy ročně statisíce dolarů. Analýzy a nápravy systémů jsou velmi pracné a drahé. Nedostupnost sluţby pro zákazníky tvoří také nezanedbatelnou ztrátu. D.o.S. útoky přitom svojí podstatou nejsou nijak sloţité ani technicky náročné. Nástroje pro D.o.S útok jsou volně dostupné. D.o.S útoky narušují činnost systému z vnějšku. Nepronikají tedy systémem dovnitř, coţ je zdlouhavější a rizikovější proces na odhalení, zejména u vysoce zabezpečených systémů. Při návrhu protokolů TCP/IP nebylo počítáno s jejich zabezpečením. I přes svůj vývoj mají protokoly mnoho bezpečnostních trhlin.56
56
Útok D.o.S. In: KITAMGELF_. SOOM 70
SQL injection SQL injection je technika napadení databázového systému přes webové rozhraní. Pokud není ošetřen uţivatelský vstup např. přes formuláře, lze jednoduchým způsobem získat přístup do administrační části systému nebo ovlivnit uloţená data v útočníkův prospěch. Útok spočívá v podvrţení SQL dotazu do databáze. Podvrţený dotaz by mohl vypadat např. takto: select count(*) from users where userName='john' and userPass='' or 1=1'
Tento dotaz vyhledá uţivatele se jménem john a místo kontroly vloţeného hesla, je nyní heslo porovnáno s prázdným řetězcem nebo vyhodnoceno na podmínku rovnosti 1=1. Bez ošetření uţivatelských dat je toto vyhodnoceno jako pravda a útočník má cestu otevřenou. Důleţité je uţivatelským vstupům zásadně nevěřit a mít je plně ve zdrojovém kódu ochráněny patřičnými technikami.57 XSS Cross-site scripting (označovaný také jako CSS) vyuţívá nedostatečné zabezpečení ve webových aplikacích. Díky této nezabezpečené chybě je do aplikace moţno vloţit škodlivý kód. XSS je moţno pouţít např. u webové aplikace, která obsahuje vyhledávání. Po kliknutí na vyhledávací tlačítko se odešle serveru řetězec přes parametr GET. Ukázka části URL po odeslání: /vyhledat.php?najdi=hledany_text
Server poté pošle klientovi stránku s hledaným textem. Do neošetřené proměnné „najdi“ je moţno vloţit i tento kód: /vyhledat.php?najdi=<script>alert(123);
Jako odpověď serveru bude stránka, kde se nachází javascriptový kód. Do dotazu lze samozřejmě vloţit i útočníkův kód z příslušné adresy přes element „src“, který se následně vykoná.58 Útoků existuje velké mnoţství, přes útoky hrubou silou (opakované dotazování na server s obrovským mnoţstvím kombinací znaků), aţ po vysoce sofistikované útoky v kombinaci s dalšími technikami průniku přes TCP/IP protokoly.
Systém je zranitelný tak, jako je zranitelná jeho nejslabší část. Mnoho rizik webových aplikací spočívá v uţivatelích, kteří nepouţívají dostatečně silné hesla nebo hesla pravidelně nemění. Heslo lze od neopatrného uţivatele relativně snadno vylákat. Často je vyuţíváno k tomuto účelu sociálního inţenýrství. Vyuţívá naivity a nezkušenosti uţivatele na základě seriózně znějícího poţadavku o sdělení osobního údaje. Kaţdopádně je důleţité věnovat bezpečnosti aplikace tu nejvyšší moţnou pozornost spolu s výběrem a proškolením uţivatelů systému. Rozpočet na projekt by měl brát i úvahu náklady spojené s jeho zabezpečením a důkladným otestováním na moţné typy útoků. Dobře zabezpečená aplikace vzbuzuje důvěryhodnost a uţivatel očekává, ţe jeho data budou v bezpečí.
8.7 Zákazník jako rizikový faktor Zákazník vystupující často jako zadavatel i investor má jistě svůj velký podíl, jestli jeho podnikatelský záměr bude realizován v daném termínu a při stanoveném rozpočtu. Můţe se však také stát, ţe samotný projekt zůstane jen v rámci záměru, neboť zákazník nedovede srozumitelnou a jasnou formou formulovat své myšlenky a vize dále. Komunikace je velmi důleţitý faktor mezi zákazníkem a dodavatelem díla. Obě strany by měly mluvit „stejnou řečí“ a jednotlivé kroky či změny na projektu si vzájemně potvrdit a odsouhlasit. Dalším rizikovým prvkem u zákazníka můţe být nedostatek rozpočtu na projekt. Zákazník často „tlačí“ na nízkou cenu či jiné výhody. Projektový manaţer však musí tento tlak ustát a nastavit jiţ v úvodu komunikaci se zákazníkem tak, aby nebyl otrokem zákazníka a neustupoval mu. Samozřejmě je důleţité, aby byl zákazník uspokojen, ale v kontextu s tím, jakou hodnotu zákazník přinese dodavateli. Internetový projekt, resp. jeho vývoj by měl být plně v reţii dodavatele. Zákazník se však často domnívá, ţe návrhu a technickému řešení rozumí sám nejlépe a není schopen přijímat protiargumenty. Dodavatel tak musí zákazníkovi patřičně a objektivně vysvětlit, ţe toto není v jeho pravomoci a měl by si nechat poradit. Mnohdy je tak ohroţen velmi nadějný projekt. Velmi rizikové jsou i změny ze strany zákazníka. Kdy i přes písemně potvrzenou komunikaci se opět jeho poţadavky změní a vše je jinak. Navrhuje se tak nové rozloţení prezentace a následně i grafická část. Vše je ale opět nutno koordinovat a zákazníka upozornit, ţe ho tyto změny budou stát nemalé peníze. Důleţitým argument je i časový rámec, kdy změny jsou moţné jen částečně, jinak hrozí ohroţení celého harmonogramu. Zavádí-li se nový produkt či sluţba na trhu, je dobré sestavit prototypový model. Ovšem do určité míry detailnosti. Lpění ze strany zákazníka na maličkostech v rámci prototypu jsou 72
pro něj vyhozené peníze. Často je toto pochopeno u zákazníka aţ s odstupem času a s ohledem na proinvestované peníze pouze do prototypu. Projekt můţe mít ideální průběh aţ do doby, kdy zákazník ztrácí motivaci pro projekt v podobě dalších investic či svého času. To je velmi silné riziko a je ho moţno podchytit jen zkušenostmi projektového manaţera a nastavením fakturačního plánu. V případě, ţe je projekt jiţ dopředu známý či odhadnutelný jako rizikový je vhodné nastavit zálohové platby v takové výši před startem projektu, aby dodavatel byl dostatečně zabezpečen proti těmto rizikovým zákazníkům. Na straně zákazníka je také riziko v podobě zásahů dalších osob do jeho rozhodování. Co schválí zákazník, nemusí schválit jeho partner, i kdyţ má v projektu vedlejší roli, ale zákazník se řídí jeho radami. Opět toto riziko souvisí s přesně definovanou komunikací a stanovením rozhodovacích pravomocí na straně zákazníka. Kdo a za co ze strany zákazníka zodpovídá, je nutné mít podchyceno co nejdříve. Ideálně před začátkem projektu. Jak jiţ bylo uvedeno, jiţ na začátku je důleţité si stanovit se zákazníkem jasná pravidla hry a informovat zákazníka jaká je jeho role. Zákazník má plné právo do projektu zasáhnout, ovšem svou roli hrají okolnosti v podobě fáze projektu a oblast, ve které chce zákazník uplatnit své slovo. Zákazník můţe být velmi rizikovým faktorem projektu nebo naopak jeho velmi cenným prkem. Předem a s určitou pravděpodobností se to mnohdy určuje těţko. Pokud je moţnost, je vhodné začít se zákazníkem řešit menší projekt, na kterém se případná komunikační a další rizika spojená se zákazníkem mohou projevit a připravit se tak na ně v dalším větším projektu. V případě, ţe se projeví opravdu závaţné nedostatky jiţ během „testovacího“ projektu, nemá smysl s daným zákazníkem realizovat další projekt.
73
9 Vhodné formy propagace Bez kvalitní e-marketingové podpory a propagace na internetu, nemá webový projekt po svém spuštění příliš nadějí se zviditelnit a upoutat ţádoucí pozornost svých budoucích zákazníků a uţivatelů. Investice do webové prezentace jsou pouze prvotní náklady. Ty mnohem větší teprve čekají a nezřídka provázejí projekt velmi dlouho. Je proto vhodné na to pamatovat a své investice nevloţit pouze do webové prezentace.
9.1 Rozvoj a výhody internetového marketingu První reklama se na internetu objevila v roce 1994. S postupným rozmachem internetu si někteří manaţeři začali uvědomovat význam internetové reklamy jako plošně cíleného média s relativně nízkými náklady. Firmy se postupně začaly na internetu více prezentovat a chtěly být více viditelní. Internetová reklama byla dlouho dobu omezena kvůli technickým moţnostem. Připojení k internetu bylo drahé a rychlost připojení nebyla velká. Datová velikost reklamy byla omezená stejně jako technologie pro její výrobu. Postupem času se však všechny tyto okolnosti změnily k lepšímu. V současné době se jiţ internetový marketing v technologicky vyspělých zemích stal významnější neţ klasický marketing. Jeho větší význam je zejména v účinnosti. Internetový marketing má mnoho výhod. Monitoring a měření dat – jsou k dispozici přesné nástroje pro sběr i analýzu dat dle různých kriterií. Dle těchto dat lze přesněji cílit i měřit úspěšnost reklamy. Dostupnost – reklama na internetu je k dispozici nepřetrţitě. Je nezávislá na dnech či denní době. Komplexnost – komunikačním mixem (bannery, newsletttery, PPC, …) je moţné potenciální zákazníky oslovit různými způsoby. Cílení – reklamu je moţné cílit na jednotlivé regiony, pohlaví a věk (zejména na sociálních sítích) nebo dle oborů zájmů cílové skupiny. Dynamický obsah – nabídku reklamy lze neustále dynamicky měnit dle potřeby. Další výhodou internetového marketingu je ve způsobech komunikace se zákazníkem. Pro tuto komunikaci je moţno vyuţít firemní www stránky, eshopy, blogy, sociální sítě, online dotazníky apod. Cílem této komunikace by mělo být zjišťování reakcí od uţivatelů. Na základě zákaznické odezvy lze velmi efektivně přizpůsobit nabízený sortiment. Vhodné sníţení ceny, rozšíření sortimentu, soutěţe, to vše můţe být součástí kvalitativně řízeného 74
vztahu se zákazníky vedoucímu k většímu zisku a zákaznické spokojenosti. Cílů marketingové komunikace můţe být několik oblastí. Můţe se pouze informovat o značce. Progresivnější formou se můţe cílová skupina ovlivnit a přimět k akci. V internetovém marketingu se jedná o konverzi. Konverze je předpokládaná akce na základě vytvoření vstupních podmínek. Pokud je jiţ konverze učiněna (např. nákup v eshopu), je další důleţitý cíl v udrţení vztahu se zákazníkem. K tomu slouţí zasílání novinek emailem, speciální slevové akce, věrnostní program apod. Budování zákaznické důvěry patří v internetovém marketingu k nejnáročnější disciplíně. Tato důvěra však také musí mít reálné základy v podobě kvalitního produktu či sluţby.59
9.2 Proč je propagace na internetu důleţitá? Neustále vznikající další konkurenční webové stránky, SEM (Search Engine Marketing) kampaně, profesionální SEO (Search Engine Optimization) optimalizace pro vyhledávače, kdy rozhodují o pozicích ve vyhledávačích takřka maličkosti, je nutné zapojit do propagace nejlépe všechny dostupné e-marketingové nástroje a moţnosti. Skloubit je do jednoho strategicky naplánovaného celku a spustit. Strategie je velmi důleţitá a neměla by se podceňovat, jak to ale mnohdy bývá. Klient by rozhodně měl za své investice dostat maximum. Je však také pravdou, ţe někdy má klient nereálné poţadavky na návratnost investic, proto je vhodné si vše vyjasnit ještě před počátkem kampaně. Reklama se stává díky sociálním sítím na internetu stále více cílenou na jednotlivé skupiny uţivatelů dle jejich potřeb, coţ usnadňuje strategii i cíle propagace. Mezi důleţité body propagace, na které se často zapomíná, patří zejména tyto: Cíl reklamy Od stanovení cíle e-marketingové kampaně se odvíjí vše ostatní. Cíl musí být přesně stanoven. Na základě cíle se stanovují ostatní prvky propagace. Cíl musí být jasně a srozumitelně formulován. Pokud cíl neexistuje, jedná se o plýtvání penězi, které by se daly vyuţít v jiném ţivotním cyklu projektu. S definicí cílů se pak snadněji odvozuje strategie a další důleţité atributy. Metriky reklamy Pro zhodnocení výsledků, zda bylo cíle dosaţeno či nikoliv slouţí metriky. Metrikou můţe být např. předpoklad konverzního poměru mezi návštěvou stránky a poţadovanou akcí na stránce. Dále to můţe být celková návštěvnost, zpětná odezva na sociálních sítích 59
JANOUCH, Viktor. Internetový marketing: prosaďte se na webu a sociálních sítích, s. 15. 75
apod. Analytické nástroje, které slouţí k vyhodnocení internetové reklamy, jsou velmi sofistikované a dokáţou sledovat mnoho parametrů. Pro identifikace zdrojů návštěv se pouţívá tzv. UTM (Urchen Tracking Module) kód. Tento kód se pouţívá v reklamních odkazech, které chceme sledovat. Kód se píše za otazník v URL adrese reklamy a přesně identifikuje zdrojové médium. UTM kód můţe vypadat například takto: www.miton.cz/?utm_source=slevomat.cz&utm_medium=banner300x300
K růběţné analýze návštěvnosti, klíčových slov vyhledávání, toku návštěvníků na stránkách a ke sledování mnoha dalších ukazatelů slouţí oblíbený a volně dostupný Google Anylics. Do stránek se vloţí automaticky vygenerovaný kód se speciálním identifikátorem. Ostatní sledované procesy (např. placené kampaně) se pak snadno nastaví v uţivatelském rozhraní. Načasování reklamy Pokud má být kampaň nasazena s cílem zasáhnout co nejvíce uţivatelů, je nutno nasadit několik technik propagace a zvolit správné načasování při jejich spouštění. Záleţí na celkové době realizace kampaně. Pokud má být krátká (horizont několika dní), kombinuje se zpravidla současné nasazení bannerové kampaně, zasílání newsletteru spolu s uveřejněním PR článků apod. V případě delší kampaně (týdny a více) se nasazují propagační prvky postupně a mají pozvolna stupňující se charakter nasazování. Někdy i správně zvolené dny dokáţou rozhodnout o úspěchu či neúspěchu. Záleţí zde ovšem na typu produktu, cílové skupině a dalších mnoha okolnostech. Správné načasování souvisí pochopitelně nejen s promyšleným harmonogramem kampaně, ale i s ročním obdobím a v nich se projevujících trendech v daném odvětví.
9.3 Moţnosti a typy propagace SEO optimalizace Mezi přirozenou formu propagace, dá-li se to tak nazvat, patří SEO optimalizace pro vyhledávače. Správně navrhnutá a aplikovaná optimalizace na klíčová slova pomůţe zajistit přední pozice ve výsledcích vyhledávání. V současné době pracují vyhledávače (u nás např. Google a Seznam) přibliţně aţ s 200 faktory ve svém algoritmu, které ovlivňují pozici ve vyhledávání tzv. SERPu (Search engine results page). Algoritmus hodnocení se neustále zpřesňuje a mění, aby se zabránilo nekalým optimalizačním praktikám a jednotlivé weby se hodnotily co nejdůvěryhodněji. 76
Některé hlavní prvky, které mají přímý vliv na hodnocení stránek: Titulek stránky – titulek by měl v sobě obsahovat klíčové slovo. Doporučuje se hned na začátku. Toto klíčové slov se také zvýrazní ve výsledcích hledání. Nadpisy – na stránce musí být pouze jeden nadpis úrovně H1 a měl by také obsahovat klíčové slovo. Ostatní nadpisy H2 , H3 atd. nejsou pro SEO tak důleţité, ale je vhodné pomocí nich strukturovat další obsah na stránce. Klíčová slova v textu – procento klíčových slov by mělo tvořit kolem 5% celkového textu. Doporučeno je klíčový text zvýraznit tučně či kurzívou. Klíčová slova v textu by měla být také pouţita v odkazech do vnořených struktur webu. Zpětné odkazy – všechny předchozí atributy patřily do tzv. on-page faktorů a týkaly se pouze přímé editace obsahu stránek. Zpětné odkazy naopak se stránkami přímo nesouvisí a patří mezi tzv. off-page faktory, tj. faktory, které ovlivňují pozice ve vyhledávání mimo stránky. Čím více kvalitních zpětných odkazů z jiných externích stránek na daný web cílí, tím lépe. Kvalitu zpětných odkazů hodnotí tzv. PageRank. Tímto hodnocením se vyjadřuje význam a kvalita stránek resp. jejich popularita. Důleţitý je také pozvolný (přirozený) nárůst zpětných odkazů. Velmi důleţité je zváţit do jakých katalogů zpětné odkazy přidávat. Některé katalogy mohou mít zakázanou indexaci nebo nemusí odkazovat přímo na vloţenou stránku, ale jen pomocí méně vhodného přesměrování.60 Zkušené firmy věnující se SEO optimalizaci mají své odzkoušené kolekce katalogů dle zaměření stránek určených k optimalizaci. SEO optimalizace se obvykle provádí průběţně po celou dobu existence prezentace a upravuje se dle analýz vyhledávání. Je to poměrně nákladná a dlouhodobá záleţitost. Efekt není ihned patrný, ale je o to stálejší, pokud je optimalizace kvalitní a vhodně rozvíjena. Při SEO optimalizaci by však nemělo zapomínat na návštěvníky stránek. Je-li text dobře optimalizovaný pro vyhledávače, ale špatně čitelný pro uţivatele, je výsledný přínos optimalizace minimální. Copywriting Jedná se o jednu z nejdůleţitějších praktik internetového marketingu. Kvůli zajímavým a dobře čtivým informacím se návštěvníci na stránky rádi vracejí a sdílejí své poznatky 60
KUBÍČEK, Michal a Jan LINHART. 333 tipů a triků pro SEO: [sbírka nejlepších technik optimalizace webů pro vyhledávače], s. 124. 77
s ostatními. Graficky, obsahově a poutavě udělaná reklama nezaručí potřebný efekt, pokud samotné webové stránky nemají kvalitní a dobře strukturovaný obsah. Napsat poutavý text pro webové stránky není tak jednoduché, jak by se mohlo na první pohled zdát. Dříve se na texty na stránkách tolik nehledělo jako dnes. SEO byl také neznámý pojem. V současné době marketingové agentury nabízejí profesionální tvorbu textů, které dokáţou návštěvníky zaujmout a přesvědčit je o uskutečnění záměru, který byl reklamou zamýšlen. Zároveň je takto napsaný text vhodný i pro vyhledávače. Autor takových textů se nazývá copywriter. Text musí vyhovět i dalším kritériím jakými jsou např. srozumitelnost, kvantita, relevantnost, formátování apod. Kvalitně napsané texty jsou základem úspěchu. Investice do nich se určitě vyplatí. Zaujmout čtenáře a přitom vyvolat poţadovanou akci je pochopitelně podloţeno určitým modelem, jak toho dosáhnout. Na začátku je upoutání pozornosti. V dalším textovém obsahu se vzbudí zájem. Tento zájem se následně vhodnou formou transformuje na zákazníkovo přání. Je-li tohoto postupně dosaţeno, následuje jiţ relativně krátký krok vedoucí k provedení akce uţivatelem. Tyto kroky se označuji zkratkou AIDA (Attentio – pozornost, Interest – zájem, Desire – přání, Action – akce). Model se vyvíjel dále a v současnosti je vyuţíváno spíše hledisko, které jako prvotní impuls vyuţívá potřebu poznání. Potřeba je pak naplněna hledáním a ověřováním. To je velmi důleţité. Zákazník si musí předem ověřit, zda daný výrobek je opravdu dostatečně kvalitní a stojí za koupi. Hodnocením nákupu pak sděluje i dalším potenciálním kupcům spokojenost s výrobkem.61 Tento model je tedy zaloţen na tzv. sociálním nakupování, Základem je tedy sdílení informací o spokojenosti produktů. Jedním z portálů, který slouţí pro takovéto potřeby je např. Heureka.cz. Portál slouţí nejen pro porovnání cen, ale i pro hodnocení produktů a sluţeb eshopů. Hodnocení produktů na Heureka.cz ukazuje následující obrázek 15.62
61 62
JANOUCH, Viktor. Internetový marketing: prosaďte se na webu a sociálních sítích, s. 109. Samsung i9100 Galaxy S II. In: Heureka.CZ 78
Obrázek 14: Heureka.cz – sdílení informací o produktu mezi uţivateli, (zdroj: Samsung i9100 Galaxy S II. In: Heureka.CZ)
PPC reklama Typ PPC (Pay Per Click) reklamy vychází z placení za kliknutí. Tato myšlenka přinesla do světa internetové reklamy skutečně převratnou novinku. PPC reklama je jedna z nejlepších forem propagace s poměrem cena/výkon. Moţnost přesného cílení dle uţivatelského vyhledávání, relativně nízké náklady a okamţitý viditelný efekt jsou velmi silné atributy této reklamy. V případě zadání klíčového slova se na prvních pozicích ve vyhledávání zobrazí reklama typu PPC na zvýrazněném podkladu. Další PPC reklama se zobrazuje v pravém sloupci. Na jaké pozici se reklama umístí, záleţí na ceně za proklik, který je ochoten inzerent zaplatit. Jak reklama funguje v praxi, je zobrazeno na obrázku 16 níţe.63
Obrázek 15: Ukázka PPC reklamy na Googlu, (zdroj: Google)
63
Google 79
Přirozené (neplacené) výsledky hledání na klíčové slovo se zobrazují aţ pod PPC reklamou. Důleţité je, aby PPC reklama skutečně odpovídala svým obsahem tomu, co uţivatel čeká, ţe se mu po kliknutí zobrazí. V případě, ţe je obsahem reklamy konkrétní produkt, měl by odkaz z PPC vést přímo do detailu produktu a nikoliv pouze do výpisu zboţí, kde jsou i ostatní produkty a nechat tak uţivatele se „doklikat“ k prezentovanému výrobku. Důleţité pojmy PPC reklamy: CTR (Click Through Rate) – míra prokliku. Jedná se o poměr mezi kliknutím a zobrazením na inzerát. Výsledná hodnota se udává v procentech. Kampaň – PPC kampaně sdruţují jednotlivé sestavy s klíčovými slovy. U kampaně se nastavuje její rozpočet, začátek a konec. Sestava – můţe skládat z několika inzerátů, které se mohou střídat. V sestavě se nastavuje maximální cena za proklik. Sestavy tvoří kampaň. Je doporučeno, aby text inzerátu v sestavě odpovídal obecné charakteristice klíčových slov, které obsahuje. Fraud click – podvodné kliky, které mají za úkol poškodit inzerenta díky záměrně častému klikání na reklamu za účelem zvýšit náklady na ni. PPC kampaň je téţ důleţité sledovat a vyhodnocovat v čase. Není nutné soupeřit s konkurencí ohledně klíčových drahých a vysoce konkurenčních klíčových slov (aţ několik desítek korun za kliknutí), ale soustředit se na levnější, ale také hledaná, ve spojení s dalším klíčovým slovem. Pokud kampaň má opravdu špatné výsledky, další kampaň bude muset být o to nákladnější, neboť v systému se archivuje historie kampaní a špatné výsledky chybně navrţené nebo dokonce klamné reklamy se v budoucnu mohou negativně projevit. Dostatečná analýza a návrh kampaně spolu s odpovídajícím korelačním kontextem stránek a textu reklamy jsou silnou zárukou dobrých výsledků. Bannerová reklama V případě plošného zacílení jsou bannery nepostradatelným nástrojem propagace. Jejich cílem je zaujmout pozornost svým sdělením a zpravidla různě vkousnou animací. Bannery mohou mít různé rozměry a tvary. Rozšířené jsou např. čtvercové (250x250px) či velké obdélníkové typy tzv. double leaderboardy (745x200px). Bannery mohou být statické či vytvořené ve flashi. Mezi statické patří jednoduché bannery tvořené jedním obrázkem ve formátu jpg či několika málo obrázky typu gif, které tvoří jednoduchou animaci. Opakem jsou flash bannery, které mohu obsahovat efektivní animace a různé interaktivní prvky. Flash bannery jsou opravdu silným nástrojem jak co nejvíce na sebe nalákat uţivatelovu pozornost. 80
V průběhu času se však u uţivatelů zvyklých na mnoţství reklamy na internetových stránkách vyvinula „bannerová slepota“. Flashové bannery se tak často přehlíţí a tvoří nutné zlo pro uţivatele. Jako efektivnější se v dnešní době zdají být statické bannery, které „netrhají“ oči a působí méně násilně. Záleţí zde ovšem také na provedení banneru, cílové skupině atd. K umístění bannerů slouţí hodně navštěvované zájmové portály. Docílí se tím tak cíle bannerů, aby byly zhlédnuty co největším moţným počet návštěvníků portálů. Zpravidla se vyuţívají silné mediální společnosti, které mají ve svém portfoliu velké mnoţství portálů s velkou návštěvností. Čím více, tím lépe. Za bannery se platí dle mnoţství zhlédnutí. Toto mnoţství vyjadřuje zkratka CPT (Cost Per Thousand). Cena je vztaţená za 1 tisíc zobrazení resp. shlédnutí banneru. Bannery jsou velmi efektivní při propagaci nové značky či produktu. Horší je to v případě zisku konverzí z bannerové reklamy např. nákupu v eshopu po kliknutí na banner. Tam záleţí i na kvalitě výrobku, přehlednosti eshopu a dalších podmiňujících faktorech k získání konverze. Newsletter Zasílání novinek (newsletteru) na emailové adresy z daného serveru je poměrně levný a účinný způsob, jak dát vědět širšímu okruhu zákazníků o nových produktech či sluţbách. V případě, ţe oborový server má ve své databázi několik desítek tisíc uţivatelů, kteří souhlasí se zasíláním obchodních sdělení, můţe poskytnout tuto databázi další straně, která tak můţe oslovit tyto odběratele svým tématicky podobným zaměřením. Cena za odeslaný email se pohybuje obecně ve spodní části několika korun. Důleţité je zvolit čas odesílání, aby reklamní email byl jedním z prvních, který uţivatel ve své emailové schránce uvidí. Plošné cílení a dostupnost jsou zjevné formy této propagace. Nevýhoda spočívá zejména v oblasti zařazení emailu antispamovým filtrem do nevyţádané pošty. Takto zařazenou poštu uţivatel v podstatě nekontroluje, a tudíţ email neuvidí. Pokud se jedná o zákazníky, kteří mají o zasílání novinek z oblíbeného webu skutečný zájem, je tento systém velmi přínosný a uţitečný jako komunikační a propagační kanál. Reklama na sociální síti Neustále rostoucí popularita sociálních sítí a Facebooku zvláště, nemohla ujít pozornosti jeho provozovatelům. Reklama na Facebooku je i díky některým povinným informacím sdělených při registraci jejich uţivateli velmi konkrétně cílená. Cílit lze na uţivatele dle pohlaví, věku, oboru zájmu apod. Reklama se zobrazuje v postranním sloupci a obsahuje malý obrázek 81
a krátký reklamní text (viz obrázek 17).64 Cena se platí jako v případě PPC reklamy za proklik.
Obrázek 16: Reklama na Facebooku, (zdroj: Reklama. In: Facebook)
PR články PR (Public relations) článek je reklamní sdělení v podobě článku o novém produktu, sluţbě apod. PR článek můţe obsahovat názorné obrázky, text a odkaz na dané stránky. Odkaz na stránky pak na populárním serveru slouţí jako důleţitý off-page prvek SEO optimalizace. PR články se vkládají buď na populární portály nebo do PR katalogů. Pro dobré hodnocení vyhledávači je vhodné, aby kaţdý PR článek byl alespoň z jedné poloviny vţdy obměněn. PR články tedy mají charakter reklamního sdělení i funkci optimalizační. Lze jen doporučit, aby PR článek byl psán zejména pro lidské uţivatele a nikoliv jen pro vyhledávací roboty.
9.4 Nevhodné a podvodné techniky Reklama by měla dodrţovat základní etické a mravní hodnoty a zdrţet se zjevného klamání zákazníka. Ne vţdy je ale toto dodrţeno. Reklama často nabízí něco, co je funkčně nereálné nebo to propaguje zavádějící formou. Je jen na uţivateli, zda na danou reklamu klikne nebo ji logicky předem odsoudí jako nevhodnou a bude ji ignorovat. Mnohdy se to stává u PPC reklam, které v textu nabízejí něco odlišného od reality na webových stránkách, které propagují. Takovéto podvodné jednání však můţe být penalizováno. Stránky by měly mít kvalitní a čtivý obsah vytvořený zkušeným copywriterem. Jak se vyhledávače snaţí odlišit podvodné stránky, můţe být text od nezkušeného autora 64
Reklama. In: Facebook 82
vyhodnocen jako nevhodná technika. Stránky se tak mohu propadnout ve výsledcích vyhledávání. Autor to sice nemyslel špatně, ale v textu mohl uvést více klíčových slov, neţ je přirozené, více odkazů do podstránek webu, neţ je běţné a vyhledávače to mohly vyhodnotit negativně. Bez ohledu, ţe úmysl autora nebyl veden za účelem podvodu na vyhledávačích. Další podvodné praktiky se týkají SEO optimalizace. Podvodné SEO techniky se nazývají jako Black hat SEO. Tyto techniky se nedoporučují, neboť můţe v případě odhalení dojít k penalizaci stránek a trvá pak velmi dlouho dobu, neţ je stránka po odstranění podvodných technik opět indexována a viditelná ve výsledcích vyhledávání. Nejčastější podvodné SEO techniky: Keyword stuffing – přehlcení klíčovými slovy. Můţe se týkat meta tagů (keywords, descriptions) či textového obsahu webu. Takto zahlcené stránky jsou penalizovány. Cloaking – jedná se o podstrčení obsahu vyhledávači, který je naprosto rozdílný od obsahu, který vidí uţivatel. Doorway
pages
–
důmyslně
sestavená
stránka
za
účelem
vysoké
pozice
ve vyhledávačích. Nemá kromě mnoha výrazné reklamy lákající ke kliknutí a mnoţství klíčových slov smysluplný obsah. Zpravidla pomocí JavaScriptu je návštěvník přesměrován na cílovou stránku. Hidden text – skrývání vysoce optimalizovaného textu. Pomocí stylů se aplikuje např. bílé písmo na bílém pozadí, velikost textu na 1px apod. Using automated link software – vyuţívání robotů pro budování zpětných odkazů. Je tak moţno získat tisíce zpětných odkazů během několika málo minut. To lze zneuţít i ke konkurenčnímu boji. Google však prohlašuje, ţe má mechanismy jak toto odhalit a zabránit tak zneuţití.65 Black hat SEO dokáţe být efektivní, ale má zpravidla krátkodobý účinek. Z dlouhodobého hlediska se tedy nevyplatí. Pro prvotní optimalizaci však můţe být přínosem. Algoritmy vyhledávačů se neustále vyvíjejí a dokáţou tyto podvodné techniky odhalit. Pro solidní a stabilní výsledky ve vyhledávání, nelze neţ doporučit podvodné SEO techniky nepouţívat. V konečném důsledku se vyplatí poctivá a hlavně trpělivá optimalizační práce.
65
What is Black Hat SEO?. In: EMINEER SEO 83
10 Pouţití v praxi Tato praktická část je zaměřena na aplikování teoretických poznatků v praktické rovině. Teorie je praktikována jiţ od úvodní analytické fáze, po metodiky vývoje, aţ po nasazení konkrétní internetové aplikace do běţného provozu společně s marketingovou propagací. Praktická část se věnuje nejen kompletnímu popisu klíčových oblastí aplikace s praktickými ukázkami, ale i moţnému technologickému a propagačnímu vývoji. Jedná se tedy v podstatě o komplexní souhrn vývoje aplikace a její další vize. K tomu je pochopitelně nutno znát detailně níţe uvedený internetový projekt. Celá tvorba aplikace je popsána z pohledu projektového manaţera. Popis bude věnován zejména s ohledem na technicko-metodický vývoj.
10.1 Obecný úvod do projektu Dodavatelská firma byla oslovena zadavatelem (právnická osoba) na základě její profesionální pověsti, širokému portfoliu provozovaných portálů a rozsahu sluţeb. Dodavatelská firma se řadí mezi špičku 5 největších internetových agentur v České republice. Firma v podstatě udává směr, kterými se „český“ internet ubírá. Historicky to byl projekt Stahuj.cz. Fenomén své doby z oblasti stahování softwaru z centralizované webové databáze. Dalším viditelným a klíčovým milníkem (kromě mnoha dalších) byla investice do projektu Slevomat. Projekt nabízející slevy ze všech moţných oblastí a sluţeb. Úspěšně se prodali na tomto portálu i automobily. Nabídka automobilů na Slevomatu má svou praktickou souvislost s popisovaným internetovým projektem. Tato souvislost bude ještě podrobně popsána. Slevomat byl a je velmi promován dodavatelskou firmou. Na stejném principu jako Slevomat vzniklo v České republice několik set slevových portálů. Důleţitou roli pro zadavatele byla i dostupnost dodavatele v případě osobních schůzek. Záměrem zadavatele bylo vytvořit nový internetový portál zaměřený výlučně na prodej nových, předváděcích a referenčních vozů. Portál by měl být nadprůměrný jak ve svém technickém, grafickém, tak zejména nákupním procesu samotného vozu. V době oslovení dodavatelské firmy zadavatelem bylo na trhu několik provozovatelů portálů, které nabízely prodej nových, referenčních, předváděcích i ojetých vozů. Všechny tyto portály nabízely standardní vyhledávání s nedostatečným filtračním rozsahem, s průměrným technickým a grafickým zpracováním. Portály působily dosti unifikovaně a vyhledávání vozů nebylo uţivatelsky příliš vstřícné. Dalo by se říci aţ uţivatelsky nepříjemné. 84
Cílem zadavatele tedy bylo přijít na tento portálový automobilový trh s něčím novým, zajímavým a orientovaným pro potřeby zákazníka, který si vybírá svůj vůz. Zadavatel na úvodní schůzce s jednatelem dodavatele potvrdil svůj předběţný zájem o realizaci svého projektu. Ze strany dodavatele byl taktéţ projeven zájem a projekt byl delegován na projektového manaţera, který by následně se zadavatelem řešil potřebné kroky vedoucí k úspěšné realizaci projektu.
10.2 Úvodní analýza a začátek projektu Několik informačních schůzek mezi zadavatelem a projektovým manaţerem pomohlo k upřesnění specifikace celého záměru spolu s dalšími souvisejícími okolnostmi. Také se rámcově stanovily moţné jednotlivé fáze, orientační odhad ceny s obecným časovým odhadem realizace. Následně se jednotlivé funkční části konkretizovaly a podrobně analyzovaly. Vznikl tak popisný souhrn detailní specifikace. Upřesnili se mise, vize záměru, jeho klíčové atributy a předpokládaná cílová skupina budoucí aplikace. Odhad náročnosti se provedl pomocí dekompozice, váţených průměrů jednotlivých funkcionalit a konzultací takto stanoveného odhadu s vývojáři. Následně se provedl detailní plán s příslušnými milníky a detailním harmonogramem. Součástí úvodního rozboru problematiky byla SWOT analýza.
Tabulka 4: SWOT analýza 85
Specifikace projektu spolu s cenovou nabídkou, časovým plánem a dalšími prvky souvisejícími s projektem byla zanesena do smlouvy o dílo. Smlouva o dílo je v případě moţného konfliktu mezi zákazníkem a dodavatelem hlavním a rozhodujícím prvek pro řešení sporů. Co je napsáno v této smlouvě, na to se lze regulérně odvolat. Smlouva by tedy měla pokrývat všechna moţná úskalí spolupráce. Smlouvu o dílo obě strany schválily a nic nebránilo začít s výstavbou aplikace. Byl proveden také základní rozbor hrozeb spojený zejména se zdrojovou kapacitou, neboť bylo v řešení několik dalších paralelních projektů. Časový i finanční rámec spojený s projektem byl zvolen dostatečný a hrozby z této oblasti byly shledány jako velmi nízké. Podcenění těchto hrozeb se ukázalo aţ později. V úvodní fázi projektu bylo také důleţité vybrat vhodnou doménu pro projekt a následně její registrace. Důleţité prvky pro výběr domény byly následující: Musí obsahovat klíčové slovo „auto“. Měla by být krátká a snadno zapamatovatelná. Měla by vystihovat podstatu portálu. Měla by být volná nebo dostupná do předem stanoveného rozpočtu. Splnit tyto jednotlivé poţadavky nebylo jednoduché, neboť v oblasti prodeje a nabídky aut byly domény se smysluplným názvem jiţ většinou zaregistrovány a musely se vymýšlet netradiční kombinace. Vycházelo se téţ z databáze dodavatele, který měl registrováno mnoho domén. Ovšem ohledně prodeje aut nebyla zaregistrována ţádná doména, která by byla pouţitelná. Po oslovení několika subjektů, které jiţ měly zaregistrovanou doménu, ale jejich poţadavky za doménu byl značně finančně nadhodnocené nebo neměly v úmyslu doménu prodat, se podařila zaregistrovat takřka “náhodně“ doména, která splňovala všechna kritéria. Vznikla spojením dvou slov a byla volná i s dalšími doménami nejvyššího řádu i s pomlčkami ve spojení slov. Vybraná a zaregistrovaná doména byla autonabidka.cz. Z důvodů ochrany proti zneuţití domény od konkurence byly zaregistrovány i domény auto-nabidka.cz, autonabidka.sk, auto-nabidka.sk a analogicky se toto týkalo i domény nejvyššího řadu typu com.
86
10.3 Vývoj projektu Pro vývoj projektu byl zvolen spirálový model vývoje, neboť bylo nutno důkladně testovat jednotlivé kroky a následně plánovat další. Počítalo se také s moţnými riziky a změnami během vývoje projektu. Všem dalším krokům předcházela analýza, se kterou spirálový model také pracuje. Vodopádový model nepřipadal v úvahu pro svou linearitu a nutnost kompletní specifikace jiţ na začátku vývoje bez moţnosti změny v jeho průběhu. Zákazník byl od první chvíle aktivně zapojen do projektu a bylo tedy omezeno případné nedorozumění ve funkcionalitách a celkovém vyznění aplikace. Zákazník téţ rychle akceptoval technologické termíny spojené s vývojem aplikace. Bylo tedy moţno pouţít jednotnou terminologii pro odborné pojmy, coţ ušetřilo svým dílem projektový čas, který byl stanoven na komunikaci. Projekt byl rozdělen do dvou hlavních fází. Za prvotní cíl v úvodní fázi bylo vyvinout aplikaci, která se dala prezentovat automobilovým dealerům a získat tak od nich zpětnou vazbu pro další vývoj portálu. V podstatě šlo v úvodní fázi o prototypový model. V další fázi by se pak aplikace upravila a konkretizovala dle zpětné vazby od dealerů, a to zejména v obchodním, ale i funkcionálním modelu. Vývoj aplikace byl zaměřen a rozdělen na dvě části portálu. První („veřejná“) část byla volně přístupná všem návštěvníkům stránek. Návštěvník mohl vůz vyhledat, přečíst si informace o portálu, kontaktovat provozovatele apod. Co návštěvník nemohl poptat, byl vůz. To mohl aţ po registraci a následném přihlášení. Po přihlášení do „neveřejné“ části mohl daný vůz poptat, spravovat svůj účet a zpřístupnily se mu další funkcionality usnadňující výběr vozu. Coţ ve veřejné části nebylo moţné. Jedna z klíčových vlastností celé aplikace slouţící k prodeji vozů spočívala v nákupním procesu. Celý nákupní proces se realizoval systémem holandské aukce. Holandská aukce spočívá v podávání stále niţších částek za aukční subjekt. Jedná se tedy o inverzní pojetí klasické aukce, jak je obecně chápána. Tedy přihazování stále vyšších částek za předmět aukce. Cílem holandské aukce tohoto portálu bylo dosáhnutí co nejniţší částky za vůz. Prodejce vozu samozřejmě z vozu můţe slevit jen takovou cenu, za kterou se mu vyplatí vůz prodat s odpovídajícím ziskem. Jako ekvivalent niţší ceny mohl nabídnout doplňkovou výbavu vozu. Proces byl v základních bodech specifikován takto: Uţivatel můţe poptat několik vozů do aukce (maximálně však tři najednou) a zadává počet dní, po které je aukce aktivní. 87
Pomocí vyhledávacího filtru si vybere dostupnou značku a model na trhu, který dále specifikuje motorizací, výbavou atd. Zadá časový interval pro aukci. Dealerům poptaných vozů se zobrazí po přihlášení v systému poptaná konfigurace vozu. O tomto stavu dealera informuje i emailová zpráva. Dealer můţe na poptávku reagovat či nikoliv. V případě, ţe dealera nabídka zaujme, můţe reagovat. Reaguje sníţením ceny vozu o stanovenou minimální částku. Všichni dealeři účastnící se aukce vidí nabídnuté ceny ostatních dealerů. Ostatní údaje o konkurenčním dealerovi jsou pochopitelně skryté. Uţivatel na nabídku reaguje a potvrdí dealerovi zájem. Administrátor portálu následně na tento a následující procesní kroky dohlíţí aţ do fáze nákupu vozu zákazníkem u dealera v showroomu. Tento proces byl rámcově namodelován do UML diagramu aktivit, který znázorňuje obrázek 18.
88
Obrázek 17: UML diagram aktivit pro popis aukce
Specifikace aukce byla v jednotlivých bodech popsána velmi podrobně, neboť v rámci projektu byl její vývoj zařazen z časové i finanční stránky mezi ty náročnější. Podrobně specifikovaný popis byl dán k potvrzení a odsouhlasení zákazníkovi. Po specifikaci procesu aukce byly definovány role a práva uţivatelů, které by měly přístup do administrace celého systému. Jednotlivé role se vhodně umístily do matice pro větší přehlednost s názvem a popisem dané role. Role byly stanoveny na: Uţivatel (automobilový dealer). Webmaster (zadavatel/zákazník). Administrátor (kodéři, vývojáři, projektový manaţer). 89
UML Use Case model na obrázku 19 níţe ukazuje jednotlivé role a jejich některé kompetence.
Obrázek 18: UML Case model jednotlivých administrátorských rolí
Dále bylo nutno navrhnout jednotlivé sekce portálu, jejich obsahy, detailně specifikovat kritéria vyhledávacího filtru, a to vše sestavit do drátěných modelů a sestavit k těmto krokům podrobný popis. Sekce portálu byly navrhnuty tak, aby vycházely zejména ze statistik poptávek vozů. Sekcí mělo být pouze několik a měly poskytnout návštěvníkovi stránek jasnou a srozumitelnou formou podstatu portálu a základní statistické informace o vozech. Statistické informace o poptávaných vozech by se pouţily do rubrik „nejvíce poptávané vozy“ (dlouhodobě nejvíce poptávané vozy), „skokani měsíce“ (model vozu, který měl v daném měsíci nejvíce poptávek) a „doporučujeme“, tj. předvýběr vozů pro nerozhodné zákazníky, kterým by tato rubrika pomohla s výběrem vozu. Další sekce byly navrţeny takto: Úvodní stránka (vyhledávací filtr a rozcestník do ostatních částí webu). Jak to funguje? (popis portálu, o jeho provozovateli, procesu nákupu). FAQ (často kladené dotazy – klíčové otázky a odpovědi na hlavní témata spojená s nákupem vozu a obchodními podmínkami). Kontakt (kontaktní informace o provozovateli portálu s kontaktním formulářem, mapou, atd.). 90
Vyhledávací filtr, který měl být dalším klíčovým prvkem, byl navrţen do dvou částí. Na základní a pokročilou část. Základní část byla tvořena nejčastěji pouţívanými prvky pro vyhledávání. Prvky tvořící základní část byly např.: značka resp. model vozu, palivo, karosérie apod. Jak je patrno, tyto prvky jsou velmi obecné a vybrat poloţky v základním filtru mohl i naprostý motoristický laik. Opakem toho byl pokročilý filtr, který se objevil aţ po klinutí na příslušné tlačítko. Obě části filtru pochopitelně byly provázány a tvořily jeden celek. Rozdělení bylo tedy pouze optické. Pokročilá část filtru se tvořila spíše agilním přístupem, neboť se často poloţky v pokročilé části měnily. Upřesňovaly se také formulářové prvky, které by „obsluhovaly“ vnitřní funkcionalitu. Změny se konzultovaly se zapojením zákazníka a bylo nutné je dodávat v relativně krátkém časovém úseku. Vývoj pokročilé části byl zákazníkovi dodáván opravdu rychle bez zbytečných procesních kroků. V počátku se to zdálo jako dobrý přístup, ale časté změny vedly k časovému prodlení. Na druhou stranu však byla pokročilá část opravdu komplexní a výběr vozu pomocí této části byl opravdu na špičkové úrovni. Potenciální odborný návštěvník portálu mohl být s nabídkou prvků (např. objem zavazadlového prostoru, počet airbagů, přeplňování, zrychlení) pro filtrování opravdu spokojen. V této fázi byla spokojenost s filtrem nadmíru velká. Po uţivatelské stránce se však ukázalo, ţe ne vše bylo navrţeno bezchybně. Postupně se jednotlivé prvky portálu integrovaly do drátěného modelu (wireframe). Drátěné modely byly nejprve načrtnuty ručně včetně doplňujících poznámek. Poté byly grafikem překresleny ve Photoshopu do vizuálně přijatelných drátěných modelů a předloţeny ke konzultaci se zákazníkem. Zákazník byl opravdu zapojen ve velké míře. V některých případech toto bylo určitě ku prospěchu, někdy méně, neboť to bylo ve věcech, které čistě spadaly do kompetence dodavatelské firmy. Postupem času se tvorba drátěných modelů ve Photoshopu opustila pro svoji nákladnost a poté vzhledem k nutnosti opatřit drátěný model značným počtem vysvětlujících komentářů. Jako relativně bezproblémový kompromis se v další fázi zvolil Microsoft Excel, který poskytoval spojení elementární digitální skicy spolu s komentáři, jak ze strany zákazníka tak projektového manaţera. Po zhotovení drátěných modelů (viz příloha č.1) úvodní stránky a stránek týkajících se aukce bylo pokročeno ke grafickému návrhu. Po zhotovení návrhů drátěných modelů z popisné specifikace se tyto modely následně transformovaly do konkrétní grafické podoby. Tato grafická podoba se poté převedla do zdrojového kódu. Tento postup se dá přirovnat v jistém vývojovém smyslu k metodice 91
MDA. Doménový model zde reprezentuje specifikace funkcionalit, konceptuální model je zastoupen drátěnými modely, relační model grafickou částí a fyzický kód skutečným zdrojovým kódem. Jak jiţ bylo uvedeno, grafická část se zhotovila na základě drátěným modelů. Jednotlivé prvky drátěného modelu nahradila reálná grafika. Vývoj celé aplikace probíhal v prostředí extranetu, chráněném přístupovými údaji, které obdrţel také zákazník, aby mohl sledovat progresi vývoje rámcově jiţ od grafické části. Mohl tak sledovat nejen celý vývoj, ale mohl se aktivně podílet na jeho procesním vývoji v komunikační úrovni po shlédnutí daného stavu. Grafické provedení a její následné vnímání je velmi subjektivní záleţitost. Zhotovily se dva barevné návrhy. První byl proveden v modro-oranţové kombinaci. Druhá varianta byla zvolena červeno-šedá. Nakonec byla vzhledem k cílové skupině (ekonomicky aktivní osoba s vyšším příjmem) vybrána druhá varianta, která působila více seriózním dojem.
Obrázek 19: Grafický návrh prototypového modelu
V grafickém návrhu je jasně patrné prázdné místo v pravé části. Je to z důvodů přepokládaného umístění banneru typu square. Jiţ ve vývojové fázi tedy bylo počítáno s vyuţitím ploch pro reklamní účely. Jako technologie projektu byl zvolen ověřený skriptovací programovací jazyk PHP (verze 5). Databázový stroj byl vybrán MySQL (verze 5). Toto spojení je velmi časté a oblíbené pro dlouholeté vzájemné propojení mezi PHP a MySQL díky jednoduché implementaci. Kombinací těchto dvou prvků lze postavit i opravdu robustní aplikace. Zdrojový kód v PHP byl plně objektový a umoţnil mimo jiné i snadnější implementaci dalších funkcionalit i přehlednost a údrţbu samotného kódu. Programovací jazyk na straně klienta byl pouţit 92
JavaScript s vyuţitím knihovny jQuery. Dále zde byla pouţita technologie AJAX, která měla za úkol obslouţit vyhledávací filtr bez opětovného načítání stránky po kaţdé změně vyhledávacího kritéria na straně uţivatele. Nevýhodou tohoto řešení je větší zátěţ na databázový stroj mnoţstvím dotazů, takţe byla nutná značná optimalizace celé filtrovací komponenty. Důleţité bylo také otestovat vyhledávání různými prohlíţeči. Zejména v Internet Exploreru verze 7 se ukázala rychlost zpracování javascriptového kódu, který je pro AJAX klíčový, jako velmi pomalá. Muselo se tedy vyvinout nemalé optimalizační úsilí pro tento prohlíţeč. Tato verze navíc měla pomalé zpracování JavaScriptu zabudované přímo v jádře, takţe o to byla optimalizace sloţitější. Poslední verze prohlíţečů (Chrome. Firefox, Opera) a i Internet Explorer 9 mají vykonávaní javascriptového kódu na dostatečné úrovni i pro náročnější aplikace psané v JavaScriptu. JavaScript je v dnešní době opravdu velmi vyuţívaný skriptovací jazyk v moderních aplikacích a tvoří podstatnou část kódu, proto je důleţité mít jeho kód plně optimalizovaný na rychlost, stabilitu i bezpečnost. Obsáhlý javascriptový kód byl součástí také této aplikace (ukázky zdrojových kódů v PHP a JavaScriptu viz příloha č. 2). Poté, co byla základní kostra naprogramována včetně grafické části, byla tato vývojová fáze předloţena
jednotlivým
vytipovaným
automobilovým
dealerům.
Jednalo
se
tedy
o prototypovou část. Některé funkcionální prvky byly interpretovány pouze obrázkem pro názornost. Nebylo tedy nutné dělat vše do detailů. Připravila se téţ efektní video prezentace k aplikaci a následně umístěná na YouTube. Také byla zpracována prezentace v Microsoft PowerPointu, kde byly názorně představeny obchodní modely a celkový záměr projektu. Představený obchodní model postavený na holandské aukci se však vzhledem k probíhající finanční krizi ukázal jako neprůchozí. Marţe dealerů by se tím sníţily na minimum. Systém holandské aukce byl tedy stornován. Navíc se po tomto otestování prototypu ukázalo, ţe některé uţivatelské prvky nebyly navrhnuty bez chyb, zejména v oblasti vyhledávání. Muselo se tedy zapracovat na odladění vyhledávacího filtru, který byl pro aplikaci zásadní. Dále bylo rozhodnuto předělat grafickou část do takové úrovně, která by byla inovátorská svým stylem i provedením. Původně navrhnutá grafická část nebyla v ničem nevyhovující, ale byla spíše formálního charakteru. Po přepracování programové i grafické části, naplnění obsahu vozů ze strany dealerů byla připravena ke spuštění finální fáze aplikace. Neţ však byla další (jiţ finální) verze připravená, byla na doméně autonabidka.cz umístěna tzv. landing 93
page, kde se stručně informovalo o projektu a moţnosti zanechání emailové adresy při případném zájmu o další informace o vývoji projektu. Aktuální verze portálu autonabidka.cz je zobrazena na obrázku 21 níţe.66 Po technické, grafické ani obsahové stránce nebyla dosud tato aplikace překonána a tvoří špičku v prostředí českého internetu, co se týče portálu zaměřeného na prodej vozů.
10.4 Projektové práce Během celého projektu bylo nezbytné jeho vývoj sledovat a řídit. Odpovědnou osobou byl projektový manaţer, jehoţ úkolem bylo, aby práce na projektu byly procesně vedené dle plánu a měřitelné. Neboť jen měřitelné hodnoty je moţno vyhodnotit a řídit. Projektový manaţer zejména rozdělil projekt na několik důleţitých milníků, přiřadil k nim zdroje, časové období, rizika a zvolil metriky pro vyhodnocení jednotlivých milníků. Jako hlavní milníky v projektu stanovil projektový manaţer tyto: Zhotovení detailní specifikace funkcionalit. Vytvoření drátěných modelů. 66
Autonabídka 94
Vypracování grafické části. Naprogramování aplikace – frontem. Naprogramování aplikace – backend. Konec testovací fáze. Akceptace zákazníkem (předávací protokol). Spuštění aplikace. Projektový manaţer vyuţíval po celou dobu projektu vlastní CASE nástroj Agevo (dostupný na www.agevo.cz), který vyvinula pro své interní potřeby dodavatelská firma. Tento nástroj obsahoval následující funkce: Zadávání projektových úkolů členům týmu i sám sobě. Sledování kapacity lidských zdrojů. Stav zadaného úkolu. Reportování provedených úkolů dle časového intervalu. Ohledně zadávání úkolů do systému Ageva bylo nutné detailně specifikovat poţadavek pro konkrétního člena vývojového týmu a případně následovala konzultace, pokud byla nutná. Následně pak pracovník úkol odhadl a projektový manaţer potvrdil a následně naplánoval. Projektový manaţer také vykazoval do Ageva své úkoly např. komunikace s klientem, projektové práce, porady a další podpůrné aktivity pro projekt. Projektové práce měly vyšší hodinovou sazbu neţ práce vývojových pracovníků a i přes niţší objem hodin je bylo nutno sledovat, neboť tvořily nedílnou součást nákladu na dílo. V průběhu řízení projektu měl projektový manaţer dohled nad jednotlivými úkoly, které se prováděly v rámci vývoje. Jak jiţ bylo uvedeno, společně s tímto projektem byly lidské kapacity paralelně nasazeny i na další projekty. Tento stav resp. vytíţenost pracovníků Agevo také zaznamenávalo. V Agevu byl evidován také strávený čas pracovníků nad úkoly i to, v jakém stavu se jednotlivé úkoly nacházejí. Procentuální stav úkolu i časové hodnoty věnované úkolu byly pochopitelně závislé na disciplíně a svědomitosti podřízených pracovníků, kteří toto v průběhu vývoje evidovali. Souhrny úkolů s časovými ukazateli se exportovaly do příslušného reportu, který se následně analyzoval z procesního a časového hlediska. Export se prováděl dle časového období. Časové období bylo stanoveno dle potřeby (report jednotlivých úkolů v Agevu viz příloha č. 3). 95
Po interním testování aplikace na moţné bezpečnostní hrozby a otestování v rámci funkčnosti a zátěţe byl vypracován předávací protokol. Spuštění bylo naplánováno na večerní hodiny. Tato doba byla zvolena s ohledem na moţnou hrozbu, která se v průběhu spuštění mohla vyskytnout ať z technické nebo jiné příčiny, která nemusela být podchycena. Na průběh dohlíţel projektový manaţer spolu s hlavním programátorem. Během spuštění probíhala také intenzivní komunikace se zákazníkem. Následně po úspěšném spuštění projektový manaţer analyzoval průběh projektu a zaznamenal si pozitivní i negativní prvky celého projektu. Toto vyhodnocení poslouţilo i jako podklad pro reinţenýring procesů ve firmě a sdílení těchto zkušeností v rámci skupiny projektových manaţerů. A to v oblasti komunikační, stanovení kapacit a jejich plánování a v neposlední řadě pro sofistikovanější pracovní hodnocení podřízených. Zde je souhrn hlavních pozitivních a negativních prvků po skončení projektu: Pozitivní Zhotovení unikátního sofistikovaného vyhledávacího filtru. Výjimečně provedená grafická část aplikace. Výrazné zlepšování komunikace se zákazníkem. Negativní Relativně větší ovlivnění projektu zákazníkem a jeho neústupnými poţadavky. Časové odloţení projektu z důvodu častých změn i po vzájemném odsouhlasení mezi dodavatelem a zákazníkem. Realita skutečného časového rámce byla větší neţ odhad o více neţ 15 %.
10.5 Komunikace s vývojovým týmem a vedení projektu Sestavení týmu bylo úkolem projektového manaţera. Byl vytvořen menší tým, který byl při maximálním vytíţení sloţen do 10 osob. Stálých členů týmu bylo do 5 osob a tým tvořili grafici, programátoři, kodéři a tester. Projektový manaţer se s jednotlivými členy týmu seznamoval v průběhu projektu. Moţnost výběru navíc byla zúţena vzhledem ke kapacitám, které byly značně vytíţeny dalšími jiţ probíhajícími projekty. O to vše, bylo vedení komplikovanější a zprvu projektový manaţer uplatňoval spíše autokratický styl. Ten později byl opuštěn po větším a detailnějším seznámení s charaktery jednotlivých členů i firemní kulturou. Navíc firemní kultura byla
96
velmi neformální a otevřená. Neexistovala tedy striktní hierarchie, kde by měl vedoucí týmu naprostý respekt. Styl vedení, který byl jiţ průchodnější a méně konfliktní byl styl demokratický. Ne na všechny členy týmu se však tento styl vedení mohl uplatnit. Záleţelo na vnitřní morálce a disciplíně konkrétního člena. Pokud projektový manaţer usoudil, ţe vývojář pracuje spolehlivě a svědomitě, umoţnil mu větší míru zodpovědnosti a v jistých okamţicích i částečné
vedení
projektu.
Během
projektu
bylo
pozorovatelné,
jak
docházelo
ke komunikačnímu vývoji v týmu. Postupně tým přecházel od formování aţ po optimální výkon, který byl nejvíce patrný ve zbývající čtvrtině projektu. Komunikace s vývojovým týmem byla pochopitelně také odlišná. A to s technicky uvaţujícími vývojáři nebo volněji uvaţujícími grafickými návrháři. U části týmu, který měl na starosti vizuální stránku projektu, bylo nutné přesvědčit je o nutnosti a důleţitosti vykazování stráveného času nad jednotlivými úkoly. Pro projektového manaţera bylo důleţité pracovat s co moţná nejaktuálnějšími daty ohledně stráveného času nad projektem resp. hlídání financí s tím spojených. Během projektu docházelo velmi často k technickým konzultacím a to jak v týmu, tak i mezi vývojovým týmem a projektovým manaţerem a rozhodovalo se o co moţná nejoptimálnějším řešení dané problematiky. Vţdy i přes různá názorová stanoviska se došlo ke konsensu. Ne vţdy však byla komunikace jednoduchá a mnohdy docházelo ve stresových situacích k vypjatějším situacím. Tyto situace se však vyskytovaly spíše v úvodní třetině projektu. Jako komunikační nástroje slouţila nejčastěji elektronická pošta, dále sdílení dat v rámci extranetového prostředí, které bylo velmi efektivní. Pro rychlou a krátkou komunikaci se vyuţívaly programy typu instant messaging, představující zejména ICQ. Pro komunikaci v rámci úkolů bylo vyuţito také Agevo, kde se jednotlivé úkoly zadávaly, vyhodnocovaly a probíhala v něm nepřímá komunikace ohledně specifikace úkolů mezi projektovým manaţerem a týmem Vývojový tým sdílel svá data a komunikaci nejen v příslušné sloţce, která byla vyhrazena projektu a měla hierarchickou strukturu na extranetu, ale také ve firemní Wikipedii, kde se zaznamenávali body k provedení (tzv. „todo“). Komunikace průběţně probíhala i se zákazníkem na osobních schůzkách či v rámci emailové komunikace, která byla nejfrekventovanějším nástrojem. Nevýhodou této komunikace byla nutnost striktního zachování spojitosti informací, neboť jednotlivé emaily na sebe v čase navazovaly a komunikačně byly značně do sebe vnořeny. Zákazníkovi byla pro lepší 97
a rychlejší komunikaci vytvořena sloţka pro sdílení dokumentů a nemusely se velké přílohy posílat pouze přes elektronickou poštu. Komunikace se zákazníkem se tříbila analogicky k formování týmu. Také měla naprosto konkrétní vývojové fáze. Mimo běţnou rutinní komunikaci se konaly pravidelně porady, kde se probíraly jednotlivé uplynulé kroky i ty následující. Projektový manaţer rozdělil patřičné úkoly, které jednotlivě diskutoval se členy týmu a objasňoval případné záleţitosti, jeţ by mohly být interpretovány odlišným způsobem a mohlo tak dojít k nedorozumění v komunikaci. Jak jiţ bylo uvedeno, počet členů týmu podílejících se na vývoji a záleţitostech kolem projektu nebyl konstantní. Svého maxima dosáhl během příprav na propagaci projektu. V těchto přípravách byli zahrnuti kreativní pracovníci a pracovníci marketingu. Kreativní pracovníci připravili poutavé audiovizuální podklady, tiskové zprávy apod. Marketingoví odborníci naplánovali marketingovou kampaň pro co největší efekt týkající se uvedení nového slibného produktu na trh. Tato fáze byla ve vývoji projektu ta nejnáročnější na komunikaci. Bylo důleţité sjednotit vzájemnou interní komunikaci mezi vývojáři, kreativními a marketingovými členy týmu. Kaţdá tato skupina měla své specifické chování, na které bylo nutno brát ohled a přizpůsobit se mu.
10.6 Rizika během projektu a jejich řešení Zásadní rizika projektu byla podchycena úvodní analýzou rizik s následným vypracováním opatření. Analýza vycházela ze zkušeností při řešení rizik, na podobných projektech, zejména co se týče rozsahu. Rizika projektu byla sestavena do tabulky a během projektu aktualizována. Dopad rizika byl stanoven dle svého významu na následující hodnoty: Katastrofický – jedná se o dopad, který můţe ohrozit realizaci celého projektu s fatálními důsledky. Kritický – tato hodnota dopadu rizika je závaţného charakteru a můţe mít za následek časové zpoţdění či navýšení finančního rámce projektu. Marginální – méně významný dopad, ovšem s dalšími souvislostmi můţe nabývat kritických hodnot. Takto označenému dopadu resp. riziku je nutno se během projektu taktéţ věnovat. Zanedbatelný – nepříliš významný dopad, kaţdopádně je dobré o něm vědět, ţe můţe nastat. 98
V tabulce 5 jsou uvedeny některá rizika, která mohla vzniknout. Název rizika
Výskyt rizika
Nedostatečná specifikace programových
%
vedení projektu 10%
funkcionalit Změna poţadavků zákazníka
Dopad rizika kritický
zákazník
10%
marginální
Nevhodně sloţený tým
tým
15%
kritický
Nedostatečné kapacity
tým
20%
katastrofický
Podcenění časové a finanční náročnosti projektu
vedení projektu 10%
kritický
Nečekaná technologická náročnost
tým
30%
katastrofický
Nevhodně zvolené a provedené testování
tým
10%
marginální
Tabulka 5: Analýza rizik projektu
Podceněno bylo riziko ohledně změn poţadavků ze strany zákazníka. Projektový manaţer sestavoval plán rizik na základě několika předchozích jednání se zákazníkem, proto zvolil nízké procento vzniku společně s následným dopadem. Toto se ukázalo jako chyba. Stejně tak, jako chybějící manaţer specializovaný přímo na analýzu rizik. Změny v zadání ze strany zákazníka, zejména v úvodních fázích, se ukázaly pro vývoj aplikace jako kritické a projekt oddálily i prodraţily. Zákazník téţ trval na přílišných detailech, tím se ztratila orientace na klíčové atributy projektu. Ve finální fázi, tedy po představení úvodní (prototypové) fáze, byly poţadavky od zákazníka mnohem konstruktivnější a vývoj aplikace byl takřka optimální. Další riziko, které nastalo, se týkalo kombinace podcenění časové a finanční náročnosti projektu a nečekané technologické náročnosti, ačkoliv bylo v analýze rizik uvedeno a existoval i scénář řešení. Vyhledávací filtr resp. pouţitá technologie byla natolik ojedinělá ve svém rozsahu pouţití pro desítky parametrů filtru, navíc v kombinaci s častými změnami filtru, ţe byl výrazně překročen časový limit na jeho zhotovení. Další neplánovaný časový úsek byl nutný na jeho optimalizaci pro jednotlivé prohlíţeče resp. jejich odlišně výkonné zpracování javascriptového kódu. Následný scénář řešení rizika bylo moţné implementovat jen z části. Řešení spočívalo ve sníţení elementů vyhledávání. To ale nakonec nepřicházelo v úvahu, neboť by se tím sníţila unikátnost této komponenty a bylo to zamítnuto. Bylo rozhodnuto vyhledávací a optimalizační proces filtru dokončit, coţ se podařilo. 99
Značné riziko, které také vyvstalo, spadalo do části uţivatelského testování. Aplikace byla odladěna technicky, procesně, ale nikoliv uţivatelsky. Toto bylo ve větší míře učiněno aţ po spuštění celé aplikace. Některé úpravy se podařilo upravit hned, některé aţ po delší době z důvodu integrační náročnosti databázových dat. Poslední riziko vzniklo díky neočekávané návštěvnosti portálu při uveřejnění reportáţe v pořadu Autosalon, jenţ patří mezi nejsledovanější a nejoblíbenější motoristické pořady v této zemi. Ačkoliv byl server předem posílen o paměťovou i procesorovou sloţku, zátěţ nezvládl a byl po několik hodin zcela přetíţen poţadavky. Následkem této zkušenosti došlo k přemístění webhostingových sluţeb na virtuální server a dále proběhla opětovná optimalizace vyhledávacího filtru, který svými dotazy méně zatěţoval databázový zdroj. Byl sestaven plán rizik i scénáře k jejich řešení, ale přesto došlo k několika rizikům. Některá šlo předvídat jistě lépe a pečlivěji (např. technologická i časová náročnost dílčích úkolů), některá byla takového rozsahu (např. návštěvnost po reklamě v televizním vysílání), ţe předčila analýzu rizik. Analýzou rizik je moţné v praxi předcházet mnoha nepříjemnostem, nelze je však předem všechny podchytit.
10.7 E-marketingová propagace projektu Jednou z výhod dodavatelské firmy, která hrála svou roli při svém výběru ze strany zákazníka, bylo to, ţe měla v provozu několika desítek vlastních portálů a vlastní marketingové agentury. Pod hlavičkou jedné firmy probíhal tedy nejen vývoj aplikace, webhostingové sluţby s registrací domén, ale i kompletní online propagace. Ve fázi spuštění dodavatelská firma MITON CZ s.r.o. disponovala návštěvností kolem 2 500 000 RU svých portálů za měsíc. Nejprve se stanovil marketingový plán, který spočíval ve vyuţití komunikačního mixu. Na základě propagačního
dlouholetých prvku.
zkušeností
Bylo
také
se
stanovily
předpoklady
návštěv
nutno
důkladně
analyzovat
rozmístění
z kaţdého reklamy
na jednotlivých portálech. Kaţdý portál byl specifický svým obsahem a bylo nutno mu přizpůsobit i online reklamu, aby byla co nejvhodnější pro jeho cílovou skupinu. V tabulce 6 jsou uvedeny některé propagační prvky a jejich očekávané CTR (Click Through Rate) „míra prokliku“.
Kompletní komunikační mix obsahoval tyto prvky: Bannery Největší vizuální prvek online propagace portálu. Cílem bannerů bylo upoutat pozornost, ale také poskytnout obsahovou informaci. Zvolená technologie pro bannery byla flash animace. Bylo to zejména z důvodů nutnosti atraktivity, zaujetí pozornosti a postupného sdělení reklamního textu. Kaţdý banner obsahoval několik animovaných „oken“, které tvořili jednotný a nenásilný celek. Pro jednotlivé bannery byly sestaveny scénáře, které se obsahově blíţily portálu, na kterém byly pouţity. Např. na portálu zdrave.cz bylo pouţito reklamního sdělení ohledně nemocného auta, které lze vyléčit nákupem nového vozu. Bannery byly zhotoveny v různých rozměrech. Nejčastěji byl pouţit typ square (300 x 300px), dále byly zastoupeny zejména rozměry skyscraper a nepřehlédnutelný leaderboard. Bannerový typ reklamy byl nasazen plošně na všechny dostupné portály dodavatele. Zejména byly vyuţity portály heureka.cz, strelectvi.cz, poptavka.cz, zdrave.cz, vareni.cz, hafici.cz, moviezone.cz a další. PR články PR články měly svůj přínos nejen díky poutavému a oborově provázanému textu s portálem, kde byly nasazeny, ale také díky zpětným odkazům, které v nich byly pouţity a odkazovaly na propagovaný portál autonabidka.cz. Zpětné odkazy z portálů, které mají vysoké hodnocení (pagerank) byly pro optimalizaci velmi uţitečné. Ve výsledcích vyhledávání na konkrétní klíčová slova se zobrazují portály obsahující tyto PR články na předních pozicích první stránky výsledků. PR články mají na rozdíl od bannerů, které slouţí k jednorázové propagaci svůj stálý přínos. Díky archivu článků můţe návštěvník kdykoliv navštívit propagovaný portál, a to i v budoucnu. Úspěšnost PR článků šlo velmi dobře vyhodnotit, stejně jako jejich SEO atributy. 101
Direct e-mailing V případě emailového marketingu bylo opět vyuţito prostředků dodavatelské firmy, která poskytla několik set tisíc emailových adres uţivatelů portálů, kteří souhlasili s příjmem obchodních sdělení prostřednictvím elektronické pošty. Byly vybrány cílové skupiny, které se nejvíce blíţily motoristickému odvětví. Důleţitým prvkem E-mailingu je jednoduchost a srozumitelnost sdělení. Následně je nutno vyuţít ke zvýšení zájmu příjemce takové zprávy, tzv. „call to action“ tlačítka, které vybízí k akci. Tlačítko je velmi výrazné a po kliknutí na něj se příjemce zprávy dostane na propagovanou sluţbu či produkt. Také s tímto bylo počítáno. Nevýhoda E-mailingu je v relativně niţší konverzi (počet příjemců a počet prokliků). Pozornost byla věnována správnému zobrazení obrázků v emailu a také moţnosti zobrazení emailu na webových stránkách, pokud uţivatel měl nastaveno zobrazování pouze textových informací. Nešlo také vyloučit zařazení a přesunutí emailu do spamu, který uţivatel běţně nekontroluje, i kdyţ i této problematice byla věnována pozornost. Zpětná a spolehlivá odezva v podobě statusu emailů, které byly přesunuty do spamové sloţky však neexistuje. Lze ale velmi dobře vysledovat úspěšnost e-mailingové kampaně. PPC PPC kampaně nemohly být při propagaci nevyuţity. Jejich okamţitý a kvalitativní přínos je jedinečný a převyšuje ve své efektivitě všechny ostatní prvky komunikačního mixu. Bylo vytvořeno několik kampaní a mnoho sestav systematicky zpracovaných do kontextově souvisejícího rámce. V automobilovém průmyslu jsou jednotlivá klíčová slova nákladná (zpravidla od 10 Kč za slovo). Čím je objem slova hledanější, tím je „nákup“ klíčového slova draţší. Je proto vhodné zvolit důmyslnější strategii, neţ pouhý nákup nákladných klíčových slov. Velmi pečlivě také bylo dbáno, aby obsah PPC reklamy co nejvíce souvisel s obsahem resp. URL stránky, na které PPC reklama cílila. Vyhodnocení PPC reklamy se vztahovalo na konverzi, jeţ byla stanovena na odeslání poptávky na vůz.
10.7.1Další pouţité formy propagace Dodavatel, jako významná internetová agentura také připravil oficiální tiskovou zprávu o spuštění nového portálu zaměřeného na prodej vozů. Tisková zpráva měla za účel oficiálně informovat o novém projektu společnosti MITON CZ s.r.o., a také jako zdroj pro ostatní mediální subjekty, které by chtěly o události informovat na svých komunikačních prostředcích. 102
Se spuštěním online propagace pochopitelně souviselo i vytvoření komerční stránky na sociální síti Facebook. Stránka na Facebooku byla vytvořena za účelem těsnější komunikace s fanoušky portálu i oslovení dalších potencionálních zájemců o nový vůz. V rámci Facebooku probíhá také jejich informování o novinkách na portále i o novinkách z motoristického světa jako jsou nové modely uváděné na trh, automobilové výstavy apod. Jako jeden z klíčových prvků v propagaci portálu autonabidka.cz bylo navázání spolupráce s jedním z nejsledovanějších a nejoblíbenějších motoristických pořadů Autosalon na stanici Prima FTV. Počátkem další vzájemné spolupráce bylo umístění reklamního sdělení (Product Placement) o novém portálu a jeho vyuţití pro nákup vozu. V pořadu bylo informováno o portálu autonabidka.cz jako o propracovaném a komplexním nástroji, který eviduje kompletní aktuální nabídku vozů, včetně jejich motorizací i výbav, ale také o detailní moţnosti srovnat vybrané vozy dle mnoha kriterií. V rámci další spolupráce s pořadem Autosalon (autosalon.cz) se na jejich webových stránkách zobrazila záloţka nazvaná „konkurenční nabídka“. Jedná se o webovou sluţbu, která na základě vstupních parametrů zobrazí k danému vozu z portálu odpovídající konkurenční nabídky. Katalog autonabidka.cz tak zprostředkovává pořadu Autosalon zajímavé informace. Velmi zajímavým a inovátorským počinem bylo zobrazení QR (Quick Response) kódu během vysílání pořadu Autosalon na konci testu vozu. Po načtení tohoto kódu přes čtečku se zobrazily v příslušném mobilním zařízení konkurenční vozy, které poskytl opět portál autonabidka.cz a zároveň byl tímto pořad více interaktivním. Na stránkách autonabidka.cz se objevil viditelný odkaz na pořad Autosalon, jeţ tímto způsobem i propaguje a zvyšuje svým způsobem návštěvnost internetových stránek pořadu. Experti
pořadu
Autosalon
téţ
vyuţívají
sofistikované
vyhledávání
na
stránkách
autonabidka.cz, které jim rychle a přehledně zprostředkuje poţadované informace pro vyuţití ve svém televizním pořadu. Jako propagační prostředek portálu byl poprvé v České republice pouţit slevový portál Slevomat (slevomat.cz), který patří na špičku mezi slevovými portály. Spolu s významným dealerem se připravila výjimečná nabídka osobních vozů Škoda Octavia. Tato nabídka byla velice úspěšná z hlediska návštěvnosti portálu (nárůst o 200%) i ohledně slevy, neboť vozy se prodaly do pouhých dvou dnů od zveřejnění nabídky na Slevomatu.67
67
Škoda Octavia Edition CZ 1.4 TSI 90 kW za 299 999 Kč. In: Slevomat 103
Obrázek 21: Propagace autonabídka.cz na portále Slevomat, (zdroj: Škoda Octavia Edition CZ 1.4 TSI 90 kW za 299 999 Kč. In: Slevomat)
Z toho je patrné, ţe slevové portály plní nejen funkci zvýšení zisku firmy, ale i propagační činnost, která je mnohdy výraznější neţ daný zisk z příslušné slevové akce. Jak bylo uvedeno, stálý přínos ohledně uskutečněného online marketingu mají PR články a také spolupráce s pořadem Autosalon, přes který je citelný zdroj návštěv portálu Autonabídka. Souhrn hlavních pozitivních a negativních prvků po skončení online marketingu: Pozitivní Propagace byla správně načasována a jednotlivé prvky komunikačního mixu byly nasazeny dle plánu. Zaznamenaný nárůst návštěvnosti a povědomí o projektu. PR články jsou dobrým zdrojem zpětných odkazů (zvýšení SEO off-page faktorů). Negativní Byla vyuţita efektivita PPC reklamy jen relativně krátkou dobu. Nebyla dostatečně zasaţena cílová skupina tvořící zájemce o nový vůz resp. motorismus obecně. 104
Online marketing, který byl proveden lze hodnotit jako průměrný, a to zejména s ohledem na cílovou skupinu uţivatelů, která nebyla zcela pokryta. Dané portály neměly vhodnou cílovou skupinu, kde by převaţovala motoristická skupina uţivatelů. V oblasti online marketingu měla být větší pozornost věnována zejména PPC kampaním a rozloţena do většího časového intervalu. Pochopitelně je nutné souvisle portál propagovat spolu s jeho rozvojem po obsahové i funkční stránce. To vše je výhledově plánováno v budoucnu realizovat.
10.8 Další moţný vývoj projektu V současné verzi jsou důleţitými prvky zejména propracovaný vyhledávací filtr, kompletní přehled trhu vozů a graficky působivé zpracování. Je však nutno opět pokročit k dalšímu rozvoji. Jako další moţný vývoj se jeví umístění článků a aktualit z motoristického světa. Je to z důvodů většího zaujmutí návštěvníka stránek, aby si nejen vyhledal daný vůz, ale i přečetl zajímavý článek a udělal si co moţná největší představu o vozu, který si hodlá koupit. Tento textový obsah je moţný díky vlastním odborným kapacitám zařídit interně nebo lze vyuţít externí dodavatele obsahu. Dále je moţné se zabývat a ještě více vylepšit uţivatelské rozhraní a zapojit samotné uţivatele do tvorby obsahu. Tento trend je přímo obsaţen jiţ v samotné podstatě Webu 2.0. To je moţné na základě diskuzních fór nebo vlastních recenzí ke konkrétním vozům apod. Také je v moţném řešení flexibilnější uţivatelské rozhraní, které by se přizpůsobilo na míru individuálním poţadavkům a vedla by se v patrnost i historie činnosti uţivatele, kterému by se na základě takto shromáţděných dat poskytly individualizované výsledky a informace o jeho oblíbených automobilových značkách a modelech. V oblasti propagace je výhledově moţné se ještě více zaměřit na oblast sociálních sítí, jako jsou zejména Facebook a Google+ a nabízet na těchto sítích speciální, pravidelně aktualizovaný bonusový obsah. Je počítáno s dalším a větším zapojením fanoušků těchto stránek. Ohledně online reklamy by pokračoval trend ve strategickém přidávání zpětných odkazů, které by více korelovaly s novým obsahem. S tímto souvisí i větší optimalizace pro vyhledávače, neboť na současných stránkách není dostatek vhodného textu. Coţ je vnímáno jako závaţný nedostatek a je nutno tuto záleţitost výrazně ošetřit. Předpokladem dalšího vývoje je i těsnější spolupráce s pořadem Autosalon a většího vzájemně výhodného provázání obou internetových prezentací. Je zde značný prostor jak oboustranně výhodnou spolupráci ještě prohloubit. 105
Jelikoţ se zkušenost s prodejem vozů na slevových portálech projevila jako kladná, není vyloučeno, ţe se na prestiţním portálu Slevomat neobjeví další mimořádně výhodná nabídka na oblíbené vozy s výraznou cenou. Jeţ by opět plnila svou zejména propagační funkci. Výhledově lze tedy počítat s technologicko-optimalizačním vývojem i další podporou v oblasti online marketingu. Pouze neustálý a dobře naplánovaný procesní růst je zárukou konkurenční výhody nad ostatními projekty, které téţ své projekty zlepšují a předkládají svým uţivatelům další výhody. Projekt autonabidka.cz si za svůj necelý rok provozu dokázal najít své fanoušky. Prodej vozů z tohoto portálu zaznamenal také svůj růst, zejména v souvislosti s propagací v rámci pořadu Autosalon a slevovou akcí na portále Slevomat. Mnoho návštěvníků se také na portál vrací a stráví na něm nadprůměrný časový úsek. Nejen tyto ukazatele dokazují, ţe je projekt smysluplný a dokáţe svým obchodním modelem a přístupem zákazníky nejen získat, ale i udrţet, a to je mnohdy to nedůleţitější, ale také nejnáročnější.
106
Závěr a poznatky Vývoj internetových projektů by měl být určitě řízený odpovídající metodikou. To platí zvláště u větších projektů, mezi které patří i výše popsaný portál autonabidka.cz. Při jeho vývoji byl pouţit spirálový vývojový model. Spirálový model počítá s moţnými změnami během vývoje i s příslušnými riziky a plánováním dalších kroků. Portál byl vyvíjen ve spirálových krocích, jejichţ základem byla analýza, řízení rizik a vývoj po stanovených částech. Vývoj po částech byl velmi důleţitý. Sníţilo se tak riziko většího objemu kódu, který by nebyl v souladu s představou zákazníka. První fáze projektu plnila také svůj prototypový význam, který se ukázal jako velmi uţitečný. Zejména z pohledu otestování obchodních modelů. Po získané zpětné vazbě na prototyp byla aplikace upravena, ale základ aplikace byl vyuţit z prototypu. Další metodika, která se při vývoji projektu uplatnila, byla agilní metodika. Zákazník byl při tvorbě vyhledávacího filtru silně zapojen do vývoje z jeho uţivatelského hlediska a také jednotlivé prvky filtru byly často měněny a rozšiřovány. Zákazník také očekával rychlé zhotovení této komponenty, která byla pro projekt klíčová. Vývojový tým tak předkládal své návrhy při řešení a byl mu ponechána z projektového hlediska větší volnost a samostatnost při tvorbě této části. V jistém smyslu byl vyuţit i postup dle metodiky MDA, jejíţ podstatou je modelování procesů a jejich transformace do zrodového kódu. V projektu tento transformační krok nebyl sice pouţit, ale filosofie MDA byla vyuţita při tvorbě struktury z definičního rámce. Na tuto strukturu byla implantována grafická část, která byla následně převedena do zdrojového kódu. Jistá analogie s metodikou MDA byla. K modelování nebylo pouţito přímo UML, ale drátěný model, který blokově strukturu popisoval. Bylo vyuţito téţ modelovacího jazyka UML na stavové procesy a schéma pohledu ve vyuţívání systému uţivatelskými skupinami. Diagramy byly velmi názorné, plně splnily svůj účel na srozumitelnost a přehlednost, a to i pro zákazníka. Ne vţdy však metodiky zaručí úspěch projektu. Je důleţitá také zkušenost projektového manaţera a vývojového týmu a také komunikace mezi nimi. Také nelze plně odladit uţivatelskou část bez dostatečně důkladného testování uţivatelskou skupinu. V testovací skupině je nutno zahrnout jak zkušené, tak méně zkušené internetové uţivatele. Skupině je nutno zadat jednotlivé úkoly, jeţ jsou klíčové pro orientaci na stránkách. Testování proběhlo 107
zejména v technické rovině a uţivatelský pohled byl pokryt nedostatečně. Zásadní nedostatky se upravovaly aţ po spuštění projektu. Technologické řešení bylo zvoleno v podobě moderního HTML 5, serverového skriptovací jazyka PHP, technologie AJAX. Jako skriptovací jazyk na straně klienta byl zvolen JavaScript s knihovnou jQuery. Databázový stroj MySQL. Všechny tyto pouţité technologie byly během vývoje shledány jako bezproblémové a plně vyhovující dané aplikaci. Bylo jen nutno důkladněji odladit náročnější AJAXovou část pro odlišné prohlíţeče s různě výkonným jádrem. Komunikace v týmu probíhala a vyvíjela se tak, jak bylo popsáno v teoretické části. Ztotoţnění a přijmutí role spolu s narůstajícím výkonem bylo velmi patrné. Také systém vedení týmu byl pouţit dle situace a uplatnilo se více modelů jednání. Jako velmi uţitečná pomůcka se ukázala také analýza a scénář rizik. Během vývoje projektu však vyšlo najevo, ţe ne všechna rizika lze takto obsáhnout, odhadnout či dostatečně popsat a zachytit jejich vazby mezi sebou. Predikce některých moţných rizik resp. jejich následků byla podceněna. Samotná propagace portálu probíhala v souladu s doporučením popsaným v teoretické části zaměřeném na online propagaci. Byly vyuţity reklamní bannery různých formátů, PR články, E-mailing a PPC kampaně. Ohledně SEO optimalizace byly provedeny pouze doporučené techniky. Portál je však tvořen málo texty, proto „přirozené“ SEO zatím nemá takový efekt, jak bylo plánováno. Je tedy nutné portál dále rozvíjet a doplnit zajímavými texty nejen pro vyhledávače, ale také pro návštěvníky. Kampaň byla správně naplánována, byly stanoveny cíle a metriky pro měření úspěšnosti kampaně. Cílová skupina, která navštěvuje portály dodavatele, však nebyla zaměřená na motorismus. Výhledově je však moţné pro propagaci vyuţít další portály, které jsou více zaměřeny na cílovou skupinu zájemců o nový vůz. K propagaci bylo také nově vyuţito slevové akce na slevovém portálu. Automobily z portálu autonabidka.cz byly vyprodány během dvou dnů a je počítáno s podobnou propagační záleţitostí i do budoucna. Nad rámec stanovené propagace se navázala se také úspěšná spolupráce s motoristickým pořadem. To vše tvoří dohromady dobrý propagační celek, který je ale nutné rozvíjet a pracovat na zvýšení návštěvnosti i konverzích z návštěv v podobě zaslané objednávky na vůz.
108
Poznatky získané v teoretické části lze úspěšně implementovat v obecné rovině na praktický vývoj internetových aplikací. Samozřejmě je vţdy nutné přihlédnout k typu aplikace a zvolit takové metodiky, které jsou pro daný projekt nejvhodnější. Ne vţdy je však moţno dodrţet všechny prvky doporučeného vývoje internetových projektů. V mnoha případech za to můţe sám zadavatel projektu, který specifikaci tak často mění, ţe jiţ projekt není udrţitelný a je ukončen. Další důvodem, proč není moţno dodrţet vhodný postup vývoje je v časovém, finančním či zdrojovém rámci. Není tedy pro důsledné dodrţení metodik prostor a některé prvky se musí obejít bez náleţité analýzy. Tato skutečnost se můţe projevit, ale také nemusí. Dokonce je to často velmi efektivní. Zejména u „rutinních“ či menších projektů, kde analýzy by sice měly být, ale jsou zastoupeny v takovém měřítku, ţe jejich absence projektu neuškodí. Vývoj internetových projektů jde velkými kroky dopředu. Pozvolna se vytrácí pouţití flash technologie jako nezbytná „efektivní“ část prezentací a je nahrazována javascriptovými knihovnami, které dokáţou vytvořit rovně zajímavé efekty. Navíc je tento kód dobře čitelný pro vyhledávače a tudíţ je to důleţitý prvek pro SEO. Trend je také patrný ve větší přehlednosti a jednoduchosti grafických i navigačních prvků. S optimalizací také souvisí stále větší důleţitost sociálních sítí, které vyhledávače jiţ postupně dokáţou indexovat a mají vliv na pozice ve vyhledávání. Proto je nutné z důvodů propagace i optimalizace věnovat sociálním sítím velkou pozornost. Stále více se také vyvíjejí mobilní aplikace. Pokud se internetová aplikace jeví jako zajímavá i pro mobilní zařízení, vytvářejí se často tyto aplikace společně. Mobilní zařízení v podobě chytrých telefonů mají stále větší podíl na trhu. Pomalu se tak přesouvají čistě internetové aplikace do mobilních. Firma, která v současné době vyvíjí pouze internetové aplikace, bude mít jiţ za několik málo let existenční problémy. Je důleţité se přizpůsobit těmto trendům a flexibilně reagovat na poţadavky trhu. S tím plně souvisí vzrůstající důleţitost mít pruţně a efektivně nastavené procesy, metodiky, technologie i formy propagace.
109
Seznam pouţité literatury Tištěné monografie 1.
FOWLER, Martin. Destilované UML. 1. vyd. Praha: Grada, 2009, Knihovna programátora (Grada). 173 s. ISBN 978-80-247-2062-3.
2.
GILMORE, Jason W. Velká kniha PHP a MySQL 5: kompendium znalostí pro začátečníky i profesionály. Vyd. 1. [i.e. 2. vyd.]. Brno: Zoner Press, 2007, 864 s. ISBN 80-868-1553-6.
3.
HOLZNER, Steven. Mistrovství v Ajaxu. Vyd. 1. Překlad Jakub Zemánek. Brno: Computer Press, 2007, 591 s. ISBN 978-80-251-1850-4.
4.
JANOUCH, Viktor. Internetový marketing: prosaďte se na webu a sociálních sítích. Vyd. 1. Brno: Computer Press, 2010, 304 s. ISBN 978-80-251-2795-7.
5.
KUBÍČEK, Michal a Jan LINHART. 333 tipů a triků pro SEO: [sbírka nejlepších technik optimalizace webů pro vyhledávače]. Vyd. 1. Brno: Computer Press, 2010, 262 s. ISBN 978-80-251-2468-0.
12. BENEŠ, Michal. Metodiky a Notace-RUP. Objektová analýza, návrh a programování [online]. 2008-02-03 [cit. 2011-12-08]. Dostupný z WWW: 13. BENEŠ, Michal. Notace UML. Metodiky a Notace-UML [online]. 2008-02-03 [cit. 201212-10]. Dostupný z WWW: 14. Co je projekt a jaké má vlastnosti. Project Management - Řízení projektu [online]. 200509-12 [cit. 2011-11-27]. Dostupný z WWW: 15. Co je to riziko a analýza rizik. In: BusinessInfo [online]. 2006-12-27 [cit. 2012-02-16]. Dostupný z WWW: 16. Communication. In: Business Dictionary [online]. [cit. 2012-02-02]. Dostupný z WWW: 17. DUDKA, Kamil. Agilní metodologie. Softwarové inženýrství [online]. 2008-02-03 [cit. 2011-12-08]. Dostupný z WWW: 18. DUDKA, Kamil. Extrémní programování. Softwarové inženýrství [online]. 2008-02-03 [cit. 2011-12-08]. Dostupný z WWW: 19. ERJAVEC, Tomaz. Standards for Language Encoding. Natural Language Server [online]. 2000-09-01 [cit. 2011-11-26]. Dostupný z WWW: 20. Google [online]. 2012-03-13 [cit. 2012-02-26]. Dostupný z WWW: 21. HCalendar 1.0. Microformats [online]. 2012-03-12 [cit. 2012-03-15]. Dostupný z WWW: 22. HLAVA, Tomáš. Spirálový model. Testování softwaru [online]. [cit. 2011-12-02]. Dostupný z WWW:
