PO-ból DPO (3. rész) - Webshop teendői a GDPR szerint

Olvasva a Facebook csoportokat és különböző blogokat, nagyon sok helyen találkozok pánikkal, haraggal a GDPR-ral kapcsolatban, így szeretnék pár fontos, webshopokat (online felületeket) érintő kérdést és teendőt tisztázni. Azt gondolom, hogy user oldalról sem fog mindenki ezzel foglalkozni, hiszen eddig is tojtak rá, hogy mi van az adataikkal és ezután is az lesz a célja, hogy mielőbb megvásárolhassa a terméket vagy használhassa a szolgáltatást, lásd jelenlegi cookie tájékoztató elfogadás.

Pár fontos alapelv

A GDPR egyik betartandó alapelve az adattakarékosság, aminek célja, hogy valóban csak annyi adatot kérjünk be és annyi ideig tároljuk, amíg az valóban szükséges.

Az adatkezelésben nincs akkor változás és továbbra is használhatjuk a felhasználok adatait, de pontosan meg kell határozni a célt és a jogalapot, valamint ezekhez egyértelműbb tájékoztatás kell a user felé és/vagy hozzájárulás a felhasználótól. 

Ehhez kapcsolódik, hogy a user számára átláthatóbbá kell tenni az adatkezelést és adattovábbítást, és a jogait könnyebben kell tudnia gyakorolni (hozzáférés, helyesbítés, törlés, korlátozás, hordozhatóság).

Ezek mellett az adatok biztonságos kezelése is előtérbe helyeződött, mivel eddig ez nem volt annyira biztosított, tisztelet a kivételnek.

És mégegy: GDPR is not optional.

Hogyan tud egy webshop első körben megfelelni az új GDPR-nak

Összeszedtem, hogy mik azok a legfontosabb pontok, amik egy ellenőrzés során elsőként kerülnek a figyelembe. Nem nyújt 100%-os védelmet, de nagyban csökkenti a kockázatot. Véleményem szerint, amíg a NAIH se ad minden kérdésre választ és nem jön ki a végleges módosított Info. Törvény, addig nem is lehet teljes megfelelőséget elérni az adatkezelési folyamatokban.

Szóval a teendők:

1. Adatkezelési tájékoztató

Frissítsük az oldalon található adatkezelési tájékoztatót az alábbiak szerint:

- a webshopot üzemeltetőt és elérhetőségeit;

- az adatvédelmi tisztviselő elérhetőségeit, ha van ilyen;

- a személyes adatok tervezett kezelésének célja, az adatkezelés jogalapját, a webshop vagy harmadik fél jogos érdekei;

- a személyes adatok címzettjeit, ha van ilyen;

- adott esetben annak tényét, hogy a webshop harmadik országba vagy nemzetközi szervezet részére kívánja továbbítani a személyes adatokat

A NAIH Adatvédelmi Nyilvántartási Számot 2018. május 25-től nem fog kiadni, így azt már nem is kell feltüntetni a jövőben.

2. Adatkezelési tájékoztató elérhetősége

Nem csak regisztrációs formon és a láblécben kell elhelyezni mostantól az Adatkezelési tájékoztató linkjét, hanem minden olyan oldalon, ahol személyes adatot kérünk be, vagy adható meg.

Itt egy érdekes problémával is találkozhatunk, hiszen több helyen van úgynevezett megjegyzés mező, pl. rendelés leadása során, ahova szintén bármit beírhat a felhasználó, akár személyes adatokat is. Figyeljünk erre is!
Fontos, hogy ha az adott oldalon van form, akkor nem elég, hogy a láblécben ott van az Adatkezelési tájékoztató linkje, hanem az adott formban is fel kell tüntetni.

3. Regsiztráció során jelölő négyzetek bővítése (adatkezelőnként)

Ez még jelenleg egy homályos pont, mert a rendelet szerint adatkezelőnként és adatkezelési célonként kellene hozzájárulást kérni a felhasználótól a regisztráció során. Jó esetben jelenleg az ÁSZF és az Adatkezelési tájékoztatót kell elfogadni egy checkbox keretében.

A jövőben az alábbi checkobox biztosan kelleni fognak:

- Elolvastam és elfogadom az Általános Szerződési Feltétleket

- Elolvastam és elfogadom az Adatkezelési tájékoztatót

- Hozzájárulok hírlevelek fogadásához (itt több opciói is lehet, lásd következő pont)

4. Hirlevél fel- és leiratkozás

Eddigi gyakorlat szerint volt egy mező, ahova beírhatta a user az email címét és egy gomb, hogy feliratkozik a hírlevelekre.

A jövőben ennek úgy kell kinéznie, hogy:

- van egy mező, ahova beírhatja az email címét

- van egy checkbox: Elolvastam és elfogadom az Adatkezelési tájékoztatót (linknek kell lennie és nem lehet bepipálva)

- hozzájárulás mező: szintén egy vagy több checkbox és nem lehet bepipálva (lásd az opcióknál)

- Feliratkozó gomb

Opciók a hozzárjárulás checkbox esetén:

1. saját hírlevél, saját reklámok küldése
2. eDM (külső ajánlatok partnerektől)
3. hozzájárulok email címem átadására 3dik félnek reklám céljából

A leiratkozásnak ugyanolyan könnyűnek kell lennie, mint a feliratkozásnak, így biztosítani kell az oldalon is és a kiküldött levelekben is. A kiküldött hírlevél láblécében szerepelnie kell az Adatkezelési tájékoztató linkjének és egy leiratkozást segítő linknek/gombnak.

