Při sepisování smlouvy o dílo je přesně specifikován předmět díla, neboli položky, které dílo obsahuje a které nikoliv. Mezi zhotovitelem a objednatelem existuje vztah důvěry, jednotlivé problémy se řeší otevřeně a konstruktivně, stavebníci a montéři dostanou do ruky přesný a jednoznačný projekt, podle kterého úspěšně vytvoří požadované dílo. Kolaudační závady jsou bezezbytku odstraněny ještě před odevzdáním díla objednateli, který se pak už jen nastěhuje a spokojeně žije...

Charakterizuje-li výše uvedený popis realitu našeho stavebnictví "na klíč", to nechť posoudí sám čtenář podle vlastních zkušeností. Pokud je ovšem řeč o informačních systémech dodávaných "na klíč" společností Unicorn, popis reálný je. Analýza, design, testování - to jsou etapy procesu výstavby systému, které na sebe navazují a zároveň probíhají paralelně a ve výsledku rozhodují o tom, zda bude produkt pro zadavatele použitelný, zda splní jeho očekávání.

Jiří Svačina, analytik:


Při tvorbě informačních systémů musíme mít na paměti, že vytváříme něco, co bude zákazníkovi dobře sloužit a automatizovat jeho obchodní procesy. Obvykle se zabýváme problémy, které nelze řešit dostupnými prostředky, a od nás se očekává, že ty prostředky nalezneme. Zákazník chce například rozšířit nebo změnit dosavadní procesy ve firmě a zjistí, že k tomu potřebuje informační systémy určitého typu. Práce analytika spočívá v tom, že musí pochopit, co zákazník chce, získat od něho všechny informace včetně představy, co má dané řešení podporovat, a pak tyto informace transfomovat do podoby vyhovující technikům IT týmu, aby mohli systém vyrobit. Role analytika je role mediátorská, je prostředníkem mezi těmi, kteří chtějí řešení, a těmi, kteří je vytvářejí. Naši programátoři potřebují srozumitelné informace, na jejichž základě vytvoří systém, který zákazník potřebuje. Když chcete stavět dům, nebudete se na počátku bavit se zedníky, ale s architekty, kteří vám nejprve vytvoří projekt, v němž transformují vaši vizi do konkrétního zadání. Taková je i role analytika. Tvorba software je stále poměrně mladý obor, abstraktní, pro spoustu lidí je to stále ještě nesrozumitelný "matrix".

Je dost neobvyklé, má-li klient informace připravené, sesumírované, rovnou použitelné k výrobě. Zákazníci mají spíše jasno, pokud jde o problém, ale už ne o způsob jeho řešení. Přidaná hodnota analytika spočívá právě v tom, že získává informace od řady lidí v návaznosti na dělbu práce a odpovědnosti; většina systémů přesahuje jedno oddělení a analytik musí informace sesbírat napříč podnikem a pak je konfrontovat se stávající situací ve firmě a s již realizovanými řešeními. Řada informací a potřebných dat ve firmě existuje, stačí je jen aplikovat, zakomponovat do nového řešení. Vše získáváme postupně. Předpokládá se, že analytik porozumí podnikání, které má řešit, proto se obvykle projektů účastní dlouhodobě - já jsem se například podílel na projektu automatizace procesů na ČSSZ, jako analytici jsme nemuseli porozumět všem procesům tak hluboce jako sami pracovníci, ale určitě jsme do nich pronikli více než běžný občan. Analytik se pak stává lidem ve firmách rovnocenným partnerem, přičemž by v ideálním případě neměl jen slepě informace přijímat, ale je i vyhodnocovat a případně rozporovat a navrhovat lepší řešení. To už ovšem vyžaduje, aby oboru rozuměl, což je důsledkem praxe.

Obecně platí, že by lidé měli být odborníky a orientovat se v oboru svých klientů. Proto se analytici oborově specializují, i když jsou i tací, kteří mají specializaci jednu a stačí jim to.

Aby člověk mohl být analytikem, musí mít know how z pěti základních oblastí:


