Összeszedtem azokat a fő pontokat, amikre egy mobil app, vagy más digitális termék fejleszttetőjeként mindenképpen figyelj oda. Nem elegendő egy terméket beindítani valahogyan, de azt tudni is kell üzemeltetni. Mivel egy termék hosszú életű, érdemes már az elején lefektetni olyan alapokat, ami később sok fejfájástól kímél meg.
Előljáróban annyit tennék hozzá a továbbiakhoz, a több ügyfelemnél látott hibás gyakorlatokat gyűjtöttem össze. Ezek tehát sajnos megtörtént esetek, és csak a szerencsének köszönhető, hogy nem lett nagyobb baj (még).
Érdemes eljátszani a gondolattal, hogy …
Mi történne, ha már nem működne olyan jól az együttműködés egy partnerrel, egy fejlesztővel vagy fejlesztő céggel?
Alkalmazás nevének kiválasztása
A mobil appok több millióan vannak a Store-okban. Nehéz ma már kitűnni. Komoly kampányt kell kifizetni érte, hogy felfigyeljenek rá a felhasználók. Ha megvan a név, ami ASO kompatíbilis (App Store Optimization), és ezt elkezdjük bejáratni, akkor nagy veszteség, ha ezt elveszik tőlünk.
Figyeljünk oda, hogy milyen kiadóként szerepel a mi pénzünkön kiadott app az adatlapján. Ezt az alkalmazás részleteinél láthatjuk. Ezen a részen vannak kitöltve a cégnév, kapcsolattartók, webhely, egyszóval a fejlesztő elérhetősége. Ha nincsen meg a technikai tudásunk, és ügynökséggel fejleszttetünk, akkor erre figyeljünk oda, hogy jól legyen kitöltve, és ránk mutasson.
Esetleg érdemes megállapodni, hogy meddig lehet kint az ügynökség neve, pl. a fejlesztési költségek X %-ának kifizetéséig. De ezután mindenképpen állítsuk be!
Ez a része könnyedén átírható az áruházak adatlapjain. Van azonban egy rész, ami nem. Ez pedig a package id Android-on és bundle Id iOS-en. Ezek olyan az egész (világon) áruházakra jellemző nevek, amikből csak egy szerepelhet. Pl. com.facebook.app nevű alkalmazás csak egy létezhet. Sőt, az Apple-nél még az is megadható, hogy a com.facebook.* előtag után is foglalt legyen általunk. A lényeg, hogy lehetőleg ez a rész is minket azonosítson.
Jogosultságok beállítása
Ha már fent esett szól az app illetőségéről, akkor egy alapvető dolog, hogy ki az app tulajdonosa az áruházban? A Google Play-en Owner, az Apple Store-ban pedig Account Holder a neve ennek a szerepnek. Ezeket soha ne adjuk át másnak!
Minden alkalmazásáruház tudja, hogy többeknek, sokféle hozzáférést kell kiosztani. Beállításukhoz megfelelő jogosultságra van szükség. Csak a legszűkebb jogokat adjuk oda pl. egy fejlesztőnek, egy ügyféltámogatást végzőnek, vagy aki az apphoz érkező megjegyzéseket kezeli.
Ne csak a store-okra korlátozódjon ez az előrelátás. A GitHub-on, GitLab-en, Bitbucket-en, AWS, Azure, Google Cloud Platform-ban (GCP), Firebase-ben, Expo.dev-en (React Native CD/CD) stb. ezek a beállítások ugyan úgy megtalálhatóak. Nézzük át őket!
Ha kell, kérjük be a felhasználónevet, vagy hozzunk létre mi magunk egy újat, aminek a minimális jogokat kiosztjuk.
Korlátozd a külső szolgáltatókat
A fenti listából kitűnik, hogy egy tech projekt nagyon sokféle külső eszközre támaszkodik. Ez jól is van így, hiszen mi főként terméket szeretnénk fejleszteni és értékesíteni. Az üzemeltetésről azonban ugyancsak gondoskodnunk kell!
Ellenőrizzük, hogy egy új szolgáltató bevezetésével mennyire zárjuk be magunkat (vendor locking)? Ha már nem megfelelő, tudunk-e költözni? Mennyire szabványos a megoldásuk, és esetleg máshol is tudjuk használni és újra felépíteni?
Minél kevesebb a külső függőség, valamint minél kevesebb a szolgáltatás, annál könnyebb kézben (észben) tartani a dolgainkat. Nem mellesleg mindig olcsóbban jövünk ki.
Legyen egy checklistád!
A fentiek alapján a saját ellenőrző listámat osztom meg, hogy mint cégvezető, mindig tudd, hogy mi történik a házad táján.
- Szerverek nevei, IP címei, felhasználók jelszavakkal
- A fontos és fő felhasználók nevei, e-mail címei jelszavakkal
- Helyreállítási e-mail címek, telefonszámok
- Hol van hosztolva a szerver? Külföldön – miért? Szükséges?
- Az adatbázisok hozzáférése védett? Nem a “gyári” jelszavakkal megy?
- Van teszt és éles, esetleg egyéb szerver, amit üzemeltetsz? Hol – hogyan érhető el?
- A Push Üzeneteket ki és honnan küldi?
- A szolgáltatásokhoz a Service key, Api key-ek hol vannak beállítva, tárolva?
Mit tegyünk, ha már baj van?
Előfordul az életben, hogy meggondolja magát egy partner, vagy te nem vagy már elégedett a munkájával és elbúcsúznátok egymástól.
Feltételezhetően a partner is békésen szeretné zárni az együttműködést, és nem gördít akadályt eléd. Ekkor sorra kell venni a checklistát, és közösen kellő időt szánni az elválásra. Aktív közreműködést kell kérni, hogy mielőbb lezárható legyen. Fontos, hogy jogilag a köztetek fennálló szerződés még köti, illetve később a jog is a segítségedre lesz, ha valami akadály felmerülne.
A fent említett eszközökben a beállítások egyszerűen megtehetőek. Saját magunk elvégezhetjük, és végezzük is el! Ha már nem dolgozunk együtt, akkor semmi szüksége nincsen a mi szervereinken, alkalmazásainkban tárolt adatainkra.
Az appok átköltöztetése, pont a fenti egyedi név miatt, már nehezebb, de nem lehetetlen. Az Apple-nél ez nehezebb, de van erre kidolgozott procedúra és az app transzferálható másik Account Holderhez. A Google-nél pedig a tulajdonost kell átállítani (és átírni az áruházi adatokat).
Remélem hasznosnak találod a gondolataimat a témában. A fentiekben szereztem tapasztalatot, láttam különféle megoldásokat. Amennyiben segítségre van szükséged, keress meg az elérhetőségeim egyikén.
Borbély Viktor vagyok, több éves Projekt menedzsment tapasztalattal. Szabadúszóként Flutter és a Spring Boot vagy Firebase Backend alkalmazások tervezését és megvalósítását végzem.
Dolgoztam több vállalatnál, az autóiparon (Continental, Valeo), a távközlésen (Ericsson) át a mobil fejlesztésig (Combit zRt. – Grepton Csoport).
Amikor együtt gondolkozásra van szükség, mindig van egy ötletem, amivel előremozdítom a megoldást. Szívesen mentorálom a körülöttem lévőket.
