IT business analystok Pécsett: Vélemények és kedvező árak

IT business analyst Pécsen

Az IT business analyst akkor kell igazán, amikor egy magánmegbízó már látja, hogy a fejlesztő és a megrendelő nem ugyanarról beszél, a feladatok csúsznak, és egy egyszerű igényből is félreértés lesz. Pécsen ez nem ritka. Kisebb webes projektnél, belső ügyviteli megoldásnál, rendelési felületnél vagy akár egy egyedi nyilvántartásnál is előjön. Az IT business analyst ilyenkor nem dísz a folyamatban, hanem fordító a két oldal között. Én személy szerint jobban szeretem, ha egy ilyen szakember már a legelején belép, mert utólag rendet rakni mindig drágább és fárasztóbb.

Sokan úgy indulnak neki, hogy van egy ötletük, beszélnek egy fejlesztővel, aztán pár hét múlva kiderül, hogy mindenki más végeredményt képzelt el. A gond nem feltétlenül a hozzáértés hiánya. Inkább az, hogy hiányzik az a köztes ember, aki pontosan feltárja az üzleti igényt, leírja a folyamatot, és érthetővé teszi, mi miért készül. Egy informatikai üzleti elemző ezt a munkát végzi. Nem csak kérdez, hanem rendszert visz a gondolkodásba. A Qjob.hu oldalon ezért keresik őt azok is, akik nem céget, hanem önálló specialistát akarnak találni egy konkrét feladatra.

IT business analyst választása

A választásnál szerintem az első szempont nem az ár, hanem az, hogy az illető hogyan kérdez. Ha valaki tíz perc után már kész megoldást kínál, az nekem gyanús. A jó üzleti elemző előbb azt akarja megérteni, mit szeretnél elérni, hogyan működsz most, kik használják majd a rendszert, és hol szokott elakadni a munka. Ez kevésbé látványos, mint egy gyors ígéret, de sokkal hasznosabb. Sok megbízó ott hibázik, hogy a magabiztos hangot összekeveri a valódi szakmai alapossággal.

Én azt nézném meg, hogy a szakember tud e egyszerű mondatokban beszélni bonyolult folyamatról. Ha csak idegen rövidítéseket mond, és a beszélgetés végére még kevésbé világos minden, abból később is nehéz együttműködés lesz. Az is fontos, hogy volt e már dolga kisebb projekttel. Egy magánügyfél vagy egy családi vállalkozás ritkán akar húsz dokumentumot és végtelen egyeztetést. Inkább gyorsan átlátható, használható rendet szeretne. A rendszerelemző akkor jó választás, ha ezt érzi.

Hasznos a rövid próbabeszélgetés is. Ebből hamar kiderül, figyel e, visszakérdez e, és meri e kimondani, ha egy elképzelés túl nagy, túl homályos vagy rossz sorrendben indulna. Nekem az a szakember meggyőző, aki nem mindenre mond azonnal igent. Az ilyen hozzáállás elsőre talán keményebbnek tűnik, de a gyakorlatban sok pénzt és idegeskedést spórol.

Pécsi helyszínek és környék

Pécsen a helyszín még mindig számít, akkor is, ha sok egyeztetés online is megoldható. Van, akinek a belváros kényelmes, mert munka után könnyen odaér. Másnak Kertváros vagy Uránváros közelebb esik. És vannak olyan megbízók is, akik inkább a város széléről vagy a közeli településekről érkeznek, például Kozármisleny, Pellérd vagy Komló felől. Egy IT business analyst munkája részben távolról is jól végezhető, de az első alkalom sokszor személyesen jobb. Ilyenkor könnyebb megmutatni a jelenlegi folyamatot, a használt fájlokat, a hibás lépéseket és azt, amit a megbízó valójában szeretne.

De nem ragaszkodnék mereven a személyes jelenléthez. Az én tapasztalatom az, hogy ha a feladat már tisztább, utána az online munka kényelmesebb és olcsóbb lehet. Sok informatikai üzleti elemző hibrid módon dolgozik. Egy induló beszélgetés személyesen, utána dokumentálás és egyeztetés távolról. Ez a forma különösen akkor praktikus, ha több döntéshozó van, vagy ha a fejlesztő nem helyben dolgozik. És Pécs esetében ez gyakran előfordul.

Feladatok és felelősség

Az IT business analyst feladata nem merül ki abban, hogy jegyzetel a megbeszélésen. Összegyűjti az üzleti igényeket, feltérképezi a jelenlegi folyamatot, tisztázza a célokat, priorizálja a funkciókat és segít eldönteni, mi fér bele az első körbe. Sokszor ő az, aki kimondja, hogy egy kívánság nem valódi igény, csak pillanatnyi ötlet. És ez fontos. A fejlesztések sokszor nem azért csúsznak el, mert nehéz a technika, hanem mert senki nem húzta meg időben a határokat.

