Építs olyan csapatot, amelyben a szükséges kompetenciák rendelkezésre állnak

Bevezetés

Az útmutató bemutatja, hogy hogyan építsünk olyan csapatot, amelyben rendelkezésre állnak a szükséges kompetenciák a magas színvonalú szolgáltatásfejlesztéshez. Ahhoz, hogy kiváló minőségű felhasználói élményt nyújtó szolgáltatásokat hozzunk létre, elengedhetetlen a széles körű kompetenciák bevonása. Az irányelv felhívja a figyelmet a design szemlélet és az ügyfélcentrikus megközelítés fontosságára, valamint hangsúlyozza a felhasználói igények alapos kutatását és az agilis csapatmunkát a fejlesztések folyamán.

A modern fejlesztések során már nem csupán szoftvereket hozunk létre, hanem digitális termékeket és szolgáltatásokat. A digitális termék szemléletben, a létrehozás folyamatában és kezelésében is eltér a régi típusú szoftverfejlesztéstől, ezért is hangsúlyos a folyamatos fejlesztés és fejlődés jelentősége. Ahhoz, hogy ez megvalósulhasson, az agilis megközelítést alkalmazzuk, és rugalmasan reagálunk a felhasználói igények és technológiák változására és kormányzati irányok és célok változásaira. A fejlesztéseket és szolgáltatásokat folyamatosan felülvizsgáljuk annak érdekében, hogy mindezeknek meg tudjunk felelni.

Az irányelv alapvetően arra fókuszál, hogy agilis és felhasználóközpontú módon működjenek a csapatok, aminek az lesz az eredménye, hogy a szolgáltatások és fejlesztések dinamikusan fejlődni tudnak. Mindezek figyelembevételével a folyamatosan változó technológiai környezetben is elérhetjük a legfontosabb célunkat, mégpedig azt, hogy megfeleljünk a felhasználóink igényeinek.

Mit jelent az, hogy minden kompetencia rendelkezésre áll?

Annak érdekében, hogy teljes képet kapjunk a csapatunk sikeres működéséhez szükséges kompetenciákról, érdemes megismerkedni dióhéjban az agilis gondolkodással és a keresztfunkcionális csapatokkal.

Az agilitás egy mindset, egy gondolkodásmód, amely a szervezetek életében több módon is megjelenhet. Az agilis gondolkodásmódnak köszönhetően mára már többféle agilis módszertan is kialakult, ezáltal a szervezeteknek lehetősége van kiválasztani, melyik a legmegfelelőbb számukra.

Az agilis irányzatok tapasztalatok szerint ott a legsikeresebbek, ahol nagy mértékű és gyakori változásra, bizonytalanságra kell számítani és ezt nagyrészt kreativitással és gyakori szállítással, tehát visszajelzésekkel kell kezelni. Az agilis működés ebben a munkakörnyezetben lehet a legideálisabb.

Az agilis megközelítési módok strukturált, szervezett működési kereteket biztosítanak. A leggyakrabban alkalmazott scrum keretrendszer egy a számos agilis lehetőség közül. Ilyenek lehetnek még például a Kanban, a Lean termék/szoftver fejlesztés, az Extreme Programming, de további ezekkel megegyező értékekre épülő hibrid megoldás is agilis megközelítésnek nevezhető. Ezekben eltérhetnek a szerepek, a folyamtok, a ceremóniák, de ami közös bennük az nem más, mint a gondolkodásmód és az értékközpontúság.

Fontos kihangsúlyozni, hogy nem kell és nem célszerű minden projektet agilis megközelítés mentén kezelni, továbbra is van és lesz is létjogosultsága a tradicionális irányzatoknak, amik az agilis értékek mentén testre szabhatóak.

Az agilis gondolkodás lehetővé teszi a projektek rugalmas kezelését, és segíti az innovatív megoldások létrehozását is. Fontos és kiemelendő eltérés a hagyományos projektmenedzsment irányzatokhoz képest, hogy az agilis irányzatoknál a teljes felelősséget nem egy fő viseli, hanem megoszlik több szereplő között. A megvalósításért és a megvalósítás módjának meghatározásáért is a csapat a felelős, tehát az agilis módszertanok önszerveződő, keresztfunkcionális csapatokkal dolgoznak. A csapat határozza meg egy adott prioritás mentén elköteleződve a saját munkamódszerét és a folyamatait, a technikai megvalósítás lépéseit, továbbá ők becsülnek feladat méretet és ők vállalják a felelősséget a szállításért is.

