Když vidíte jen špičku ledovce, aneb proč se vyvarovat změnových požadavků při vývoji webu

Při vývoji webu není možné všechno naplánovat dopředu. Časem zjistíte, že potřebujete navíc kalkulačku, nějakou tu landing page nebo obsáhlejší menu. Během vývoje by ale mělo takových změnových požadavků být co nejméně. Za každou změnou mohou být dlouhé hodiny kodérské práce. To pak navyšuje čas potřebný k dokončení webu i jeho cenu.

V AITOMu označujeme tyto práce jako „změnové požadavky“ (ang. “Change requests”) - jsou to úkoly a zadání, které se provádí nad rámec zadání projektu a nejsou tedy obsaženy v objednávce či smlouvě. V rámci celého projektu máme vypracované detailní zadání a toho se držíme. A především podle tohoto zadání máme nastavený harmonogram prací tak, abychom jej mohli stihnout.

Jak vidí změnový požadavek kodér?

Moderní weby jsou provázané do hloubky. Zdánlivě malá úprava jako například posunutí loga, může být z hlediska kódu velmi náročná. A pokud je web optimalizovaný pro mobilní zařízení, je tedy responzivní, jsou tyto změny o to náročnější.

Takový web si můžete představit jako dům. Představte si, že si vyberte typový dům z katalogu a začnete stavět. Když máte hotové základy, rozhodnete se, že chcete jen naprosto drobnou změnu - rozšířit jeden pokoj o půl metru. To je u domu přece zanedbatelný rozdíl, že? Jenže je potřeba vzít v úvahu možné ovlivnění statiky, přepočítat materiál, překreslit projekt a samozřejmě také předělat již hotové základy. Z pohledu uživatele drobná změna v zadání poté může znamenat zásadní rozdíl v ceně i termínu realizace.

To, co nakonec uživatel vidí, je tedy jen špička ledovce. Nestačí jen upravit kód, musíte také vše otestovat a zkontrolovat ve všech možných zařízeních.

Jak vypadá změnový požadavek

Kodérův  ledovec

Ukažme si na příkladech jednotlivé kroky, jak změnové požadavky řešíme v AITOMu. Každá kvalitní vývojářská agentura má nějaký zavedený postup, jak veškeré změny v kódu předávat na finální prezentace tak, aby nemohlo dojít k chybě, odstávce a podobně. Představme si modelové příklady:

Příklad 1: Úprava tlačítka

Krok Časová
náročnost
Kodér si nastuduje zadání a najde optimální řešení 10 minut
Založení feature branch (v podstatě kopie kódu) 5 minut
Spuštění kopie stránek na lokální serveru ve svém počítači 10 minut
Provedení příslušné úpravy 5 minut
Otestování změny ve všech potřebných zařízeních 30 minut
Nahrání změny zpátky na produkční server 10 minut
CELKEM 70 minut

Příklad 2: Přidání dalších položek a efektu slideru

Krok Časová
náročnost
Kodér si nastuduje zadání a najde optimální řešení 10 minut
Založení feature branch (v podstatě kopie kódu) 5 minut
Spuštění kopie stránek na lokální serveru ve svém počítači 10 minut
Provedení příslušné úpravy 120 minut
Otestování změny ve všech potřebných zařízeních 30 minut
Nahrání změny zpátky na produkční server 10 minut
CELKEM 185 minut

Vidíte, že i na pohled malá změna zabere kvůli technologickému procesu velké množství času, kterému se prakticky nejde vyhnout. V AITOMu řešíme přesuny mezi lokálními servery a produkčními automaticky.  Kodér 3x klikne a o zbytek se postará automatický deploy. Tím jednak eliminujeme chybovost a také dramaticky snižujeme časovou náročnost veškerých změn.

Dvakrát kresli, jednou kóduj

Obecně vzato je lepší se při vývoji změnovým požadavkům vyhnout. Pokud si dopředu dobře připravíte podklady, nebudete muset změnové požadavky řešit. V AITOMu kompletní podobu webu připravujeme v rámci zadání – ve vstupní studii. Díky tomu přesně víme, kde a jaká tlačítka budou, zda a jaké chceme carousely, připravíme si responzivní  verzi atd.

Zvažte tedy dopředu, co na webu skutečně potřebujete. Zamyslete se nad rozvojem webu do budoucna. Chcete rozšiřovat portfolio na webu? Řekněte o tom vývojářům rovnou. Připraví dopředu takový kód, který umožní jeho rozšíření. Je mnohem lepší v první fázi nevyužít potenciál webu naplno než do stránek v budoucnu přidávat komponenty, na které není web od začátku stavěný.

Co když už změnové požadavky nastanou?

Někdy se změnovým požadavkům vyhnout nelze. Například pokud během realizace webového projektu dojde ve vaší firmě k výrazným změnám, např. v portfoliu služeb apod., musíme na toto jako vaše agentura reagovat. V zásadě existují základní dvě varianty, jak se s těmito nevyhnutelnými změnovými požadavky poprat.

a) Změnové požadavky, které je nutné zapracovat do webu v průběhu jeho realizace

Pokud se jedná o nutné změny, které jsou svým charakterem pouze takové, že ovlivní např. jen textový obsah webu, není obvykle problém tyto změny do vývoje zařadit okamžitě a díky předem domluvené rezervě nebývá problém s dodržením termínu. Pokud se však jedná o náročnější úpravy, kdy je potřeba změnit design, strukturu nebo zásadní funkce webu, je potřeba počítat s tím, že se dokončení webových stránek může posunout a případně také prodražit.

b) Změnové požadavky, které je možné zapracovat do webu po jeho spuštění

Pokud se nejedná o dramatické změny, navrhujeme většinou společně s vývojáři zařadit je do 2. fázi realizace, tedy po dokončení webu. Tyto požadavky se v průběhu tvorby webu postupně hromadí a po spuštění webu se následně vyhodnotí jejich priority a řeší se formou dodatků ke smlouvě či objednávce.

Nechte si poradit

Nejdůležitější je zachovat si chladnou hlavu a spolu s vývojáři popřemýšlet nad tím, které změny je třeba na realizovaném  webu promítnout ihned, aby byly implementovány ještě před jeho spuštěním, a které je možné odsunout na seznam budoucího rozvoje webu. Vysvětlete si změny, jejich význam pro vaši obchodní strategii, náročnost jejich realizace a nechte si navrhnout takové řešení, které bude pro váš byznys to nejpřijatelnější. Vždy děláme maximum, abychom společně s klientem našli správný kompromis.

Zpět na články