V článku Koala42 a vývoj aplikace jsme probrali pěkně popořádku, jak pod našima rukama ve spolupráci s klienty vznikají webové nebo mobilní aplikace. Teď je načase zavřít učebnici a ukázat si, jak naše teorie vypadají v praxi.

CTO Koaly Filip Molčík v roce 2017 navázal spolupráci s Qapline, českým expertem na logistiku kamionové přepravy, který potřeboval navrhnout  interní systém pro správu objednávek a propojování zákazníků s přepravci nebo se sklady zboží. Co byla na začátku taková lepší excelovská tabulka, se za 4 roky rozvinulo v robustní ERP (enterprise resource planning) systém a ambice se teď upírají k umělé inteligenci.

Byznys firmy Qapline si člověk může představit jako takový Uber pro nákladní přepravu. Kmenový tým tvoří dispečeři, kteří komunikují se sítí nasmlouvaných řidičů a domlouvají co nejefektivnější přepravu zboží, ať už jde o jednotlivé palety, nebo celé kamiony. Snaží se využít každý centimetr volného místa v nákladním prostoru na kilometry, které řidič musí tak jako tak na svých trasách absolvovat.

Pokud kamion veze zakázku do Německa a měl by se vracet zpátky do Čech nevyužitý, naplánuje mu Qapline dokládku. Je to doslova win-win situace – zákazník dostane zboží z místa A na místo B za příznivou cenu a kamion nejede zbytečně prázdný.

Qapline měl na svůj nový interní systém několik důležitých požadavků. Potřebovali, aby fungoval v reálném čase spolehlivě a bez zádrhelů, tedy aby byl pro dispečery naprosto intuitivní. Dále šlo o automatizaci kroků během zadávání poptávky a během fakturace, aby se maximálně šetřil čas. Nakonec chtěl Qapline do systému napojit databázi, aby mohl algoritmus systému pro jednotlivé zakázky navrhovat ideální propojení s přepravcem.

Aplikace, kterou jsme pro Qapline vyvinuli, funguje následovně:

Poptávka se vyexportuje a pošle dopravcům, které systém nabídl, respektive jejich dispečerům. Po odsouhlasení zákazník dostává potvrzenou objednávku s fakturovanou cenou. Podle profilu dopravce se nastaví i jazyk exportované objednávky a faktury, aby byly anglicky, německy nebo polsky – jak je potřeba.

Nejnovější přírůstek do sady funkcí je právě automatická fakturace, která je propojená s účetním softwarem POHODA. Tým Qapline nemusí plýtvat časem na manuální zadávání čísel do databáze, na ruční sčítání a odčítání. Místo toho se může věnovat obchodu, hledání nových dopravců a potřebám konkrétní zakázky.

V nejbližší budoucnosti nás čeká vylepšit napojení na systém POHODA, aby byla všechna data na jednom místě a žádné procesy nemusely probíhat bokem v excelových tabulkách. Aby bylo možné počítat cashflow, zobrazovat přehledné grafy s trendy – a nakonec aby třeba nutnost používat POHODu zanikla úplně.

Nabízel by se i vývoj mobilní aplikace, ale zrovna pro Qapline to právě teď není aktuální. Dopravci a řidiči-živnostníci jsou zatím zvyklí dostávat objednávku psaným emailem a pokyny ve formátu PDF. Až bude zákazník ale připravený na změnu, tak pro nás nebude problém novou platformu doplnit.

V logistice jsme samozřejmě byli úplní nováčci, takže bylo potřeba, abychom otevřeli hlavy a nechali se vzdělat. Do Qapline jsme se šli podívat, nechali si vysvětlit procesy a vlastnoručně si zkusili odbavit dopravu. Během toho jsme přemýšleli, jak potřeby Qapline skloubit s tím, co víme o uživatelské zkušenosti a o tom, jak lidé reagují na různé typy rozhraní.

První MVP (minimal viable product) před lety obsahoval to nejzákladnější, co zjednodušovalo dispečerům práci. Od té doby jsme hodně pokročili, protože jsme díky agilnímu vývoji mohli operativně reagovat na vývoj technologií.

V případě Qapline se povedlo optimalizovat přechod na Google cloud platformu. Použili jsme Kubernetes a nastavili jsme, aby se server vypnul v 5 hodin odpoledne, když dispečeři přestanou být v aplikaci aktivní. Server díky tomu neběží naprázdno a šetří se energie a peníze.

