Jak přebrat aplikaci? Provedeme vás celým procesem

Většina programátorů je hravá a s tvůrčím duchem. Takže není divu, že je snem spousty z nich dostat projekt, ve kterém si mohou nakódovat úplně novou aplikaci na „zelené louce“ a vybrat si k tomu technologie, které jim vyhovují. Bohužel, alespoň podle mých zkušeností, je v posledních pár letech realita dost odlišná. Ne že by se stále neprogramovaly nové systémy. Většina velkých zákazníků má ale už svůj software hotový a jeho změna by je stála množství času a peněz. Pokud něco potřebují, jedná se spíš o drobný rozvoj, anebo o přechod k jinému dodavateli, od kterého si slibují snížení nákladů. Přesně tohle už mne potkalo několikrát.

Co s tím, pokud nechcete dopadnout jako parta vědců v Oblasti 51, kterým právě přivezli sestřelené UFO na prozkoumání? Nejlepší je mít na to metodiku nebo alespoň nějakou osnovu, podle které budete postupovat a která vám pomůže nezapomenout na nic důležitého. I my jsme se k ní časem propracovali. Není to sice žádná raketová věda, ale i tak nás to stálo dost úsilí, času a zkušeností z několika projektů.

Tak tuhle větu mějte stále na paměti! I ve věcech, u kterých nás ani nenapadlo, že by mohly být nejasné, to zaskřípalo.

Pokud právě stojíte před úkolem něco převzít a po přečtení předchozího zvažujete, jestli se do toho pustit, nebo radši odjet do Ameriky žít mezi Indiány, nezoufejte. Dá se tím projít, když víte, na co si dát pozor a zahrnete to do plánu převzetí.

Tento plán by měl zahrnovat následující

Nemusí to být nutně takto chronologicky za sebou. Některé body se budou prolínat celou etapou přebírání

1) Budujte vztah se zákazníkem.

2) Zmapujte a popište hlavní funkčnosti aplikací, rozhraní na aplikace třetích stran a popis HW, na kterém aplikace běží. Seznamte se s aplikacemi u zákazníka. Potvrďte si rozsah a časový rámec převzetí u zákazníka.

3) Spolupracujte s předchozím dodavatelem

a. Konzultujte s ním přebírání aplikací

b. Dohodněte se s ním na řešení oprav plynoucích ze záruky (předchozím dodavatelem)

c. Spolupracujte na některých částech a přebírejte projekt postupně.

4) Nastavte, jak bude zákazník sdělovat své požadavky. Jakým způsobem se bude zadávat práce v týmu. Kam se bude ukládat kód, jak bude aplikace testována, předávána a nasazována zákazníkovi do provozu, …

5) Převezměte instalační balíčky posledních verzí aplikací včetně DB.

6) Vytvořte vlastní prostředí a instalujte aplikace na něm.

7) Převezměte zdrojové kódy.

a. Přidělte aplikace analytikům a programátorům tak, aby měl každý vymezenou svou oblast a neprobíhalo zkoumání chaoticky a podle toho, koho zrovna co zajímá.

b. Zevrubně zmapujte zdrojové kódy (počet řádků, použité technologie, počet modulů, statická analýza kódu, …)

c. Podrobněji zmapujte procházení a rozcházení kódu

d. Vytvořte ze zdrojových kódů balíčky a instalujte je na vlastním prostředí

8) Porovnejte funkčnost aplikací „ze zdrojového kódu“ s funkčností přebíraných aplikací „z instalačních balíčků“. Nejlépe instalací u zákazníka a s potvrzením totožné funkčnosti od něho.

9) Převezměte i řešení incidentů a podporu

10) … a odteď to je už jen na vás.

Jestli jste si všimli, nepíšu to ani z pohledu programátora, analytika a ani jiné role. Při přebírání aplikace jsou totiž důležití všichni a nemělo by se zapomenout na žádné hledisko.

Pokud něco přebírám, musím vědět co

Přijde vám to jasné? Ne vždy to tak je. Už jsem se setkal i s tím, že ani sám zákazník nevěděl, že když chce, abychom přebrali webovou aplikaci, tak musíme převzít i několik dalších aplikací, které stojí za ní. Ona zmiňovaná aplikace je jen jednoduché rozhraní k zadávání požadavků, které ale zpracovávají jiné části systému. Tudíž z přebírání, které by trvalo dejme tomu měsíc, je najednou měsíců několik, a pokud na to máte fixní rozpočet, je hned o problém víc.