Volt egy eset, amikor egy ügyfél egy új ügyfélkezelő felületet szeretett volna. A beszélgetés elején még úgy tűnt, hogy legalább húsz külön funkció kell neki. Később kiderült, hogy ebből valóban öt számít napi szinten, a többi csak ritka külön kérés lenne. A specialista végül úgy rakta össze a logikát, hogy előbb a valódi alapfunkciók készüljenek el. A projekt így nem csak olcsóbb lett, hanem használhatóbb is. Szerintem ez jó példa arra, miért nem szabad rögtön mindent egyszerre kérni.

Sokan hibáznak, amikor azt hiszik, a rendszerelemző majd helyettük kitalálja a teljes üzleti modellt. Nem ez a dolga. Ő abban segít, hogy a meglevő célból egyértelmű, fejleszthető feladat legyen. A jó szakember kérdez, visszajelez, egyszerűsít és tisztáz. De a döntéseket a megbízónak is vállalnia kell. Ha ez nincs meg, akkor a legjobb dokumentációból is bizonytalan fejlesztés lesz.

Árak és díjszabás

Az árak erősen függnek attól, hogy valaki egy rövid konzultációt kér, követelményfeltárást szeretne, vagy több héten át tartó támogatást a fejlesztés mellett. Az is számít, hogy egy meglévő rendszer javításáról van szó, vagy teljesen új megoldás előkészítéséről. Én úgy látom, hogy a túl olcsó ajánlat itt különösen veszélyes. Olcsóbban persze lehet találni embert, de ha nincs mögötte valódi elemzés, akkor a spórolás később sokkal többe kerül. Olcsóbb 15.000 alatt ritkán lesz igazán alapos munka. Ezt nem szabályként mondom, inkább tapasztalatból.

A közepes ársáv szerintem sokszor jobb döntés, mint a legolcsóbb ajánlat. A nagyon magas díj sem jelent automatikusan jobb minőséget, de az gyanús, ha valaki komoly munkát egy rövid beszélgetés áráért ígér. Itt nem csak időt fizetsz, hanem azt is, hogy valaki észreveszi a rejtett ellentmondásokat. És ez az a rész, amit laikusként nehéz előre felmérni.

Közös munka menete

A folyamat általában egy tisztázó beszélgetéssel indul. Nem az a lényeg, hogy legyen rögtön kész megoldás, hanem hogy világos legyen, mire kell választ adni. Mi a cél. Kik használják majd a rendszert. Mi fáj most a legjobban. Mi az, ami nélkül nem indulhat el a fejlesztés. Ha ezek a kérdések nincsenek rendben, minden további lépés csak találgatás lesz. Én mindig ezt a részt tartom a legfontosabbnak, még ha kívülről kevésbé látványos is.

Ezután jön a jelenlegi helyzet felmérése és a kívánt működés leírása. A jó üzleti elemző itt nem csak azt írja le, amit hall, hanem vissza is ellenőrzi, hogy ugyanarra gondolnak e a szereplők. Sok vita innen ered. A megbízó egyszerűbb kezelést szeretne, a fejlesztő kevesebb kivételt, a felhasználó pedig gyorsabb munkát. Ezek nem mindig ugyanabba az irányba mutatnak. Egy informatikai üzleti elemző dolga éppen az, hogy ebből kezelhető sorrend legyen.

És utána még nincs vége. A dokumentum önmagában kevés, ha senki nem nézi át rendesen. A jobb szakemberek vállalnak egyeztetést a fejlesztővel, pontosítást a menet közben felmerülő kérdéseknél és rövid utánkövetést is. Szerintem ez különösen fontos, mert a legtöbb félreértés nem a legelején, hanem a megvalósítás közben bukik ki.

Gyakori hibák

Az egyik legnagyobb hiba, amikor a megbízó mindent egyszerre akar. Új felületet, automatizmust, jelentéseket, értesítéseket, mobilos kezelést és még további külön logikát is. Ez érthető vágy, de ritkán jó indulás. A túl nagy első kör általában csúszást és feszültséget hoz. Én a fokozatos építést tartom életszerűnek. Előbb működjön az alap. Utána jöhetnek a kényelmi részek.

Másik tipikus gond, hogy valaki a fejlesztőtől várja az üzleti döntést. Ez nem fair és nem is hatékony. Volt már olyan helyzet, amikor egy ügyfél három külön embernek háromféleképp mondta el ugyanazt a feladatot, majd csodálkozott, hogy három eltérő javaslatot kapott. Sok ilyen konfliktus megelőzhető lett volna, ha előbb egy rendszerelemző rendbe teszi az igényeket. Nekem ez az egyik leggyakoribb minta, amit látok. Nem rosszindulatból történik, csak azért, mert mindenki a saját nézőpontjából beszél.

És gyakori az is, hogy valaki túl sokáig halogatja a segítségkérést. Addig toldozza a meglévő folyamatot, amíg már senki nem tudja, melyik lépés miért van benne. Ilyenkor a javítás már nehezebb, mint egy tiszta újratervezés. De még ekkor sem késő. Ha a probléma kimondható, akkor már el lehet indulni egy egyszerűbb, nyugodtabb megoldás felé.