A DevOps filozófiája, amikor a fejlesztést szoftverkarbantartással kombinálják, senki számára nem meglepő. Egy új trend lendületet vesz – a DevOps 2.0 vagy a BizDevOps. Már három összetevőt egyesít egyetlen egésszé: az üzletet, a fejlesztést és a támogatást. És ahogy a DevOps-ban a mérnöki gyakorlatok képezik a fejlesztés és a támogatás kapcsolatának alapját, úgy az üzleti devopsban is az analitika tölti be a „ragasztó” szerepét, amely összeköti a fejlesztést az üzlettel.
Azonnal beismerem: hogy igazi bizdevopot kaptunk, azt csak most, okos könyvek olvasása után tudtuk meg. Valahogy kifejlődött az alkalmazottak kezdeményezésének és a tökéletesítés iránti elfojthatatlan szenvedélynek köszönhetően. Ma az analitika a fejlesztés termelési folyamatának része, nagymértékben csökkenti a visszacsatolási hurkokat, és rendszeresen nyújt betekintést. Elmondom részletesen, hogy nálunk miként van elrendezve.
A klasszikus DevOps hátrányai
Amikor új ügyféltermékek születnek, a vállalkozás ideális vásárlói magatartási modellt alakít ki, és jó konverziót vár el, amelyre építi üzleti céljait és eredményeit. A fejlesztő csapat a maga részéről arra törekszik, hogy nagyon jó, minőségi kódot készítsen. A Support ezzel szemben a folyamatok teljes automatizálását, az új termék karbantartásának egyszerűségét és kényelmét reméli.
A valóság leggyakrabban úgy alakul, hogy az ügyfelek meglehetősen bonyolult folyamatot kapnak, az üzlet alacsony konverzión nyugszik, a fejlesztőcsapatok javítást adnak ki javítás után, és a támogatás elfullad az ügyfelektől érkező kérések folyamában. Ismerős?
A rossz gyökere itt a folyamatba ágyazott hosszú és rossz minőségű visszacsatolási hurokban rejlik. A vállalkozások és a fejlesztők, miközben a sprintek során igényeket gyűjtenek és visszajelzéseket kapnak, korlátozott számú vásárlóval kommunikálnak, ami nagyban befolyásolja a termék sorsát. Gyakran ami egy embernek fontos, az egyáltalán nem jellemző a teljes célközönségre.
A termék fejlesztése jó irányba haladó pénzügyi jelentésekkel és piackutatási eredményekkel a piacra dobás után hónapokkal megtudhatja. És a korlátozott mintaméret miatt nem adnak lehetőséget hipotézisek tesztelésére nagyszámú ügyfélen. Általában hosszúnak, pontatlannak és nem hatékonynak bizonyul.
trófea eszköz
Találtunk egy jó módot, hogy megszabaduljunk ettől. Egy olyan eszköz, amely korábban csak a marketingeseket segítette, az üzletemberek és a fejlesztők kezébe kerültünk. Elkezdtük aktívan használni a webelemzést, hogy valós időben lássuk a folyamatot, hogy megértsük, mi történik itt és most. Ennek alapján tervezze meg magát a terméket, annak nagyszámú vásárlóhoz való eljuttatását.
Ha valamilyen termékfejlesztést terveznek, akkor azonnal látható, hogy ez milyen mérőszámokhoz kapcsolódik, és ezek a mutatók hogyan hatnak az értékesítésre, az üzlet szempontjából fontos jellemzőkre. Így azonnal kiszűrheti a hipotéziseket alacsony hatással. Vagy például terjesszen ki egy új funkciót statisztikailag jelentős számú felhasználó számára, és kövesse nyomon a mutatókat valós időben, hogy megértse, minden a tervezett módon működik-e. Ne várja meg a visszajelzést kérések vagy jelentések formájában, hanem azonnal kövesse nyomon és haladéktalanul korrigálja a termék létrehozásának folyamatát. Bevezethetünk egy új funkciót, három nap alatt statisztikailag helyes adatokat gyűjthetünk, további három napon belül változtatásokat hajthatunk végre – és most egy hét alatt elkészül egy nagyszerű új termék.
Nyomon követheti a teljes tölcsért, az összes vásárlót, aki kapcsolatba került az új termékkel, megtalálhatja azokat a pontokat, ahol a tölcsér élesen szűkült, és megértheti az okokat. A fejlesztők és a vállalkozások is ezt figyelik, ez a napi munka része. Ugyanazt az ügyfélutat látják, és együtt ötleteket és hipotéziseket generálhatnak a fejlesztés érdekében.
Az üzlet és a fejlesztés ezen integrációja az analitikával együtt lehetővé teszi a termékek folyamatos létrehozását, folyamatos optimalizálását, a szűk keresztmetszetek keresését és áttekintését, a teljes folyamatot.
Az egész a komplexitáson múlik
Amikor új terméket hozunk létre, nem a nulláról indulunk, hanem egy már meglévő szolgáltatási bonyolultságba építjük be. Egy új termék kipróbálásakor az ügyfél leggyakrabban több részleggel kerül kapcsolatba. Kommunikálhat a kapcsolattartó központ munkatársaival, az irodában lévő vezetőkkel, kapcsolatba léphet a támogatással, használhat online chateket. A metrikák segítségével láthatjuk például, hogy mekkora a terhelés a contact centeren, hogyan lehet a legjobban feldolgozni a beérkező kéréseket. Meg tudjuk érteni, hogy hányan jönnek az irodába, és javasoljuk, hogyan adjunk további tanácsokat az ügyfélnek.
Ugyanez a helyzet az információs rendszerekkel. Bankunk több mint 20 éve létezik, ez idő alatt heterogén rendszerek nagy rétege jött létre és működik jelenleg is. A háttérrendszerek közötti interakció néha kiszámíthatatlan. Például néhány régi rendszerben korlátozzák a karakterek számát egy bizonyos mezőben, és ez néha összeomlik az új szolgáltatásban. A hiba követése szabványos módszerekkel meglehetősen nehéz, de a webes elemzés használata alapvető.
Elérkeztünk arra a pontra, ahol elkezdtük az összes érintett rendszer hibaszövegeinek átvételét és elemzését, amelyek megjelennek az ügyfélnek. Kiderült, hogy sok közülük elavult, és el sem tudtuk képzelni, hogy valamilyen módon részt vesznek a folyamatunkban.
Munka az analitikával
Webelemző és SCRUM fejlesztőcsapataink ugyanabban a helyiségben vannak. Folyamatosan érintkeznek egymással. Szükség esetén szakemberek segítenek a mérőszámok beállításában vagy az adatok feltöltésében, de alapvetően maguk a csapattagok dolgoznak az analitikai szolgáltatással, nincs semmi bonyolult.
Segítségre van szükség, ha például bizonyos függőségekre, további szűrőkre van szükség egy korlátozott típusú klienshez vagy forráshoz. De a jelenlegi architektúrában ritkán találkozunk ezzel.
Érdekes módon az analitika bevezetéséhez nem kellett új informatikai rendszert telepíteni. Ugyanazt a szoftvert használjuk, amellyel korábban a marketingesek dolgoztak. Már csak a felhasználását kellett összehangolni és az üzleti életben, fejlesztésben megvalósítani. Természetesen nem tudtuk átvenni azt, ami a marketingnek van, hanem mindent újra kellett konfigurálnunk, és a marketingnek hozzáférést kell adni egy új környezethez, hogy ugyanabban az információs mezőben legyenek velünk.
A jövőben azt tervezzük, hogy megvásároljuk a webelemző szoftver továbbfejlesztett verzióját, amely képes megbirkózni a feldolgozott munkamenetek növekvő mennyiségével.
Emellett aktívan integráljuk a webelemzést és a belső adatbázisokat a CRM-ből és a számviteli rendszerekből. Az adatok összevonásával teljes képet kapunk az ügyfélről minden szükséges rovatban: források, ügyféltípusok, termékek szerint. Az adatok megjelenítését segítő BI-szolgáltatások hamarosan minden részleg számára elérhetőek lesznek.
Mire jutottunk? Valójában a gyártási folyamat részévé tettük az elemzést és az ezzel kapcsolatos döntéshozatalt, aminek látható hatása volt.
Analitika: ne lépjen a gereblyére
És végül szeretnék megosztani tippeket, amelyek segítenek elkerülni a bizdevops építési folyamatában jelentkező ütéseket.
- Ha az elemzést nem lehet gyorsan elvégezni, akkor rossz elemzést végez. Egyetlen terméktől egy egyszerű utat kell követnie, majd méreteznie kell.
- Olyan csapatnak vagy személynek kell lennie, aki jól érti a jövőbeli elemzési architektúrát. Még mindig el kell döntenie a parton, hogyan méretezi az elemzést, integrálja más rendszerekbe, és hogyan használja fel újra az adatokat.
- Ne generáljon extra adatokat. A webstatisztika a hasznos információk mellett egy hatalmas szemétlerakó is, rossz minőségű és redundáns adatokkal. Ez a szemét pedig megzavarja a döntéshozatalt és az értékelést, ha nincsenek egyértelmű célok.
- Ne az elemzés kedvéért végezzen elemzést. Először is a célok, az eszköz kiválasztása, és csak azután - az elemzés csak ott, ahol ez hatást fejt ki.
Az anyagot Olga Chebotarral ().
Forrás: will.com