Příkladem může být webová aplikace, do které se zadávají požadavky na generování reportů. Uživatel požadavek zadá, pak se něco děje a nakonec si vygenerovaný report stáhne k sobě. Tohle generování může dělat jak aplikace, tak to může vytvářet na pozadí běžící windows service napojená na frontu v databázi, která to ale ještě mimochodem strká někam do document management systému, kde se vše ukládá a zálohuje. A hned se vám taková aplikace krásně rozkošatí.

Pokud tedy mohu radit, vytvořte si nejdřív seznam přebíraných aplikací, vztahů mezi nimi a navazujících aplikací třetích stran. Nezapomeňte i na seznam dokumentace apod. Chápu, že číst manuály a nějaké dokumenty o systému je vždy až ta poslední možnost, jak se o něm něco dozvědět. Často je to ale užitečné a je možné se z toho vyčtete spoustu věcí, které například zákazník ani nepovažuje za důležité, protož mu je předtím zařizoval předchozí dodavatel. A až si ten přehled budete tvořit, zapojte do toho také architekta nebo programátory, kteří prověří, jestli je skutečně pravda to, co se o systému řeklo na manažersko-obchodní úrovni. Někdy se ty pohledy od sebe dost liší.

No a teď už jen to všechnu know-how o aplikaci nějak dostat k vám do firmy

Dost by vám v tomto i dalších krocích pomohl někdo, kdo se v přebíraném systému vyzná. Nemusí být však nutně člověk od zákazníka. Dost často je jediným, kdo o aplikacích něco technického ví, předchozí dodavatel. Je ideální, když má pomoc následujícímu dodavateli zakotvenou přímo ve smlouvě se zákazníkem. Ne vždy to tak ale je, a pokud je předchozí dodavatel na vás naštvaný, že přišel o zakázku, moc sdílný vůči vám nebude. Na druhou stranu není ani příliš dobré, když je nadšený, že se zrovna této zakázky zbavil. Pomineme-li emoce a to, že zákazník nemá často na předchozího dodavatele páky, zbyde už jen jediný prostředek. Peníze. Oficiálně a s vědomím zákazníka zaplaťte předchozímu dodavateli a jeho lidem za konzultace, které od nich budete potřebovat. Řeknou vám spoustu informací, jejichž zjišťování by vás jinak stálo mnohem více času i nákladů. Pokud se „neseknou“, je to pro ně další možnost, jak zúročit své znalosti z projektu a ještě něco díky tomu vydělat. Nehledě na to, že spousta projektů umožňuje i to, že si je najmete jako subdodavatele do doby, než si budete sami jistí v kramflecích.

Menší krok stranou: Dřív to zákazníci nepožadovali, ale nyní si už většina z nich ve smlouvách s novým dodavatelem dohaduje také exit plán. A tohle je správný okamžik, kdy si ho můžete začít tvořit. Jste nyní ve stejné situaci, jako bude dodavatel po vás. Takže si pište, co jste potřebovali a co by se mělo zajistit pro snadný přechod. Až to budete předávat někomu jinému, bude vás to stát méně času i peněz.

Když něco přebírám, budu to taky muset někde provozovat

Práce pro architekta, databázistu, vývojáře a IT.

Bývá dobrým zvykem, že vývojáři vyvíjí na svém prostředí a ne rovnou v produkčním. Proto je dobré si udělat prostředí vlastní. Pomíjím teď specifika projektů, kde vývojové a další prostředí poskytuje přímo zákazník. Můžete začít tím, že si zjistíte, na jakém HW běží aplikace u zákazníka, jaký OS používají, jakou mají DB, jaký další SW je potřeba pro běh aplikací atd. Ve své firmě se pak následně snažte vybudovat prostředí co nejpodobnější.

Až budete zřizovat nové servery, doporučuji už dopředu počítat s tím, že budete mít jednotlivých prostředí časem nejspíš víc (pro vývojáře, testery a analytiky). Takže už na začátku zvolte vhodnou konvenci v pojmenování, ať je na první pohled jasné, do kterého prostředí jaký server patří.

