Alkalmazás átvétele más fejlesztőtől: mire figyelj és hogyan zajlik?

Az appod él, vannak felhasználói, de a fejlesztő eltűnt, nem vállalja az új funkciókat, vagy a javításaitól egyre rosszabb lesz minden. Esetleg egy félkész projekt áll és nem tudod, mi készült el belőle valójában.

A jó hír: egy működő vagy félkész alkalmazás átvehető, ha az új csapat ismeri a technológiát és megkapja a kódot, a dokumentációt és a szükséges hozzáféréseket. A fejlesztőváltás önmagában nem jelenti, hogy az appot újra kell írni.

Röviden:

• Előbb biztosítsd, hogy a fiókok a céged nevén legyenek és csak utána mondd fel a régi szerződést.
• Az átvétel felméréssel kezdődik, nem fejlesztéssel.
• Az újraírás csak egy a három lehetséges út közül.
• Élő appnál az átállás alatt is kell valaki, aki felel a működésért.

Miért vált fejlesztőt egy cég?

Nem csak azért, mert a fejlesztő abbahagyta. Sokszor az ügyfél bontja fel a szerződést, mert nem elégedett. A saját átvételeinkből néhány tipikus helyzet:

• Minden működött, de jött négy-öt új funkcióigény és módosítás, amit a korábbi fejlesztő már nem vállalt.
• Az appon csak egy kötelező frissítés kellett: idén volt olyan ügyfelünk, akinél a Google Play követelményei miatt kellett SDK-frissítés és a korábbi fejlesztő ezt már nem csinálta meg.
• Egyre gyakrabban jöttek elő hibák és a javításoktól csak rosszabb lett. Az ügyfél ezért bontott szerződést és hozta el hozzánk az appot.
• A korábbi csapat befejezte a fejlesztést és nem maradt, aki tovább vigye.
• A korábbi csapat csak messzire előre tudott időpontot adni és lassan kommunikált.

Az ok befolyásolja, mire kell figyelni. Ha a régi fejlesztő elérhető és együttműködik, az átadás egyszerűbb. Ha eltűnt, a hozzáférések megszerzése lesz az első feladat.

Működő és félkész app átvétele között is van különbség. Egy élő appnál az a cél, hogy a felhasználók semmit ne vegyenek észre az átállásból. Félkész projektnél először azt kell tisztázni, mi készült el valóban, mi működik és mi hiányzik még.

Milyen appokat veszünk át?

Elsősorban React Native-ben készült mobilappokat, Node.js-es backendeket és React vagy Next.js alapú webes felületeket, de PHP-s backendet is. Más technológiájú projektet is átnézünk, de hogy vállaljuk-e, az összetettségtől függ. Sokszor mondunk nemet, mert csak olyan munkát vállalunk, amiért biztosan felelősséget tudunk vállalni. Ha új appot fejlesztetnél, azt a mobilalkalmazás-fejlesztés oldalunkon mutatjuk be.

Mik a leggyakoribb gondok átvételnél?

• Hiányzó dokumentáció, sokszor még kommentek sincsenek a kódban. Ez a leggyakoribb. Ilyenkor a rendszer működését a kódból kell visszafejteni, ami időt visz el.
• Eltűnt a fejlesztő és a fiókok az övéi voltak, nem az ügyfélé. Ez a legrosszabb helyzet, mert a szerverhez, az áruházi fiókhoz vagy a külső szolgáltatásokhoz is nehéz hozzáférni.
• A fejlesztő megvan, de lassan reagál, vagy nem akar együttműködni. Ilyenkor a kód feldolgozása is lassabban halad.
• Ellenőrizetlen, mesterséges intelligenciával írt kód vagy kódrészletek. Egyre gyakrabban látjuk és sokszor ezek okozzák a hibákat. Erről lent külön is írunk.
• Több fejlesztő dolgozott rajta egymás után, egyeztetés nélkül. Ez a kódon is látszik: mindenki a saját megoldását tette hozzá és a végeredmény összetákolt.

Mielőtt fejlesztőt váltasz: rendezd a hozzáféréseket és a tulajdonjogokat