A magas színvonalú szolgáltatásfejlesztések előállításáért felelős csapat pedig akkor a leghatékonyabb, ha keresztfunkcionális. Mégpedig azért, mert ebben az esetben a különböző szakterületeken, különböző tudással és tapasztalatokkal rendelkező emberek összeállnak, hogy közösen egy projekten vagy feladaton dolgozzanak és mindezt anélkül teszik, hogy másoktól függenének, akik nem a csapat tagjai. A keresztfunkcionális csapatok elsődleges célja a hatékony együttműködés és a gyors eredmények elérése, szállítása.

Egy agilisan gondolkozó keresztfunkcionális csapatnak a teljesség igénye nélkül az alábbi fontos kompetenciákkal kell rendelkeznie:

• Rugalmasság és alkalmazkodóképesség: Az agilis környezetben dolgozó csapatoknak gyorsan kell reagálniuk a változó igényekre és kihívásokra. Rugalmasan kell kezelniük a prioritásokat és az új információkat, valamint alkalmazkodniuk kell a változó projektkörnyezethez.
• Kollaboráció és kommunikáció: A csapatokban történő hatékony együttműködés és kommunikáció elengedhetetlen. A csapattagoknak képesnek kell lenniük kommunikálni egymással, megosztani az információkat és az ötleteket, valamint együttműködni a feladatok végrehajtásában. Ez magában foglalhatja a közös munkaterületek használatát, a rendszeres megbeszéléseket és az állandó visszajelzést.
• Rugalmas gondolkodás és problémamegoldás: A fejlesztőknek és csapatvezetőknek képesnek kell lenniük gyorsan és hatékonyan megoldani a problémákat. Rugalmasan kell gondolkodniuk, kreatív megoldásokat kell találniuk és képesnek kell lenniük a hibák gyors javítására.
• Terméktudatosság: A csapatoknak jól kell ismernie a fejlesztett terméket és annak céljait. Értékelniük kell a felhasználói perspektívát, és olyan funkciókat kell kifejleszteniük, amelyek valóban hasznosak és értékesek a felhasználók számára.
• Iteratív fejlesztés és folyamatos javítás: A csapatok folyamatosan fejlesztik a terméket iteratív módon. Ez magában foglalja a rendszeres retrospektívák és visszajelzések alkalmazását, hogy javítsák a folyamatot és a termék minőségét.
• Technikai készségek: Az agilis szoftverfejlesztésben résztvevő csapatoknak rendelkezniük kell a megfelelő technikai készségekkel a termékfejlesztéshez. Ez magában foglalja a programozási nyelvek, keretrendszerek és eszközök ismeretét, valamint a tesztelési és automatizálási módszerek alkalmazását.

A csapatot a szolgáltatások fejlesztési folyamatai közben több, különböző szerepkörben dolgozó ember alkotja. Ezek a szerepkörök a teljesség igénye nélkül a következők lehetnek:

• Terméktulajdonos (Product Owner): A terméktulajdonos felelős a termék stratégiájának és irányának meghatározásáért. Ő kommunikál a stakeholderekkel, priorizálja a feladatokat, és meghatározza a fejlesztés következő lépéseit.
• Scrum Master: A Scrum Master a Scrum bevezetéséért és fenntartásáért felelős. Ő segíti a csapatot a folyamatos fejlődésben, a folyamatok betartásában és a hatékony munkavégzésben.
• Fejlesztők: A fejlesztők a szoftverfejlesztés központi részét képezik. Ők felelősek a kódolásért, a funkciók implementálásáért és az iteratív fejlesztési ciklusban való részvételért. Gyakran több programozási nyelv és keretrendszer ismeretével rendelkeznek.
• Tesztelők (QA szakemberek): A tesztelők felelősek a szoftver teszteléséért és minőségének biztosításáért. Ők teszteseteket készítenek, végrehajtják a manuális vagy automatizált teszteket, és jelentik a hibákat vagy hibaelhárítási javaslatokat a fejlesztőknek.
• Service designer: Ők végzik azt a tevékenységet a fejlesztések során, ami összehangolja az embereket, az infrastruktúrákat, a kommunikációt és az anyagi összetevőit egy szolgáltatásnak, hogy értéket teremtsenek minden érintett számára, jól megkülönböztethető márkaélményt építsenek (brand experience) és maximalizálják az üzleti potenciált.
• UX/UI tervezők: Az UX/UI tervezők felelősek a felhasználói élmény és a felhasználói felület tervezéséért. Ők olyan tervezési elveket alkalmaznak, amelyek javítják a termék felhasználhatóságát és vonzerejét.
• DevOps szakemberek: A DevOps szakemberek az infrastruktúra és az alkalmazások üzemeltetéséért felelősek. Ők segítenek az automatizált tesztek, a konfigurációkezelés és a folyamatos integráció/folyamatos szállítás (CI/CD) folyamatok bevezetésében.

Amennyiben mindezek a kompetenciák és szerepkörök rendelkezésre állnak a csapat számára, akkor hatékonyan és gyorsan tud dolgozni, szem előtt tartva a felhasználói igényeket és a munkafolyamatok közben nem lesz kiszolgáltatva másoknak, nem kell más emberekre, más tudásra, tapasztalatra várni és a csapat ezzel is értékes időt és erőforrást takarít meg.

A keresztfunkcionális csapat

A keresztfunkcionális csapat különböző szakértelemmel rendelkező emberek csoportja, akik egy közös cél elérése érdekében szerveződnek egy csapattá, így többféle szaktudás képviselteti magát a csapatokban, akikre a cél elérése érdekében szükség van, vagy lehet.

Mindez a Scrum útmutató szerint egyszerűen megfogalmazva a következőt jelenti:

"A keresztfunkcionális csapatok rendelkeznek minden olyan kompetenciával, amely a munka elvégzéséhez szükséges, anélkül, hogy másoktól függenének, akik nem részei a csapatnak”

A keresztfunkcionális csapatok manapság nagy népszerűségnek örvendenek, de nem újak. Sikeresen alkalmazták őket más iparágakban az autógyártástól a technológiáig. A keresztfunkcionális csapatok a modern üzleti környezetünk kihívásaival foglalkoznak. A világ nagyon gyorsan változik, ezért folyamatos innovációra van szükség a fennmaradáshoz. Az innováció pedig valójában a különböző kompetenciákkal, tudással és tapasztalattal rendelkező emberek találkozásából és együttműködéséből alakul ki. A keresztfunkcionális csapatok főbb jellemzői a következők:

• Különböző szakértelem: A csapat tagjai különböző szakterületeken szakértők. Ez lehet fejlesztés, tervezés, tesztelés, projektmenedzsment, üzleti elemzés stb. A különböző szakértelmek kombinációja segít a csapatnak a teljes probléma megértésében és a sokoldalú megoldások kidolgozásában.
• Célorientáltság: A keresztfunkcionális csapatok egy közös célt követnek. Ez lehet egy termék vagy projekt létrehozása, egy üzleti cél elérése vagy egy adott feladat teljesítése. A csapat tagjai összpontosítanak a cél elérésére és összehangolják tevékenységeiket ennek érdekében. A keresztfunkcionális csapatok nem az egyéni célokra és hozzájárulásokra összpontosítanak, hanem a csapat kollektív céljaira és elkötelezettségére. Optimalizálják a munka áramlását az egész csapatban.
• Autonómia: A keresztfunkcionális csapatok általában maguk döntenek a munkamódszerekről, a prioritásokról és a feladatok végrehajtásáról. Autonómiájuk lehetővé teszi számukra, hogy gyorsan reagáljanak a változásokra, rugalmasan alkalmazkodjanak és hatékonyan dolgozzanak.
• Kommunikáció és együttműködés: A csapat tagjai között folyamatos kommunikáció és együttműködés van. Ez segít az információáramlásban, a tudásmegosztásban és a problémamegoldásban. Az erős kommunikáció és az együttműködés lehetővé teszi a csapatnak, hogy közösen dolgozzon a feladatokon és felgyorsítsa a folyamatokat.
• Teljesítménymérték és felelősség: A keresztfunkcionális csapatok gyakran mérhető teljesítményekre és felelősségre összpontosítanak. A csapat közösen vállalja a felelősséget a célkitűzések eléréséért, és rendszeresen felülvizsgálják az elért eredményeket.
• A cél eléréséhez szükséges készségek rendelkezésre állnak: A keresztfunkcionális csapatok együtt dolgoznak: rendelkeznek azokkal a készségekkel, amelyekre szükségük van a csapaton belül a feladatok elvégzéséhez a csapatok közötti koordináció és ellenőrzés nélkül.
• Kiküszöbölik a jelentős csúszásokat: A keresztfunkcionális csapatok nem késleltetik az előrehaladást a készségek specializációja vagy a csapaton belüli vagy kívüli bizonyos emberekre való támaszkodás miatt.
• Hibák feltárása a fejlesztések során: A keresztfunkcionális csapattagok közösen járulnak hozzá a tesztelési erőfeszítésekhez, valamint együttműködnek a sprintciklus teljes életútja során.

