< Zpět na články

PMkoš – projekťákem na Bazoši

Budeme dělat appku pro bazoš.cz! Bylo nám jasné, že na tuhle aplikaci lidé uslyší. Vždyť kdo by neznal Bazoš – platformu, kde prodávají máminy kamarádky i mí bývalí spolužáci, prostě několik generací. A sehnat se tam dá VŠECHNO. O motivaci tedy v týmu nebyla nouze.

První schůzka s panem Bazošem (tak interně říkáme majiteli největšího inzertního portálu u nás) proběhla nad očekávání dobře a rychle jsme se dohodli na podmínkách spolupráce. Pro mě to je výjimečný klient, vždyť je to člověk, který v Česku vymyslel internet a internetový byznys.

Rozsah dodávky

Měli jsme dodat nativní aplikace pro dvě platformy – Android a iOS. Mobilní aplikace ke svému fungování potřebují backend. Jde o logiku na serveru, se kterou aplikace komunikují – dostávají a vracejí informace od uživatele. Tudíž většina dat, která v aplikacích jsou, chodí přes backend. V našem případě Bazoš již samozřejmě backend má a využívá ho ke komunikaci s webovým klientem bazos.cz.

Co se děje před vývojem

Když se dohodneme na spolupráci na nějakém novém projektu, obvykle následuje buď analýza nebo specifikace produktu. Nejprve si ale u každého jasně řekneme, komu aplikace slouží a jaký je její cíl. Na Bazoši následovala specifikace funkcí, které bude aplikace mít. Specifikace znamená seznam funkcí – jednoduše co bude aplikace umět.

Pokračovali jsme UX návrhem. Při navrhování aplikace bereme v potaz nejen současné a nastupující trendy, ale také provádíme analýzu konkurenčních aplikací. Výstupem UX návrhu je wireframe, česky mu někteří říkají dráťák. Wireframe shrnuje všechny funkce aplikace v černobílém přehledu obrazovek. Hlavní roli hraje použitelnost a jednoduchost.

Na UX navazuje grafická podoba aplikace – design. Častá chyba, kterou vídáme u ostatních mobilních vývojářů, je, že místo designu jenom obarví wireframe. Tak se ale grafika nedělá. Od klienta jsme pro design měli velice jednoduché instrukce – oranžovou ano, červenou ne.

Vyvíjíme

Na vývoj aplikace jsme měli dost času. Úvodní schůzka byla v říjnu roku 2016 a až na léto 2017 byla naplánovaná televizní kampaň. Vše jsme měli s přehledem stihnout. Není pro nás tedy klíčový termín dodání ani přísný rozpočet. Nastavili jsme na projektu jednoznačnou metriku – kvalitu.

Teď trochu odbočím k metodice. Na projektech je vhodné nastavit jasnou metriku, která je měřitelná. Pokud jde o projekt s omezeným rozpočtem, jde nám o ušetření hodin. Klasickým příkladem je MVP – minimum viable product, kde si zákazník chce ověřit funkčnost své myšlenky. V takovém případe příliš neinvestujeme do grafiky, ani do „fancy“ funkcí, ale chceme aplikaci rychle dokončit, aby se dostala mezi testovací skupinu lidí.

Druhou možností je omezený čas. Nasadíme na projekt větší tým, což nám dovolí stihnout termín. Běžně se jedná o termíny domluvených mediálních kampaní nebo testování s většími skupinami lidí. Pozor na zvětšování týmu až ke konci projektu, to totiž dost dobře nefunguje. Tato pravda je již přes 20 let známá.

Na projektu je třeba definovat parametr, který bude měřit to, co potřebujeme. Pozor ale na správný výběr parametru, protože ve finále mají týmy snahu měřítka plnit a to se může otočit v neprospěch projektu. Například kniha 97 pravidel projektu dává konkrétní příklad: U týmů, které měří počet odpracovaných hodin, bude mnoho odpracovaných hodin. To ale nemusí znamenat, že tým vytváří kvalitní produkt.

Druhé odbočení k metodice odpovídá na otázku, jak zajistit, aby členové týmu dokázali o menších otázkách rozhodovat sami. Dám příklad. Když nastoupil nový ředitel do jedné nízkonákladové letecké společnosti, čekaly ho nemilé povinnosti – vyřešit stížnosti zákazníků. Ty se totiž přes celou korporátní pyramidu dostávaly až k samotnému řediteli. Jednou ze stížností byl i požadavek podávat oříšky na palubě zdarma. Rozhodovat o takových drobnostech je samozřejmě nesmírně vyčerpávající. Proto vydal jednoznačné rozhodnutí, které bylo snadno interpretovatelné – „Chceme udržet cenu nízko“. Vždy, když se poté měli zaměstnanci o nějaké otázce rozhodnout, rozhodovali se v souladu s tímto jednoduchým a jasným pravidlem a nepotřebovali se pokaždé radit s ředitelem.

Vraťme se k Bazoši, kde jsme jako hlavní metriku nastavili kvalitu. Pokud měli členové týmu možnost napsat funkci buď robustně a s větší časovou dotací, nebo rychleji, ale s technickým dluhem (což by bylo vhodné například pro MVP), dokázali se sami rozhodnout pro první variantu.

Cesta do storu a reakce uživatelů

iOS aplikaci jsme vydali na začátku května roku 2017 a byla vřele přijata komunitou. Naprosto opačně tomu ale bylo u Android aplikace. Po vypuštění aplikace následovalo pro celý tým obrovské překvapení, jelikož žádná naše aplikace ještě nevzbudila tak rozporuplné ohlasy. Na jednu stranu nás lidé chválili za funkční appku, na druhou nám doporučovali jít si usekat ruce a utopit se v rybníce.

Konkurence na Androidu

Celý problém byl v tom, že několik let fungovala konkurenční aplikace, která používala databázi inzerátů od Bazoše a obsahovala výpočetně velice náročné funkce, které jsme do naší aplikace nemohli naimplementovat. Lidé si na ni zvykli. Konkurenční aplikaci byl zamezen přístup k databázi, a tak se musela přeorientovat na jiný inzertní portál. Jakmile to uživatelé zjistili, sesypali se s kritikou na Bazoš.

Jak naložit s hodnocením

Na záplavu negativních recenzí reagoval klient sám. S trpělivostí odpovídal na všechny dotazy a „hejty“. Tady je malá ukázka negativních komentářů.

A ještě pár pozitivních komentářů. Rozdíly mezi některými byly opravdu velké, tuhle appku uživatelé buď nesnáší, nebo zbožňují.

Údržba aplikace

Klient chce svou aplikaci udržet jednoduchou, funkční a bez chyb. Proto jsme s příchodem nových verzí operačních systémů pro Android i iOS provedli refaktorování obou platforem. Pomohlo to také ke snížení počtu pádů. Nyní aplikace padá převážně jen na exotických zařízeních, jako je například myPhone HAMMER ENERGY. Průměrně padá méně než jednomu procentu zařízení.

V rámci údržby jsme na podnět jednoho z uživatelů zapracovali i podporu pro nevidomé a slabozraké uživatele pro Android i iOS. Bazoš je tak jedna z mála aplikací na českém trhu, která se přístupností zabývá. (Více o nedostatečné přístupnosti aplikací zde.)

Vyvinout appku pro českou inzertní jedničku byla skvělá zkušenost. Více takových klientů jako pan Bazoš! Děkuji za přečtení a případné komentáře.

Michal Režnický
Michal Režnický
Project Manager

Máte zájem o spolupráci? Pojďme to probrat osobně!

Napište nám >