Update:
- ha már egy regisztrált usernek szeretnénk küldeni hírlevelet egy új termékünkről, akkor a jogalap lehet hozzájárulás vagy jogos érdek és mindkét esetben tájékoztatni kell. Első esetben a visszavonásig, második esetben tiltakozásig tárolhatjuk az e-mail címet
- ha egy sima hírlevelet küldünk feliratkozott usernek, akkor jogos érdek a jogalap és tájékoztatás után tiltakozásig tárolhatjuk az e-mail címet

5. Adatbázisok életben tartása és a profilozás

2018. május 25. utána csak olyan személyes adatokat tárolhatunk és használhatunk, amik megfelelnek az új rendeletnek. Így szükséges a régi adatbázisok életben tartása. Ezek esetében a következő képpen kell eljárni: tájékoztatni kell a felhasználót az új célokról, és ez ellen tiltakozhat.

Ha van olyan funkcióink (pl. ajánló rendszer), ahol profilozás történik, akkor ott is a legegyszerűbb megoldás, hogy tájékoztatjuk az ügyfelet, aki ez ellen tiltakozhat. Ilyenkor vagy kikapcsolom az adott szolgáltatás működését vagy megtagadom tőle a regisztráció lehetőségét.

6. Automatikus döntéshozatal

Kevés helyen tárgyalt, de annál fontosabb téma. Ha a weboldalamon pl. a szállítási költség a user címe alapján módosulhat, akkor az automatikus döntéshozatalnak számít és erről tájékoztatnom kell a felhasználót az Adatkezelési tájékoztatóban. Vegyük sorra, hol található ilyen jellegű logika és ezeket írjuk bele a tájékoztatóba.

Célok és jogalapok

A bevezetőben említettem, hogy kicsit kavar van a fejekben és túlzottan félünk a GDPR-tól, pedig sok esetben könnyítést ad. Cserébe csak annyit vár el, hogy az adatokat valódi céloknak és megfelelő jogalap mellett kérjük be, tároljuk.

A GDPR 6. cikke foglalkozik azzal, hogy milyen jogon kérhetünk be és tarolhatunk adatokat.

a, a felhasználó hozzájárult az adatkezeléshez, tehát bepipált egy checkboxot, ahol tájékoztattuk, hogy ott miért és mire kell az adat
b, szerződés teljesítéséhez szükséges az adat, pl. vásárláshoz
c, jogi kötelezettség teszi szükségessé az adatkezelést, pl. számla kiállítása
d, az érintett érdekeinek védelmében (pl. baleset)
e, közérdekű feladat végrehajtásához (pl. önkormányzati adatkezelés)
f, jogos érdek (pl. fraud vizsgálat, IT biztonság)

Egy webshop esteében általában az a, b, c és f jogalapok szoktak szükségesek lenni. Az f, pont az egyik olyan kiskapu, amit elég sok mindenre rá lehet húzni. Nekem, mint webshop pl. jogos érdekem, hogy eladjak és mondjuk ezt egy hírlevélben kiküldött konkrét ajánlattal tudom elérni...

Minden adat kezelés esetén szükséges a felhasználó tájékoztatása vagy hozzájárulása. Hozzájárulás esetén is kötelező tájékoztatni a felhasználót:

- az adatkezelő elérhetőségéről

- az adatkezelés céljáról

- az érintettek és a személyes adatok kategóriáról

- címzettek kategóriáról (adatfeldolgozókról)

- az adattárolás időtartamáról

Lényeges különbség, hogy tájékoztatás esetén csak tiltakozhat a user, hozzájárulás esetén pedig visszavonhatja a hozzájárulását. Itt érdemes figyelni arra, hogyha közös hozzájárulást kérünk több adatkezelési célhoz és az egyikhez visszavonja a hozzájárulást, akkor a többi esteében is törölni kell. 

Nagyon fontos és erről is kevés szó hangzik el, hogy IT technikai oldalról ez egy olyan feladatot ró ránk, hogy tudnunk kell az adatbázisban tárolt adatokat cél és jogalap szerint csoportosítani, kezelni, törölni.

Mit is jelent a kifejezett hozzájárulás módja:

- aláírt

- email megerősítés, online form

- lényeg: egy gomb megnyomása mellett van egy második megerősítés

Facebook és Google

Ezt is sokszor félreértelmezik a hirdetések, remarketing esetén. A Facebook az adatkezelő, ha saját adatai alapján targetál

Ha az én adataim alapján, az általam beadott felhasználói adatok alapján targetál, akkor a Facebook az adatfeldolgozó és én vagyok az adatkezelő.

Google dolgozik már rajta, hoyg az Analytics szolgáltatását GDPR kompatibilissé tegye. Új beállítás lesz elérhető oldal property szinten, amivel be lehet állítani, mennyi ideig tárolod 1-1 felhasználó adatait az utolsó aktivitásától számítva (vagy úgy általában).

Szintén hamarosan érkezik a programozott módon elérhető adattörlés, aminél client ID (cookie), user ID (saját weboldalad azonosítója) vagy App ID segítségével lehet törölni 1-1 konkrét felhasználó history-ját Analyticsben.

GDPR szempontból valószínűleg consent nélkül is futtatható lesz az alap GA mérés az ún. Advertising features nélkül, amihez viszont már user consent kell. Ez főleg a demográfiai riportok adatmennyiségére és a remarketing lehetőségekre lesz várhatóan erősen kihatással.

Szállítási cím probléma

A GDPR egyik fontos alapelve az adattakarékosság, tehát csak annyi adatot kérjünk be és tároljunk, amennyi valóban szükséges, és csak addig tárolhatjuk, amíg szükséges. És ez felvet egy olyan problémát, hogy a szállítási címre csak addig van szükségünk, amíg a rendelés kiszállítása megtörtént. Így utána törölni kell ezeket az adatokat. Nem életszerű és mint user roppant bosszantó lenne, ha minden alaklommal újra be kellene írnom a szállítási címemet egy már regisztrált webshopban leadott rendelés esetén.

