Egy workshopon könnyű azt érezni, hogy “minden a helyén van”: ott ül minden stakeholder, készülnek a post-itek, mindenki hozzáteszi a saját igazságát. Aztán pár héttel később mégis előjönnek a klasszikus tünetek, amikor nő a scope, csúszik a megvalósítás, a support már előre fáradt, és a végén kiderül, hogy ugyanarról beszéltünk – csak nem ugyanazt értettük alatta.

Ezek a félreértések ritkán szakmai hiányosságból jönnek; inkább abból, hogy egy komplex szolgáltatásban mindenki a saját szeletét látja, és nincs közös kép arról, mitől fog tényleg működni. A felület elkészül, a szolgáltatás meg működni fog… de csak akkor, ha megtervezzük a valóságot is hozzá.

Először az új megközelítésben az volt a kihívás, hogy korábbi gyakorlatomban a gyors problémafelvetéshez gyors megoldás kellett. Sokszor pont az vitt előre, hogy a tapasztalatból gyorsan összeállt egy jó irány, és már lehetett is építeni. Szolgáltatásoknál viszont ez a reflex néha túl hamar akart végső választ adni, miközben a rendszer tele van kivételekkel, függőségekkel és láthatatlan háttérfolyamatokkal. Fontos ugyanakkor, hogy ilyenkor a tapasztalat nem tűnik el, csak szerepet vált, azaz a kész terv helyett hipotézis lesz, amit még alaposan meg kell kutatni és validáltatni.

Ebben lett a service design nekem egy rugalmas, mindennapi eszköztár. Nem csak akkor használom, amikor “klasszikus” service design kutatás és tervezés zajlik, hanem akkor is, amikor terméket, folyamatot, ügyfél journeyt vagy belső működést kell tisztázni. Bele tudom szőni bármelyik munkafolyamatba, ami lehet egy backlog-rendezése, egy scope-egyeztetése, egy fejlesztési kick-off vagy egy incidens utóelemzése. A journey, a blueprint, a touchpointok és a backstage lépések nálam olyan közös hivatkozási pontok, amik segítenek ugyanazt érteni ugyanazon – és időben kiszúrni, hol épülne be a “költséges vakvágány”.

A mindset-váltásból nekem ezek a gyakorlati kapaszkodók maradtak (és azóta nem engedem el őket):

1. Ne hagyatkozz az eddigi tapasztalataidra – ha már az elején biztosra tudod a megoldást, akkor beleesel abba a csapdába, amibe én is – nem az a lényeg, hogy én mit tartok hatékonynak, hanem hogy mi a (kutatással alátámasztott) valódi szükséglet.
2. „Definition of Done” szolgáltatás-szinten – nincs kész, amíg nincs folyamat, felelős, mérés és kommunikáció.
3. Pilot és prototípus, mint tanulási ciklus – kisebb körben, mérhetően, gyors visszacsatolással és minél alaposabb validációs pontokkal – leginkább a végfelhasználókkal.
4. Ne funkciót priorizálj, hanem fájdalompontot – átfutási idő, hibaarány, ügyfélszolgálati terhelés – ezek PM-nyelven is erős érvek.
5. A stakeholder-menedzsment legyen „design-olt” – workshop helyett közös termékek (journey, blueprint), amikhez vissza lehet térni.
6. És ami a legfontosabb: beszélj a felhasználóval – ugyanis ők ismerik a valódi problémát, ők tudják validálni a hipotéziseket és végső soron az ő igényeik határozzák meg, hogy mi a jól működő szolgáltatás.

Előfordulhat, hogy PM szemmel a service design túl soknak tűnik akkor, ha a sok kutatás és workshop lelassítja a döntést és a szállítást. Ha viszont megvan a jó egyensúly, illetve célzottan használjuk, az csodákat tesz a megoldás minőségével. Nekem viszont inkább szakmai biztosíték, mint feleslegesnek tűnő, trendi és sokadik módszertan. Hiszen lehet gyorsan haladni, csak úgy kellene, hogy közben csökken a költséges vakvágány esélye, és a végén nem csak egy felület lesz kész, hanem maga a működő szolgáltatás is. Mert lássuk be: a rossz tervezés a legköltségesebb fejlesztési módszertan.

Sánta Márk
Product Owner