Jaké podklady poslat před poptávkou mobilní aplikace
Čtyři body, které patří do zadání mobilní aplikace, co ovlivňuje cenu a dobu vývoje a proč odhad vychází z dohodnutého rozsahu, ne z univerzální ceny.
Užitečná nabídka na mobilní aplikaci začíná stručným zadáním, které pokrývá čtyři věci: kdo bude aplikaci používat a jaký hlavní úkol má řešit, zda jde o první verzi, nebo stávající aplikaci, na jaký backend nebo API se má napojit a kdo za něj odpovídá, a jaké jsou požadované platformy, priority, termín a rozpočtová omezení. Cena a doba vývoje závisí na rozsahu, a proto spolehlivý odhad vychází z dohodnutého rozsahu, ne z univerzální ceny nebo termínu.
Článek vysvětluje, co jednotlivé části zadání dodavateli řeknou, co ovlivňuje cenu a dobu vývoje a co do první zprávy nepatří.
Jaké čtyři věci poslat?
Kdo bude aplikaci používat a k čemu
Popište uživatele, ať už jde o zákazníky, zaměstnance, nebo partnery, a jeden úkol, se kterým jim má aplikace pomoci. Věta „Technici v terénu zapíší každou kontrolu a na místě ji uzavřou podpisem“ řekne mnohem víc než „aplikace pro naše techniky“. Pokud je skupin uživatelů víc, napište, na které v první verzi záleží nejvíc.
První verze, nebo stávající aplikace
U první verze napište, co už existuje: průzkum, návrhy, webový produkt, prototyp. U stávající aplikace popište problém, který chcete vyřešit, použitou technologii, kdo vlastní zdrojový kód a zda z něj lze aplikaci dnes sestavit a vydat. Převzetí aplikace závisí na jejím stavu, způsobu sestavení a závislostech a to vše je potřeba posoudit před dohodou o rozsahu práce. Pomohou i veřejné odkazy do obchodů s aplikacemi.
Backend nebo API a kdo za ně odpovídá
Pokud se aplikace napojuje na existující systém, pojmenujte ho a napište, co jeho API dnes umí a kdo ho může upravit. Na tom člověku záleží stejně jako na samotném API. Pokud systém zatím neexistuje, napište to: u nového produktu se v rámci rozsahu dohodne, co potřebuje na straně serveru. Podrobněji se tomu věnuje článek co musí umět vaše API, než začneme stavět aplikaci.
Platformy, priority, termín a rozpočet
Uveďte, zda potřebujete iOS, Android, nebo obojí, co je nejdůležitější, pokud bude nutné volit, termín, který je pevný z konkrétního důvodu, a případná rozpočtová omezení. Rozpočtový rámec není závazek. Pomáhá navrhnout první verzi, která se do něj vejde.
Kolik bude aplikace stát a jak dlouho vývoj potrvá?
Každý odhad nakonec stojí na stejných faktorech:
- Uživatelské úkoly. Kolik úkolů aplikace pokrývá a jak složitý je každý z nich. Schválit požadavek je jednodušší než vyplnit vícekrokovou žádost s nahráním dokumentů.
- Připravenost návrhu. Zda jsou obrazovky a průchody navržené a schválené, rozpracované, nebo je teprve potřeba je určit.
- Kvalita API. Zda API už každý úkol pokrývá a přihlášení i oprávnění kontroluje server, nebo je ho nejdřív potřeba upravit.
- Integrace. Platby, ověření identity, mapy, analytika nebo jiná SDK a služby třetích stran, každá s vlastními požadavky.
- Práce offline. Které úkoly musí fungovat bez připojení a jak se změny později synchronizují.
- Testování. Zařízení, verze systému a scénáře, které je potřeba otestovat na obou platformách, včetně bezpečnostního nebo regulatorního posouzení, pokud ho vaše organizace vyžaduje.
- Vydání. Účty v obchodech, požadavky schvalovacích procesů a kdo odpovídá za jednotlivá vydání a předání.
U MVP omezíme první verzi na podstatný úkol, čímž tyto faktory udržíme pod kontrolou. Další rozvoj a údržbu vymezíme samostatně podle potřeb projektu.
Pokud se ještě rozhodujete mezi jedním sdíleným kódem a samostatnými nativními aplikacemi, článek React Native pro firemní aplikace vysvětluje, které z těchto faktorů sdílený kód ovlivní a které ne.
Proč odhad potřebuje dohodnutý rozsah
Dvě aplikace popsané jednou větou se mohou pracností výrazně lišit, jakmile jsou známé uživatelské úkoly, integrace a požadavky na vydání. Proto odhadujeme podle dohodnutého rozsahu a neslibujeme univerzální cenu ani termín. Zadání je začátkem tohoto rozsahu. Rozhovor, který následuje, doplní, co zadání nepokrylo.
Co nevíte, zapište jako neznámé. Věta „Nevíme jistě, zda to naše API umí“ je užitečná informace. Obě strany z ní vědí, co je potřeba ověřit, než se na odhad dá spolehnout.
Co do první zprávy nepatří
Do první zprávy prosím nevkládejte přístupové údaje, klíče k API ani zákaznická data. K posouzení spolupráce nejsou potřeba a jejich posílání e-mailem pro vás představuje riziko. Podrobné interní dokumenty počkají, až se obě strany dohodnou, jak s nimi naložit.
Co následuje
Pro začátek stačí krátké shrnutí: pošlete ty čtyři body přes kontaktní stránku, klidně jen v pár větách. Pak probereme vhodnost spolupráce, vyjasníme návaznosti, hlavně backend a případná SDK, a dohodneme podklady pro rozsah a odhad. Stejné otázky ve zkrácené podobě najdete na stránce vývoj mobilních aplikací.