Přechod na agilní tvorbu eshopu se vyplácí nám i zákazníkům

Před léty, 2002, jsme začínali tvořit eshopy na smlouvu o dílo. Museli jsme přesně vědět, co zákazník potřebuje, kdy to jsme schopni dodat, přesnou specifikaci, cenu i termín.

Jenže zákazníci neví, co potřebují, dokud to nemají v ruce.

A tak se často dělo, že ikdyž jsme se mohli rozkrájet, zákazníci nebyly spokojeni úplně. Vždy něco předpokládali, mysleli si, viděli to jinde, vždyť tak to přece mají všichni, atp. Spokojenost ani na jedné straně.

Zpřesňování specifikace nebylo správnou cestou

Tak jsme šli cestou přesnějších specifikací.

Právník připravil přesnou smlouvu, která měla 10 stran. To nikdo číst nechce. A k tomu perfektně rozepsanou každou funkcionalitu každé z částí eshopu. Hurá, teď to bude ok.

Jenže takto rozepsané zadání mělo často i 500 stran. Z dobrého úmyslu tak byl jen alibismus - my to přece sepsané máme, tak bylo jasné, co dostanete. Jenže:

• Po dodání eshopu se zákazníci přiznali, že specifikaci jen proletěli.
• A spokojenější nebyli.

Jakmile eshop převzali, a začali jej zkoumat, mnoho věcí chtěli upravit zadarmo, protože "tak je to přece správně". Mnoho věcí zjistili, že nikdy nevyužijí. A byly málo ochotni se bavit o dalším placení, aby se dostali tam, kde chtěli být od začátku.

Místo smlouvy o dílo smlouva o spolupráci a agilní vývoj

Je normální, že má zákazník svou představu, která se liší od jeho skutečných potřeb. Ale přijde na to, až si na eshop sáhne.

Proto jsme kompletně změnili přístup. A zákazníci jsou spokojení, my taky. Zákazník dostává přesně to, co potřebuje. Za optimální náklady, a dříve. A my děláme jen smysluplnou práci, tu zbytečnou už ne, a baví nás to, a máme spokojené zákazníky.

Jak vypadá tvorba eshopu nyní?

1. Jakmile pochopíme zákazníkovy potřeby, směr a vize, připravíme pro něj demo eshopu. Bezplatně. Demo zdaleka neumí všechno, co bude potřebovat. Ale je to dobrý odrazový můstek.
2. Zákazník si demo osahá. A pokud mu přibližbně vyhovuje, domluvíme se na spolupráci.
3. Smlouva o dílo už neexistuje. Rovnou podepisujeme smlouvu o spolupráci a agilním vývoji. V té se odkazujeme na demo, které už má zákazník osahané. Tím má jasnou představu, jak co funguje a ví, že systém plní jeho očekávání.

Pak pokračujeme tvorbou eshopu:

1. V první etapě připravíme eshop, který z dema vychází. Ale je už použitelný pro komerční využití, už to není jen demo. Zákazník zná přesnou cenu i termín dodání.
2. Ve druhé etapě do něj přidáme ty části, které už jsme někdy tvořili, a do eshopu je lze implementovat s malými úpravami. Tady zná zákazník taky přesnou cenu i termín dodání.
3. A ve třetí etapě spoupracujeme na ladění eshopu. Upravují se už nasazené části, tvoří se části nové. Tady zná zákazník hrubý odhad ceny a přibližný termín dodání. Proč přibližný?

Jde o agilní vývoj. Tedy časově i nákladově nejvíce efektivní způsob vývoje software.

Zákazník sám určí, kterému jeho požadavku se máme právě teď věnovat. Sám si řídí priority.

Jakmile požadavek otevřeme, věnujeme se jen jemu. Zákazník jej dostane doručen v minimální funkcionalitě, aby si jej mohl co nejdříve osahat. A pak si sám řekne, kterým směrem dál. My ten směr zpracujeme a opět ihned dodáme zákazníkovi. A tak dokola, dokud není zákazník spokojen. Po každé iteraci jsou známy už spotřebované náklady, i hrubý odhad nákladů na další iteraci. Fakturuje se reálně strávený čas.

Proto se málokdy stane, že bychom něco mazali. Nebo se zásadně vraceli. Takže se neutrácí čas, ani peníze zbytečně za něco, co zákazník kdysi chtěl, ale už nechce, nebo chce jinak.

Zákazník dostává přesně to, co potřebuje právě teď. Řídí si vývoj sám. Efektivně, racionálně, přímočaře.

Žádné vícepráce, změnová řízení, dodatky ke smlouvám. Nic takového.

Optimální cestou k výsledku. A je spokojen.