A leggyakoribb hiba az, hogy a cég előbb lezárja az együttműködést és csak utána kéri el a hozzáféréseket. Ilyenkor az átadás sokszor lelassul és előfordul, hogy a saját termékedhez sem férsz hozzá. Amíg a korábbi csapattal él a szerződés, sokkal egyszerűbb mindent rendben átvenni.

Hozzáférés és tulajdon nem ugyanaz. Az, hogy be tudsz lépni egy fiókba, még nem jelenti, hogy a tiéd. Ha a szerver a fejlesztő saját fiókjában fut és ő fizeti a számlát, akkor nem te rendelkezel róla. Ezeket nézd végig:

Nézd meg a szerződést is. Mit ír a forráskód átadásáról, a felhasználási jogokról, a fiókokról, a felmondásról és az átadásban nyújtott segítségről? Ha a tulajdonjog vagy az átadási kötelezettség vitatott, kérd jogász segítségét.

App Store és Google Play: kié az app?

A fejlesztőváltás és az áruházi átadás két külön feladat.

• Ha az app a céged fejlesztői fiókjában van, elég a hozzáféréseket módosítani: a régi fejlesztőt eltávolítod, az újat felveszed.
• Ha egy másik szervezet fiókjában van, hivatalos átadásra (app transfer) van szükség. Az Apple-nél ehhez a küldő és a fogadó fiók tulajdonosának is lépnie kell, a kód átadása tehát önmagában nem elég. A feltételeknek megfelelő appok megtartják az értékeléseiket, a véleményeiket és a frissíthetőségüket. A Google Play átviszi a felhasználókat, a statisztikákat, a véleményeket, az értékeléseket, az előfizetéseket és az áruházi adatlapot, de néhány fiókszintű adat, például a tömeges exportok és a bevételi jelentések nem költöznek át. Az átadás előtt mindig nézd meg az Apple és a Google aktuális feltételeit.

Mobilspecifikus részletek, amikről ritkán esik szó:

• Android aláírókulcs. Ha az app a Play App Signinget használja, az alkalmazás aláírókulcsát a Google őrzi, a fejlesztő pedig egy feltöltési kulccsal dolgozik. Ezt a kulcsot és a jelszavát kérd el. Ha elveszett, a Google-nél kérhető új feltöltési kulcs. Régebbi appoknál, ahol a Play App Signing nincs bekapcsolva, a saját aláírókulcs elvesztése azt jelentheti, hogy az appot nem lehet többé ugyanazon az adatlapon frissíteni. Ezt az átvétel elején érdemes tisztázni.
• iOS tanúsítványok és profilok. Ezek a fejlesztői fiókhoz kötődnek. Ha a fiók a tiéd, a fiók tulajdonosa újra tudja generálni őket.
• Push értesítések. Az Apple push-kulcsa és a Firebase-projekt is a céged fiókjában legyen, különben az átállás után leállhatnak az értesítések. Apple-átadás után a fogadó félnek új push-tanúsítványt vagy kulcsot kell létrehoznia, amikor a régi lejár.
• Előfizetések az Apple-nél. Ha az app automatikusan megújuló előfizetést árul, az átadás előtt a küldő fél létrehoz egy alkalmazásspecifikus megosztott titkos kódot (shared secret) és átadja a fogadó félnek, hogy a szerver tovább tudja ellenőrizni az előfizetéseket. Az átadás után a fogadó fél újat generál.
• Ami az Apple-nél nem költözik: például az Apple Pay kereskedői azonosító. Az átadás előtt a TestFlight béta-tesztelést le kell állítani és mivel az app az átadás után eltűnik a küldő fiókjából, előtte érdemes minden adatát elmenteni.
• Ami a Google Playen nem költözik: az átadás előtti rendelések és a pénzügyi jelentések a régi fiókban maradnak, a tesztcsoportok és az integrált szolgáltatások összekapcsolásai sem jönnek át. Ha az appban van alkalmazáson belüli vásárlás, a fogadó fióknak aktív fizetési profillal kell rendelkeznie.
• Bejelentkezés Apple-azonosítóval (Sign in with Apple). Ha az app ezt használja, az átadás előtt a küldő félnek minden felhasználóhoz átadási azonosítót kell generálnia, különben a felhasználók bejelentkezése sérülhet.
• Keychain-megosztás iOS-en. Az átadás után a megosztott keychain csak a következő frissítésig működik. A fogadó félnek a saját csapatazonosítójával kell új keychain-csoportot beállítania és a frissítés után a felhasználóknak egyszer újra be kell jelentkezniük.

