SYSTÉMOVÝ INŽENÝR A JEHO ROLE VE VÝVOJI PRODUKTU

V počáteční – inicializační – fázi pomáhá systémový inženýr analyzovat a identifikovat, v čem jsou možná úskalí požadovaného nového produktu anebo požadovaných změn produktu existujícího.
Na základě této analýzy pak systémový inženýr přichází s návrhy na možná řešení.
V této fázi systémový inženýr úzce spolupracuje s projektovým manažerem (PM), kterému pomáhá s tvorbou návrhu na zahájení projektu (nabídky).
PM zpravidla od systémového inženýra požaduje analýzu dopadů (Impact Analysis) jednotlivých variant řešení, rozpad prací (Work Breakdown Structure) a často i expertní odhady na jejich provedení (obvykle v MD – Man-Days, česky člověkodnech).
Zákazník (klient/sponzor) odsouhlasí nabízené řešení, případně u variantních řešení si vybere jedno z nabízených řešení, anebo si také nevybere žádné (to v případě, že předložený návrh řešení podle jeho názoru nesplňuje jeho očekávání), případně požádá o úpravy jím preferované varianty.
Projektoví manažeři si pak vymění informace o termínech na analýzu a vývoj, a pro systémového inženýra začíná boj. Boj s časem, protože ne vždy dohodnuté termíny odrážejí reálnou potřebu na zpracování zakázky, boj s vlastníky různých částí systému, boj s často ne zcela srozumitelnou nebo nekompletní stávající dokumentací, a někdy i boj se sebou samotným.
Zcela klíčovou fází je fáze analýzy, ve které systémový inženýr sbírá detailní informace jednak o požadavcích na nový systém, resp. na požadované úpravy stávajícího systému, a zároveň se snaží získat maximum informací o systémech, se kterými bude třeba komunikovat, získávat z nich data, nebo do nich data dodávat.
Jedním z hlavních výstupů práce systémového inženýra je tzv. specifikace požadavků na systém (System/Subsystem Specification). Tato specifikace obsahuje všechny požadavky na systém a definuje rozsah projektu. Často se používá anglický výraz „scope“, co je v něm popsáno, musí být uděláno, aby byl projekt z pohledu klienta hotov.
Ve vývojové fázi projektu systémový inženýr komunikuje hlavně s vývojáři, kteří pracují na vývoji systému podle systémové specifikace a dalších dokumentů systémového inženýra. Vývojáři se na „svého“ systémového inženýra obracejí s dotazy, připomínkami anebo novými návrhy. A to buď sami, nebo jsou nastaveny pravidelné (ideálně s velmi malou periodou) konzultační schůzky. Pro každý projekt se hodí jiná intenzita komunikace, každopádně jí ale prakticky vždy musí být dostatek, přiměřeně k rozsahu projektu. Systémový inženýr rozhodně jen nedoplňuje dokumentaci o to, co opomenul, případně nedomyslel do všech důsledků atd. při její tvorbě. Někdy musí třeba svolávat a koordinovat další analytické schůzky, aby došlo k získání informací od všech zúčastněných stran, podle výsledků schůzek pak musí upravovat a doplňovat svou dokumentaci. Pokud jsou na schůzkách sjednány změny zadání, systémový inženýr je zapracovává do dokumentace.
Jakmile se vývoj blíží k úspěšnému závěru, musí být připravovány testovací procedury a scénáře pro testování systému, které mají za cíl ověřit, že vyvinutý systém splňuje všechny požadavky systémové specifikace. Tyto testovací scénáře a procedury připravují buď testeři, nebo test designeři, kteří při své práci vycházejí kromě jiného i z dokumentace systémového inženýra, kterou s ním konzultují. Systémový inženýr se následně účastní přezkoumání a případně i spolu schvaluje výsledné testy, podle kterých se nový systém testuje. Podle počtu členů vývojového teamu může testovací scénáře také někdy (výjimečně) zpracovávat systémový inženýr, a systémový inženýr může také někdy sám testovat.
Následné testování po nasazení systému u konkrétního zákazníka bývá další moment, kdy na systémového inženýra čeká výrazně více komunikace – zákazník přebral systém k testu a jeho testeři nacházejí chyby. A také „zdánlivé chyby“, protože se často stává, že i když byly sepsány stovky stran podrobné dokumentace, tak až po nasazení se zjistí, že některé funkcionality byly zákazníkem myšleny trochu jinak. Systémový inženýr pak musí odpovídat na dotazy, proč ta či ona část systému má takovou a takovou funkci, a také se na něj obracejí s žádostí o podporu projektoví manažeři, jejichž cílem je dostat zaplaceno za každou změnu, která nebyla požadována a schválena ve specifikaci ... Zatímco častým přáním řady zákazníků je naopak neplatit za další úpravy nic. Systémový inženýr tak musí bránit sebe, své specifikace, potažmo svého zaměstnavatele. V tomto minovém poli pak musí s bezchybným poker-face argumentovat, vyjednávat, analyzovat, a nacházet řešení…
..... pohled kolegy, který v SE působí již řadu let