Rozchoďte si databázi. Pokud není DB součástí instalace jednotlivých aplikací, budete si ji muset někde stáhnout a u sebe nainstalovat.

Bez té se určitě neobejdete. Dejte si pozor při jejím získávání na následující: zákazník může (a většinou i má) několik prostředí (například testovací a produkční). Databáze se pro tato prostředí mohou lišit. V testu mohou být věci navíc (nebo i méně) než na produkci. Snažte se proto, aby zákazník dotlačil předchozího dodavatele k tomu, aby databáze na jednotlivých prostředích uvedl do stavu 1:1. Během přebírání může původní dodavatel stále do DB dělat různé úpravy. Nespoléhejte se proto, že pokud si na začátku přebírání stáhnete databázi, bude taková i na jeho konci. A i když tohle vše bude v pořádku, stále máte šanci, že naleznete v DB věci, které se vůbec nepoužívají. Čím dříve se na to zeptáte, tím spíš vám někdo odpoví. Za dva roky o tom už zákazník nebude nic vědět a s původním dodavatelem už taky dávno nemusí být v kontaktu, takže ani jeho se nezeptá.

Tak ty se vám také budou hodit. Kvůli GDPR a jiným bezpečnostním omezením je vám většinou nikdo osobní data nebude chtít poskytnout bez jejich anonymizace. To pro vás, protože o nich a o systému, který přebíráte, zatím prakticky nic nevíte, bude ale problém, protože nebudete vědět všechny potřebné vazby a souvislosti, abyste to byli schopní udělat pořádně. Možná má ale nějaká data předchozí dodavatel nebo sám zákazník. Snažte se proto, aby vám nějaký vzorek poskytli. Co si ale budete moci stáhnout nejspíš bez problémů, budou číselníky, různá nastavení a parametry.

Když už máte své prostředí, měli byste mít na něj také co nainstalovat. Nejspíš ještě nebudete mít vlastní instalační balíčky aplikace (nebo aplikací), protože je ještě neumíte vytvářet. Proto si vyžádejte ty, které má váš zákazník od předchozího dodavatele. Můžete si tak začít rozbíhat prostředí nezávisle na přebírání kódu, což ocení především analytici, kteří si budou chtít nové aplikace co nejdříve prohlédnout. Zároveň vám to umožní zjistit, zda jste se opravdu dozvěděli o všem, co si máte nainstalovat k tomu, aby teď už skoro vaše aplikace běžela. Ne vždy (respektive prakticky nikdy) je vše řádně zaznamenáno v instalačních a administrátorských příručkách, které si tímto projdete a zjistíte, co v nich chybí. A i pokud nebude žádný potřebný SW chybět, užijete si určitě spoustu zábavy s nastavováním různých parametrů.

Máte nainstalováno? Jen málo systémů, modulů, aplikací nebo jiných částí, ať už je nazýváte, jak chcete, funguje samo. Většinou je budete muset přes nějaká rozhraní propojit. Pokud máte všechny části daného systému, budete v pohodě. Většinou jsou ale potřeba i aplikace, které vám nikdo neposkytne, a které sice zákazník má, ale spravuje mu je jiná firma a nemůže vám je poskytnout. Anebo i kdyby chtěl, je to tak složité, že pro vaše potřeby by jejich zprovoznění bylo dost nákladné. V tom případě vám nezbyde nic jiného než zjistit, jak dané rozhraní funguje a naprogramovat si nějaký jeho emulátor. U spousty případů si vystačíte s odesláním dat a obdržením jednoduché návratové hodnoty. Jiná rozhraní mohou být dost složitá. Nezapomeňte proto do harmonogramu přebírání zohlednit i toto.

Ještě poznámku. V podobné situaci byl nejspíš i předchozí dodavatel a zmiňovaná rozhraní si také musel nějak vytvořit. Asi vám je jen tak nedá, ale zkuste si projít kód, který přebíráte. Dost často se stává, že jsou ona rozhraní přímo v něm někde schovaná. I vývojář je totiž potřeboval a musel je mít někde po ruce.