- práce má základní pravidla, musíte tedy znát metodiku, jak se analýza a potažmo celý systém vytváří. Analytik musí znát "řemeslo"- na co se ptát, jak informace zaznamenat. Metodiku mají různé firmy různou, ale stále jde o jedno: získat informace, zaznamenat je a předat dál;

- musí rozumět danému byznysu;

- měl by podle mého rozumět informačním technologiím. Analytik, který nikdy reálně neprogramoval, je pouhý teoretik a řada věcí mu může unikat. Získává přeci informace proto, aby vznikly informační systémy, které staví programátoři, je tedy dobré o programování něco vědět;

- musí porozumět prostředí zákazníka, pochopit je, musí vědět, co může a co nemůže navrhnout;

- analytici jsou vždy součástí týmu, takže musí umět pracovat v týmu, komunikovat, řídit.

Jsou to lidé, kteří nesou image IT společnosti mezi klienty.

Jsem 73. ročník, maturoval jsem těsně po revoluci, počítače se rozjížděly a člověk měl v tomto oboru obrovskou svobodu. Na střední škole jsem se zabýval programováním, po maturitě jsem studoval softwarové inženýrství na FJFI ČVUT a už v průběhu studia jsem nastoupil do Unicornu jako programátor. Školu jsem pak nedodělal, natolik mě práce zaujala. Naučil jsem se řemeslo, byl jsem programátorem, softwarovým architektem, až jsem dospěl k tomu, že mi nejvíce vyhovuje role analytika. Cesta podobná té mé je podle mého optimální. V různých rolích tu působím už 16 let, posledních asi šest let jako analytik. Vzdělání jsem si nakonec doplnil dálkově na fakultě informatiky a managementu v Hradci Králové.

Služebně mladším kolegům pomáhám orientovat se a zapracovávat, do řad analytiků často nastupují lidé s převážně ekonomickým vzděláním, kteří mnohdy nevědí, jak se software tvoří. V 90. letech byla práce s počítačem synonymem pro programování, dnes už jsou lidé spíš uživateli, aktivně s počítačem nepracují, často se mi zdá, že lidé přicházejí z vysokých škol hůř připravení na IT práci než dříve. Pro nás bylo programování koníčkem, dnes je to bráno jako zdroj obživy.

Obor se samozřejmě vyvíjí z hlediska organizace práce i technologií, což znamená pořád se učit něčemu novému. Sebevzdělávání je tudíž nezbytné, a to jak v metodice, v technologiích, tak v oborech, pro něž se analýza dělá. A jaké má analytik perspektivy? Role analytika je logickým odrazovým můstkem pro manažerské nebo obchodní pozice. Osobně se teď chci věnovat práci, kterou dělám, jak nejlépe budu umět a z hlediska vzdálenějšího horizontu bych se možná viděl na místě obchodníka.

Pavel Zeman, softwarový architekt:


Když se tvoří software, je na počátku fáze analýzy, pak fáze designu, která stanoví, jak bude systém fungovat, pak je vývoj a nakonec testování. Já nastupuji do procesu ve druhé fázi, od analytika dostanu detailně zpracované byznys zadání, na jehož základě navrhnu, jak bude realizováno. Výstupy analytika jsou ve formě požadavků dvou různých druhů: funkční požadavky, to znamená požadavky na to, co systém má dělat, a požadavky nefunkční týkající se použitelnosti, spolehlivosti, výkonu a další, například jak bude napojen na stávající technologie, které klient využívá... Na základě všech požadavků detailně navrhnu, jak má systém vypadat. To znamená definovat celkovou architekturu, zvolit vhodné technologie, vhodné "stavební bloky", které jsou již hotové a je možné je využít, rozdělit celé řešení na relativně nezávislé části, takzvané moduly nebo komponenty, a pro každou část specifikovat, co a jak bude dělat a jak bude komunikovat s ostatními. Součástí návrhu je i integrace se stávajícími systémy nebo to, jak bude organizován vývoj, jaké nástroje použijeme, jaké prostředí. Všechno to je pro projekt klíčové: když návrh zkazíte, vývojáři stráví spoustu času nad nesmyslem. Je to podobné, jako když při stavbě mrakodrapu v 50. patře zjistíte, že nosné zdi v přízemí praskají, protože nevydrží zátěž. Architekt je zodpovědný za to, že systém funguje.