• Az előkészítési (discovery) szakasz szükséges kompetenciái és szereplői

A modern fejlesztések során már nem csupán szoftvereket hozunk létre, hanem digitális termékeket. A digitális termék szemléletben, létrehozás folyamatában és kezelésében is eltér a régi típusú szoftverfejelsztéstől.

Szemléletében kiemelt figyelmet fordít a felhasználókra, azok igényeire, és az általuk használt kezelőfelület minőségére is. A megrendelő üzleti (politikai) célok képviseletéért felelős, nem pedig a funkciók kitalálásáért, abban az esetben, ha a kutatást és a megvalósítást nem maga végzi. A technológiai, infrastrukturális kérdések pedig a megvalósíthatóság kérdéskörében merülnek fel.

Az új fejlesztés létrehozásának a folyamatában is különbség van. Mivel a megrendelő nem funkcionális igényeket (megoldásokat) definiál, hanem célokat, és a célok eléréséhez a felhasználói igények megvalósításán keresztül jutunk el, így másfajta munkafolyamat is szükségeltetik. Több hasonló keretrendszer is van (dual track, design thinking, double diamond stb.) de lényegében az összesről elmondható, hogy discoveryvel (előkészítéssel) indul aztán koncepció alkotási szakasz következik, végezetül pedig a szállítás.

Az előkészítési (discovery) szakasz gyakorlatilag abban segíti a döntéshozókat, hogy egyértelműen eldönthető legyen számukra, hogy egy adott fejlesztést érdemes-e megvalósítani, vagy sem. A döntés meghozatalához elengedhetetlen a következők megismerése:

• A leendő szolgáltatás felhasználóinak megismerése közvetlen interjúkkal, megfigyelésekkel és tesztesetek, tesztelések elvégzésével. Továbbá a felhasználók viselkedési szokásainak, felmerülő problémáinak és szükségleteinek feltérképezése is kiemelt jelentőségű.
• Fontos megismerni az aktuális politikai döntés hátterét a szolgáltatás létrehozásról, a felhasználható technológiák repertoárját és az üzleti folyamatokat, továbbá a jogszabályi környezetet is.

A fejlesztés megvalósítására kijelölt csapatnak rugalmasnak kell lennie a szolgáltatástervezési folyamat során. Mindezt amiatt, mert nem lesz szükség az összes szerepkörre a szolgáltatástervezés minden szakaszában, így a csapatnak alkalmazkodnia kell a szolgáltatás által támasztott igényekhez és a munkafolyamat különböző fázisaihoz.

Az egyes szereplőknek tisztában kell lenniük az előkészítési (discovery) szakasz sikeres lebonyolításában betöltött szerepükkel és felelősségükkel. Mindenki hozzáteszi a munkához a saját szakértelmét és mindenki részt vesz a kutatási folyamatban is. A felhasználók kutatása csapatmunka, az összes szakértelemre szükség van a teljes körű feltérképezéshez.