A részletek az Apple app-átadási útmutatójában, a Google Play app-átadási leírásában és a Play App Signing leírásában találhatók.

Mit kérj el az átadáskor?

Ezt a listát érdemes végigvenni a régi fejlesztővel, lehetőleg írásban:

•  Forráskód teljes előzménnyel: a mobilapp, a backend és az adminfelület kódja is, nem csak az appé.
•  Egyezik-e a kód az éles verzióval? Előfordul, hogy egy javítás közvetlenül a szerverre került, de a kódtárolóba nem. Ez az első telepítésnél elveszhet.
•  Build- és kiadási leírás: hogyan készül a telepíthető app, hogyan kerül az áruházba, hogyan történik az aláírás.
•  Környezeti változók és kulcsok listája. Ezeket ne e-mailben kérd, hanem biztonságos megosztással, egyéni fiókokon keresztül.
•  Külső integrációk: fizetés, e-mail, SMS, push, térkép, egyéb API-k és hogy kinek a fiókjában futnak.
•  Ismert hibák, félkész funkciók és az „egyelőre így hagytuk” döntések.
•  Üzleti szabályok, amelyek a kódból nem derülnek ki maguktól.
•  Az eredeti specifikáció és az, hogy a megvalósítás hol tért el tőle.
•  Lejáratok: domain, SSL-tanúsítvány, az Apple fejlesztői program éves díja, fizetős szolgáltatások előfizetései.
•  Egy átadó beszélgetés a régi fejlesztővel, amelyben végigmegy a rendszeren. Ha lehet, vegyétek fel.
•  Átadás-átvételi jegyzőkönyv, amely rögzíti, mit és mikor adtak át.

Hogyan zajlik nálunk az átvétel?

1. Első egyeztetés. Mielőtt a kódot megnéznénk, ezeket kérdezzük:

• milyen technikai dokumentáció van és mi a jelenlegi technológia és infrastruktúra;
• milyen technológiával készült a mobilapp, a backend és a webes vagy adminfelület;
• hol fut a rendszer és milyen külső szolgáltatásokra épül;
• mely funkciók készek, melyek félkészek és melyek okoznak gondot;
• él-e az app és hogyan jut el a felhasználókhoz;
• milyen változtatásokat szeretnél;
• megvan-e az eredeti specifikáció és hol tért el tőle a megvalósítás.

Az első konzultáció és a magas szintű technikai felmérés ingyenes.

2. Gyors átnézés, általában 48–72 órán belül. Ha szükséges, titoktartási megállapodást kötünk és átfutjuk a kódot is. Ebből megmondjuk, reális-e, hogy vállaljuk és érdemes-e továbblépni. Az első áttekintéshez nem kell korlátlan éles hozzáférés. Egyéni fiókokat és biztonságos megosztást használunk.

3. Részletesebb vélemény és vállalási feltételek. Ha továbblépünk, az első megkereséstől számítva általában 4–7 napon belül részletesebb véleményt és vállalási feltételeket adunk. Az egyik legfontosabb kérdés ilyenkor, hogy a kapott verziót le tudjuk-e fordítani és tudjuk-e tesztelni.

4. Célzott kódátnézés, ha szükséges. Ha a kódot mélyebben meg kell érteni, ezt külön elvégezzük. Ilyenkor ezeket nézzük meg:

• az architektúrát és a kód minőségét;
• a kommenteket és a dokumentációt;
• hogyan működik a rendszer a gyakorlatban;
• hogy megvan-e minden, ami a továbbvitelhez kell: a kódtároló, a fejlesztői fiókok és a kulcsok.

A díját az első eredmények alapján adjuk meg. Ha utána nagyobb továbbfejlesztést is velünk végeztetsz, nem kell külön kifizetned. Ha nem lesz közös munka, a kódátnézés díját ki kell fizetni. Ez a lépés a garancia szempontjából is számít (lásd lent).