Výsledkem tohoto kroku by mělo být vybudované prostředí u vás ve firmě a fyzické převzetí aplikací (čímž se myslí, že získáte minimálně jejich instalační balíčky) včetně dokumentace.

Jestli jste s instalačními balíčky neobdrželi i zdrojový kód, měli byste ho začít rychle shánět. Bude brzy potřeba. Kód, který si seženete, by měl odpovídat instalačním balíčkům, které jste obdrželi.

Máme prostředí. Teď ještě zjistit, k čemu ty aplikace, které na něm běží, jsou a co umí

Tohle je práce hlavně pro analytiky a možná i testery, kteří se v tom budou vrtat a zkoumat. Zapojí se ale nejspíš i vývojáři, kteří budou hledat chyby v kódu. Ten by už měli u sebe mít a budou se snažit chyby odstranit, aby analytici mohli pokračovat v bádání.

Nemá asi cenu rozebírat, že by pomohlo, kdyby analytikům někdo tu aplikaci předvedl a vysvětlil, jak s ní uživatelé pracují. Na rozdíl od předchozího kroku by měl toto zvládnout sám zákazník.

Skvělé je, když se také dostanete k seznamu incidentů, které se v nějaké poslední rozumné době na aplikaci udály. Už jen jejich počet a druh vám může naznačit, jak to s kvalitou aplikace opravu vypadá a čím se nejspíš budete v budoucnu zabývat. Taky vám to dost pomůže, pokud v kódu naleznou programátoři komentáře typu „tohle jsem přidal kvůli tasku #1234“ apod. Budete si totiž moci dohledat, co to vlastně ten task #1234 byl.

Aby se vývojáři nenudili

Aplikace máte. Zdrojový kód také. Prostředí je rozběhané. Analytici zkoumají funkčnosti. Co dál? Dál je potřeba rozchodit zdrojový kód u jednotlivých vývojářů na počítačích, aby byli schopní si aplikaci zkompilovat a spustit u sebe a třeba ji i prokrokovat, až budou zjišťovat, jak funguje. A to brzy budou. Analytici totiž po chvíli zjistí, že dokumentace, kterou dostali, jim nestačí a spousta věcí v ní není. A když se už v tom kódu vývojáři vrtají, měli by se naučit jak výsledek, který zkompilují, také nasadí na nějaký server nebo jiný počítač. To je dost podstatná věc, protože nejde jen o to něco opravit nebo nově vyvinout, ale je stejně důležité dostat to také k zákazníkovi. V lepším případě mu to budete nasazovat sami, v tom horším a obvyklejším mu předáte instalační balíček a instalaci si už zákazník zajistí sám.

Tak si hlavně dejte pozor na následující:

Ušetří vám to spoustu chyb typu: „ale u nás to jde.“

Někdy u něho na servery instaluje více firem, využívají jen některé technologie, anebo na to prostě mají takový postup, který někdo vymyslel před dvaceti let a nechtějí to od té doby instalovat jinak.

Seznámení s kódem

S kódem se vývojáři budou seznamovat celou dobu. Je naivní si myslet, že dostanou kód a měsíc na to, aby se ho naučili. Naučí se toho spoustu, ale nikdy to nebude na sto procent. Vždy se v aplikaci najde něco, co vás překvapí klidně i po pár letech, kdy si už myslíte, že kód opravdu znáte.

Proto uvádím několik bodů pro inspiraci, co dělat:

Je dobré si vyzkoušet pár reálných oprav/úprav aplikace, které může zjistit analytik od zákazníka. Nikdo se nebude zlobit, když v rámci budgetu na přebírání zvládnete i věci, které vás stejně neminou.