Součástí návrhu je i ověření klíčových principů pomocí prototypů - kupříkladu zákazník chce, aby naše aplikace uměla komunikovat se čtečkou karet, kterou neznáme. V rámci návrhu tedy uděláme jednoduchou aplikaci, která bude komunikovat se čtečkou, a pak už můžeme pokračovat v práci na celém systému. Musíme mít jistotu, že vývoj půjde hladce. Někdy má zákazník až nereálné požadavky, pak s ním musíme diskutovat, navrhovat alternativní řešení. Záleží na typu projektu, ale analýza a design probíhají do značné míry paralelně a celé to zabere tak 20 - 40 % práce na projektu.

Softwarovým architektem se člověk nestane naráz, ale praxí a zkušenostmi, které získá v profesním životě. Měl by být dobrý vývojář, umět dobře programovat alespoň v jedné konkrétní technologii. Obvykle se začíná na pozici vývojáře, po nějaké době se člověk stává specialistou na danou oblast a posouvá se od vývoje k navrhování, až postoupí do role architekta. Měl by znát technologie a principy, které se používají při vývoji systému, měl by mít i znalosti z oblasti infrastruktury. Dalším předpokladem je znalost angličtiny - dost materiálů a technologií je v angličtině. Nesmí mu chybět znalosti teoretických principů, základních algoritmů a datových struktur, které se využívají při řešení typických problémů. Znát byznys klienta není tak nezbytné, ale pokud architekt tu znalost má, ulehčí mu to práci. Nezbytná je i znalost metodiky a principů vývoje software i proto, aby věděl, kde získávat informace, jakým způsobem je zpracovávat a zaznamenávat, s kým spolupracovat, komu v týmu jaké úkoly zadávat.

Odmalička jsem se zajímal o počítače, byl jsem na specializované matematické základní škole, po střední škole jsem pokračoval studiem informatiky na matematicko fyzikální fakultě. Při studiu jsem nastoupil do Unicornu na pozici junior vývojáře. Postupně jsem se učil principy a technologie, pak jsem dostal první malé projekty a nakonec se propracoval k projektům, na nichž pracuje 20-30 lidí a já navrhuji jejich architekturu. Kariérní růst určitě existuje, můžu se posunout například na pozici ředitele IT architektury, který má odpovědnost za všechny realizované projekty.

Kreativita je pro softwarového architekta vlastnost důležitá, ale neřeší vše. Architekt musí vymyslet inovativní řešení, ale držet se přitom jistých mezí, standardních postupů. Nemá smysl klientovi nabízet Ferrari, pokud mu bude dobře sloužit i škodovka. Někteří kolegové z VŠ pracují v bankách a stěžují si na jednotvárnost práce, což je přesně to, nač si my stěžovat nemůžeme. Práce na informačních systémech v Unicornu v žádném případě není nic monotonního.

Július Čunderlík, test architekt:


V rámci vývoje software je testování samostatná disciplina. Testerova úloha je zjistit kvalitu toho, co bylo naprogramováno, nakolik je vytvořený software použitelný a odpovídá-li zadání. Ověřujeme všechny dimenze kvality: může to být jeho rychlost, jak byl navržen, jak se udržuje, obnovuje, jaká je jeho funkčnost, použitelnost, výkonnost, bezpečnost. Proto také test architekt je už u zrodu projektu, aby od počátku věděl, co je cílem projektu, a mohl navrhnout, jak tu kvalitu pak budeme ověřovat. Testovací tým podle metodiky stanovené testovacím architektem připravuje testovací případy a scénáře, dle kterých pak bude kvalita software ověřována. Existují obecná pravidla testování a best practices, ale vždy závisí na tom, jak rozsáhlý systém budeme testovat. Příprava testů probíhá po celou dobu vývoje systému.