Remélhetőleg itt még történik egy módosítás, vagy állásfoglalás a NAIH-tól, addig is van rá egy kiskapu... 

Az ugye tiszta, hogy futárszolgálat esetén adatfeldolgozásról van szó, nem pedig adatkezelésről, mert a vásárlás teljesítéséhez igénybe kell vennem a futárt!? Mindaddig, amíg a futár cég nem veszi át és használja saját célra az adatokat!

Webshop motorok

Ha valamilyen webshop motort használsz, akkor gondban lehetsz az ügyben, hogy hol tárolódnak az adatok. Ilyen esteben ugye aláírod a Service agrement-et, és tájékoztat arról, hogy hol és hogyan tárolja, kezeli az adatokat. Ezt meg kell tenned a felhasználóid felé is.

Fontos, hogy pl. a Shopify nem adatkezelő (nem hoz döntést), csak tárolja az adatokat. De ez EU-n kívüli adattovábbításnak minősül és kifejezett hozzájárulás nem kell csak tájékoztatás.

IT biztonság és üzemeltetési problémák

Sajnos üzemeltetési szempontból is akadnak nem életszerű megfelelési kötelezettségek. Ilyen a felejtés joga esetén a biztonsági mentésekből is törölni kellene az adatokat, de ez nem életszerű és nem kivitelezhető ésszerű keretek között. Erre is várunk még állásfoglalást.

Ami itt fontos lehet, hogy egyrészt biztosítani kell a megfelelő biztonsági intézkedéseket, az adatok biztonságát, saját szerver esetén a jogosulatlan hozzáférés megakadályozását. Ha keretrendszerrel dolgozunk és különböző verziók vannak, akkor jelezni kell, hogy nem friss a keretrendszer, ami biztosági kockázat. Ilyenkor az ügyfél (tulajdonos) a felelős, hogy a frissítés költségét kifizeti-e vagy vállalja a régebbi rendszer sebezhetőségéből adódó kockázatot, mivel ő az adatkezelő.

Összefoglalva

A lényeg a megfelelő tájékoztatás, a felhasználói jogok gyakorlásának biztosítása, az adatok kezelésének időtartamára vonatkozó előírások betartása és figyeljünk oda, hogy különleges adatokat csak kifejezett hozzájárulás esetén tárolhatunk (9. cikk)

Igyekszem a profilozásról is írni hamarosan egy újabb bejegyzésebn.

Addig is: úgy kezeld mások adatait, ahogy elvárnád, hogy a tiedet kezeljék!

PO-ból DPO (2. rész) - HR és backoffice teendők

Az előző GDPR-ral kapcsolatos bejegyzésemben említettem, hogy a következő etap a belső folyamataink felmérése volt, hogy pontosan hol és milyen személyes adatokat kezelünk, ezekhez milyen folyamatok útján kik férnek hozzá. Három területre bontottam a működésünk alapján a vizsgálandó területeket:

1. HR/backoffice/sales
2. IT biztonság (üzemeltetés)
3. Ügyfeleink rendszereinek fejlesztése és azok megfelelése

Elsőként a belső folyamatokat vizsgáltuk meg, egy kisebb csapattal, ahol az érintett területek képviselték magukat. Ez fontos, hiszen DPO-ként nem feltétlenül ismerem az adott terület folyamatait és nem is kötelességem ismerni azt.

HR workshop eredménye

Az előzetes vizsgálat és a csapatmunka során az alábbi helyeken történik adatkezelés vagy továbbítás:

- jelentkezési folyamat (reqruitment/CV kezelése)

- felvétel/beléptetés (munkaszerződés, email hozzáférés, céges telefon, laptop)

- bérszámfejtés

- kiléptetés (munkaviszony megszüntetése)

- a saját honlapunkon kapcsolat felvételi form, adatkezelési nyilatkozat

- üzemorvos

- jogosultság kezelés

- iroda ház kamera rendszer

Nézzük pár példát, hogy milyen kérdések merültek fel és milyen érdekes folyamatok vannak, amikkel foglalkoznunk kell:

- ügyfél scoring rendszer

- belső munkatársak DISC elemzése, teljesítmény értékelése

- fotós belső eseményeken

Ezekhez is kell külön hozzájárulás, tájékoztatás, illetve, ha ezeket az értékelési adatokat felhasználjuk a fizetésemelés mértékének megállapításához, akkor profilozásról beszélünk és hatásvizsgálatot kell készíteni.

Mobil és laptop

A mobil és laptop használat esetében is sok csavart tartalmaz a GDPR. Mobiltelefon céges környezetben történő használata esetén az alábbi esetekkel találkozhatunk:

1. saját mobil, céges sim
2. saját mobil, saját sim
3. céges mobil, céges sim
4. saját szám, saját sim, de beviszem a flottába

A GDPR-nak való megfelelés esetén, ha magánszámot tárolok a céges mobilon, akkor írásban engedélyt kell kérnem az adott magánszemélytől, aki ezt később visszavonhatja. De ha magánkézbe lévő készüléket használok, akkor céges adatokat nem tárolhatok rajta. Legjobb a saját mobil céges sim, amikor a céges számokat a céges sim kátyán tárolom.

De ha bevitted a cégbe a saját számod, akkor sajnos bonyolódik a helyzet, mivel a telefonszámod bekerül pl. az emailben az aláírásodba. Ebben az esetben kilépéskor a szerződésekből, emailekből törölni kell(ene). Mi a megoldás?

