nav line

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é architekturywebové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ě.

  1. 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.
  2. 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í.
  3. 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.
  4. 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.
  5. 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).
  6. 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í.
  7. 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“.
  8. 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ě.
  9. 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.
  10. 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. 

Schéma propojení rolí

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.

  1. 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.
  2. 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ů.
  3. 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).
  4. 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.

  1. KDO a CO?
  2. JAK?
  3. 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í.

Proces přípravy FE

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. 

Ohodnoťte článek

Jaká je vaše front-end strategie?

Související články

Vyhledávání na blogu

Webová integrace

Webová integrace jako nová oblast pro business „velkých" webových agentur.

o webové integraci

Profily blogujících