A DevOps filozófiája, amely az alkalmazásfejlesztést összekapcsolja a szoftverek karbantartásával, már senkit sem lep meg. Egy új trend kezd teret nyerni — DevOps 2.0 vagy BizDevOps. Ebben a három összetevő: üzlet, fejlesztés és támogatás egy egységes rendszerbe olvad össze. Ahogy a DevOpsnál az mérnöki gyakorlatok képezik a kapcsolat alapját a fejlesztés és a támogatás között, úgy a bizdevopshoz az analitika tölti be a 'ragasztó' szerepét, összekapcsolva a fejlesztést az üzlettel.
Azonnal el kell ismernem: arról, hogy nekünk valódi bizdevopsunk van, csak most értesültünk, miután okos könyveket olvastunk. Valahogy magától alakult ki a munkatársak kezdeményezése és a folyamatos fejlődés iránti szenvedély következtében. Jelenleg az analitika a fejlesztési folyamat részévé vált, jelentősen csökkentve a visszajelzési hurkokat, és rendszeresen ellátva bennünket felismerésekkel. Részletesen elmondom, hogyan működik nálunk minden.
A klasszikus DevOps hátrányai
Amikor új ügyfélt termékeken gondolkodnak, az üzlet egy tökéletes ügyfélviselkedési modellt alkot, és jó átváltással számol, amely alapján meghatározza üzleti céljait és teljesítményeit. A fejlesztőcsapat a maga részéről arra törekszik, hogy nagyon jó, kiváló minőségű kódot készítsen. A támogatás pedig a folyamatok teljes automatizálására, valamint az új termék kísérésének egyszerűségére és kényelmére számít.
A valóság legtöbbször úgy alakul, hogy az ügyfelek meglehetősen bonyolult folyamatokat kapnak, az üzlet alacsony átváltásba ütközik, a fejlesztőcsapatok folyamatosan javítják a hibákat, míg a támogatás elmerül az ügyfelektől érkező megkeresések áradatában. Ismerős?
A probléma gyökere a hosszú és nem megfelelő visszajelzési hurkában rejlik, amely a folyamatba van beépítve. Az üzlet és a fejlesztők a követelmények összegyűjtése és a visszajelzés kapcsán a sprintek során csak korlátozott számú ügyféllel kommunikálnak, akik jelentős hatással vannak a termék sorsára. Gyakran az egyik számára fontos dolog egyáltalán nem jellemzi a teljes céltábort.
A termék fejlődésének helyes irányáról való felismerés a pénzügyi jelentésekkel és a piackutatási eredményekkel együtt érkezik hónapokkal a bevezetés után. Ráadásul ezek is a mintavétel korlátai miatt nem teszik lehetővé a hipotézisek széles körű tesztelését az ügyfelek nagy számán. Röviden: a folyamat hosszú, pontatlan és nem hatékony.
Trófeaszerű eszköz
Megtaláltuk a jó módját, hogy elbújjanak ettől. Az eszköz, ami korábban csak a marketingszakembereknek segített, most már a vállalkozások és fejlesztők kezébe került. Elkezdjük aktívan használni a webanalitikát, hogy valós időben figyeljük a folyamatokat, és azonnal megértsük, mi történik. Ennek alapján tervezzük a terméket és a nagyobb ügyfélkörre való bevezetést.
Ha termékfejlesztés történik, azonnal megnézhetjük, hogy milyen mutatókkal áll összefüggésben, és hogyan befolyásolják ezek a mutatók az értékesítést és a vállalkozás szempontjából fontos jellemzőket. Így az alacsony hatású hipotéziseket azonnal kiszűrhetjük. Vagy például bevezethetjük az új funkciót statisztikailag jelentős számú felhasználónál, és valós időben nyomon követhetjük a mutatókat, hogy megtudjuk, minden úgy működik-e, ahogyan azt elképzeltük. Ne várjunk a visszajelzésekre panaszok vagy jelentések formájában, hanem kövessük magunk a folyamatot, és gyorsan korrigáljuk a termék fejlesztését. Az új funkciót három nap alatt bevezethetjük, majd statisztikailag helyes adatokat gyűjthetünk, még három nap alatt módosíthatunk, és íme, egy héten belül kész egy kiváló új termék.
Nyomon lehet követni az egész értékesítési tölcsért, minden ügyfelet, aki kapcsolatba lépett az új termékkel, felfedezni azokat a pontokat, ahol a tölcsér hirtelen szűkült, és megérteni az okokat. A fejlesztők és a vállalkozás most ezt együtt követi, ez a napi munka része. Ugyanazt az ügyfélutazást látják, és együtt ötleteket és hipotéziseket generálhatnak a fejlesztésre.
Ez a vállalkozás és a fejlesztés elemzéssel való integráció lehetővé teszi a termékek folyamatos létrehozását, a folyamatos optimalizálást, valamint a szűk keresztmetszetek keresését és észlelését az egész folyamatban.
Minden a bonyolultságról szól.
Amikor új terméket hozunk létre, nem tiszta lappal kezdünk, hanem beépítjük a már létező szolgáltatások összefonódásába. Amikor az új termékhez közelítnek, az ügyfelek legtöbbször több részleggel is kapcsolatba lépnek. Beszélhetnek a kapcsolattartó központ munkatársaival, az irodai menedzserekkel, kérdéseket tehetnek fel a támogatásnak, vagy online chatbe is léphetnek. A mutatók segítségével láthatjuk például, hogy mekkora a terhelés a kapcsolattartó központon, és hogyan lehet a legjobban kezelni a bejövő kérdéseket. Megérthetjük, hogy hány ember jut el az irodáig, és javaslatot tehetünk arra, hogyan tanácsolhatnánk tovább az ügyfelet.
A tájékoztatási rendszerek esetében is pontosan így van. Bankunk már több mint 20 éve működik, ez idő alatt létrejött és jelenleg is működik egy nagy, eltérő rendszerekből álló rendszer. A backend rendszerek közötti interakció néha kiszámíthatatlan. Például egy régi rendszerben egy bizonyos mező esetében korlátozás van a karakterek számát illetően, és ez néha összeomlasztja az új szolgáltatást. A hibák nyomon követése standard módszerekkel meglehetősen nehéz, de webanalitikával gyerekjáték.
Eljutottunk odáig, hogy minden érintett rendszerből begyűjtjük és elemezzük azokat a hibaüzeneteket, amelyek a kliensnek megjelennek. Kiderült, hogy sok közülük elavult, és még csak el sem tudtuk képzelni, hogy ezek valamilyen módon részt vesznek a folyamatunkban.
Elemzési munka
Webanalitikáink és SCRUM fejlesztőcsapataink egy helyiségben dolgoznak. Folyamatosan együttműködnek egymással. Amikor szükséges, a szakemberek segítenek a metrikák beállításában vagy az adatok kinyerésében, de legtöbbször a csapattagok maguk dolgoznak az elemző szolgáltatással, ami nem bonyolult.
Segítségre van szükség, ha például valamilyen függőségekre, további szűrőkre van szükség korlátozott típusú ügyfelek vagy források esetén. De a jelenlegi architektúrában ezzel ritkán találkozunk.
Érdekes, hogy az analitika bevezetéséhez nem volt szükség új IT-rendszer telepítésére. Ugyanazt a szoftvert használjuk, amellyel korábban a marketingesek dolgoztak. Csak a használatát kellett jóváhagyni és beilleszteni a vállalkozásba és a fejlesztésbe. Természetesen nem tudtuk csak úgy átvenni a marketing osztálytól, mindent újra kellett konfigurálnunk, és már a marketingnek hozzáférést adni az új környezethez, hogy ők is velünk egy információs térben legyenek.
A jövőben tervezzük, hogy megvásárolunk egy fejlettebb webanalitikai szoftververziót, amely kezeli a növekvő feldolgozási ülések mennyiségét.
Emellett aktívan folyik a webanalitika integrálásának folyamata a CRM-ből és a számviteli rendszerekből származó belső adatbázisokkal. Az adatok egyesítésével teljes képet kapunk az ügyfélről minden szükséges aspektusban: források, ügyféltípusok, termékek szerint. A BI-szolgáltatások, amelyek segítenek az adatok vizualizálásában, hamarosan minden részleg számára elérhetővé válnak.
Mi lett a végeredmény? Gyakorlatilag az analitikát és a döntéshozatalt a gyártási folyamat részévé tettük, ami látható hatást gyakorolt.
Analitika: ne lépj a lapátra
Végül szeretnék megosztani néhány tippet, amelyek segítenek elkerülni a hibázást a bizdevops kiépítése során.
- Ha az analitikát nem sikerül gyorsan elkészíteni, akkor valószínűleg nem a megfelelő analitikát csinálod. Az egyszerű úton kell elindulni egy termék felől, majd azt skálázni.
- Muszáj, hogy legyen egy csapatod vagy egy ember, aki jól érti az analitikai architektúrát. Már a kezdetekkor meg kell határozni, hogyan fogod skálázni az analitikát, integrálni más rendszerekbe és újrahasználni az adatokat.
- Ne generálj felesleges adatokat. A webstatisztika nemcsak hasznos információkat tartalmaz, hanem egy óriási szemétdombot is a gyenge minőségű és felesleges adatokkal. Ez a szemét akadályozni fog a döntéshozatalban és az értékelésben, ha nincsenek világos célok.
- Ne csinálj analitikát csak az analitika kedvéért. Először a célok, a megfelelő eszköz kiválasztása, és csak utána — analitika csak ott, ahol az hatékony.
A anyag együtt készült Csebotár Olga közreműködésével ().
Forrás: habr.com
