Všichni si přejeme, aby nás to nikdy nepotkalo. S vývojářem máte nastavený fix-time, fix-price, ale nedodrží se ani jedno. Funkce, které měly být hotové během dvou sprintů, se táhnou měsíce. Komunikace začíná drhnout. A vy někde hluboko tušíte, že projekt nejde zamýšleným směrem.
V takové chvíli je třeba promyslet, jestli má smysl pokračovat se stejným týmem, nebo jej raději předat novým vývojářům. Změna dodavatele už dnes nemusí znamenat chaos ani zahozenou investici. Pokud se udělá správně, může projektu hodit záchranné lano a vytáhnout ho z propasti ztráty nebo úplného konce.
Vždy je ale třeba mít na paměti několik klíčových bodů:
1. Kdy předat vývoj aplikace jinému týmu?
Jako první přichází ta nejtěžší fáze: rozhodnutí o přechodu.
Obvykle se k němu klienti uchylují, pokud:
nové funkce přibývají pomalu nebo vůbec (release v nedohlednu);
dojde k výraznému překročení budgetu;
zvolené technické řešení neodpovídá původní vizi;
vývojáři nedodržují deadliny a špatně komunikují.
Pokud jste došli k závěru, že je změna nutná, na prvním setkání s novým týmem je třeba sladit očekávání a nastavit podmínky převzetí. V opačném případě totiž hrozí, že nový tým vkročí do stejných pastí jako původní vývojář.
Může to znít otřepaně, ale stále platí, že otevřená komunikace mezi všemi stranami je naprosto stěžejní.
2. Technické podklady
Rozhodli jste se pro změnu a shromažďujete technické podklady? Pro nejsnažší předání si připravte:
zdrojové kódy a přístup do repozitáře,
dokumentaci k architektuře a hlavním funkcím,
přístupy k produkčnímu a testovacímu prostředí,
informace o databázích, API a externích integracích,
CI/CD pipeline a způsob nasazování,
účty v App Storu, Google Play, Firebase, cloudu, analytice a monitoringu,
backlog, roadmapu a seznam známých chyb,
Řádná dokumentace výrazně usnadňuje život novým vývojářům. Projekt se dá převzít i bez ní, ale za cenu hlubší analýzy, která zpomalí celý proces.
3. Analýza stavu projektu
Jakmile se rozběhne handover, standardně probíhá analýza technické kondice aplikace.
Rešerše má za cíl objektivně posoudit, v jakém stavu se software nachází. Nahlíží se na kvalitu kódu, architekturu, bezpečnost, výkon, stabilitu nebo aktuální míru technického dluhu. Vývojáři přitom naskakují do rozjetého vlaku a potřebují rychle pochopit, v jakém stavu projekt je, co (ne)funguje a co je potřeba převzít z hlediska kódu, infrastruktury, práv i provozu.
Smyslem auditu je určit jasnou prioritizaci: co ohrožuje provoz, co blokuje další vývoj, co zvyšuje náklady a co může počkat. Díky tomu lze rozhodnout, jestli aplikaci stabilizovat, postupně modernizovat, nebo některé části přepsat.
V Netglade při přebírání rozpracovaných aplikací opakovaně vidíme, že největší problémem bývá nedostatečná dokumentace nebo nejasná vize. Samotný kód téměř vždy dosáhne přijatelného baselinu, o to víc v dnešní době, kdy jeho značnou část píše AI.
Proto je důležité provést interní audit a identifikovat, zda nedošlo k chybám i na straně zadavatele, nejčastěji nerealistickým požadavkům nebo nekonkrétním cílům.
4. Legislativa
Občas se setkáváme s případy, kdy klient nemá ošetřené legislativní požadavky přechodu.
Před změnou dodavatele je nutné ověřit, kdo vlastní práva ke zdrojovému kódu, grafice, databázím a dokumentaci. Ve smlouvě s původním dodavatelem musí být zřejmé, zda firma získala majetková práva, licenci, nebo jen právo aplikaci používat.
Vedle autorských práv je potřeba zajistit přístupy k účtům a službám (Apple Developer, Google Play Console, apod.). V ideálním stavu jsou vedené na firmu, ne na původního dodavatele. Pokud jsou klíčové služby pod účtem dodavatele, může být předání složitější.
U aplikací, které pracují s osobními údaji, je potřeba zkontrolovat také GDPR, přístupová oprávnění a bezpečné předání dat. Nový tým by měl mít přístup jen k tomu, co skutečně potřebuje, a ideálně v režimu, který je smluvně i bezpečnostně ošetřený.
5. Předání know-how
Nejlepší scénář je řízené předání, při kterém původní tým vysvětlí architekturu, otevřené problémy, release proces, známá technická omezení. Stačí několik dobře vedených předávacích schůzek, aby nový tým získal kontext, který by jinak musel týdny zpětně dohledávat.
Z praxe ale známe, že takových případů je méně. Dokumentace je často neúplná a komunikace s původním dodavatelem kusá. I v takovém případě lze projekt převzít. Jen je potřeba počítat s tím, že nový tým nejdřív vytvoří vlastní technickou mapu aplikace, zorientuje se v závislostech a ověří, jak se systém skutečně chová v produkci.
6. Rozběhnutí projektu
Po převzetí není obvykle nejlepší strategií hned naskočit do vývoje nových funkcí.
Prvním cílem by měla být stabilizace: rozběhnout projekt lokálně, ověřit buildy, zkontrolovat pipeline, základní monitoring a crash reporting. Případně vydat novou verzi na storu jen s kosmetickými změnami, abyste v praxi vyzkoušeli, jestli celý proces proběhne hladce.
Tato fáze snižuje riziko, že se naváže na staré problémy. Nejdřív je třeba ověřit technický základ, na kterém se dá znovu plánovat roadmapa, sprinty a dlouhodobý rozvoj produktu.
7. Zachránit, nebo přepsat?
Převzetí aplikace automaticky neznamená rewrite. Někdy je ekonomicky i technicky výhodnější navázat na existující kód, vyřešit největší rizika a postupně aplikaci modernizovat. Jindy je ale původní řešení natolik vzdálené cíli, že je kompletní nebo částečný přepis nutností.
Při rozhodování by se mělo vycházet z auditu, byznysových priorit a současného stavu architektury. U legacy systémů se často vyplatí přepisovat postupně — po modulech, funkcích nebo vrstvách —, aby aplikace mohla dál fungovat.
8. Roadmapa: návrat k původní vizi
Po technickém auditu a stabilizaci by ideálně měla vzniknout upravená roadmapa, která propojí technický stav projektu s byznysovými prioritami. To je moment, kdy se z problematického projektu může znovu stát produkt s jasným plánem, který nový tým může postupně naplňovat.
Stojíte právě teď na vývojovém rozcestí?
V Netglade běžně přebíráme rozjeté projekty a přepisujeme legacy systémy.
