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ő