Jaké podklady poslat před poptávkou mobilní aplikace

Užitečná nabídka začíná čtyřmi body: uživatelé a jejich hlavní úkol, současný stav aplikace, systémy, na které se má napojit, a omezení pro dodání. Pro začátek stačí ke každému jedna nebo dvě věty.

Cena a doba vývoje závisí na dohodnutém rozsahu. Zadání pomůže tento rozsah vymezit a pojmenovat otázky, které je potřeba před odhadem vyřešit.

Č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

Pojmenujte uživatele a jejich hlavní úkol. Může jít o zákazníky, zaměstnance nebo partnery. Pokud je skupin víc, určete, která je pro první verzi nejdůležitější.

Například: „Technici v terénu zapíší každou kontrolu a na místě ji uzavřou podpisem.“ Dodavatel tak má konkrétní postup, který s vámi může probrat.

První verze, nebo stávající aplikace

• První verze: Napište, co už existuje, například průzkum, návrhy, webový produkt nebo prototyp.
• Stávající aplikace: Popište problém, technologii, vlastníka zdrojového kódu a zda lze aplikaci dnes sestavit a vydat. Přidejte veřejné odkazy do obchodů.

Stav stávající aplikace, způsob sestavení a závislosti je potřeba posoudit před dohodou o jejím převzetí.

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.

Vyplněné fiktivní zadání

Fiktivní příklad ukazuje míru detailu pro užitečný první rozhovor. Nepopisuje klientský projekt ani závazek k dodání.

Firma a uživatelé: Northline Services, fiktivní servisní firma. Aplikaci by používalo přibližně 35 techniků v terénu. Dispečeři by dál pracovali ve stávajícím webovém systému.

Hlavní průchod: Technik otevře dnešní přidělenou návštěvu, zapíše odpovědi z kontrolního seznamu a dvě hodnoty ze zařízení, volitelně přidá fotografie, požádá zákazníka o podpis a dokončenou návštěvu odešle.

Stávající systémy a odpovědnost: Dispečerský systém už nabízí API pro zakázky a provozovny zákazníků. Petra, fiktivní vedoucí backendu klienta, odpovídá za změny API. Přihlášení a nahrávání fotografií existují; odeslání po práci offline, stránkování a stabilní kódy chyb je ještě potřeba ověřit.

Platformy a priority: iOS a Android. První prioritou je dokončení návštěvy. Technik musí tento průchod zvládnout bez signálu a data odeslat po obnovení připojení.

Mimo první verzi: Plánování výjezdů, fakturace, sklad, živé sledování techniků a náhrada stávajícího webového systému.

Závislosti: Testovací účty se syntetickými návštěvami; testovací API ve verzi plánované pro produkci; rozhodnutí o řešení konfliktů; firemní účty Apple a Google ve vlastnictví Northline Services; určené osoby pro převzetí a vydání v obchodech.

Termín a rozpočet: Pevný termín spuštění ani schválený rozpočet zatím nejsou. Northline Services chce odhad po vyjasnění práce offline a mezer v API. Obojí je zapsané jako neznámé místo odhadu naslepo.

Otevřená rozhodnutí: Lze odeslanou návštěvu upravit? Jak dlouho smějí fotografie zůstat v zařízení? Co se stane, když dispečer změní návštěvu v době, kdy je technik offline? Kdo odpovídá za podporu po vydání?

Příklad dává dodavateli dost informací, aby pojmenoval další otázky. Nepředstírá, že už jsou zodpovězené.

Prázdná šablona ke zkopírování

Zkopírujte ji do vlastního dokumentu nebo první zprávy. Nevkládejte do ní hesla, klíče k API ani zákaznická data.

Firma nebo produkt:
Uživatelé:
Hlavní úkol v první verzi:

První verze, nebo stávající aplikace:
Co už existuje:
Veřejné odkazy, pokud existují:

Backend nebo API:
Osoba nebo tým, který za ně odpovídá:
Známé mezery v API:
Testovací prostředí: ano / ne / neznámé

Platformy: iOS / Android / obojí
Úkoly, které musí fungovat offline:
Potřebná SDK nebo funkce zařízení:

Co patří do první verze:
Co je výslovně mimo rozsah:
Závislosti na vašem týmu nebo dodavatelích:

Pevný termín a jeho důvod, pokud existuje:
Rozpočtové omezení nebo rámec, pokud je známý:

Otevřená rozhodnutí a neznámé:
Osoba, která práci přebírá:
Osoba odpovědná za vydání v obchodech:

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í.

První verzi soustřeďte na podstatný úkol. Další rozvoj, údržbu a podporu vymezte samostatně.

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.

Neznámé věci zapište. „Nevíme jistě, zda to naše API umí“ oběma stranám říká, 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í.