To, že kód nepadá, neznamená, že je správně. Zkuste ho proto prověřit statickou analýzou kódu. Jednak vám většina těchto nástrojů sdělí, kolik to má řádků. Na což se velice rád ptá management. Hlavně vám to ale rychle poskytne přehled technologií a jejich rozsah, které jsou použity (například, zda v očekávaném C# kódu nejsou i komponenty z Visual Basicu apod.). A dozvíte se také o tom, jak je ten kód napsaný a jaké problémy můžete do budoucna očekávat. Je dobré s výsledkem seznámit i zákazníka, aby nežil v domnění, že vám předchozí dodavatel předal vybroušený diamant, který jste následně svými zásahy naprosto zničili.

Obsahuje přebíraný kód nějaký cizí framework nebo komponentu? Nejspíš ano. Pokud je to obecná komponenta nebo framework, jste v pohodě. Dokumentaci většinou k podobným věcem předchozí dodavatel nedodá, ale aspoň si ji budete moci sehnat někde jinde. Často jsou to ovšem náklady navíc a budete si možná muset koupit licenci, abyste to mohli používat a vyvíjet. I tak je to ale ta lepší varianta. Mnohem problematičtější je, když použil nějaký svůj vlastní firemní Framework a jedná se v podstatě o určitý vendor-lock. V horším případě to pro vás bude naprostý blackbox. V lepším, pokud dodal i zdrojové kódy, vyčtete alespoň něco z nich. Dokumentaci totiž nejspíš nedostanete a zeptat se také nemáte kde, pokud není zákazník natolik silný a nevynutí si ji. Nezbyde vám proto nic jiného, než se modlit, aby byl framework co nejméně chybový a vy do toho nemuseli dělat žádný zásah.

Statickou analýzu používejte i při vašem programování a snažte se postupně co nejvíce prohřešků odstranit.

Asi nejkurióznější věci, které jsme při přebírání kódu našli, byl nákupní seznam některého z předchozích vývojářů a v jiném projektu pak video s návodem na výrobu hliněné okaríny. Takže si určitě nedělejte iluze, že přebíraný kód bude v perfektním stavu.

Rozhodně se připravte na to, že za vámi budou chodit vývojáři s tím, že to snad programovali v nějaké chráněné dílně a že by to chtělo celé napsat znovu. Určitě to tak je, i my jsme takový kód přebírali plni naivních iluzí, jak ho dáme do pořádku. Jenže zákazník vám na to peníze nejspíš nedá. A vaše firma do toho také pravděpodobně nebude chtít investovat vlastní peníze, když se může stát, že za dva nebo tři roky, či na kolik máte smlouvu, to zase vyhraje někdo jiný. Moc velký prostor na nějaké úpravy tedy mít nebudete. Většina kódu proto nejspíš zůstane taková, jaká je. Přesto se snažte ho co nejvíc vyčistit, protože teď je nejvhodnější doba. Později vás bude mnohem víc tlačit čas a peníze a to, za co jste proklínali předchozí dodavatele, budete bohužel muset v rámci kompromisů dělat nejspíš taky.

Přebrali jsme

Tak už umíme udělat balíček stejný, jako jsme dostali. Máme tedy přebráno. Ani omylem! Jste si jistí, že zdrojový kód, ze kterého jste vytvořili balíček, opravdu obsahuje všechnu funkcionalitu a je naprosto aktuální? Všichni budou říkat, že ano. Vyzkoušejte si přesto instalaci u zákazníka, už jen kvůli testu, že skutečně u něho při instalaci nespadne. Přeci jen vaše prostředí, na kterém jste ho určitě také otestovali, může být v některých detailech jiné. A když už ho bude mít nainstalovaný, tak ať si ho zákazník rovnou projde a potvrdí vám, že funkčnost, která v něm je, je skutečně ta správná a aktuální. Stane se totiž, ale to tak jednou, možná dvakrát za deset let, že vám dají sice aktuální instalační balíčky, ale zdrojové kódy jsou o něco starší. A řešit to, až se na to přijde, což taky může být klidně za rok a většinou v tom největším presu, když zrovna dodáváte něco jiného, stojí hodně nervů. Obzvlášť, když vám pak zákazník bude tvrdit, že jste si to měli převzít pořádně a že už teď oslovovat předchozího dodavatele, aby jim dal skutečně tu poslední verzi, nebude. Výsledkem bude buď naštvaný zákazník, že musí platit znovu za něco, co už měl opravené, anebo vy, že budete opravovat něco zadarmo.

Pro zamyšlení: v dnešní době, kdy se skloňuje bezpečnost ve všech pádech, zkusili jste projít zdrojový kód, který přebíráte, jestli v něm nejsou nějaká zadní vrátka, virus nebo jiný malware? Není na serveru nainstalovaná nějaká diagnostika, která posílá informace stále k původnímu dodavateli? Nezůstaly původnímu dodavateli přístupy k zákazníkovi do prostředí?

Teď už jsme skutečně přebrali

Zákazník nám potvrdil (písemně), že v námi dodaných aplikacích, které jsme zkompilovali z obdržených zdrojových kódů, je veškerá funkcionalita od původního dodavatele, a ověřili jsme, že instalační balíčky jdou nainstalovat. Takže od teď už všechno opravujeme a vyvíjíme my. Skutečně? A co když budete něco opravovat? Kdo to bude platit? Budete opravovat chyby po předchozím dodavateli nebo to opravuje v rámci záruky on? Když to opravuje on, jak budete řešit přebírání oprav? Když to opravujete vy, zaplatí vám to zákazník nebo to bude chtít zdarma, když už za to jednou zaplatil?

Doporučuju si podobná témata se zákazníkem ujasnit co nejdříve, předejde spoustě překvapení. Z vašeho pohledu je dobrým řešením udělat tlustou čáru a vše, co je v aplikaci ke dni, kdy ji přebíráte, brát jako funkcionalitu. Všechny změny a opravy jsou pak nový požadavek na vás, který by měl být samozřejmě placený.

Tak a to by mohlo být všechno

Ale není. V průběhu celého přebírání byste si měli postavit tým, který bude sehraný, jeho členové si budou navzájem sedět a budou spolu schopní komunikovat a řešit problémy. Měli byste si také vybudovat nějaké úložiště pro kód, systém pro správu požadavků a zadávání práce. Nastavit způsob, jak vám požadavky bude předávat zákazník. Zvolit si metodiku vývoje, a ať už to bude vodopád nebo nějaká agilní, nechat si na ni zvyknout nejen váš tým, ale i zákazníka. Prostě spoustu věcí, které se dost často předpokládají automaticky, ale na kterých to potom ve výsledku drhne.

A co na to zákazník?

Respektive spíše lidé, se kterými se budete na projektu setkávat vy. Pro ně je to často dost nepříjemná situace. Byli zvyklý na předchozího dodavatele, který se vyměnil většinou bez ohledu na jejich přání, protože o tom rozhodlo vyšší vedení na základě úplně jiných kritérií, než měli oni. Pravděpodobně se stane, že s dodavatelem mají za ta léta mezi sebou už i přátelské neformální vazby a teď je někdo zpřetrhal. Navíc je čeká mnohem víc práce, než kdyby to zůstalo, jak bylo. Spousta věcí už běžela automaticky a to se teď mění. Vstupujete proto dost často na nepřátelské území a to se musíte snažit změnit. Bude na vás, abyste přesvědčili protistranu, že jste odborníci, kteří vědí, co dělají, a celé to převzetí proběhne hladce. I když to tak nejspíš nebude. Snažte se proto vyjít zákazníkovi vstříc a vystupovat i trochu s pokorou. Nezapomeňte také zákazníka informovat, co se právě děje. To, že si od něho vezmete kódy, přestanete s ním komunikovat a na měsíc si někam zalezete je zkoumat, v něm moc velkou důvěru nevzbudí.

Zažil jsem firmu, a naštěstí to nebyla ta naše, která přijela na první „přebírací“ schůzku se zákazníkem, vytasila se tam bez jakékoliv znalosti procesů na jeho straně s přesným harmonogramem přebírání a nadiktovala mu, jak to bude. Zástupci zákazníka jen koukali, protože sami věděli, že spoustu věcí v jejich hodně velké organizaci prostě není možné tímhle způsobem zajistit. A hlavně, že oni to dělat nebudou a dodavatel si musí o příslušné věci a přístupy zažádat sám. Navrhli proto další schůzku, kde by si vyjasnili, co je a není potřeba. Manažer dodavatele jim řekl, že klidně ano, ale že na ni nepojedou už osobně, protože zákazník je od nich daleko a budou to řešit po Skypu. Ta firma po několika měsících, kdy nebyla schopná si zařídit ani přístupy lidí do areálu zákazníka, natož něco přebrat, o tu zakázku přišla, protože s nimi zákazník ztratil trpělivost.

Přeju vám při tom přebírání hodně štěstí a pevných nervů, až si budete rvát vlasy a přát si, aby tu zakázku vyhrála radši vaše konkurence.