5. Javaslat és tételes ajánlat. A felmérés alapján javasoljuk a további utat (lásd lent) és tételes ajánlatot adunk. Átvételre nincs sablonár, minden projektet külön árazunk.

6. Átállás. A hozzáféréseket átállítjuk, a régi hozzáféréseket és jelszavakat pedig csak akkor szüntetjük meg, amikor már tudjuk, mi függ tőlük.

7. Első mérföldkő. Egy jól körülhatárolt első cél: egy kritikus hiba javítása, a megbízható kiadási folyamat helyreállítása vagy egy kisebb funkció elkészítése. Egy sürgős javítás általában 1–2 héten belül elkészül. Egy nem sürgős továbbfejlesztés a kapacitásunktól függ, de jellemzően 1–4 héten belül elkezdődik. Ebből mindkét fél látja, hogyan működik az együttműködés.

8. Továbbfejlesztés és támogatás. Ezután jöhetnek az új funkciók és a folyamatos karbantartás. Arról, hogy indulás után milyen feladatok vannak egy appal, ebben a cikkben írtunk.

Újra kell írni az appot?

Nem feltétlenül. A felmérés után három út közül lehet választani:

1. Folytatás a meglévő kódon. Ha a kód rendezett és a technológia még támogatott, ez a leggyorsabb és legolcsóbb.
2. Egyes részek javítása, a többi megtartása. A problémás részeket rendbe tesszük, a jól működő részekhez nem nyúlunk.
3. Egy nagyobb rész újraírása. Akkor indokolt, ha a meglévő alapokra építeni drágább vagy kockázatosabb lenne, mint lecserélni őket.

Egy példa a saját átvételeink közül. Egy ügyfelünk, akinek B2B és B2C appja is volt, keretrendszer-frissítést, kuponkód-kezelést és banki átutalásos fizetést kért. A kódot korábban többször foltozták, a konvenciók következetlenek voltak, a logika nehezen követhető. A problémás komponenseket előbb újraírtuk és csak utána bővítettük őket. Ezután elkészült a frissítés és az új funkciók és azóta a további módosítások is könnyebben mennek, mert a gyenge pontok rendbe kerültek.

Mesterséges intelligenciával írt app átvétele

Egyre több olyan app jut el hozzánk, amelynek a kódja részben vagy teljesen mesterséges intelligenciával készült. Önmagában az, hogy a fejlesztéshez AI-eszközt használtak, nem probléma. A gond akkor kezdődik, amikor a létrehozott kódot senki nem ellenőrizte, nincsenek tesztek és a fejlesztő sem látja át, hogyan működik a rendszer. Az ilyen appok gyakran gyorsan eljutnak egy működőnek látszó állapotig, aztán elakadnak: a hibák javítása egy ponton túl újabb hibákat szül.

Az ilyen kódnál a garanciavállalás és a hosszú távú karbantartás is nehezebb, mert gyakran következetlen és nincs mögötte átgondolt szerkezet.

Ettől még nem utasítjuk el automatikusan. Ha a kód és az ötlet eléri a minimálisan elvárt minőséget és meg tudunk egyezni az ügyféllel úgy, hogy érti a mi szempontjainkat is, megpróbálunk segíteni. Ilyenkor a felmérés különösen fontos: abból derül ki, mi tartható meg és mit kell rendbe tenni, mielőtt továbbfejlesztenénk.

Mi van, ha a korábbi fejlesztő nem működik együtt?

1. Készíts leltárt a hozzáférésekről. Ki rendelkezik a kódtárolóval, a szerverrel, a domainnel, az adatbázissal és az áruházi fiókokkal? Az, hogy be tudsz lépni valahova, még nem jelenti, hogy jóvá is tudod hagyni az átadást.
2. Kérd írásban, ami hiányzik. Nevezd meg pontosan, melyik kódtárolót, dokumentumot vagy fiókműveletet kéred, kitől és milyen határidővel.
3. Nézd át a fejlesztési szerződést: a forráskód átadását, a szellemi tulajdont, a fiókokat, a felmondást és az átadási segítséget. Ha a tulajdonjog vagy az átadási kötelezettség vitatott, fordulj jogászhoz.
4. A tervet a biztosan meglévő hozzáférésekre építsd. Az Apple-nél például a küldő és a fogadó fiók tulajdonosának is lépnie kell, a kód átadása ehhez nem elég.

