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

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • 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

Egy olyan csapat vezetésével bíztak meg, ami jó szakértőkből állt és sokat dolgoztak, az ügyfél mégis elégedetlen volt, és ez sok konfliktust eredményezett. Utólagos visszatekintés.

Egy olyan csapat vezetésével bíztak meg, ami jó szakértőkből állt és sokat dolgoztak, az ügyfél mégis elégedetlen volt, és ez sok konfliktust eredményezett. Utólagos visszatekintés.

Úgy esett, hogy egy IT csapat vezetésével bíztak. A csapat egy multinacionális nagyvállalaton belül végzett szoftverfejlesztési, alkalmazástámogatási és projekt feladatokat a szintén cégen belüli ügyfél részére. A fejlesztő csapat 10 főből állt, fejlesztők, koordinátorok és PM-ek vegyesen, két országban két külön irodában. Az ügyfél valójában ügyfelek hálózatát jelentette szerte Európában, egy központi koordinációs/döntéshozó csapattal. A fejlesztőknek a döntéshozó csapattal kellett együtt dolgozni.

A kiindulási problémát az jelentette, hogy ez a döntéshozó csapat, a menedzserek – vagyis az ügyfél - elégedetlenek voltak a fejlesztőkkel. Amikor valamilyen változtatásra volt szükség, a fejlesztés rendszerint késett – az IT volt mindenben a „kerékkötő”. A késések miatt sok volt az eszkaláció, és ebből adódóan sok volt a konfliktus. Az általános benyomás az volt, hogy „az IT nem csinál semmit”. Az ügyfelek egy „agilis” IT-t szerettek volna, ami nem megkerülendő akadály hanem partner az üzletmenet fejlesztésében.

 

Az IT csapatot jobban megismerve a következőkre derült fény: Elkötelezett, hozzáértő emberekből állt, akik régóta végezték munkájukat, nagyon értettek a technológiához, sokat dolgoztak, és igyekeztek a minőségi elvárásoknak megfelelni. A szoftver jól működött, évek óta nem volt adatvesztés vagy kritikus leállás.

Ugyanakkor a rendszertelenül beérkező fejlesztési igények, a sok eszkaláció, a prioritások változása, a direkt felhasználó-fejlesztő kommunikáció sok fennakadást okozott. A csapat alapvetően jól működött, nem volt szükség radikális változtatásokra. Ugyanakkor világossá vált, hogy bizonyos dolgokat lehet – és kell – javítani.

 

Az első változtatás arra irányult, hogy az IT csapat munkáját transzparenssé tegyem az üzleti vezetők felé. Őket mindig csak az aktuális fejlesztések érdekelték, miközben az IT csapat nagyon sok máson is dolgozott: hibákat javított, karbantartott, projekteket vezetett, projekteket készített elő. Ezek közül az aktuális priós ügyek csak a munka kis részét jelentette – a többit láthatóvá kellett tenni. Ezért bevezetettem egy havonta elkészülő vezetői tájékoztatót, ami a csapat által lefedett terület ÖSSZES informatikai feladatát tartalmazta, eredmények, státusz, projektek, metrikák és előrejelzés témákkal.

Mivel minden adat egy prezentációban jelent meg, közérthető módon, ezért mindenki megértette, mit csinál a csapat, és mit ért el. Korábban nem látott összefüggések jelentek meg, például hogy ha egy adott hónapban sok komoly hiba esett be, akkor a projektek nem haladtak annyira.

 

A következő dolog az IT és az üzleti terület közötti kommunikáció javítása volt. Korábban a fejlesztési igények kontrollálatlan, teljesen véletlenszerűen estek be. Tipikus eset: az egyik felhasználó az ebédlőben „csípi el” a fejlesztőt, kér tőle valamit, aztán amikor az nem lesz kész másnapra, akkor eszkalál.

Alapszabályként azt fogalmaztuk meg, hogy új igényekkel ne a fejlesztőket keressék meg közvetlenül, hanem engem. Amiről nem tudok és amiről nem tud az üzleti vezető, az nincs, azért nem vállalok felelősséget. A fejlesztők pedig elhessegették a kiskaput kereső felhasználókat.

Ugyanakkor létrehoztunk egy „hivatalos csatornát” a fejlesztési igények leadására, ami ellenőrizhető és számonkérhető. Az igényeket 3 részre osztottuk:

1) Programhibák: Ezeket emailben a helpdesk-re kell bejelenteni, és követni kell a cégnél hatályos helpdesk folyamatot. Súlyos programhibákkal azonnal foglalkozunk, tehát garantáljuk üzletmenet folytonosságát.

