HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • sagabona: szia... elég régen született ez a bejegyzés, én csak most akadtam rá véletlenül. Érdekes dolgokat írsz, részben egyetértek az általad gondoltakkal, azonban pár dologban messze más a véleményem - ez ... (2018.10.19. 11:14) Gondolatfoszlányok a pályaválasztásról
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

… tette fel a kérdést Sipos Tamás az AgileHungary rendezvényén. Tényleg, hova tűnt?

… tette fel a kérdést Sipos Tamás az AgileHungary rendezvényén. Tényleg, hova tűnt?

Az eredeti kérdést a következő linken lehet megtekinteni: http://www.meetup.com/AgileHungary/ideas/493046/

Mint látható, eredetileg a SCRUM-hoz és az agilis módszertanokhoz kapcsolódik a felvetés, hiszen ott ilyen szerepkör nincsen, illetve a programozók/egyéb szereplők veszik át.

Hosszan lehetne arról vitatkozni, hogy szükség van-e BA-ra, illetve a programozók, vezető fejlesztők képesek-e átvenni a feladatait. Nem szeretnék ezen vitázni, inkább egy egészen más megvilágításba helyezném a kérdést.

Szerintem a BA szerepének megértéséhez nem a tipikus fejlesztési projektet kell tekinteni (5-8 fejlesztő, 4-8 hónap munka) hanem a nagy projekteket és a projektek utóéletét.

Nagy projektek és a BA

Ugyebár eltérő a „nagy projekt” definíciója – ami az egyiknek nagy, az a másiknak még kicsi. Igazából úgy definiálnám a nagy projektet, ahol már elég sok csapat és fejlesztő dolgozik ahhoz, hogy senki emberfia nem látja át a munkát. Mondjuk úgy 40 fejlesztőnél már ez a helyzet.

Egy ilyen méretű csapatnál pedig már a kommunikáció lesz a legfőbb kihívás: hogyan lehet a felhasználói igényeket (amik esetleg egy több százas méretű felhasználói bázisból lesz összegyűjtve) világosan elmagyarázni a fejlesztőknek?

Ami konkrétan a közös terminológia kialakítását, a fogalmi rendszer felállítását, illetve a fogalmi rendszer segítségével a leendő szoftver meta-szintű definiálását jelenti.
Feltehetőleg ennek a meta-szintű definíciónak az összeállítása tovább tart és több vitát övez, mint a leprogramozása.

Minél nagyobb a méret, az egyes fejlesztők és vezető fejlesztők annál kevésbé látják az egészet, annál nagyobb lesz a vakvezető kutyaként funkcionáló BA-k felelőssége.

Mi történik a szoftver átadása után?

A legtöbb szoftverfejlesztő abban a tévhitben él, hogy a kész szoftver átadása és elindítása után a munka véget ért. Az igaz, hogy a kész szoftver átadása után jön a számlázás, a pénz átutalása, a projekt záró buli, és a jól megérdemelt 2 hét Hawaii nyaralás.

Pedig a munka nem áll meg, sőt folytatódik!

Az élet változik, az üzlet változik, tehát a kész szoftver is folyamatosan változtatni kell. A szoftver üzemeltetés velejárója a változáskérelmek (CR) áradata, amiket valakinek valahol el kell készítenie. A kész szoftver átadása nemcsak a vége valaminek, hanem a folyamatos változtatások kezdete.

A változtatások esetén a legnagyobb kérdést azt jelenti, hogy
a) Hogyan lehet a legegyszerűbben a kért változtatást megtenni
b) Milyen hatást okoz ez a szoftver többi részére

Ezekre a kérdésekre olyan ember tud választ adni, aki metaszinten átlátja a szoftver működését, a szoftver belső folyamatait, az alkalmazott fogalmi rendszert. Sőt nem csak átlátja, de úgy hozzá tud nyúlni – például új fogalmakat létrehozni – hogy attól a szoftver kerek egész maradjon, annak integritása ne sérüljön.

Miért ne tudná ezt megcsinálni egy fejlesztő? Mert a fejlesztő csak az adott változtatást látja. Ugye tipikusan itt olyan szoftverről beszélünk, ami mondjuk 50 mérnökév munkával állt elő. A fejlesztő a szoftver akármelyik moduljába, részletébe bele tud nézni, meg tudja mondani hogy adott ponton mit csinál a kód, és adott ponton bele is tud javítani – de nem látja a teljes képet. Ha pedig kód alapján követi vissza a folyamatot akkor az sok munka is lesz, és nem is biztos hogy sikerült minden részletet feltérképeznie.

Ezzel szemben a Business Analyst csuklóból megmondja, mi hogy van és mit hogy kell csinálni.

