Húsz évvel ezelőtt szoftverfejlesztőként kezdtem a karrieremet. Akkoriban a szoftverfejlesztés még nagyon új területnek számított, számos kezdeti nehézséggel, gyermekbetegséggel, ráadásul gyakran hasonlították össze más, fejlettebb területekkel. Sokszor hallottuk: "Az a sok bug, amint a szoftverben hagytok, el tudnátok képzelni hasonlóan alacsony színvonalat a repülőgépiparban?" Egyértelmű volt, hogy a szoftverfejlesztőknek még sokat kellett tanulniuk.

Sok minden változott azóta. A külvilág számára a legfeltűnőbb előrelépés a projektmenedzsmenthez való hozzáállás megváltozása volt. A fejlesztők mielőtt bármilyen kódot írtak volna, hosszú dokumentációt készítettek az adott folyamatról. A fejlesztést követően a tesztelők átnézték a terméket hibákat keresve, majd csak ez után juttatták el azt a megrendelőhöz.

A munkavégzésnek ez a módja viszont nem működött túl jól a legtöbb szoftveres termék esetében. A valóság ugyanis sokkal komplexebb, mint ahogyan azt a dokumentáció írói le tudják jegyezni. A specifikációk meghatározásától a termék szállításáig tartó rugalmatlan folyamat pedig nem biztosítja az ügyfelek elégedettségét. Az agilis módszertan ezzel szemben a végeredményt helyezi fókuszba: egy működő terméket és az elégedett ügyfeleket. Előnyei miatt sok szoftverfejlesztő cég vezette be sikeresen ezt az új munkavégzési módszert.

Agile mindenhol

Érdekes módon a fiatal és éretlen szoftverfejlesztői ipar lett a követendő példa a hagyományosabb szektorok számára. Hirtelen mindenhol elkezdték adaptálni az agilis projektmenedzsmentet. Számos szervezet hozta meg azt a stratégiai döntést, hogy mindent agilis módszerek alapján kell csinálni.

Az a felismerés indokolta ezt a változást, hogy az elégedett ügyfelek és egy működő végtermék fontosabbak, mint a folyamatok vagy szerződések. Értelemszerűen a szolgáltatásmenedzsment területén ez különösen lényeges.

De mit jelent ez valójában?

Az agilitás végső soron a jobb végeredmény eléréséről szól. Agilisnak lenni nem egyenlő a Scrummal vagy más hangzatos folyamatokkal. Természetesen jó ötlet lehet bevezetni egy olyan struktúrát, amelyet tapasztalt szakértők már alaposan átgondoltak, de fontos felismernünk, hogy önmagában egy újabb folyamat bevezetésével nem leszünk előrébb.

Agilisnak lenni azt jelenti, hogy ahelyett, hogy mindenki a főnökön keresztül kommunikál, a kollégák tudják egymásról, hogy ki min dolgozik éppen. Agilisnak lenni azt jelenti, hogy a munkatársak segítenek egymásnak, és nem szigorúan csak a saját feladatlistájukat és munkaköri leírásukat követik. Agilisnak lenni azt jelenti, hogy az ügyfelek is aktívan részt vesznek a folyamatokban, nem csak az azt megelőző tárgyalásokban. Agilisnak lenni azt is jelenti, hogy rugalmasan állunk a feladatokhoz, és nem félünk váltani, amikor szükségesnek érezzük - még akkor sem, ha a projekt elején mások voltak az elvárásaink.

Agile vagy ITIL? Vagy inkább Agile és ITIL?

Ez mind jól hangzik, de észben kell tartani, hogy egy ügyfélszolgálaton a felhasználók a problémáikat jelentik be. Ha egy bejelentő nem tudja elérni a levelezését, akkor nem akar a rugalmas agilis problémamegoldás folyamatában részt venni, hanem csak azt szeretné, ha mihamarabb tudna megint e-maileket küldeni.

Az agilis hozzáállás nem azt jelenti, hogy el kell hagyni olyan bevált és sikeres folyamatokat, mint például az incidenskezelés. Az Agile és az ITIL nem zárják ki kölcsönösen egymást. Az agilis módszerek segítenek a már meglévő folyamatokat továbbfejleszteni, például úgy, hogy egy felhasználói portál bevezetésével jobban bevonjuk az ügyfeleket aktuális projektekbe.

Talán az Agile azokban a folyamatokban jelentheti a legnagyobb segítséget, ahol a működő termék szállítása vagy az ügyfelek elégedettségének biztosítása okoz nehézséget. Az ITIL egyes folyamataiban, például a változáskezelésben, ahol sok embernek kell aránylag hosszú időn át szorosan együttműködni, az agilis hozzáállás nagy valószínűséggel javítja a végeredményt és az ügyfelek elégedettségét is.

Hogyan kezdjünk neki?

Természetesen segít, ha olyan embereket vonunk be az átállás folyamatába, akiknek van tapasztalatuk a témában. Tehát ha lehetséges, beszéljék meg a helyzetet egy olyan emberrel, aki az agilis módszertan trénereként funkcionálhat. Ennek az embernek nem kell folyamatosan ott lennie az adaptáció alatt, de egy szakértővel való konzultáció segít az elindulásban és a kezdeti nehézségek leküzdésében.

Benno Richters

cégvezető, TOPdesk

A TOPdesknél a szoftverfejlesztésben már nagyon régóta az agilis módszertant használjuk, nemrégiben azonban más területekre is kiterjesztettük ezt. Leírnék pár dolgot, amit a folyamatból tanultam, és amiket érdemesnek találok megosztani:

– Mi a Kanban módszert használjuk. Ez egy egyszerű és hatékony módja annak, hogy a projektek folyamatát mindenki számára átláthatóvá tegyük.
– Minden nap tartunk egy úgynevezett standupot. Ez egy 5, maximum 10 perces megbeszélés, amikor mindenki elmondja min dolgozott az előző nap, és milyen feladatai vannak az adott napra. Ez segít abban, hogy mindenki naprakészen be legyen vonva a részleg életébe.
– Ne aggódjon azon, ha elsőre nem minden tökéletes. Vizsgálják meg, hogy hogy haladnak mondjuk minden második héten, és legyenek agilisak magával a folyamattal kapcsolatban is. Változtassanak azokon a dolgokon, amiket ön vagy a csapat jónak lát.

Személy szerint nagyon örülök, hogy a saját szervezetünkben bevezettük az agilis módszertant, és biztos vagyok benne, hogy a váltás az ön ügyfélszolgálatának is kiváló szolgálatot tehet!

Benno Richters
cégvezető, TOPdesk