Potřebuje i vaše firma interní systém, který chytře automatizuje procesy a šetří čas? Dejte nám vědět! Budeme o vás pečovat stejně svědomitě jako o Qapline.

Přesun serveru do Google cloudu nebyl od začátku hotová věc. Naše rady často nefungují hned. V případě Qapline jsme navrhovali: převeďte aplikaci do Googlu, abyste nemuseli platit 50 tisíc měsíčně za údržbu místního serveru. Google je dnes záruka, jistota, zabezpečení.

Přeci jen, argumentovali jsme, spediční služba musí fungovat spolehlivě. Každý výpadek může způsobit obrovské potíže. Stačí jeden nešikovný úklid v datovém centru, vytažený kabel – server se odpojí, procesy stojí a škoda se dá měřit v řádu stovek tisíc. Na podobné hrozby se snažíme myslet a upozorňovat. V případě Qapline jsme nakonec krok tímto směrem udělali.

Technologie nejsou jediná oblast, ve které se snažíme klientovi dobře poradit, když nás napadají praktická řešení do budoucna. Protože sami těžíme ze zkušeností s prací v metropoli, můžeme pomoci našim klientům z menších měst i co se týče financování, networkingu, sociálních sítí a podobně. Věříme v solidaritu a výměnu zkušeností. Když se bude dařit jim, bude se dařit i nám.

Podle webu Bankmycell se počet uživatelů smartphonu s internetem v roce 2021 vyšplhal na 6,37 miliard. Není tedy divu, že poptávka po mobilních aplikacích jde s tímto trendem ruku v ruce. Zvažujete v rámci svého byznys záměru aplikaci taky, ale nevíte, na kolik vás přijde peněz a hlavně proč? Pak je tento článek pro vás. 

Jen v samotných Čechách mají firmy na výběr mezi velkým množstvím softwarových studií, která dokážou klientovi postavit aplikaci na míru tak, aby pomáhala plnit jeho podnikatelský záměr. Tito klienti se snaží mezi vývojáři zorientovat a vybrat toho pro ně nejlepšího. Ale pokud nejdou vyloženě na doporučení a váhají, často sklouznou k tomu, že se rozhodují podle ceny za vývoj. 

V článku, který ukazuje vývoj aplikace krok za krokem, jsme nastínili, v čem spočívají specifika a výhody agilního vývoje. Většina vývojářů má zavedenou právě tuto metodiku a na faktorech, které cenu aplikace ovlivňují, se víceméně všichni shodují.

Na začátku nového projektu tyto faktory s klientem procházíme v rámci analýzy jeho potřeb, abychom zjistili, jak komplexní si aplikaci představuje. V tomto článku si je shrneme pod pět základních otázek a připojíme k nim zároveň naše doporučení nebo komentář k dobré praxi.

První bod, který je potřeba si vyjasnit, je, kolik aplikací se vlastně bude vyvíjet. Ta, kterou uživatel uvidí a bude ji používat ve webovém prohlížeči, je na frontendu. Další ale poběží v pozadí na backendu a bude organizovat data vložená uživatelem. Potom může být žádoucí vytvořit i mobilní verzi aplikace, jednu pro iOS, další pro Android. Nakonec bude potřeba připravit i administraci, aby si klient mohl sám vyměňovat obsah a grafické prvky. Než jsme se nadáli, už vyvíjíme 5 aplikací.

Tato otázka navazuje na první, protože technologie se vybírají podle platforem. Situace se nám rozpadá na další dva scénáře.

Aplikace může být plánovaná pro byznys, který už je delší dobu zavedený a má určitou finanční stabilitu. Dá se očekávat, že bude aplikace každý měsíc rozšiřována o nové funkce a bude muset podporovat poslední vychytávky nových smartphonů. V takovém případě je lepší ji psát nativně. Pro Android se použije Kotlin/Java a pro iOS Swift.

