Vývoj nové aplikace ve firmě se kolikrát neobejde bez promarněných byznysových příležitostí. Stává se, že vývojáři nemají k dispozici potřebná data, která by ilustrovala, jak si firma stojí na trhu a jak funguje její podnikání. Výsledné řešení pak nemusí být úspěšné, nebo se musí zcela předělat. Co s tím? Předcházet tomu lze důkladnou rešerší, ale i odvahou vstoupit do otevřené diskuze s klientem a nebát se navrhnout jiný postup – třeba simultánní vývoj backendu a frontendu.
Jak nasadit v krátkém čase kvalitní aplikaci, která se stane uživatelským hitem? Navíc v době, kdy v organizacích sílí tlak na neustálé vylepšování digitálních produktů a služeb? Vedle technického know-how úspěch do velké míry záleží také na navázání partnerství mezi firmou a dodavatelem softwaru.
To na začátku vyžaduje jistou dávku asertivity a vzájemné důvěry, která často chybí. Zadavatel se bojí dát různé informace ven, protože nevnímá dodavatele jako partnera, ale jako gatekeepera. Toto stigma pak umocňují i sami dodavatelé, kteří se do této role často rádi stavějí – vytvoří například něco, co nefunguje nebo fungovat přestane, dodavateli řeknou, že „to tak chtěl“, načež se vše musí předělat a klient to znovu zaplatí. Je to i tím, že klientům mnohdy chybí technologické know-how. Pokud někdo má psát softwarovou specifikaci, musí vědět, jak funguje API, jaký je mentální proces softwaru či zodpovědnosti jeho jednotlivých částí, rozumět vývoji.
V Renomii jsme takovou specifikaci například dostali od CTO a bylo v ní skvěle vidět, co řeší backend, infrastruktura i frontend. Jenže takové lidi většina firem nemá. Jak tedy vytvořit digitální produkt, který svou funkčností dalece překoná původní očekávání? Aby firma mohla dodavatelům softwaru věřit, je nutné v průběhu celého projektu komunikovat s klientem jak o jeho potřebách, tak i o logice vlastních návrhů.
Nejprve analýza trhu, až potom technické zadání
Na začátku každého projektu by měla být snaha zjistit, jak firma, která vás oslovila, funguje interně. Zadání totiž často přichází na základě interního byznysového cíle, který je součástí firemní strategie. Jenže řadě product ownerů často chybí hlubší technologická znalost, což má za výsledek vágní zadání, na kterém oni stráví zbytečný čas a vy si z něj reálně nic neodnesete. V této fázi by vás proto mělo zajímat úplně všechno – od předmětu podnikání a historie společnosti přes interní procesy až po průzkum trhu. Právě tady mi přijde, že řada firem chybuje, protože se zaměřují hlavně na technické řešení, snaží se hned do první verze vecpat co nejvíce funkcí či se vrhnout na technickou dokumentaci vůbec předtím, než mají aplikaci hotovou.
K technickému zadání má ale smysl vracet se teprve po zpracování úvodní analýzy klientova byznysu a jeho potřeb. Výhodou je, že pak nemusíte po spuštění první verze hned iterovat aplikaci kvůli chybám vzniklým z nedostatku vstupních informací. Téměř v polovině případů původní zadání ve spolupráci s klientem změníme tak, aby přesněji sedělo na business case. Jako externí softwarová firma na rozdíl od klienta nepůsobíme v daném oboru přes deset let, a tak můžeme čerpat z čisté mysli a nezaujatosti. Snažíme se navrhovat úpravy zadání tak, aby aplikace firmě přinesla další příležitosti i později.
Nic z toho se však neobejde bez vzájemné důvěry. Na jedné straně jde samozřejmě o ochotu firmy sdílet informace v podobě vlastního výzkumu, datových a UX analýz s externím vývojářským studiem. Na straně druhé je zase nutné umět jako vývojář klientovi ukázat návrhy designů, předat mu vlastní pohled na věc a zkusit hned na začátku minimalizovat případná nedorozumění.
Teprve tehdy je namístě tvorba wireframů a sepsání technických specifikací, na kterých klientovi design demonstrujeme a bavíme se o možných funkcích. Zároveň jsme ale ke konci této fáze schopní začít pracovat i na backendu a infrastruktuře, což výrazně zrychluje celý vývoj. Zatímco totiž probíráte návrhy a kreslíte vizualizace, můžete zjišťovat, která data již máte a co naopak chybí k dosažení požadovaného výsledku.
Není důvod se bát iterovat za chodu
Při vývoji softwaru platí jedno základní pravidlo – software nikdy nebude úplně hotový. Měnící se nároky uživatelů, rozvoj digitálních služeb a další faktory vedou k tomu, že digitální produkt, který firma kontinuálně nevyvíjí, může snadno zastarat. Nemá proto smysl hned na začátku usilovat o „dokonalou“ tvorbu aplikace, která bude splňovat všechny možné požadavky a kombinace funkcí. Naopak je ze zkušenosti lepší ji vydat co nejdříve jako MVP a postupně ji vylepšovat.
V elevupu se snažíme odladit alespoň 70 % možných problémů, které by mohly produktu skutečně uškodit. Pak už ale přecházíme k realizaci, a klient se tak rychle dostane ke skutečné zpětné vazbě od uživatelů – ať už v podobě testerů či beta uživatelů – a může s ní hned začít pracovat. Díky tomu například zjistí, že uživatelé aplikace mají trochu jiné potřeby nebo způsob práce s ní, než si klient myslel. Nebo se ukáže, že jim nějaká funkce chybí.
Problém dnešní doby je v tom, že řada klientů chce aplikaci „vymazlit“ ještě předtím, než ji vypustí ven. Historicky se nám ale už několikrát potvrdilo, že přijít na trh s rozpracovanou aplikací a získat několik týdnů zpětné vazby náskok oproti firmám, které se ji snažily před spuštěním vyladit do nejmenších detailů, hrálo v úspěchu zásadní roli. Třeba jako v případě aplikace Zelená karta pro řidiče, kterou jsme v elevupu vyvinuli pro Renomia/PFP a která dnes patří mezi 40 nejstahovanějších aplikací v AppStoru. Ta při svém spuštění nabízela pouze několik funkcí bez nutnosti registrace, dnes už řidičům slouží ke sdílení řady dalších dokladů i jako pomocník při technických kontrolách.
Simultánní vývoj frontendu a backendu navíc dává oběma stranám více možností. Skrze iteraci v softwaru se dostanete k cíli daleko dřív a můžete už jen vylepšovat. Navíc sami uživatelé aplikací jsou na takový přístup zvyklí a můžou průběžné aktualizace vnímat dokonce jako potvrzení toho, že se tvůrce softwaru o aplikaci stará a neustále ji vylepšuje. Funguje to jako ujištění a zároveň zákazníky dané firmy učíme, aby odpovídali na recenze v online obchodech. I to je další neinvazivní způsob, jak lidem ukázat, že aplikace je živá a důvěryhodná. A firma pak má potřebnou uživatelskou základnu a kredibilitu, zatímco může plánovat další kroky k jejímu rozšíření.