A legegyszerűbb, hogy a munkavállaló nem hozhatja be vagy nem viheti ki a számát. Második megoldás, hogy belépéskor vagy kilépéskor tájékoztatni, hogy ezeket az adatokat te, mint munkáltató tovább tárolod. Ilyenkor tiltakozhat. Ha kilépéskor hozzájárulást kérsz, akkor azt később visszavonhatja.

Laptopok, PC-k esetében elkerülhetetlen, hogy személyes adatok kerüljenek rá, ami szintén okozhat jogi problémát. Ezt szintén meg tudjuk előzni tájékoztatással, amelyben jelezzük, hogy minden, céges gépen tárolt adat céges adatnak minősül, így a felelősséget áthárítjuk a munkavállalóra.

A laptopok esetén az integritást és bizalmas jelleget is szem előtt kell tartani és mindent megtenni annak érdekében, hogy az adott OS napra kész legyen, az OS által nyújtott biztonsági beállítások be legyenek kapcsolva. A titkosított HDD ésszerű megoldás, így ajánlott.

Hogyan járjunk el az aktuális munkavállalókkal?

Új belépő munkavállaló esetén a szerződés aláíráskor kell vagy a szerződésbe foglalni az adatvédelmi szabályzatnak való megfelelést, vagy külön dokumentumként kezelni. Már meglévő munkavállalók esetében szerződés módosítás vagy tájékoztatás után, de minden esetben a munkavállalónak kell bepipálnia, hogy hozzájárul adott adatok munkáltató általi kezeléséhez és alá kell írnia.

Érdemes kitérni minden adatkezelési esetre:

- email server

- tender

- fotó

- stb.

Az egyik legfontosabb tudnivaló, hogy az esetek többségében törvényi vagy szerződéses jogalap van az adatok kezelésére, tarolására és a munkavállalók tájékoztatás vagy hozzájárulása szükséges hozzá.

Érdemes arra figyelni, hogy hozzájárulás esetén élhet a visszavonás jogával, de tájékoztatás esetén csak tiltakozhat, amit, az adott esetet megvizsgálva, el is utasíthatunk.

Ha a belső szabályzatunk részletesen kitér minden adatkezelési folyamatra, akkor első körben jól jártunk el.

Ha a szerződéseket, aktákat, személyes adatokat tartalmazó dokumentumokat papír alapon tárolunk, akkor azokat mindig elzárva kell tartani és egy úgynevezett kulcsrendet létrehozni, amiben nyilván van tartva, hogy kik férhetnek hozzá az adott szekrény tartalmához. Ezt a kulcsrendet is ebben a zárható részben kell tárolni.

Következő részben a webshopok teendőiről fogok írni.

PO-ból DPO (1. rész) - DPO feladatai a gyakorlatban

Disclaimer: jelen blog nem fog a fogalmak és rövidítések magyarázatával foglalkozni, mivel született erre már ezer oldal és bejegyzés.

A saját webshopom miatt már régóta foglalkoztam az online jogi megfelelőséggel, mindig is fő szempont volt, hogy a vásárlóink tisztában legyenek a jogaikkal és korrekt vásárlási folyamatokkal találkozzanak. Cégünk részt vett és kvalifikált az E-commerce Hungary (akkor még SzEK.org) által szervezett Vedd a neten! kezdeményezésen is.

A Virgo-nál is folytattam ezt a tevékenységemet a PO teendők mellett, hogy ügyfeleinket napra készen tudjuk tartani és tájékoztatni olyan témában, mint pl. az elállási jog.

Az adatok védelmében született GDPR-ral is így kezdtem el foglalkozni, és mivel ezt magamra húztam, így megnyertem a cégcsoporton belüli DPO szerepkört is.

Célom, hogy a gyakorlati oldalról mutassam be a GDPR megfelelés lépéseit, előkészületeit és nehézségeit egy konkrét cég esetében.

Mi is az a DPO és mi a GDPR lényege gyakorlati szempontból?

Sok facebook csoportban és blog bejegyzésben tapasztalom azt a problémát, hogy az emberek nagyon komoly nyűgnek élik meg a GDPR-ra való felkészülést. Az is. De közben teljesen jogos a kezdeményezés, hogy az adatainkat normális keretek között kezeljék, védjék. Ha a saját adatink fontosak, akkor másoké miért nem? Vagy ha mi nem kezeljük mások adatait megfelelően, akkor miért várjuk el, hogy a mienket igen?

Én azt gondolom, hogy ez egy nagyon jó lehetőség, hogy átgondoljuk:

- milyen adatkezelési folyamataink vannak,

- az adott folyamatok során milyen adatokat kezelünk,

- valóban szükséges-e minden adat bekérése, kezelése,

- nyújt-e bármi üzleti hasznot, hogy ezeket az adatokat bekérjük?

Érdemes optimalizálni a folyamatainkat, szükség esetén törölni olyan adatokat, amik nem nyújtanak hasznot. A jelenleg futó projektek esetében is már a fejlesztés folyamán célszerű megvizsgálni, hogy minden log-ra, adatgyűjtésre valóban szükség van-e?

Gondoljuk át a jogalapokat, milyen hozzájárulások kellenek majd, és ezeket hogyan tudjuk bekérni?

Ebben lehet segítség a DPO, aki szaktudásával tudja segíteni a csapatokat.

Fontos tudni, hogy a DPO nem lehet HR vezető, nem lehet IT vezető és nem lehet tulajdonos, olyan független személynek kell lennie, aki nem irányítható és ki tud állni az adatok biztonságért! És éppen ezért nem lehet érintett, nem dönthet a személyes adatok kezelésének céljáról és eszközeiről. 

Kizárt pozíciók:

- vezérigazgató

- ügyvezető

- pénzügyi-,

- egészségügyi-,

- marketing-,

- HR-,

- IT-vezető

- bíróság előtti képviselet

Milyen feladatim vannak a cégben?