Az előkészítési (discovery) szakasznak nincs meghatározott időtartama, de nagy általánosságban elmondható, hogy négy - nyolc hét alatt befejezhető. A meghatározott cél dönti el azt, hogy mennyi időt szükséges fordítani rá.

Ha a létrehozni kívánt szolgáltatás kutatási területe teljesen új és még senki nem kutatott a témában, akkor lehet, hogy egy kicsit hosszabb időre van szükség a tökéletes feltérképezéshez. Ha már ismert a kutatási terület, akkor valószínűsíthető, hogy egy kicsit rövidebb kutatási szakasz is elegendő lehet.

Miután meghatározásra került a kutatás célja és mindenki megértette a csapatban a felmerült problémákat amire válaszokat keresünk, akkor készen állunk a kutatás megkezdésére. A fókusz az előzőekben leírtak szerint a felhasználók és a felhasználók környezetének megismerésére kerül, valamint a felmerülő problémákra és azok megoldási javaslatainak megtalálására. Az előkészítési szakasz sikerességéhez nagyon fontos, hogy kapcsolatot tartsunk a lehető legtöbb szereplővel szervezeten belül és kívül is a széles spektrumú inputok begyűjtése érdekében.

Az előkészítési (discovery) szakasz akkor fejeződik be, amikor egyértelmű döntést lehet arról hozni, hogy a szolgáltatásfejlesztés megvalósul-e, tovább lép-e a koncepcióalkotási szakaszba, vagy sem. Amennyiben a döntés pozitív, tehát tovább lép a fejlesztés a megvalósítási szakaszba, akkor a következőkkel már tisztában vagyunk, illetve rendelkezünk velük:

• Életképes szolgáltatást fejleszthetünk, amely megkönnyíti a felhasználók életét és a szükséges feladataik elvégzését.
• A fejlesztés költséghatékony, előzetesen mérlegelésre került a döntéshozók részéről a fejlesztés költségvonzata és az általa elérhető eredmény hatása.
• Rendelkezésünkre állnak dokumentálva a felhasználói igények és a kutatási eredmények.
• Tisztában vagyunk azzal, hogy a megvalósítási szakaszban milyen ötleteket, prototípusokat akarunk létrehozni.
• Rendelkezésünkre áll azon erőforrások összessége, vagy tudjuk azt, hogy milyen erőforrások szükségesek számunkra, amelyek a fejlesztés következő szakaszában szükségeltetnek.

Az előkészítési (discovery) szakaszhoz szükséges kompetenciák és szereplők a teljesség igénye nélkül következők lehetnek:

• Különféle Workshopok lebonyolítása (például: KPI) a projekt sikerességi szempontjának, szempontjainak meghatározására

  1. Facilitátor

  2. Érintett Stakeholderek.

• Generatív Design kutatás elvégzése állampolgári kompetencia és viselkedés fókusszal, melynek eredménye a kutatási insight

  1. Design kutató

  2. Service designer

  3. Product designer

  4. Design menedzser

  5. Product owner

  6. GOV kapcsolatokkal rendelkező szakember.

• Technológiai feltételek megteremtése, melynek eredménye a fejlesztési környezet és az adatkapcsolatok megtervezése architektúra javaslattal

  1. Vezető fejlesztő (fullstack)

  2. Fejlesztési vezető

  3. Architect szakértő

  4. Domain expert.

• Jogi és dokumentációs háttér megteremtése, melynek eredménye a jogszabályi környezet és korlátok ismerete, valamint a fejlesztéshez szükséges dokumentáció elkészítése

  1. Projekt menedzser

  2. Igazgatásszervező

  3. Jogi szakértő.

Az előkészítési (discovery) szakaszt követő esetleges projekt leállítás nem tekinthető hibának. A cél ezesetben a felhasználók megértése és annak meghatározása, hogy mire van szükségük. Előfordulhat, hogy olyan eredményre jut a kutatásunk, ami miatt meg kell változtatni a terveket, vagy új irányt kell venni, és ez teljes mértékben helytálló. A tervezési folyamat iteratív, nem lineáris. Néha a felfedezés eredménye további kutatást igényel. A cél a jobb eredmények elérése, nem pedig egy új szolgáltatás mindenáron történő bevezetése.