2) Change Request-ek: Kisebb fejlesztési igények (1 hónap vagy rövidebb) egy CR listára kerülnek fel, amit az üzleti vezető priorizál, és minden héten közösen átnézzük. Az IT csapat garantálja, hogy ezeket a fejlesztéseket a legjobb tudása szerint végrehajtja, a prioritás szerinti sorrendben (vagyis az 1. helyen álló igényt először, utána a 2. helyen állót, stb)

3) Projektek: Nagyobb fejlesztési igények (1 hónapnál nagyobbak) külön erőforrást igényelnek, ezért ott be kell tartani a cégnél hatályos, a projektekre vonatkozó folyamatokat. Például szükség van szponzorra, projekt indító dokumentumra, jóváhagyásokra. A jóváhagyott projektek saját dedikált erőforrással rendelkeztek, ezért azok végrehajtása garantált (határidő, scope, budget).

Ezzel a 3 folyamattal az összes igényt sikerült lefedni, és mind a 3 fajta igényre (hibajavítás, kis fejlesztés, nagy fejlesztés) sikerült egyértelmű és kontrollált utat adni. Mindegyik esetben a végrehajtás mérhető és visszaellenőrizhető, elkerülendő a félreértéseket.

 

Az új folyamatok bevezetésénél a felhasználókat segíteni kell a folyamatok megismerésében és betartásában. Fontos volt, hogy ezt ne felesleges bürokráciának lássák, hanem megértsék azt, miért van erre szükség. Fontos volt, hogy a folyamatok egyszerűek legyenek, tehát például az átlagos felhasználónak csak annyi dolga volt, hogy írja le a kérését emailben X-nek és kérjen rá Y-tól jóváhagyást.

Ugyanakkor azt is világossá kellett tenni, hogy ha valami nem követi a folyamatokat, akkor azzal nem biztos, hogy a csapat tud foglalkozni – hiszen a csapat éppen az üzleti vezető által jóváhagyott feladatokon dolgozik.

 

Az új folyamatok során kulcsfontosságú volt a beérkező igények szűrése. Azzal, hogy a folyamat egységes lett, megelőztük azt, hogy ugyanakkor essen be sok különböző igény különböző emberektől. Az üzleti vezetés látta, hogy mik az aktuális igények, és pontosan meg tudta mondani, ezek közül mi fontos és mi nem. Nem az IT szűrte az igényeket, hanem az üzlet – megszűnt az ellenségeskedés.

 

A beérkező igényeket nem csak szűrni, hanem limitálni is kellett. A csapat ugyanis csak 10 főből állt, és csak adott mennyiségű fejlesztést tud elvégezni egy hónapban. Megegyeztünk, hogy a Change Request-ek listája maximum 10 elemű, ennél több ügyön nem tudunk egyszerre dolgozni. Viszont nem szólunk bele, hogy mi az a 10, és hogy milyen sorrendben van. Akinek pedig nagyobb munka kell határidőre, az indítson projektet.

 

Eddig nagyrészt az ügyfél kommunikációról írtam, de az is világossá vált, hogy az új folyamatok mellé megbízható teljesítést is kell tenni – tehát növelni kell a hatékonyságot. Az eszkalációk és a felesleges ügyfél-kommunikációk elkerülésével a hatékonyság már emelkedett, de ennél többre volt szükség. Meg kellett keresni azt a módot, hogy ha az üzleti vezető kér valamit, akkor az tényleg elkészüljön – mert ha nem készül el, akkor az IT kerékkötő lesz.

Ehhez az első lépés az volt, hogy a csapat belső működését meg kellett változtatni: „mindenki mindent csinál” helyett dedikált emberek végezzenek dedikált feladatot. Amíg mindenki mindent csinált, addig ha beérkezett egy hiba, akkor mindenki eldobta az aktuális munkáját és nekiállt a javításnak. Márpedig hibák mindig érkeztek. Ezért a munkavégzés esetleges volt.

Ez átalakult abban az értelemben, hogy a csapat néhány tagja dedikáltan csak hibajavítással, a beérkező hibajegyekkel foglalkozott, míg másik csakis fejlesztéssel és CR-ekkel foglalkoztak. És természetesen voltak akik mindkettővel, az adott helyzettől függően. Ez az átszervezés azt jelentette, hogy ha beérkezett egy új hiba, akkor senki sem dobta el az aktuális munkáját, hiszen tudták, hogy valaki biztosan foglalkozik a hibával és megjavítja azt. Az új fejlesztéseken fix emberek dolgoztak, ezért garantálható volt, hogy a fejlesztések elkészüljenek.

Amikor pedig nagyobb fejlesztés esett be, akkor arra lett külön ember a projekt költségvetéséből, nem kellett a többi munkavégzést felfüggeszteni.

 