A GDPR szerint:

- tájékoztat és szakmai tanácsot ad a társaság és az adatkezelést végző alkalmazottak részére a GDPR és egyéb adatvédelmi jogszabályok szerinti kötelezettségeikkel kapcsolatban;

- ellenőrzi a GDPR-nak, az adatvédelmi jogszabályoknak, és a társaság személyes adatok védelmével kapcsolatos belső szabályainak való megfelelést. Ide tartozik például: feladatkörök kijelölése, az adatkezelési műveletekben vevő személyzet tudatosság-növelése és képzése, valamint a kapcsolódó auditok;

- kérésre szakmai tanácsot ad a GDPR szerinti, nagyobb kockázatú adatkezelések esetén kötelező adatvédelmi hatásvizsgálatra vonatkozóan, valamint nyomon követi a hatásvizsgálat elvégzését;

- együttműködik az adatvédelmi felügyeleti hatósággal, és az adatkezeléssel összefüggő ügyekben kapcsolattartó pontként szolgál az adatvédelmi felügyeleti hatóság felé, valamint adott esetben bármely egyéb kérdésben konzultációt folytat vele.

Emellett a DPO nem bocsátható el és nem vonható felelősségre a munkája miatt, az esetleges bírság is a társaságot terheli. Mondhatni milyen jó dolga van, de vegyük észre, hogy ez felelősség teljes munka, hiszen a bírságok mértéke akár egy cég életében is kerülhet.

És akkor mi a gyakorlat?

Elsőként azonosítottam azokat a területeket, ahol érint minket a GDPR:

- belső folyamatok (HR, backoffice, sales)

- IT biztonság (belső és külső üzemeltetések)

- ügyfél oldali teendők (készülő és supportált projektek)

Ezután belső workshopokat csináltunk, ahol azonosítottuk, hogy milyen adatokat kezelünk az adott területen, milyen folyamataink vannak és kinek milyen adatokat adunk át. Majd a jogalapot is hozzárendeltük ezekhez a folyamatokhoz.

De mit is várunk el egy DPO-tól?

Bár nem vonható felelősségre a DPO, de mindenképpen elvárt tőle, hogy szakmailag rátermett legyen, ismerje az adatvédelmi jogokat, a hatósági iránymutatásokat, adatbiztonsági és IT-folyamatokat. Ezenfelül ismerje a vállalat és ügyfeleinek környezetét, és érdemes megfelelő képzésen is részt venni.

És még egy apróság a DPO-kal kapcsolatban: az adatvédelmi tisztviselő esetén fontos elvárás az adatvédelmi tisztviselő elérhetőségeinek közzététele, illetve a NAIH-hoz való bejelentése.

Következő részben a HR workshop eredményéről írok majd.

Miért jó a tartalom vezérelt fejlesztés?

Amikor a Virgo-nál kezdtem, akkor az első projektem egy viszonylag egyszerű, információs portál elkészítése volt. Kis csapattal, meglévő követelmény elemzéssel időre végeztünk, a termék bemutatása és az adminok oktatása után átadtuk a honlapot.

Elkezdődött a tartalommal való feltöltés és jöttek a problémák. Amikor elkészült a drótváz és a look&feel, ügyfél elfogadta azt, majd az élesítést követően a tartalom feltöltéskor derült ki, hogy a főoldalon a hírek boxok nem jól jelennek meg a tartalom miatt, és funkció szerint sem volt elfogadható.

Az alapfelállás szerint a három leggyakrabban olvasott hír jelenik meg a főoldalon, de a hírek publikálása után vált egyértelművé, hogy így a friss hírek sosem fognak megjelenni. Módosítottuk a főoldalon megjelenő hírek működését a kérésnek megfelelően:

- első helyen jelent meg a legfrissebb hír

- második helyen a legtöbbet olvasott hír van

- harmadik helyen pedig mostantól random jelennek meg a hírek

Bár apróságnak tűnik, de rosszul éreztem magam, csalódott voltam egy picit a termékben.

Egy feature vagy egy projekt átadása után gyakori eset, hogy az ügyfél panaszkodik. Az ügyfél azt mondja, nem erre gondolt, nem ezt beszéltük meg, stb. Egyértelmű, hogy kezelni kell az ilyen szituációkat, a nemeket. Ha már egy átadott fejlesztésen kell változtatni, akkor az kellemetlen beszélgetéseket tud szülni, és költség oldalról is nem várt kiadás az ügyfél számára. Így a cél nem a konfliktus feloldása, hanem annak megelőzése.

De miért is jutunk el ilyen helyzetekhez?

Röviden tekintsük át mi a fejlesztés megszokott menete, mikor történik meg a tartalom feltöltés:

- megtörténik a követelmény elemzés

- a storyk alapján a csapat lefejleszti a feature-t

- belső tesztelés után

- demozzuk az ügyfélnek

- átadjuk a terméket és

- elkezdődik a tartalom feltöltése

Bontsuk két részre a problémát belső és külső folyamatok alapján.

Ha nem áll rendelkezésre megfelelő adat vagy tartalom, akkor lassítja a fejlesztési folyamatot, illetve létrejöhet az úgynevezett fejlesztői software: a specifikáció szerint elkészült a software, de user oldalról használhatatlan.

Az adathiba vagy adat hiánya rossz terméket, felesleges munkát szül és bár költség oldalról ez talán még kezelhető, de egy rossz termékből jót faragni már nagyobb kihívás.

A tesztelés és a demo során is bizonytalan helyzet állhat elő, ha távol áll az éles környezettől, állapottól. Ha demo felületes, ha csak azt írjuk be egy statikus oldalra, hogy pl. ez egy teszt oldal, akkor nem kapunk visszajelzést az ott lefejlesztett funkciókról. Sokkal látványosabb tud lenni, ha valós adatokkal töltünk ki egy oldalt:

Hiányosan kitöltött statikus oldal

Feldíszített statikus oldal

Ha ügyfél oldalról közelítjük meg a problémát, akkor szerintem az egyik fő gond, hogy a demo során egy bizonytalan ügyfelet kaphatunk, aki nem tudja eldönteni, hogy az adott fejlesztés sikeres-e vagy nem, átvehető-e vagy nem. Ha átveszi, de a tartalom feltöltés során kiderül, hogy valami nem az elvárások szerint működik, akkor az plusz költséget jelent számára.

Nagyon fontos még, hogy adott funkcióval kapcsolatban a kivételek feltárása is megtörténjen  segítsük ebben az ügyfelet.

Előfordult olyan is, hogy beégetett adatokkal dolgoztunk egy projekt során, ami elfedte a valós adatokkal járó problémákat. A funkció fejlesztése során nem volt megfelelő termék import és emblémázás import file, még változott közben, így később derült ki az éles adatokkal való feltöltés során, hogy nem jól dolgozzuk fel, nem minden adatot dolgozunk fel a file-ból.

Mit tehetünk ezen problémák elkerülésére?

Célszerű már a story-k írása közben a tartalmakat, teszt adatokat összegyűjteni, a story-ra rárakni, becsatolni, use case-eket írni. Fel kell tárni a kivételeket, adott funkciónál a folyamaton végig menni, modellezni.

Ha a portál, a termék több nyelvű, akkor figyelni kell arra, hogy pl. egy gomb esetén más a hosszúságú a benne megjelenő szöveg magyar nyelven és más hosszúságú német nyelven.

Segítségünkre lehet a priorizálásban is, hogy azt a story-t vesszük előre, amihez van tartalom így az ügyfelet is motiváljuk a tartalom gyártásra. Ezen a ponton nagyon fontos, hogy ki az, aki a tartalmat előállítja, az információk eljussanak hozzá, illetve tőle hozzánk.

Előnyök

A sikeres demo mellett, csökkenteni tudjuk a fejlesztési időt, megkönnyíthetjük a tesztelést és egy jobb végterméket kapunk a fejlesztés folyamán. Ezáltal a CR-ek és a reworkok száma is kevesebb lesz.

Ha rendelkezésre állnak a végleges tartalmak, akkor a rollout idejét is csökkenthetjük, és a csapat mellett az ügyfél elégedettségét is növelhetjük.

Könnyűnek hangzik, igaz? :-)

Hátrányok

Nem mindig életszerű, hogy a fejlesztés előtt legyen meg minden majd egyszer lefejlesztendő funkcióhoz az éles tartalom, amit az ügyfélnek kell biztosítania. Agilis megközelítés szerint, roadmap alapján az adott funkció groomingjára/preplanningjére kell meglennie az adott anyagnak. Ha már a projekt elején bekérünk valamilyen anyagot, akkor előfordulhat, hogy mire a funkció gyártásához érünk az már nagy valószínűséggel nem lesz valid és mi téves magabiztossággal fogunk tervezni, fejleszteni.

Másik probléma, hogyha elvárjuk, hogy a PO/BA a userstoryba már bele írja a teszt eseteket, akkor az rengeteg ráfordítást kíván a részéről. Tapasztalat alapján ez nem mindig kivitelezhető, az egyéb teendők mellett nem biztos, hogy marad rá elég idő, így keressük meg a mi projekt szervezetünkbe illeszthető megoldást.


Üzenet

Egyértelmű, hogy az előkészítés sok időbe telik, ezért edukálni kell az ügyfeleket. A jó termék elkészítéséhez jó adatokat kell előállítani, vagyis az ügyfélnek már előbb el kell kezdenie dolgozni, mint a csapatnak, ideális esetben már a követelmény elemzés során megkapnánk ezeket az információkat. Ez nem minden esetben kivitelezhető, főleg egy új termék fejlesztésekor, vagy a folyamatok optimalizálásakor, módosításakor, de törekednünk kell rá.

Az én miértem újragondolva

Hiszek abban, hogy folyamatos tanulással, önfejlesztéssel segíteni tudom a munkájában és a céljai elérésében a csapatomat, a szervezetemet és ezen keresztül az ügyfeleimet.

Hiszek abban, hogy értéket teremtünk, értékes tagja vagyok a szervezetnek és fordulhatnak hozzám az emberek, ha tanács, segítség kell.

Célom, hogy hosszú távon jó követelmény elemző, tanácsadó váljon belőlem, vezetői képességeim folyamatosan javuljanak és bízzanak bennem az emberek. Magabiztos tudásommal irányt mutassak a folyamatosan fejlődő és változó online világban az üygfeleinknek.

Ahogy egy szoftver sincs kész soha, úgy egy szervezet és a szervezet tagjai is mindig tudnak fejlődni, és célom ebben részt venni, munkámon kívül plusz ismeretek megszerzésével és átadásával segíteni munkatársaimat.

Hiszem, hogy egyensúlyt tudok teremteni a munkám és a családom között, hogy a körülöttem lévők jól érezzék magukat.

“Karnyújtásnyi körben felelős vagy a világért, önmagadért és önvalódért.” - kortárs költő

Félmaraton, avagy 9 probléma, amivel találkozhatsz, ha nem figyelsz a scrum csapatodra

Tavaly szeptemberben, a nyár elmúltával kellemes, hűvös reggelre ébredtünk egyik szombaton. Összepakoltuk a szükséges felszerelést, az energiát adó ételt, italt, megfelelő öltözetet és elindultunk életem első félmaratonjára. Half.