Budoucnost ale může být nejistá –  klient je například začínající startup, aplikace může být zamýšlena jako zkušební rozšíření portfolia, případně má plnit jen „office“ funkce jako nástavba na informační systém. Takový projekt je lepší psát hybridně, např. v React Native. V těchto situacích se taky dá využít technologie Progressive Web App, tím stáhnout náklady ještě níž a ušetřit čas. Od rozhodnutí o platformách a technologiích se dále odvíjí počet vývojářů v týmu. S hybridním vývojem si poradí i dva programátoři (jeden píše backend a druhý frontend pro web, iOS i Android), kdežto k nativnímu vývoji budou potřeba vývojáři čtyři – jeden na backend a pak tři jednotlivě na web, iOS a Android frontend.

Stejně jako vývojovou fázi i design lze řešit různými způsoby. Nejlevnější a zároveň nejjednodušší variantu pro následný vývoj představuje design vycházející ze stanovených „guidelines“ od společností Apple a Google. Guidelines tvoří ucelený systém standardizovaných prvků designu, které využívají nativní Apple a Google aplikace.

Pokud se budeme držet Apple nebo Google guidelines, aplikace bude i po změnách vypadat jako „každá jiná od Applu nebo Googlu“. Je to sice levnější řešení, ale Váš brand určitě neposílí.

Jaké jsou výhody předepsaného systému? Uživatel se s dotyčnými prvky setkal již mnohokrát a jejich ovládání zná. Je to trochu jako byste se přestěhovali do identického domu, jen s odlišnými barvami na stěnách a novou kuchyňskou linkou. Navíc jsou tyto prvky efektivní. Počítá se s jejich použitím v různých prototypovacích nástrojích. Stačí je poskládat do požadovaného layoutu a přizpůsobit k obrazu svému. 

Abychom tomu předešli, raději navrhujeme vlastní guidelines. Je to sice o něco dražší, ale klient dostane unikátní designový systém sestavený jen pro jeho aplikaci. Pak záleží jen na něm, jestli dá přednost originálnímu vzhledu, nebo se spokojí s ekonomickou variantou, v rámci které se guidelines jen „posunou“ do vývojové fáze a staví se z nich aplikace za běhu.

Doporučujeme raději věnovat péči UI designéra opravdu každé obrazovce. Stává se, že guidelines zcela nepokryjí potřeby aplikace a na některých místech je potřeba vymyslet řešení na míru. Ve fázi návrhu lze také pohodlně ověřit, zda mají jednotlivé obrazovky aplikace logickou návaznost a zda je prostředí snadno ovladatelné.

Tato otázka má na cenu největší vliv a větví se do dalších témat. Aplikace může být jednoduchá, obsahovat jen pár obrazovek a žádnou backendovou infrastrukturu. Může ale být i složitá až hyper-složitá, kdy už v sobě spojuje prvky sociální sítě se strojovým učením nebo rozšířenou realitou.

Během úvodní analýzy zjišťujeme, jak důležité jsou pro klienta funkce v následujícím seznamu. Dáváme mu je do souvislosti s našimi zkušenostmi, s produkční náročností a s cenou, aby se sám mohl rozhodnout, jestli jsou to pro něj „must have“, nebo jen „nice to have“.

Jak jsme řekli v článku o fázích vývoje, ne vždy zbývá klientovi místo v budgetu na hloubkové, automatizované testy. Patří ale mezi naše nejvýraznější doporučení, aby se tato metoda testování aplikace využila, protože dokáže mnohem rychleji než člověk otestovat všechny možné průchody aplikací, jejichž počet s přidáváním funkcí exponenciálně roste.

Automatické testy projdou nejdůležitější scénáře použití (login, platba, úprava profilu…) a zjistí, jestli u nich s novou aktualizací nenastala regrese – tedy situace, kdy nově přidaný kód rozbije starší, již otestovaný kód v jiné části aplikace.

Po tom, co společně s klientem provedeme analýzu jeho potřeb, potvrdíme si sadu funkcí a design, si vezmeme 14 dní na to, abychom připravili klikací prototyp. Na jeho základě se dá udělat první hrubý odhad celkové ceny vývoje.

1. Hrubší odhad po odsouhlasení UX prototypu, a to na základě podobnosti s jiným projektem.

2. Přesnější odhad při naceňování jednotlivých sprintů, kdy klientovi komunikujeme částku, jakou ho bude stát dalších 14 dní vývoje.

