Každý projekt a uživatel je unikátní. Ve Futured nechceme být továrna na aplikace, proto ke každému projektu přistupujeme individuálně. Pokud je tomu klient otevřený, postupujeme při vývoji aplikace agilně.
Co je to agilní vývoj
Vyvíjet agilně znamená, že aplikace vzniká popořadě. Můžete postupovat po úplně malých krůčcích, kdy se funkce:
navrhne → implementuje → zvaliduje → upraví → přidá se k ní další.
V praxi se ale daleko častěji začíná pracovat na větším celku, který uspokojí nejdůležitější potřeby uživatelů a který na nich již rovnou můžete otestovat – říká se mu jádro aplikace aka MVP (Minimum Viable Product). Následný postup je stejný, jako jsme popsali: průběžnou validací a úpravami se k jádru přidávají další funkcionality podle priorit.
Výsledná aplikace se tedy nakonec může poměrně hodně lišit od původních představ zadavatele, ale (když se to dělá správně) pokrývá ty nejdůležitější potřeby většiny uživatelů.
Hlavním vodítkem, kterým směrem se dál vydat, je přitom kontinuální zpětná vazba, a to jak od klienta, tak od uživatelů.
Představa, že už na začátku víme vše, je mylná
A to je za nás hlavní důvod, proč se vydat agilní cestou.
U fix time fix price (FTFP) projektů musí být klient schopný přesně popsat, jaký produkt chce. Trh se ale neustále mění a vyvíjí, a uživatelé jsou nároční: očekávají kontinuální zlepšování. Co bylo good enough před rokem, to už je dnes zastaralé.
Kolik to stojí
V agilních projektech se klientovi účtuje pouze skutečně odpracovaný čas. Pokud je projekt vedený dobře, může z původně zamýšleného budgetu dokonce i ušetřit.
U FTFP projektů je koncová cena, termín i rozsah projektu stanoveny hned na začátku spolupráce. Zní to jako komfortní vím-na-čem-jsem řešení, které ale finančně není fér ani pro jednu stranu. I při velmi dobrém zadání a detailní analýze dodavatel často není schopen odhalit veškeré podrobnosti a úskalí projektu, a zpravidla pak nastanou dva scénáře:
- Dodavatel nechce projekt podhodnotit, často tedy cenu stanoví vyšší. Pokud se mu práci podaří zvládnout rychleji, nemá ale tendenci to reflektovat při fakturaci – klient pak platí i za práci, která se nestala.
- Pokud naopak dodavatel cenu neodhadne správně a překročí čas/kapacitu, má zpravidla dvě možnosti – náklady pokryje ze svého, nebo (a to od klientů slýcháme poměrně často) zvolí variantu, kdy je klient nucen platit vícepráce.
Přání vs potřeba
Ve Futured neplníme slepě zadání – baví nás nad ním kriticky přemýšlet a hledat ta nejlepší řešení. O tom je podle nás skutečná spolupráce. Klientům proto pomáháme naplnit skutečné potřeby projektu, které mohou být leckdy odlišné od původních představ a přání, se kterými nás oslovuje. Nicméně… vedou k opravdovému cíli: k aplikaci, která posouvá klientův byznys a kterou lidé chtějí používat.
Okamžitá zpětná vazba
V jádru agilní spolupráce je intenzivní komunikace s klientem, který se kromě projektového manažera pravidelně setkává i s designéry a konkrétními vývojáři, a rovnou tak může přetavit byznys záměry do technicky realizovatelné podoby, a případně se nechat inspirovat našimi zkušenostmi.
Jak to prakticky funguje
Klient je součástí našeho Slacku (či jiného nástroje, který nám umožní komunikovat stejně, jako bychom pracovali v jedné kanceláři), kam může své otázky či požadavky obratem přidávat. Koncepčnější debaty pak probíhají formou online setkání. Potkáváme se ale i osobně, rádi si uděláme výlet do Vídně či Lausanne, abychom klienty poznali i z jiné stránky.
Frekvence a forma setkání přitom vychází z potřeby a zájmu klienta, ale obecně se rádi vídáme alespoň jednou za dva týdny.
Nevýhody agilního vývoje
Určitá míra nejistoty přináší diskomfort: Nevím na korunu přesně, kolik to bude stát. Nevím, jak přesně bude výsledek vypadat… Aplikace (a software obecně) ale není ready made řešení. Právě její dokonalé přizpůsobení potřebám uživatelů je onou unikátní hodnotou, kterou agilní vývoj umožňuje.
Varianta FTFP může pro klienta vypadat lákavě – zná budget i termín dodání aplikace. Zpravidla brzy po začátku vývoje se ale zjistí, že se mění trh nebo potřeby klienta/uživatelů. FTFP projekty pak často končí tak, že klient dostane něco, co „nepotřebuje“.
První agilní projekt? Tři tipy, jak se v něm cítit komfortně
Získejte si na agenturu zpětnou vazbu od jiného klienta.
Začněte v malém (MVP) a vyzkoušejte si, zda chemie funguje a máte ze sestaveného týmu dobrý pocit. Tak dobrý, že mu svěříte důležitou část svého byznysu.
Pokud se bojíte, že bude aplikace výrazně dražší, než jste v úvodu zamýšleli, nebojte se definovat strop rozpočtu. Chtějte mít neustálý přehled o tom, kolik je z něho už utraceno / kolik peněz zbývá.
Kdy říct agilnímu vývoji NE
Ve Futured věříme, že pokud jsou jasně nastavená očekávání, je agilní vývoj pro obě strany vhodné řešení. Jeho použití je ale problematičtější například u státních zakázek, které mají konečnou cenu. I tam lze ale ponechat část budgetu na funkcionality, které vykrystalizují v průběhu vývoje základu aplikace, a tím si nechat volné ruce.
Text navazuje na úspěšný rozhovor s Vlaďkou.
Case study: Agilní (spolu)práce na aplikacích DECATHLON
Na příkladu klienta DECATHLON, pro kterého vyvíjíme už několikátou aplikaci, vám nastíníme, jak může agilní spolupráce v praxi vypadat.
Na úvod je ale důležité připomenout, že každý klient a projekt je unikátní, proto tento příklad neberte jako manuál. Realita je mnohem barevnější a plastičtější. Ostatně o tom celý agile je: o flexibilitě.
DECATHLON Click & Collect
Odjíždíte na dobrodružnou dovolenou a předpověď hlásí déšť. Potřebujete pláštěnku, ale nechce se vám zbytečně běhat po obchodech. A na doručení z eshopu je už málo času…
Řešení může být kombinace obojího: Zboží si vyberete na eshopu a za hodinu si ho už vyzvedáváte na prodejně. Když na pobočku dorazíte, obsluha několikrát klikne do tabletu a přesně ví, jaký balíček vám předat, i to, zda je již zaplacený či nikoliv. Aplikace ale pomůže i se složitějšími situacemi vrácení zboží na sklad.
Přesně takovou aplikaci jsme pro DECATHLON vyvinuli. A nadále ji vylepšujeme.
Jak vypadá agilní spolupráce s DECATHLONem
Tým DECATHLONu se na nás obrátil s nápadem na aplikaci, ke které měl definovaný měsíční budget. Následná tvorba konkrétního zadání probíhala v úzké spolupráci s námi.
V iniciální (nejintenzivnější) fázi projektu jsme představu klienta, která zahrnovala i požadavky pracovníků prodejen, převzali a náš design tým nachystal ruku v ruce s vývojáři optimální způsob jejich realizace, a to tak, aby používání bylo pro prodavače intuitivní a vývoj nebyl zbytečně komplikovaný a nákladný.
Po každém přidání nové funkcionality nebo provedení změn sesbíralo IT oddělení DECATHLON zpětnou vazbu od pracovníků na prodejnách, a připomínky spolu s námi přetavilo v nové zadání.
Neplýtvali jsme tedy časem na něco, co potenciálně nikdo nepotřebuje.
Místo toho jsme se zaměřili na naplňování potřeb a odstraňování překážek konkrétních lidí, kteří s aplikací pracují nebo pracovat budou.
Přestože je základ aplikace již více než rok hotový, s týmem DECATHLONu stále spolupracujeme na rozvoji dalších funkcionalit, které prodavačům zjednodušují práci. Přímo v aplikaci tak už nyní lze zaplatit, změnit cenu, nebo objednávku vrátit do centrálního skladu. A DECATHLON s ní má do budoucna velké plány.
Spolupráce probíhá organicky a bezešvě.
Klient je součástí našeho Slacku, takže v případě nově vzniklé otázky či potřeby jednoduše napíše zprávu do společného channelu, kde se mu ozve buď projektový manažer nebo přímo vývojář. Na větší požadavky si domlouváme online hovor, kde si vše vyspecifikujeme a doptáme se na „detaily”. Následně odhadneme časovou náročnost a po odsouhlasení kalkulace se rovnou pustíme do práce.
Spolupráce je tak velmi flexibilní pro obě strany.
––
Úspěšnou aplikaci můžeme vytvořit i pro vás.
Napište Lukášovi, který Futured založil a vede: [email protected] & +420 605 312 459
Chcete se k nám přidat? Aktuálně hledáme hned několik kolegů.
Ozvěte se Míše a pobavte se o možnostech spolupráce: [email protected] & +420 739 106 507.