Izgalom, egészséges félelem fogott el, ha őszinte akarok lenni magammal, nem edzettem rá megfelelő módon, de nem is lehet mindig mindenre felkészülni, testileg. Ezért fontos volt, hogy szellemileg ott legyen az ember.

Maga a pálya nagyon szép részen futott, a hőmérséklet ideális volt, a szint emelkedés 277 méter. Veszprémiként hozzá vagyok szokva a futás során az emelkedőkhöz és a lejtőkhöz, de ez durvábbnak ígérkezett. Szerencsére a pálya egy részét ismertem már az Ultrabalatonról, akkor is itt futottam.

A hétköznapi futások során 4:40-es, 5:00-ás pace-eket szoktam futni, és ezt 13 km-ig tudom is tartani.

A rajt előtt megfogalmaztam egy célt, hogy 2 órán belül szeretném lefutni a félmaratont. Ehhez kb 5:30-as átlagot kell futnom kilométerenként. De a végén is, az utolsó kanyarban is. Nem tűnik nehéznek, hiszen te magad döntöd el, hogyan futsz. Ha egyedül vagy. De külső hatások miatt sokszor lankad a figyelem, ezért kell ésszel futni és nem erővel. Fontos, hogy a rajtnál a tömeg lendülete ne ragadjon magával, vagy ha valamelyik szakaszon a hátad mögött, szinte a nyakadban érzed a másik versenyzőt, akkor ne kezdj el versenyezni, mert belemehetsz egy olyan hajszába, ahol idő előtt elfáradsz és a saját célkitűzésedet nem fogod elérni.

Ugyanez a nyomás érezhető egy projekt során is, ahol az ügyfél által meghatározott határidőre és budget-re is folyamatosan figyelned kell. Folyamatosan szállítanod kell, jó minőségű funkciókat, kevés bug-gal.

Könnyű beleesni abba a hibába, hogy ezt a nyomást átterheled a csapatra és termelési stressz alatt tarod őket, nem is feltétlenül szándékosan. Egy rövidebb projekt (4-5 sprint) alatt is tud káros lenni ez a munkamenet, de egy nagyobb lélegzetvételű (1 éves) projekt során nagyon nagy károkat tud okozni a csapatnak, a cégnek és az ügyfélnek is.

Ha ilyen nyomás alatt tartod a csapatot (és magadat), akkor az alábbi problémákkal, hibákkal találkozhatsz:

• planning, grooming elhagyása, elnagyolása
• tervezési feladatok kihagyása
• ezek következtében rossz minőségű funkciók lefejlesztése
• ennek következtében bug hegyek
• demotivált csapat
• nem jön létre a csapat hangulat
• funkciók, igények nem megfelelő felmérése
• refaktorálás hegyek (amire persze nem lesz idő)
• felmondások

Ilyen hibákkal és egy ilyen csapattal nehéz fenntartani az ügyfél elégedettséget, így mindenképpen azt javaslom, hogyha még ez több konfliktust is szül az ügyféllel, hogy a csapatot hagyd nyugodtan dolgozni, adj időt tervezésre, amíg nincs egy funkció rendesen követelmény elemezve, addig ne add oda a csapatnak (a csapat pedig ne fogadja be azt!).

Ahogy a félmaratonra, úgy egy projektnél sem tudsz mindig mindenre felkészülni, mindig lesznek váratlanul felmerülő problémák, de ilyenkor nagyon fontos, hogy azt tudd mondani, “Jó, most álljunk meg, gondoljuk át a problémát, állítsunk fel megoldási utakat.” Ésszel, racionálisan gondolkodva kell a helyzetet kezelni és nem elrohanni az elején a tömeggel.

A félmaraton alatt sokszor kellett észnél lennem és szándékosan visszafognom magam, mondani, hogy "Állj!", "Lassan!", hogy legyen erőm a teljes szakaszon. Tudatosan kell lépésről lépésre haladni, a külső tényezőket amennyire lehet kizárni, és akkor elérhető a cél. Akár még előbb is, nehézségek nélkül.

Növekedéssel járó ügyfél kezelési problémák online és offline

Mikor valaki sokat jár a piacra, a pékségbe, és mindig ugyanarra a helyre, akkor egy idő után szinte ismerősként kezeli az eladó a vevőt. Az ismerősöknek pedig több vagy jobb jár. Először csak kedves köszönés, aztán már szól az eladó, hogy ne abból a tojásból vegyél, hanem a pult alól kapsz frisset vagy szól, hogy ebből a paradicsomból ma inkább ne vigyél. Kialakul egy bizalmi kapcsolat és biztos, hogy továbbra is ott fogsz vásárolni, nem fogod a piacot körbe járni, hogy hol olcsóbb a paradicsom 10 Ft-tal.

Második fiamnak közeledik a születésnapja és megérett a nagyobb biciklire, így neki is elkezdtem keresgélni a neten ugyanazt a típust, amit a nagyobbik fiamnak vettünk, de más színben. Találtam is, jó áron. Megrendeltem. Két nap után kaptam az emailt, hogy az még sincs raktáron és már nem is forgalmazzák. Sebaj, megyünk a következő "boltba". Hasonlóan jártam. Már morogtam, de még időben elkezdtük a beszerzési projektet, így nem volt aggódni való, mentem a következő webshop-ba. Itt is kosárba tudtam tenni a terméket, azt írta ki, hogy raktáron van, de végül itt sem került kiszállításra a kerékpár.