Hogyan marad élő az app az átállás alatt?

Élő appnál az átállás alatt is tisztázni kell:

• ki figyeli és támogatja a terméket;
• melyik tárhelynek, domainnek és előfizetésnek kell aktívnak maradnia;
• hogyan ellenőrzitek, hogy a mentések tényleg visszaállíthatók;
• hol folyik a tesztelés;
• hogyan hagyjátok jóvá a kiadásokat és hogyan lehet visszaállni egy korábbi verzióra.

A kimenő szolgáltatásokat és hozzáféréseket csak akkor szüntesd meg, amikor már tudod, mi függ tőlük.

Ha lehet, az átmenet egy részében a régi és az új csapat párhuzamosan dolgozik. Nálunk ez volt már nagyon gördülékeny, gyors válaszokkal és valódi segítőkészséggel és volt olyan is, ahol minden információért külön kérni és várni kellett. Ezért érdemes az átadási segítséget még a felmondás előtt, írásban rögzíteni: ki, mennyi ideig, milyen gyorsan válaszol a kérdésekre.

Biztonság és adatvédelem

• Cseréld le a jelszavakat és a kulcsokat, miután a régi fejlesztő hozzáférését megszüntetted: szerver, adatbázis, külső szolgáltatások API-kulcsai.
• Mindenki egyéni fiókkal dolgozzon, közös jelszavak nélkül. Így később pontosan visszavonható, ki mihez fér hozzá.
• Ha az új csapat éles személyes adatokhoz fér hozzá, adatfeldolgozói szerződés kell vele.
• Kérd a függőségek átnézését is. Az elavult könyvtárak biztonsági kockázatot jelentenek és egy régi keretrendszer-verzió frissítése maga is munka lehet.

Mennyibe kerül és mennyi ideig tart?

Átvételre nincs sablonár, mert két app ritkán van ugyanolyan állapotban. Nálunk így működik:

• Az első konzultáció és a magas szintű technikai felmérés ingyenes.
• Az első visszajelzés általában 48–72 órán belül, a részletesebb vélemény és a vállalási feltételek az első megkereséstől számítva 4–7 napon belül érkeznek.
• A célzott kódátnézés díját az első eredmények alapján adjuk meg. Ha utána nagyobb továbbfejlesztést is velünk végeztetsz, nem kell külön kifizetned, ha nem lesz közös munka, igen.
• Az első mérföldkő: egy sürgős javítás általában 1–2 héten belül elkészül, egy nem sürgős továbbfejlesztés jellemzően 1–4 héten belül elkezdődik.
• A további munkára tételes ajánlatot adunk, a többi projektünkhöz hasonlóan fix áron, mérföldkövekre bontva.

Garancia. Ha az együttműködés szerződéssel és célzott kódátnézéssel indul, a felmérés után a szerződésben rögzített részekre és feltételekkel a meglévő kódra is vállalunk garanciát. Ha csak egy-egy javításba vagy továbbfejlesztésbe kell beugranunk, a garancia arra vonatkozik, amit mi készítettünk. Ezt igyekszünk rugalmasan kezelni.

Az átvétel teljes időtartamát és költségét leginkább ez befolyásolja: mennyi dokumentáció van, mennyire rendezett a kód, megvannak-e a hozzáférések, mennyire elavultak a használt technológiák, mennyire segítőkész a korábbi fejlesztő és mi az első cél.

Hogyan válaszd ki az átvevő csapatot?

Olyan csapatot keress, amelyik már a kód megnézése előtt el tudja mondani, hogyan zajlik a felmérés és milyen információkra van szüksége. Kérdezd meg:

• ki nézi át a rendszert és ki fog rajta dolgozni;
• hogyan mutatják be a javítás vagy újraírás közötti javaslatot;
• milyen reakcióidőre és milyen gyakoriságú tájékoztatásra számíthatsz.

Ha általánosságban is szempontokat keresel, ebben a cikkben összeszedtük, mire figyelj, amikor fejlesztőcéget választasz.