Beszéltem sok analitikus kollégával, akik ragaszkodnak ahhoz, hogy a csapatuk soha ne nyúljon a “termeléshez”. Bár jó okunk van arra, hogy óvatosak legyünk, amikor olyan változtatásokat hajtunk végre, amelyek hatással lehetnek az ügyfelekre, úgy vélem, hogy a szoftverek egyre inkább adatvezérelté válásával kritikus fontosságú, hogy biztonságos módokat találjunk arra, hogy az analitikus csapatokat képessé tegyük az adatvezérelt alkalmazások létrehozására és telepítésére.
Mi a termelés?
Először is, néhány fogalom meghatározása. A “termelés” egy környezet. Általában néhány környezet van, ahol a kód futtatható (a sorrendben):
- Lokális fejlesztés
- Távoli fejlesztés
- Staging / QA
- Termelés
Minden “alkalmazásnak” több környezete van, amelyek közül az egyik a nem fejlesztő felhasználókkal szemben álló környezet. A nem fejlesztői felhasználókkal szemben álló környezetet tipikusan “termelésnek” nevezik.
Itt a tézisem: Ez alól természetesen vannak kivételek, és a különböző típusú alkalmazások az adatvezéreltség különböző “fokozataival” rendelkeznek. Történelmileg néhány vállalat azért habozott az alkalmazásainak adatvezéreltebbé tételével, mert a szoftvermérnökeik nem rendelkeztek megfelelő adatismeretekkel, és féltek attól, hogy az Analytics-csapat hatással legyen az alkalmazásra. Természetesen az új funkciók hozzáadásáról aszerint kell döntenie, hogy azok mennyire lesznek értékesek, nem pedig egyszerűen azért, mert egy blogger azt mondta, hogy tegye meg. Ha ezt nem lehet biztonságos módon lehetővé tenni, akkor úgy kell módosítania az ügyféllel szembenéző alkalmazását, hogy ez lehetővé váljon.”
Ha az utolsó bekezdést sokkolónak találta, akkor most le fogom szedni a lábáról: az összes elemzője már minden nap telepíti a termelésbe, máris. Hadd mutassam be a kedvencemet2és a legellenszenvesebbet. Az emberek szeretnek engem a partikon. kérdéssor:
- A BI-eszköz, amelyet úgy konfigurál, hogy a vállalaton belüli felhasználók számára jelentéseket készítsen – ez nem a gyártás?
- Az az R-szkript, amely összegyűjti az adatokat, megtisztítja őket, és vizualizációt készít egy PPT-hez, amelyet e-mailben küld a vezetői csapatnak, ez nem a gyártás?
- Az az Excel-fájl (tele kóddal), amelyet egy több millió dolláros leltározási döntés meghozatalához használnak, ez nem a gyártás?
Ne feledd: csak azért, mert nincs fejlesztői környezeted, még nem jelenti azt, hogy a felhasználó felé néző környezeted nem termelés!
Egy csomó startup esetében az emberek a “termelés” szót rövidítésként használják a felhasználó felé néző webes alkalmazásukra (a cég stádiumától függően lehet, hogy még mindig egy rails monolit). Amellett, hogy azt mondom, hogy abba kellene hagyni az ilyen homályos kifejezések használatát, azt szeretném támogatni, hogy gondolkodjunk el azon, hogy miért akarjuk lehetővé tenni a nem mérnököknek, elemzőknek és adattudósoknak, hogy egy ügyfélbarát alkalmazáshoz telepítsenek. Végül néhány stratégiával fejezem be, hogyan lehet ezt operacionalizálni.
Miért adjunk felhatalmazást az analitikai csapatnak az ügyfelek befolyásolására?
A modern szoftverfejlesztés és termékfejlesztés számára az adatvezérelt alkalmazások építése a tét. A holnapi alkalmazásokban az adatok az elejétől a végéig integrálva lesznek, és ha az adatszakértők és az alkalmazásfejlesztők között fal húzódik, akkor rosszul járunk.
Itt van néhány példa az adatvezérelt termékekre, amelyeket érdemes felépíteni:
- Tompson-mintavételezés bevezetése a webhelyváltozatok többkarú bandita teszteléséhez
- A vásárlók klaszterezése célzott marketing e-mailek vagy landing page-változatok számára
- Az elvándorlásra hajlamos vásárlók előrejelzése, és csak ezeknek a vásárlóknak adjon kuponkódot
- Termékajánló / keresési rangsoroló algoritmusok bevezetése
Ha ilyen adatvezérelt termékeket akar építeni, akkor azt akarja, hogy az adatszakértői dolgozzanak rajtuk. Íme néhány ok, amiért érdemes elgondolkodni azon, hogy elmosódjon a határvonal az Analytics3A szokás szerint ebben a bejegyzésben az “Analytics” és az “elemzők” kifejezést a lehető legtágabb értelemben használom, beleértve az adattudósokat, adatelemzőket és más adatszakértőket. csapatodat és a szoftverfejlesztő csapatod többi tagját:
- Az adattudósok az algoritmus szakértői, és fontos a folyamatos integráció
- Az alkalmazásodat adatokkal akarod működtetni!!
- Az analitikusok ismerik a legjobban az adatokat, így kevésbé valószínű, hogy hibáznak
- Más munkájának gyártása szar munka
- Az analitikusok iterációjának blokkolása eng priorizálással lelassít mindenkit és frusztrációhoz vezet
Nem vitatható, hogy a termékmenedzserek vagy a tervezők új tartalmakat telepíthetnek az oldalra egy CMS-en keresztül. Ha ez támogatná a markdownt, akkor triviálisnak is kellene lennie. Az elemzőket is hagyhatnád, hogy egy CMS-en keresztül módosíthassák az algoritmusok súlyait, szóval miért ne hagyhatnád, hogy egy modellt telepítsenek, amíg ez a modell megfelel annak az API-nak, amit az alkalmazás elvár? Természetesen, mivel az Ön analitikai csapata nem biztos, hogy rendelkezik az összes eszközzel vagy készséggel egy összetett webes alkalmazáson való munkához, meg kell győződnie arról, hogy ezeket a módosításokat biztonságos és hatékony módon tudják elvégezni (azaz használhatják az általuk ismert eszközöket, a többi rész pedig absztrahálva van).
Hogyan hatalmazza fel az analitikai csapatot az ügyfelek befolyásolására?
Most, hogy megbeszéltük, miért lehet ez jó ötlet, beszélhetünk arról, hogyan lehet ezt biztonságosan és hatékonyan megvalósítani. Íme néhány példa, amit a múltban láttam (és szívesen hallanék még többről, ha tudsz jó mintát):
- Mikroszolgáltatások
- A termékrangsoroló algoritmus élhet egy API mögött, így az elemzőcsapat az alkalmazás többi részének érintése nélkül telepítheti a változásokat
- Felhasználói profilok
- Megőrizheti a kulcsfontosságú felhasználói attribútumokat egy olyan táblázatban, amelyhez a webes alkalmazás hozzáférhet (pl.g., egy redis cache-en keresztül), amelyet az analitikai csapat kezel (ETL, ML, bármi, amíg az API nem változik)
- Súlyok / pontszámok
- Ha van egy modellje, amely súlyok vagy attribútumok alapján dolgozik, hogy létrehozzon egy “pontszámot” (pl, csalási kockázati pontszám), akkor ezeket a súlyokat egy olyan táblázatban tarthatja, amelyhez az elemzőcsapat írási hozzáféréssel rendelkezik
A kód mint konfiguráció tervezési mintáról már írtam korábban, és általában véve ez egy nagyszerű minta arra, hogy a nem mérnökök számára lehetővé tegye a kód biztonságos telepítését termelési környezetbe. A blog barátja, Harlan Harris szintén írt a domain-specifikus nyelvek használatáról a gépi tanulási modellek tesztelésének, koordinálásának és termelésben való telepítésének megkönnyítése érdekében.