• Koncepcióalkotási szakasz szükséges kompetenciái és szereplői

Amíg az előkészítési (discovery) szakasz a kutatásról szól, a koncepcióalkotási szakasz a hipotézisek teszteléséről és a kísérletezésről. A koncepcióalkotási szakasz célja tehát annak meghatározása, hogy miként lehet kielégíteni az előkészítési (discovery) szakasz során azonosított felhasználói igényeket. Ez lehetőséget teremt arra, hogy viszonylag rövid idő alatt gyorsan legyen lehetőség tesztelni számos különböző megközelítést a felhasználókkal a szolgáltatás létrehozása előtt.

A koncepcióalkotási szakasz gyors tempójú, és sok esetben váratlan irányba is mehet, mielőtt véglegesen meghatározná, hogyan nézhet ki a végső megoldási javaslat a szolgáltatás kialakításához. Többféle megközelítést is lehetőség nyílik kipróbálni és leteszteli ugyanazon problémára rövid határidővel annak érdekében, hogy az ezáltal felmerülő akadályokat megtalálhassuk és kijavíthassuk, mielőtt túl sok erőforrást és tőkét fektetünk egy felmerült szolgáltatásfejlesztési lehetőségbe.

A jól megtervezett szolgáltatások messze túlmutatnak azon, amit a felhasználó lát. A mögöttes folyamatok, az ügyfélszolgálat és a technológia hatással van a szolgáltatás teljesítményére. A koncepcióalkotási szakasz a teljes körű szolgáltatás megtervezéséről szól. Ebben a szakaszban az ötleteket prototípusokká alakíthatjuk, ezt követően pedig a felhasználókkal tesztelhetjük. Azáltal, hogy interaktív prototípusokat készítünk a felhasználók számára, az ötletek valósággá válnak, és kialakul a szolgáltatás közös megértése. Az elkészített prototípusoknak elég reálisnak kell lenniük ahhoz, hogy érdemi visszajelzéseket tudjanak nekünk adni a felhasználók. A jó prototípus konstruktív visszajelzéshez és további betekintéshez vezet, nem egyetértéshez.

Rendkívül fontos, hogy a csapat minden tagja szorosan részt vegyen a prototípusok elkészítésében a koncepcióalkotási szakasz során. Ez nemcsak jobb tervezési eredményhez vezet, hanem segíti azt is, hogy a csapatnak közös megértése legyen a termékről és a csapat által meghozott tervezési döntésekről.

A koncepcióalkotási szakasz akkor tekinthető lezártnak, ha:

• Megfelelően letesztelt prototípussal vagy prototípusokkal rendelkezünk a folyamat végére.
• A fejlesztés szállítási szakaszába tovább lépve világos elképzelésünk van a leendő szolgáltatásról.
• A szolgáltatás támogatására használt technológiák mindenki számára érthetőek.
• A szállítási szakaszban a létrehozandó funkció(k) terve és elkészítési rangsora, fontosságuk szerint rendelkezésre áll és mindenki számára elfogadott.
• A létrehozandó szolgáltatás fejlesztés következő szakaszának finanszírozása és erőforrás szükséglete biztosított.

A cél az, hogy meghatározzunk egy minimálisan életképes terméket, amelyet a fejlesztés szállítási szakaszában lehet felépíteni és szélesebb körben tesztelni. A minimálisan életképes termék a szolgáltatás első működő megvalósítása. A minimálisan életképes termék egy olyan termék verzió, ami a lehető legkevesebb erőforrás ráfordítással a lehető legnagyobb tanulási potenciált nyújtja, vagy másképpen fogalmazva, ez a szolgáltatás leggyorsabb és legegyszerűbb verziója, amely éppen elegendő funkcióval rendelkezik az alapvető felhasználói igények kielégítésére és az érték biztosítására.

Amennyiben a koncepcióalkotási szakasz eredménye az, hogy:

• nincs szükség a fejlesztendő szolgáltatásra,
• a szabályzat, a technológia, a pénzügyi vagy egyéb korlátok akadályozzák azt, hogy a szolgáltatás teljes mértékben megfeleljen a felhasználói igényeknek,
• a szolgáltatás fejlesztése nem költséghatékony,
• egy másik szolgáltatás adaptálása vagy fejlesztése jobb megoldás,