Közel jártam ahhoz, hogy vevő megtévesztése miatt hatóságoknak kezdjek el írogatni. Megrendült a bizalom. Átváltottam troll üzemmódba. Ahol lehetett adtam le rendelést az adott kerékpárra, makacsságom nem hagyta veszni a dolgot, kell az a bicikli. AZ a bicikli kell! Az egyik helyről szintén visszajelzést kaptam, hogy jelenleg nem elérhető az áhított tárgy, de 2-3 hét alatt be tudják szerezni. Mondom nosza, az még belefér. A héten járt le a határidő és jelentkezett is a vállalkozó, hogy sajnos a szállítmány nem volt teljes (nem is fogadtam volna rá, hogy lesz), így a kért árú nem érkezett meg. BUT! Ugyanaz a márka, típus más színben van, amiben az első villa teleszkópos és a kellemetlenségért cserébe ezt a másik rendelés árában, vagyis kedvezményesen oda tudja adni, ha megfelel. Fiam a színt jóváhagyta, műszakilag nyerünk, és végre találkoztam egy Kereskedővel.

Jól esett, hogy törődtek az igényünkkel, foglalkoznak velünk (ego), és vannak olyanok, akik ennyire odafigyelnek a vásárlóikra. Anno a saját webáruházamban is az egyik legjobb rész volt, amikor személyesen ismertem a vásárlókat, tudtunk segíteni nekik, megoldást találni az esetleges problémáikra.

Egy darabig. A példaként említett offline piacon van egy korlátozott számú felhasználó, akik napi szinten visszatérnek, és mivel egy város nem szokott éves szinten 20-30%-kal növekedni lakosságilag, így a visszatérők száma sem fog ugrásszerűen, kezelhetetlenül növekedni. Az online minőségi kerékpárt vásárlók száma is korlátozott, ahogy a saját esetemben is, így sokkal könnyebb helyzeteben, előnyben vagyunk a nagyobb vagy tömegcikkeket értékesítő webshopokkal szemben.

Viszont a nagyoknak is kezelni kell az ügyfeleket, viszonylag gyorsan és jól. Itt nincs közvetlen viszony, itt egy-egy user csak egy-egysor az adatbázisban, és nem is a felhasználókat nézik, hanem a rendeléseket. Ekkora mennyiséget már nem is lehet máshogy, ezt el kell fogadni. Nem reális elvárás, hogy a tulajdonos, ügyvezető minden ügyfelet ismerjen, dolga a cég építése, fejlődésének, növekedésének biztosítása. Nem vehetünk fel userenként sem ügyfélszolgálatost, így olyan megoldásokhoz folyamodnak, mint például a

- chatbot (itt egy remek leírás róla)

- gyíkdzsungel*

- automatizálások

Azonban egy chatbot, vagy egy kihelyezett ügyfélszolgálatos sosem fog olyan jogokkal és döntési lehetőséggel  rendelkezni, hogy pl. egy kerékpárból jókora kedvezményt biztosítson, csak azért mert a beígért termék nem érkezett meg adott színben. De azt sem fogja megérteni, hogy a karácsonyra megrendelt sál hiánya a karácsony fa alól milyen vitát fog generálni. Elég csak az edigital facebook oldalát megnézni Black Friday akció után.

A személytelen kommunikáció, a korlátozott emberi erőforrás és az automatizált folyamatok a növekedés velejárója.

De mit tehet egy nagyobb webshop a bizalom felépítéséért és annak megtartásáért, a vevői reklamációk csökkentéséért?

Egy normális checkout kialakítása ma már nem atomtudomány, vehetjük alapnak, rengeteg helyen leírták már hány oldal legyen, mi szerepeljen rajta, hogyan, stb.

Hogy mitől lesz egy webshop megjelenésében bizalomgerjesztő szintén külön műfaj, és elég szubjektív.

Miért is jön a vásárló a webshopunkba? Hogy megvegye a kívánt terméket. Gyorsan, probléma mentesen. Tehát ha már becsalogattuk az ár összehasonlító oldalakról vagy a hirdetésekből és kosárba is engedjük tenni a kívánt terméket, akkor legyen az a nyomorult termék valóba raktáron, vagy 2-3 napon belül elérhető.

De mi van akkor ha tényleg reklamációra kerül a sor.

Talán épp a fenti okfejtésnek mond ellen, de itt jönnek képbe az okos megoldások, automatizálások, amelyek már túl mutatnak egy átlagos webshopon, amitől több lesz.

Az első kommunikációs pont a rendelés státuszról kiküldött értesítő levél, amelynek informatívnak kell lennie, a változásokat kövesse nyomon. De ne így!

Ha egyedi reklamációs esettel van dolgunk, akkor azt a rendszerben tudjuk kezelni, jelölni, akár kiemelt ügyfélszolgálatost rá állítani. SEO szempontból elengedhetetlen ma már  termékek alatt megtalálható értékelések, és egy elégedett reklamáló ügyfél szívesebben ad visszajelzést az oldalunkon. A csalódott ügyfél a tékozló homárra fog írni.

Hogy megkönnyítsük az ügyfélszolgálatosok helyzetét, akkor automatizált opciókat is létrehozhatunk, amelyekből válogathatnak a károk enyhítése céljából.

Az már csak plusz pont, ha a vevő jogait kihangsúlyozva, egyértelműen és könnyen elérhető módon közzé tesszük (pl. elállással kapcsolatos jogok), már a rendelés visszaigazoló levélben is.

Attól, hogy online felületre viszük át a termék eladást/szolgáltatást, ez még kereskedelem és az alapvető elvárások megmaradnak az ügyfelek részéről. Talán az ego, talán a nosztalgia, de mégis jól esik az embernek, ha kedvesebben köszönnek neki a pékségben, vagy frissebb árút kap a piacon, így mindig lesz egy olyan szegmens, ami offline maradhat, és ahol mindig első osztályú lesz az ügyfél kezelés.

*gyíkdzsungel: a gyakran ismételt kérdések olyan útvesztője, ahol sosem fogod megtalálni a telefonos elérhetőséget, mert nem az a cél. :-)