Podklady pro mobilní aplikaci: kompletní checklist
Co si od klienta vyžádat, než se začne stavět aplikace: účty v obchodech, branding, API klíče i právní stránky, se zdůvodněním a načasováním.
Proč jsou podklady pro aplikaci jiná disciplína
Webový projekt se zasekne na chybějícím logu nebo přihlašovacích údajích, které nikdo nemůže najít. U aplikace se stane totéž, navíc ale existuje kategorie, kterou web nikdy nemá: účty, které může založit jen klient, odeslání do obchodu, které může schválit jen vlastník účtu, a proces schvalování, který proběhne jednou, pozdě, a odmítne celou aplikaci kvůli jediné chybějící věci. URL adresa se zásadami ochrany osobních údajů, která by u webu byla jen milým doplňkem, je tady tvrdý požadavek pro odeslání do obchodu. Platební integrace, která by u webu mohla dorazit až ve třetím týdnu, u aplikace blokuje úplně první testovací build, pokud je pro aplikaci klíčová.
Tento seznam je uspořádaný stejně jako náš obecný checklist podkladů pro webový projekt, ale kategorie i odhad načasování se liší natolik, že zacházet s aplikací jako s "webem s ikonkou" vede ke zbytečným zdržením. Pokud projekt potřebuje i novou vizuální identitu, doplňte tenhle checklist o brief na logo a branding — ten pokrývá samotnou značku, tenhle všechno kolem ní.
Checklist po skupinách
Před kickoffem znamená, že projekt se bez toho nedá smysluplně začít, nebo že bez toho budete přepracovávat hotovou práci. Může počkat znamená, že vývoj může pokračovat s dočasným řešením nebo rozumným výchozím nastavením, dokud nedorazí skutečná verze.
Účty a přístupy
| Položka | Proč ji potřebujete | Načasování |
|---|---|---|
| Registrace v Apple Developer Program pod vlastní identitou klienta | Tohle může spustit jen klient a nemáte to pod kontrolou, jakmile o to požádáte — předejte to jako úkol klienta hned první den, nečekejte, až na to narazíte. | Před kickoffem |
| Vývojářský účet v Google Play Console pod vlastní identitou klienta | Stejná logika jako u Applu: musí to být účet klienta a je potřeba o něj požádat dřív, než vás to zablokuje. | Před kickoffem |
| Vy jako spolupracovník s vývojářskou rolí, ne jako plný vlastník účtu | Umožní vám stavět, testovat a odesílat aplikaci bez toho, abyste drželi klíče od účtu, který vám nepatří — víc k tomu níž. | Před kickoffem |
| Přístup k existujícímu záznamu aplikace, pokud přebíráte již běžící aplikaci | Žádost o převod nebo o přidání spolupracovníka od účtu předchozího vývojáře, vyřízená dřív, než budete potřebovat vydat aktualizaci. | Před kickoffem, pokud nahrazujete existující aplikaci |
| API přístupy pro App Store Connect / Play Console, pokud automatizujete buildy nebo vydávání | Potřeba až ve chvíli, kdy existuje CI/CD pipeline, která je bude využívat. | Může počkat |
Identita a podklady pro záznam v obchodě
| Položka | Proč ji potřebujete | Načasování |
|---|---|---|
| Název aplikace a zdrojový soubor ikony | Název může být potřeba rezervovat v obou obchodech dřív, než ho zabere někdo jiný, a ikona ovlivňuje kus vizuálního designu. | Před kickoffem |
| Popis pro obchod (krátký i dlouhý, ve formátu daného obchodu) | Potřeba pro odeslání, ne pro stavbu aplikace — do té doby stačí zástupný text. | Může počkat |
| Screenshoty nebo podklady na jejich přípravu (makety na zařízeních lze vygenerovat, jakmile existuje UI) | Nejde je dokončit dřív, než existuje UI, které lze vyfotit, ale směr brandingu pro ně by měl být jasný dřív. | Může počkat |
| Kategorie a klíčová slova pro vyhledávání | Ovlivňuje dohledatelnost, ne funkčnost — rozhodnutí na úrovni odeslání do obchodu. | Může počkat |
| URL podpory a URL zásad ochrany osobních údajů | Oba obchody vyžadují při odeslání živé URL adresy; zásady ochrany osobních údajů navíc potřebují skutečný obsah, ne zástupný text, pokud aplikace sbírá jakákoli uživatelská data. | Může počkat, ale musí být hotové před odesláním |
Obsah
| Položka | Proč ji potřebujete | Načasování |
|---|---|---|
| Jaké jazyky má aplikace podporovat | Mění technické nastavení pro texty, layout i formát data a čísel — nákladné dodělávat dodatečně, pokud je aplikace postavená kolem jednoho jazyka. | Před kickoffem |
| Texty uvnitř aplikace — onboarding, popisky obrazovek, prázdné stavy, chybové hlášky | Struktura a layout mohou vzniknout se zástupným textem; finální texty jsou obsahový průchod, ne přepracování, jakmile existují. | Může počkat |
| Licencovaná média (stock fotky, sady ikon, fonty), ke kterým už má klient práva | Ujasní, co je použitelné bez samostatné licenční konverzace uprostřed vývoje. | Může počkat |
| Právní text, který musí být přímo v aplikaci (obrazovka s přijetím podmínek, upozornění) | Odlišné od obsahu, který stačí mít někde online — tohle musí být obrazovka, kterou uživatel vidí a odsouhlasí. | Může počkat, ale musí být hotové před odesláním |
Integrace a přístupové údaje
| Položka | Proč ji potřebujete | Načasování |
|---|---|---|
| API klíče pro jakoukoli službu, na které stojí klíčová funkce aplikace (mapy, platby, rezervační systém) | Pokud bez toho aplikace nefunguje, nejde o integraci na později, ale o součást stavby od prvního dne. | Před kickoffem, pokud je klíčová pro aplikaci |
| Přístupy k backendu nebo CMS, pokud aplikace komunikuje s existujícím systémem | Stejná logika jako u webu, který si ponechává stávající hosting: ověřte přístup dřív, než začne integrační práce. | Před kickoffem |
| Přístupy pro push notifikace (APNs klíč pro iOS, server key pro Android) | Potřeba až ve chvíli, kdy se push notifikace skutečně zapojují a testují. | Může počkat |
| Účet u platební brány, pod vlastním jménem klienta, pokud aplikace přijímá platby | Vlastnictví tady záleží ještě víc než u webu — viz poznámka níže. | Před kickoffem, pokud jsou platby klíčové |
| Přístupové údaje pro přihlášení přes sociální sítě (Facebook nebo Google OAuth aplikace, pokud je plánované "přihlásit se přes…") | Konfigurační krok, který může probíhat souběžně se zbytkem vývoje, nic neblokuje. | Může počkat |
Právní a compliance
| Položka | Proč ji potřebujete | Načasování |
|---|---|---|
| Zásady ochrany osobních údajů | Nutné pro odeslání do obchodu ve chvíli, kdy aplikace sbírá jakákoli uživatelská data; měly by přijít od klienta nebo jeho právníka, ne být vymyšlené za něj. | Před kickoffem |
| Jaká uživatelská data aplikace skutečně sbírá a proč | Oba obchody se na to při odeslání výslovně ptají a odpověď rozhoduje, jestli je vůbec potřeba obrazovka se souhlasem — lepší to vědět dřív, než se postaví datový model. | Před kickoffem |
| Podmínky používání | Mají stejnou právní váhu jako zásady ochrany osobních údajů. | Může počkat, ale musí být hotové před spuštěním |
| Odpovědi na dotazník pro věkové hodnocení (násilí, obsah od uživatelů, herní prvky apod.) | Požadavek na úrovni odeslání, ne vývoje — vyplní se, jakmile je jasný skutečný obsah aplikace. | Může počkat |
| Odvětvová upozornění specifická pro obor (zdravotní data, finanční služby, aplikace pro děti) | Požadavky se liší podle oboru i podle pravidel obchodu; ověření je odpovědnost klienta, ne něco, co pokryje výchozí šablona. | Před kickoffem u regulovaných oborů |
Testování a vydání
| Položka | Proč ji potřebujete | Načasování |
|---|---|---|
| Minimální verze OS a rozsah podporovaných zařízení | Rozhodnutí o rozsahu, které ovlivňuje, jaké funkce je bezpečné použít — vyřešte to dřív, než napíšete kód počítající s novějším OS, než mají skuteční uživatelé klienta. | Před kickoffem |
| E-maily interních testerů (TestFlight, interní testovací kanál v Play) | Potřeba, jakmile existuje build, který stojí za otestování. | Může počkat |
| Očekávání ohledně analytiky nebo hlášení pádů | Levné zapojit během vývoje, nepříjemné dodělávat, až aplikace má skutečné uživatele a mezeru v datech. | Může počkat |
| Pevný termín vydání a co ho určuje | Spuštění vázané na konkrétní událost má reálný termín, který určuje, kolik času zbývá na testování; bez takové události je prostoru víc. | Před kickoffem |
| Kdo má finální slovo pro odeslání do obchodů | Odeslání do obchodu je často ten krok, který nejde tiše vzít zpět — ujasněte si to jednou, hned na začátku. | Před kickoffem |
Proč by účty v obchodech měly patřit klientovi, ne vám
Je lákavé zaregistrovat klientovu aplikaci pod vlastním vývojářským účtem — je to rychlejší, účet už máte a klient nemusí nic vyplňovat. Je to taky nejčastější zdroj nepříjemného rozhovoru později.
Vývojářský účet je domovem aplikace. Její identita, historie hodnocení a recenzí, schopnost stávajících uživatelů dostávat aktualizace i případná aktivní předplatná — to všechno žije pod tímto účtem, ne pod samotnou aplikací. Pokud účet patří vám a spolupráce skončí, přesun aplikace na klientův vlastní účet není rychlá změna nastavení, ale formální proces převodu mezi dvěma vývojářskými účty, který může po dobu převodu narušit schopnost aplikace vydávat aktualizace. Pokud účet od začátku patří klientovi, konec spolupráce znamená jen odebrání vašeho přístupu spolupracovníka — aplikace se nikam přesouvat nemusí.
Stejná logika, jaká platí pro přihlašovací údaje k hostingu, platí i tady, jen s vyššími sázkami: účet, který dokáže aplikaci smazat nebo předat někomu jinému, by měl kontrolovat klient. Přidejte se jako člen týmu s rolí odpovídající tomu, co práce vyžaduje — Apple i Google to podporují — místo stavby pod účtem, který by klient bez vaší spolupráce nikdy neopustil.
Jak předat přístupové údaje a API klíče bezpečně
Všechno ve skupině integrací a přístupových údajů výše je buď pozvánka (přidejte mě jako spolupracovníka s konkrétní rolí), nebo tajemství (jeden API klíč, tajný klíč platební brány, heslo k backendu bez možnosti omezeného přístupu). Zacházejte s nimi jinak: pozvánka by měla být vždy omezená na to, co úkol vyžaduje — stejný princip rozebíráme podrobněji v článku jak si od klientů bezpečně vyžádat přihlašovací údaje. Tajemství, které nejde omezit — samotný API klíč, podpisový klíč webhooku — by nemělo cestovat e-mailem ani chatem vůbec, protože tam pak zůstává natrvalo. Přesně pro tenhle případ existuje typ položky secret v BriefGate: hodnota se zašifruje ve chvíli, kdy ji klient zadá, a uvolní se jednou tomu, kdo o ni požádal, místo aby dál žila v e-mailové schránce.
Kde do toho zapadá BriefGate
Vyžádat si účty a položky, které mohou počkat, každou zvlášť — jeden formulář na tohle, e-mail na tamto, telefonát na třetí věc — je přesná cesta k tomu, že klient bude potřebovat čtyři upomínky na čtyři různé věci. BriefGate umožní agentovi, nebo vám z dashboardu, zadat celý tenhle checklist jako jednu sadu typovaných položek: secret pro klíč platební brány, image pro ikonu aplikace, structured pro odpovědi o sbíraných datech — všechny popsané v typech položek. Klient dostane jeden branding portál a jeden ukazatel průběhu místo roztroušeného vlákna, BriefGate posílá upomínky na chybějící položky podle zvoleného rozvrhu, a skupinu účtů a přístupů lze dokonce nastavit jako váš vlastní úkol místo klientova pomocí položky s přiřazením owner, pokud jste to zrovna vy, kdo si musí pohlídat vyžádání převodu.