Situace
Typická situace po změně dodavatele, odchodu vývojáře nebo po delším období bez technického vedení.
Převzetí cizí nebo rozpracované aplikace je citlivý moment. Firma potřebuje pokračovat, ale zároveň nechce rozbít provoz ani investovat do technického směru, který se za tři měsíce ukáže jako slepá ulička.
Největší riziko bývá v neznámých závislostech, nepřehledném release procesu a v tom, že důležité znalosti zůstaly u původního dodavatele.
Proto dává smysl nejdřív zmapovat realitu systému a až potom rozhodovat, co stabilizovat, co zjednodušit a co případně přepsat.
Bez úvodního zmapování se snadno opravují jen viditelné symptomy a zůstávají skryté provozní i rozvojové blokátory.
Začínám orientací v systému, závislostech, provozu a kritických scénářích. Z toho vznikne prioritizovaný plán, který kombinuje stabilizaci, zrychlení dalšího vývoje a realistickou míru změn.
Cílem není jen něco rychle opravit. Smyslem je vrátit projektu kontrolu, přehled a další rozvoj bez zbytečné nejistoty.
Ideálně ano, ale často se postupuje po vrstvách. Nejdůležitější jsou repozitáře, prostředí, deployment a lidé, kteří znají byznys kontext.
První audit obvykle rychle ukáže, kde je skutečné riziko. Teprve pak má smysl bavit se o větším refaktoru nebo rewritu.
Ano. U většiny takeover projektů je to nutnost. Právě proto preferuji postupné mapování a stabilizaci místo tvrdých řezů bez kontextu.
Ano. Mohu navázat dlouhodobější spoluprací nebo předat strukturovaný plán vašemu internímu týmu.
Další krok
Stačí krátce popsat stav aplikace nebo procesu a hlavní riziko, které dnes řešíte.