Znalost zadavatele hraje velkou roli, programátor naprogramuje, co je zadáno v analytických dokumentech, ale testeři musí ověřovat nejen jednotlivé funkčnosti, ale celý byznys proces v komplexu. Testování probíhá obecně ve dvou hlavních fázích. Jedna fáze zahrnuje systémové a integrační testy, tam je nejužší kontakt s vývojem, testy ověřují spolupráci jednotlivých funkčností. Pak je tu fáze uživatelských akceptačních testů, což je eliminace chyb z pohledu koncového uživatele a ověření před tím, než se program nasadí do ostrého provozu. Jsou různé typy projektů, pokud stavíme "na zelené louce", vývoj trvá nějakou dobu a program pak žije svým životem. Pokud má klient požadavky na změny, jsou už jen dílčí povahy a je tudíž dobré, když v týmu zůstávají lidi, kteří na projektu pracovali. Na velikosti projektu závisí i to, zda je tester vytížen na sto procent, nebo pracuje ještě na dalších projektech souběžně. Důležité jsou termíny, do kterých je třeba věci zrealizovat.

Test architektem se člověk nestává hned po škole. Potřebuje zkušenosti v oboru testování, takže nejprve vykonává testy podle zadání, k výkonu této práce potřebuje být precizní a spolehlivý, ale nemusí mít žádné hluboké technologické znalosti programovacích jazyků, databází a podobně. Pak se člověk stává testovacím analytikem, to už musí mít nějaké znalosti metodiky testů, která se stále rozvíjí a trendy se mění, pak musí mít schopnost pochopit byznys klienta, znát například bankovnictví a jeho obory, třetí potřebnou znalostí jsou detailní vědomosti o průběhu fáze analýzy a vývoje systému, aby mohl návrh testu přizpůsobit potřebám. Test architekt pak vytváří testovací strategii. Měl by být schopen číst zdrojový kód software, nebo přinejmenším rozumět syntaxi jazyka, znát SQL a nástroje, které mu práci ulehčí - úložiště pro různé testovací případy, které už jsem provedl, nástroje pro zadávání nalezených defektů, nástroje pro automatizaci testů - zde je nutnost znát programovací jazyk, ve kterém jsou testovací skripty vytvářeny. Architekt musí taky umět řídit lidi, očekává se od něho, že je schopný lidem předat svou vizi a vést je, a to jak v testování, tak i ve vývoji. Úkolem řídicího manažera je hlídat termíny, architekti jsou jeho poradními orgány, které mu pomáhají, aby se úkoly splnily včas a v požadované kvalitě.

Specializace není na škodu, ale kdo chce růst, měl by mít širší záběr než jen jeden obor.

Moje cesta na současnou pozici byla specifická: vystudoval jsem pražská práva, ovšem od druháku jsem pracoval tady v Unicornu jako tester a postupně jsem si projekt za projektem prošel pozice až tam, kde jsem teď - hlavní testovací architekt, který konzultuje a pomáhá vytvářet metodiku a testovací procesy. Povědomí o počítačích jsem měl asi jako každý z mé generace, ale nic jsem nevěděl o vývoji software, z vlastního zájmu jsem si znalosti doplňoval. Zatím o návratu k právu neuvažuji. Z pohledu testování je test architekt nejvýše, ale kariéra bude určitě pokračovat - například ke komplexnímu quality assurance - zajišťování kvality v celém průběhu vývoje software vyžadující objektivní pohled. Pak jsou ve společnosti pozice manažerské, na které lze z pozice testovacího architekta vystoupat.

Jak se stát test architektem? Je třeba mít o obor zájem, věnovat se samostudiu, sledovat aktuální trendy, metodiky, rozvíjet se. V rámci firmy funguje dobře strukturované interní vzdělávání, kurzy zaměřené na konkrétní věci i ve spojení s Unicorn College. Na naší vysoké škole jsem garantem předmětu testování software, který se učí ve třetím ročníku. Jelikož se od architektů předpokládá, že budeme šířit dobré jméno společnosti i na veřejnosti, přednášíme na odborných konferencích. Jsem tu od roku 2003 a díky projektům jsem poznal řadu společností na českém i slovenském trhu, to taky skýtá spoustu informací pro výkon činnosti. Je tu příjemná rozmanitost a různorodost klientů i projektů. Stává se mi, že mě z jiných firem "přetahují", chodí mi nabídky a já je s díky odmítám, protože chci ve společnosti zůstat, mám tu prostor pro růst a další profesní rozvoj.