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.
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.