Igazából az ilyen emberre van egy másik kifejezés: Subject Matter Expert (SME). Aki ismeri a szoftvert, a fogalmi rendszert, a fogalmi rendszer szintjén tud becsléseket adni a változtatásokra, és a változtatásokat a fogalmi rendszeren végrehajtva instrukciókat (specifikáció) tud adni a fejlesztőknek a változtatás tényleges megvalósítására.

És most eljutottunk egy fontos kérdéshez: ki fontosabb a szoftverfejlesztés szempontjából, az SME/BA vagy a fejlesztő?
Bizony hogy az SME/BA!

Fejlesztők jöhetnek-mehetnek, nem gond. Ha új fejlesztő jön, akkor majd beletanul a szoftverbe, a szoftver fogalmi rendszerébe, és máris tud dolgozni. De ha egy SME-t elveszítünk, akkor a tudást veszítettük el. Amikor arról beszélünk, hogy a „szoftverfejlesztő csapat kemény magja”, akkor én ezalatt az analyst-ot értem.

Talán meglepő lehet, de nálunk majdnem annyi analyst dolgozik, mint fejlesztő. Pontosan azért, mert a változtatások előkészítése, a fogalmi rendszer kezelése legalább akkora munka, mint maga a fejlesztés, és ráadásul sokkal fontosabb is.

Átveheti-e, elláthatja-e a programozó az analyst feladatait?

Igen, sőt az a jó, ha az analyst már látott kódot közelről. Az lesz a jó analyst, akinek van affinitása az informatikához, plusz még ért a rendszerszervezéshez (és az ahhoz szükséges képességekhez).

Mindazonáltal a programozó nem rendszerszervező – a két tevékenység egész mást jelent, és egész más készségek kellenek hozzá. A tipikus programozó nem rendszerszervező. A váltást tudatosan kell megtenni.

Az átlépés legnagyobb gátja az, hogy a rendszerszervező a technológián felülemelkedve absztrakt fogalmi szinttel és folyamatokkal foglalkozik, beszélnie kell a felhasználók nyelvét, ja és jól kell tudnia dokumentumot készíteni (sokkal nehezebb, mint Móricka gondolja).

A programozó tipikusan kézzel fogható dolgokkal dolgozik (kód), távol tartja magát üzleti folyamatoktól és felhasználóktól, ezen felül utál dokumentumot írni.

Igazából én úgy látom, hogy a BA nem tűnt el sehova, továbbra is ott van. Annyi történt, hogy a programozók jelentősége csökkent (pont úgy ahogy megírtam az IT jövője című cikkben), ezért megpróbálják átvenni egyéb szerepkörök feladatait. Ilyen a BA, de megpróbálják elvenni a tesztelők kenyerét (lásd automatizált teszt) illetve a projektvezetőét (lásd SCRUM master). A helyes kérdés nem az, hogy hova tűnt a BA, hanem hogy a programmer/analyst-ok eléggé felkészültek-e az analyst feladatok ellátására?

Címkék: hova tűnt analyst rendszerszervező agilehungary

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr25211439

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Hesz Roland 2010.11.18. 22:27:45

"Hová tűnt a rendszerszervező/Business Analyst a szállító oldalon? … tette fel a kérdést Sipos Tamás az AgileHungary rendezvényén. Tényleg, hova tűnt?" Most pont egy SCRUM-os projekten dolgozom, mint BA. A fejlesztők örülnek, hogy van valaki, aki tud beszélni az üzlettel, össze tudja szedni az igényeket, ráadásul úgy, hogy gondolkodásra készteti a Product Ownert. Viszont a napi munka során azt tapasztalom, hogy az ideális talán az, ha a BA nem a fejlesztői csapat tagja, hanem a megrendelőé, és mintegy mellék product owner működik közre. Egyrészt, mert "elcsúszva" dolgozunk. Két hetes sprint esetén nem fér bele a 2 hétbe az elemzés is. Annak kész kell lennie mire a sprint elkezdődik - értsd: mire a sprint tervező találkozó eljön, addigra az üzletnek viszonylag kiforrott elképzeléssel kell rendelkezni az igényekről amit a sprint végén lefejleszte akar látni. Tehát én mindig a következő sprint anyagán dolgozom. És még csak véletlenül sem írok elő semmit az üzlet által elvárt dolgokon kívül. Aztán hogy azt Oracel-ben, vagy betonkeverővel valósítják meg, kis túlzással talán mindegy is :)

Zsuffa Zsolt · http://itkodex.hu 2010.11.19. 17:10:47

Ebben a témában ajánlom még a tisztelt hölgyek, urak figyelmébe: http://www.linkedin.com/groupItem?view=&gid=37631&type=member&item=25033774&qid=9b70bfad-86e7-4e55-b1dc-3005d035a057&goback=.gmp_37631 A kérdés, nem csak nálunk kérdés :-)