abban az esetben érdemes lehet visszatérni az előkészítési (discovery) szakaszhoz, vagy újrakezdeni a koncepcióalkotási szakaszt. Természetesen felesleges munkának érezhetünk ekkor minden eddig elvégzett feladatot, viszont a már levont tanulságok javítják a végső szolgáltatás minőségét.

A koncepcióalkotási szakasz befejezését követően lehet a legjobb döntés befejezni egy adott szolgáltatás megvalósítását és nem továbblépni a fejlesztés szállítási szakaszába. Ez teljes mértékben elfogadott, hiszen nem minden projektnek kell eljutnia a fejlesztés szállítási szakaszába. Ésszerű és megfontolt döntés egy olyan szolgáltatás fejlesztését leállítani ebben a szakaszban, amely nem fog működni, ezáltal is erőforrást megtakarítva a szervezet számára.

Koncepcióalkotási szakasz szükséges kompetenciái és szereplői a teljesség igénye nélkül a következők lehetnek:

• Koncepció készítés és validálás keretében közös vizuális megoldási javaslat (prototípus) készítése

1. Product designer (UX /UI)

2. Vezető fejlesztő

3. Fejlesztési vezető

4. Projekt menedzser

5. Igazgatás szervező

6. Design kutató (koncepció validálás)

7. Fejlesztő

8. Scrum Master

9. Tartalom író

• Szállítási szakasz szükséges kompetenciái és szereplői

A szállítási szakasz az, amikor a szolgáltatás végre életre kel. Az elérendő cél egy valódi szolgáltatás létrehozása, amely jól működik egy nagyobb felhasználói közösség számára. Az koncepcióalkotási szakasz során kifejlesztett és tesztelt prototípusokat arra használhatjuk fel, hogy egy minimálisan életképes terméket állítsunk élő, mindezt pedig felhasználói környezetben.

Gyorsan és kis lépésekben fejleszthetünk ebben a szakaszban, időt szánva annak megerősítésére, hogy a szolgáltatás fejlesztésének minden szegmense megfelelő irányban halad. A közszolgáltatás elindítása a végső használhatósági teszt, mivel valós adatokat és felhasználói visszajelzéseket gyűjthetünk. A visszajelzés a szolgáltatás finomítására, funkciók hozzáadására és módosítására szolgál, amíg a szolgáltatást ki nem vezetik. A szállítási szakasz várható időtartamáról is elmondható, hogy a fejlesztés volumenétől függően változó. Általánosságban elmondható, hogy három – négy hónap szükségeltetik a befejezéshez.

Igyekezzünk elkerülni a perfekcionizmust és nem késleltetni egy szolgáltatás elindítását, amíg minden egyes problémát ki nem dolgoztunk, és tökéletesen nem működik minden. Egyetlen szolgáltatás sem lesz tökéletes. A szolgáltatásokat az éles üzembe állítást követően lehet és kell is módosítani, ezért kritikus fontosságú a folyamatos tesztelés és fejlesztés. Abban a pillanatban, amikor a szolgáltatással értéket tudunk nyújtani a felhasználóknak, vagy több értéket nyújtunk nekik, mint a jelenleg meglévő szolgáltatás, akkor készen áll a szolgáltatás az indításra.

Az előkészítési (discovery) és koncepcióalkotási szakaszokból származó kutatás és prototípus-készítés segít a felhasználói visszajelzések alapján rangsorolt ütemterv kialakításában. Ez a feladatlista (backlog, hátraléklista) a szolgáltatásba beépítendő funkciók és fejlesztések listájaként működik.

A feladatlista soha nem teljes még ilyenkor. A szállítási szakasz során új visszajelzések érkeznek és ezek alapján az elkészítendő feladatok listája további funkciókkal és fejlesztésekkel frissül.

A szállítási szakasz célja, hogy ezeket a követelményeket kis feladatokra bontsa, és elkezdjen egy működő szolgáltatást építeni. Miután elegendő alapvető funkciót fejlesztettünk ki egy minimálisan életképes termékhez, a szolgáltatás bétaként indul az élő teszteléshez. Míg a visszajelzéseket és elemzéseket összegyűjtjük a feladatlista frissítéséhez, a sprintek folytatódnak, és minden sprint után új funkciókkal és fejlesztésekkel bővül a szolgáltatás.

