Jaká je vaše front-end strategie?
Je front-end strategie něco, co potřebujete? Co to vlastně je? Nebo prostě ty “frontendy“ nějak uděláte? Je common front-end pro vás?
Moje běžná zkušenost z velké korporace – máme dvacet, třicet… sto interních a externích systémů. Každý vypadá jinak, ovládá se jinak, udržují se jinak – máme v tom trochu chaos, ale chceme to zjednodušit - rádi bychom nějaký společný, jednotný, uživatelsky přívětivý, lehký… „front-end“.
Front-end (FE) lze chápat, jako prezentační vrstvu vycházející z paradigmatu třívrstvé architektury a webového integrátora jako někoho kdo pomáhá s tou částí „SW ekosystému“.
V tomto článku chci shrnout principy úspěšného FE resp. „Common Front-end“ a popsat základní fáze procesu dodání nového FE.
Principy kvalitního a úspěšného Front-endu
Domnívám se, že správná FE strategie se opírá o následující principy, které pomohou zajistit, že FE je „dobrý a úspěšný“ z pohledu uživatelů a business cílů a je také realizován „správně“, tedy efektivně, transparentně a udržitelně.
- Koncentrace na uživatele
Z definice FE plyne důraz na interakci s obsluhou, prioritou je uživatel a jeho využití nabízeného FE, při zachování byznys přínosů a daných technologických podmínek. Uživatel musí být zapojen do všech kroků procesu přípravy a vývoje FE. - Business Value
I FE je systém (aplikace), která musí přinášet požadovanou obchodní hodnotu a investice do něj musí být obhajitelná. Zapojení Business lidí je klíčové po celou dobu vývoje a je zdůrazněno dále. Role Business Analytika následně reprezentovaná rolí ala Product Owner je jednou z klíčových pro naplnění tohoto očekávání. - Flexibilta
FE je část aplikace, se kterou pracuje a uživatel a ve které se pro něj zhmotňují veškeré systémy, které jsou „za“ – v nižších vrstvách architektury. Požadavky uživatelů se v čase mění, stejně tak jako požadavky businessu. Na tyto změny je nutné reagovat rychle a flexibilně. Často i bez nutnosti změny v dalších částech systému. FE musí být navržen tak, aby tyto změny bylo možné provádět, dle vzniklých požadavků – ideálně jim i předcházet. - Time to Market
Time to Market úzce souvisí s flexibilitou. Chápeme pod ním schopnost přinést provedenou změnu v co nejkratším čase uživateli. Tato potřeba se odráží v nutnosti krátkého vývojového i „release cyklu“. Jehož podmínkou je maximalizace využití již existujících částí a to ve všech krocích vývoje FE. - Měřitelnost
FE technologie umožňují detailní měření. Cílem je veškeré změny provádět na základě výsledků měření a následně změny vyhodnotit opět měřením. Vhodné zvolení metrik stavu před a po změně je podstatné pro správné zhodnocení změny. Metrik může být celá řada - chování uživatelů, chování systému (performance, např. security), ale i obchodně výkonnostní metriky (různé konverzní poměry, doby odbavení a pod). - Iterativní vývoj, agilní principy
Iterativní vývoj s kontinuálním zapojení UX/CX a business kapacit je cestou k efektivnímu dodání prováděných změn. A vzhledem k běžně nižší komplexnosti je výhodnější než „klasické vodopádové“ způsoby řízení, byť se tyto nevylučují. - Společné zapojení Business a IT a UX
Kontinuální zapojení rolí spojených s UX/CX a byznys value je důležité po celou dobu vývoje. Oddělování těchto rolí do etap neodpovídá principům iterativního vývoje a ohrožuje budoucí podobu „produktu“. - Zachování klíčového know-how
V rámci procesu dochází k získání know-how (nebo již existuje). Know-how klíčové pro vlastníka FE musí zůstat interně a řádně dokumentované. Podmínkou pro to je řádné oddělení byznys logiky od prezentační vrstvy (FE) a ideálně i identifikace pracovních rolí primárně obsazovaných interně. - Výkonnost
Pro pohodlnou práci s FE systémem je rychlost jeho odezvy při předpokládaných počtech uživatelů a cílových zařízeních. Výkonnost musí být chápána i z pohledu obchodního. V každém případě kontinuální zvyšování výkonnosti (Performance Tuning) je úzce spojeno se schopností výsledky měřit. - Bezpečnost
FE je „branou“ do společnosti a důraz na bezpečnost je zcela zásadní. Z toho důvodu nároky na ní jsou zásadní a musí odpovídat požadavkům definované v organizaci, kde se FE implementuje.
Principy napříč FE – Common Front-end (CFE)
Front endy jednotlivých systémů nežijí samostatně, ale vzájemně se ovlivňují. Proto je důležité, aby u všech byla dodržována následující sada pravidel napříč jednotlivými FE systémy.
- Konzistence
Konzistence chování, vzhledu nejen uvnitř jednoho FE systému, ale napříč systémy. Uživatelské prostředí musí být postavené na stejných principech a poskytnout jednotný a kvalitní uživatelský zážitek. - Re-use
Opakované využití existujících částí jak na rovině UI/UX, tak úrovni technologické a vývojové – schopnost využít komponenty znovu výrazně ovlivňuje Flexibilitu a Time to Market dodávky jednotlivých FE systémů. - MVP (Multi Vendor Platform) princip
Bez ohledu na zvolené technologie a nástroje, musí být zachována možnost dodávání více dodavateli a tím zajištěn Anti-Vendor lock (nezávislost na jednom dodavateli). - Kvalita
Jasné sady standardů pro zajištění jednotné kvality FE napříč systémy.
Proces přípravy FE
Proces přípravy FE je možné rozdělit do tří základních fází, které vycházejí ze SW inženýrství a které nazýváme dle otázek, na které nacházíme odpovědi.
- KDO a CO?
- JAK?
- Je to OK a běží to (správně)?
Tyto fáze se mohou vzájemně prolínat a ve schématu jsou naznačeny vztahy mezi jednotlivými kroky fází. Důležitý je také pohled náročnosti na jednotlivé etapy a kroky, který se snažíme nastínit velikostí kruhu.
V rámci procesu vývoje FE je možné identifikovat tři základní skupiny rolí:
- Business – zodpovědní za obchodní přínos systému
- UX/CX – návrh designu a funkčnosti FE
- DevOps – vývoj, testování a provoz
Zapojení těchto rolí je znázorněno barevně dle předpokládaného rozsahu jejich zapojení.
KDO a CO?
Výzkum
Výzkumem je zahájena každá výrazná změna FE. Cílem výzkumu je sběr dat (kvalitativních/ kvantitativních), jako podklad pro analytickou fázi. Data slouží k lepšímu pochopení současného ale i budoucího stavu, jeho silných a slabých stránek. Zaměřujeme se na všechny 3 klíčové aspekty – obchodní, technické i uživatelské. Stanovujeme také porovnávací metriky a provedeme jejich aplikaci na stávající stav.
Analýza
Analýza odpovídá na otázku - CO bude předmětem vývoje, tedy pomocí čeho naplnit obchodní, funkční, technické a uživatelské cíle projektu. Toto je možné pouze na základě analýzy získaných dat v předchozí fázi, která nám poskytne vhled a informace o tom, KDO je nebo bude uživatelem, jaké má potřeby, motivace a omezení, jaké úlohy řeší, jak podobnou situaci řeší konkurence, co funguje a co ne.
Již v rámci tohoto kroku jsou doporučeny postupy využívající některých návrhových technik – zejména „mockup“ prototyp budoucího stavu. Tyto postupy mají za cíl výrazně snížit pracnost tohoto kroku a přiblížit jeho výstupy business zadavateli.
V případě, že nedochází v rámci FE k funkčním změnám, může tato část být výrazně zkrácena.
JAK
Návrh
Návrh primárně odpovídá na otázku - JAK bude výsledný FE navržen. V uzavřeném prostředí je zejména technologická část podmíněna existujícím „technologickým stackem“ a využívanými vzory (totéž lze uplatnit i pro UX část návrhu).
Oproti klasickému pojetí IT návrhu, zde dochází k maximálnímu zefektivnění práce a lepšímu pochopení návrhu zadavatelem. Z pohledu obchodních a uživatelských požadavků, k tomuto slouží vizualizace návrhu, za pomocí metod rychlého prototypování (různé úrovně detailu – skici, wireframes, interaktivní HTML prototypy), které výrazně minimalizují textový popis návrhu.
Kromě zefektivnění, je cílem prototypování hlavně rychlá validace návrhu se zadavatelem a jeho otestování na budoucích uživatelích. Díky tomuto přístupu můžeme na začátku této fáze připravit několik různých variant budoucího řešení (koncepty/nápady), ty validovat a vybrat nejvhodnější z nich k dalšímu rozpracování.
Zvýšení kvality výsledného návrhu je dosaženo iterativním přístupem, kdy je prototyp několikrát otestován a znovu vylepšen. To vše mnohem dříve, než je zahájen samotný vývoj.
V prostředí agilního vývoje není nezbytné ani žádoucí, aby bylo navrženo kompletní řešení, před vývojovou fází. Vývojovou fázi je možné zahájit v momentě, kdy máme připraven kompaktní návrh klíčových částí řešení (Minimal Viable Product) a dostatečné podklady pro několik prvních sprintů vývoje. Dopracování dalších částí návrhu se pak děje souběžně se samotným vývojem. Zde je pak výrazný prostor pro úsporu času a větší flexibilitu návrhu, který může reagovat na změny cílů v průběhu implementace.
Vývoj
Vývojová fáze probíhá iterativně a to prolínáním s fází návrhu. Vhodná metodika pro iterativní vývoj je například SCRUM.
V rámci vývoje jsou klíčové role product ownera a scrum mastera. Celkový setup týmu musí stále dodržet princip společného zapojení businessu a UX.
Zapojení UX do fáze vývoje má 2 podoby:
- UX designér je součástí DEV týmu – vyjasňuje zadání, dopracovává detaily návrhu, poskytuje podporu.
- Souběžně připravuje/ dopracovává podklady pro další sprinty.
V rámci „definition of done“ každého řešeného úkolu musí být i kontrola kvality z předem definovaných pohledů – zejména funkčního a UX.
Je to OK a běží to?
QA
Přesto, že v rámci vývoje je QA (Quality Assurance) součást „Definition of Done“ každého úkolu, existují stále oblastí, které je nutné testovat samostatně nad celým produktem s přihlédnutím k vazbám na okolní systémy. Tyto testy jsou často vykonávány specialisty mimo základní agilní team. Jedná se zejména o tyto oblasti:
- Testování bezpečnosti
- Testování výkonnosti
- Integrační testy
- Standardní „check list“ testy definované zadavatelem.
- Uživatelské testování
- Expertní zhodnocení UX
Nasazení a provoz
Proces nasazení a provoz samotný je zásadně ovlivněn zvolenou systémovou architekturou a technologický stackem. Samotné problematika kontinuální integrace a automatizace deploymentu je popsána například v samostatném seriálu a přesahuje svým rozsahem tento článek.
Měření
Nezbytným krokem po nasazení je kontinuální měření „výkonu“ řešení. Toto zahrnuje činnosti spojené s měřením a vyhodnocováním nastavených metrik, technických parametrů i kvantitativních/ kvalitativních parametrů z pohledu uživatelů.
Na základě výstupů měření je možné kvalifikovaně zhodnotit naplnění stanovených cílů projektu a prioritizovat drobné i koncepční změny řešení.
Dalším přínosem měření, je umožnění dalšího zvyšování obchodního i technického výkonu.