A szoftver jó minőségű volt, de mégis érkeztek be hibák – köztük sok volt az ismétlődő vagy ugyanarra az okra visszavezethető hiba. Bevezettem, hogy a helpdesk hibajegyeket heti rendszerességgel átnézzük, keressük a hasonló okokat és trendeket keresünk. Egy-egy hiba helyett azokra a jelenségekre koncentrálunk, amik sok hibát – ezzel együtt sok munkát – okoznak. Elindultunk egy olyan úton, hogy hónapról hónapra egyre kevesebb hibánk lett – egyre több idő maradt új fejlesztéseket csinálni.

 

A trend analízis során kiderült, hogy sok hiba nem a csapat „bűne”: interfész hibák, kézi adatbevitel, kézi riporting. Ezeket lépésről lépésre automatizáltuk, hogy kiiktassuk az emberi hiba lehetőségét. Az interfész hibák okát megkerestük és korrigáltuk (ami azért volt nehéz, mert sokszor hálózati problémára vezettük vissza, azaz nem alkalmazás hiba). Sok interfész hiba adódott, egy hibás adatküldés kijavítása jelentős mennyiségű emberi beavatkozást igényelt: nem csak az interfészt kellett újraküldeni, de ellenőrizni az adat integritást és a tranzakció sikerességét mindkét oldalon.

A kézi adatbevitel és kézi riporting helyett inkább a szoftver lett megokosítva, hogy ezeket a felhasználók maguktól is megtehessék. Előfordult, hogy valakinek 1 napi munkájába került adatokat kinyerni az adatbázisból kézzel az egyik üzleti szakértő számára, akinek erre a riportra minden hónapban szüksége volt.

 

Végül pedig a fenti lépések eredményeit össze kellett gyűjteni és visszajelezni a csapat, illetve az üzlet felé. Őszintén elmondani: miben volt javulás, mi az amin még dolgozni kell. A visszajelzés fontos, különösen ha pozitív.

Az első pozitív élmények után ugyanis mindenki megtáltosodott, és futószalagon hozta az ötleteket, mit hogyan lehetne jobban csinálni.

 

Fél év alatt sikerült eljutni oda, hogy a kezdeti ellenséges légkör megszűnt, egy év múlva pedig már konstruktív együttműködés jellemezte az IT és az üzlet kapcsolatát.

 

Az „agilis IT” vonalról e cikk 2. részében foglalkozok.

Címkék: it üzlet emberek ügyfél csapat vezetés

A bejegyzés trackback címe:

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

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.

ozon 2012.05.22. 15:57:29

a vezetői tájékoztatóban milyen metrikákat lehet definiálni? konkrét példákra lennék kiváncsi. Hány nyitott bug van? ilyenek?

Ismeretlen_102125 2012.05.22. 19:25:09

Főbb problémák az adott hónapban Change Request-ek számának alakulása (nyitott, lezárt, érkezett) Hibajegyek számának alakulása időben (nyitott, lezárt, érkezett) Ticket-ek státusz szerinti megoszlása - ez rávilágít arra, hogy hol kinél milyen stádiumban akad el a munka Benchmarking - vállalaton belül más csapatokkal összehasonlítva hány ticket-et kapott és zárt le az adott csapat Időbeli terhelés - az adott hónapban az összes csapatra vonatkozóan hány ticket érkezett a helpdesk-re Projektek státusza Roadmap: az előttünk álló hónapok és a főbb feladatok Előrejelzés, mi várható Éves stratégia és annak teljesülése És még beletenném a mission statement-et az elejére

Zoli 2012.05.25. 15:45:35

Már másik postodban is olvastam, hogy említed a specializált feladatvégzést. Pl. hogy valaki csak hibákat javít a teamben. Ez szembe megy azért az agilis (team központú) elvekkel. Ha a helyzet megengedi, megoldásként azt szokták alkamazni, hogy a teamen belüli fejlesztői supporton mondjuk kéthetente rotálódnak a csapat tagjai.

Ismeretlen_102125 2012.05.28. 09:56:18

@Zoli: lehet hogy szembe megy az agilis elvekkel. Viszont itt konkrétan jó volt ettől eltérni: a "mindenki mindent csinál" és a rotáció helyett hatékonyabbnak bizonyolt a specializálódás. És tervezhetőbb lett a szállítás.

Kutya23 2012.05.31. 09:34:47

Zolinak abban igaza van, h nehéz fenntartani a motivációt a csak bugfixszel foglalkozó fejlesztőknél. De gondolom hosszabb távú rotációval (mondjuk félévente) ez a gond megoldható
süti beállítások módosítása