Fontos nyomon követni és dokumentálni a fő teljesítménymutatókat, még a béta időszakban is. Az analitika elengedhetetlen a szolgáltatás teljesítményének méréséhez és a további figyelmet igénylő gyenge pontok azonosításához.

A szállítási szakasz abban az esetben tekinthető lezártnak, ha:

• Elkészül a szolgáltatás teljesen működőképes verziója, amely megfelel a felhasználói igényeknek.
• A fejlesztés során azonosított és kijavításra került hibák listája, valamint a használhatósági problémák listája dokumentálásra kerül.
• A szolgáltatás javítása, fejlesztése érdekében teljesítendő további feladatok listájának dokumentálása elkészült.

A szolgáltatás éles üzembe állítása akkor kezdődik, amikor a szolgáltatás elérte a kifejlett szintet, és az ütemtervben szereplő összes fő funkció fejlesztése befejeződött. Az éles üzembe állított szolgáltatások további erőforrások nélkül gyorsan elavulnak, és nem felelnek meg sem a digitális szolgáltatási szabványnak, sem pedig a felhasználói igényeknek.

A cél a folyamatos figyelés, kutatás, tesztelés és iterálás mindaddig, amíg a lefejlesztett szolgáltatás aktív marad. A szolgáltatás elindítása után fontos, hogy folyamatosan kísérjük figyelemmel annak állapotát, és gondoskodjunk a karbantartásáról. Az aktív szolgáltatásokon végzett munkát soha nem szabad befejezettnek tekinteni. A felhasználók igényei és viselkedésük is idővel változik, ezért a szolgáltatásoknak alkalmazkodniuk kell, hogy lépést tartsanak mindezekkel.

A szállítási szakasz szükséges kompetenciái és szereplői a teljesség igénye nélkül a következők lehetnek:

• Design tervek kidolgozása, aminek eredményeképpen vizuálisan kidolgozott (pixel pontos) interface tervek, szöveges és nem szöveges tartalmak, valamint a design system kialakításra kerül.

  1. Product designerek (UX, UI)

  2. UI designer (design system építés)

  3. UX designer (szövetgíró jogi / közérthetőségi szempontok)

  4. Desing menedzser

  5. Illusztrátor

• Agilis fejlesztés, melynek eredményeképpen életre kel, lefejlesztésre kerül a digitális termék.

  1. Frontend fejlesztő

  2. Backend fejlesztő

  3. Platform specialista (mobil, web, hibrid)

  4. Vezető fejlesztő

  5. Scrum Master

  6. Product owner

  7. Tesztelő (automata)

• Jogorvoslás biztosítása, melynek eredményeképpen a szolgáltatással kapcsolatos felhasználói utak és jogszabályok összehangolásra kerülnek.

  1. Jogi szakértő

  2. Igazgatás szervező

• Mérés, melynek eredményeképpen az éles releas-re vonatkozó kimutatások, javítási feladatlisták elkészülnek.

  1. Churn rate

  2. Data analyst

• Dokumentáció készítés, melynek eredményeképpen a szolgáltatáshoz kapcsolódó és szükséges dokumentáció elkészül.

  1. Product owner

  2. Jogi szakértő

  3. Vezető fejlesztő

  4. Service designer

• A fejlesztési folyamat szereplői

A modern szolgáltatásfejlesztési folyamat szereplőit az alábbi megközelítés szerint is csoportosíthatjuk:

Vágyottság: Felhasználói igények

Üzleti szempontok: Megrendelői igények

Megvalósíthatóság: Technológiai szempontok

Felhasználói igények képviselői

1. Design kutató

2. Product designer

3. UX designer

4. UI designer

Megrendelői igények képviselői

1. Megrendelők

2. Business analyst

3. Politikai döntéshozó

Megvalósíthatóság képviselői

1. Frontend fejlesztő

2. Backend fejlesztő

2. Backend fejlesztő

4. Domain expert

Összegzés