Postupně jak se agilní metodou posouváme vpřed a odškrtáváme seznam požadavků, je obrys konečné ceny čím dál zřetelnější. Tímto stylem práce za 4–6 měsíců dorazíme k MVP, kdy klient dostane do ruky první funkční verzi aplikace. V tuto chvíli si může vyhodnotit, kolik z původně naplánovaných funkcí skutečně chce dotáhnout, v jakém pořadí po sobě a v jakém časovém horizontu. Touto dobou je spolupráce zpravidla už běží jako na drátkách a pro klienta není těžké se rozhodnout, kolik ještě chce do aplikace investovat času a prostředků, aby byla tip ťop a podle jeho představ.

Řekněte nám, o jaké aplikaci přemýšlíte,

a my se vám rádi ozveme s nezávazným návrhem.

Pokud byste si rádi přečetli více o naší práci, doporučujeme rozkliknout náš BLOG, na kterém shromažďujeme například rozhovory s našimi klienty nebo různé tipy a triky z oblasti technologií a podnikání.

• Řízení projektu metodou waterfall
• Proč stále častěji dostává přednost agilní vývoj
• Design v pojetí Koaly
• Postupné iterování aplikace
• Dbáme na zastupitelnost
• Komunikace mezi vývojářem a klientem
• Testování, opomíjená část vývoje
• Vydáním příběh nekončí

Agilní vývoj si naproti tomu klade praktické cíle v kratších úsecích – sprintech. Na začátku každého sprintu, který trvá 14 dní, se definují jednotlivé dílčí úkoly (tasky) a programátoři je potom postupně z projektu ukrajují. U agilní metody se nedá závazně říct, jestli bude celý projekt trvat tři měsíce, nebo šest, ale klient může vývoj daleko více ovlivňovat. Na konci každého sprintu dostává report, ve kterém vidí, o jaký kousek vývoj zase pokročil kupředu, a může podle potřeby upřesnit zadání. 

Pokud se vrátíme k metafoře s automobilem – nedodáváme klientovi po částech precizně sestrojený volant, nápravu, karoserii a tak dále. Dostane od nás rovnou koloběžku, která ho dopraví z bodu A do bodu B. V tu chvíli může aplikaci vzít a ověřit si její základní funkce v praxi se zákazníky.

Agilní vývoj počítá s tím, že se během projektu budou dít změny, takže když se s klienty bavíme o ceně a jejím zafixování, docházíme k tomu, že je pro obě strany lepší mít flexibilní budget. Vývojář pak nemá svázané ruce, když ze strany klienta přijdou v průběhu vývoje nové požadavky, a kromě toho dokáže pružně zakomponovat novinky z technologického pokroku.

Podle náročnosti aplikace na programování případně jeden až tři z celkového týmu 13 zkušených vývojářů. Máme v týmu lidi s širokým záběrem v technologiích a programovacích jazycích, ale zároveň držíme kolektivní know-how projektu, abychom zaručili zastupitelnost a aby se sprinty v případě nemoci nebo náhlého výpadku lidí nezadrhávaly. Píšeme kód i dokumentaci tak, aby mohl kdokoli do projektu naskočit, rychle se zorientovat a navázat na kolegovu práci.

Je pro nás úplně běžné se s klientem synchronizovat denně nebo párkrát do týdne. Jsme dostupní na telefonu, na e-mailu, nebo chatovacích nástrojích. Všechny požadavky sepisujeme do backlogu, který v každém daném okamžiku přesně odráží současný stav aplikace. Máme potom pečlivý záznam o tom, kde zrovna ve vývoji jsme a na čem jsme se s klientem domluvili.

Každý projekt postupně roste. Koloběžka na sebe nabaluje další a další funkce a zakomponovat je bývá těžší než na začátku, protože už se jedná o změny v mnohem komplexnějším celku. I přesun tlačítka na jiné místo může trvat půl dne, protože k tomu nestačí Ctrl+X a Ctrl+V.

Vývojář musí nejdřív zjistit, co všechno změna ovlivní, musí ji naplánovat, provést a otestovat. Na backendu se může snadno stát, že se i menší změna nečekaným způsobem projeví v úplně jiné části aplikace.

O časové náročnosti ale s klientem otevřeně mluvíme a na konci sprintu ukazujeme, kolik hodin se strávilo na kterém úkolu, abychom případně mohli upravit priority.