Olen puhunut monien muiden analytiikan ammattilaisten kanssa, jotka ovat vakuuttuneita siitä, että he haluavat, että heidän tiiminsä ei koskaan koskisi ”tuotantoon”. Vaikka on hyviä syitä olla varovainen aina, kun tehdään muutoksia, jotka voivat vaikuttaa asiakkaisiin, uskon, että ohjelmistojen muuttuessa yhä enemmän datapohjaisiksi on ratkaisevan tärkeää löytää turvallisia tapoja, joilla analytiikkatiimit voivat rakentaa ja ottaa käyttöön datapohjaisia sovelluksia.
Mitä on tuotanto?
Ensiksi muutama termin määritelmä. ”Tuotanto” on ympäristö. Yleensä on olemassa muutamia ympäristöjä, joissa koodia voidaan ajaa (etenemisjärjestyksessä):
- Lokaali kehitys
- Kaukokehitys
- Staging / QA
- Tuotanto
Jokaiseen ”sovellukseen” kuuluu useampia ympäristöjä, joista yksi on se ympäristö, joka kohtaa ei-kehittäjäkäyttäjät. Sitä, joka kohtaa ei-kehittäjäkäyttäjät, kutsutaan tyypillisesti ”tuotannoksi”.
Tässä on minun teesini: Tähän on tietysti poikkeuksia, ja erityyppisillä sovelluksilla on eriasteinen tieto-ohjautuvuus. Historiallisesti jotkin yritykset ovat epäröineet tehdä sovelluksistaan enemmän datapohjaisia, koska niiden ohjelmistosuunnittelijoilla ei ollut datataitoja ja he pelkäsivät antaa analytiikkatiimin vaikuttaa sovellukseen. Päätökset uusien ominaisuuksien lisäämisestä pitäisi tietysti tehdä sen perusteella, kuinka arvokkaita ne ovat, eikä vain siksi, että joku bloggaaja kehotti sinua tekemään niin. Jos sitä ei ole mahdollista mahdollistaa turvallisella tavalla, sinun pitäisi muuttaa asiakaskohtaista sovellustasi siten, että se on mahdollista.”
Jos tuo viimeinen kappale oli mielestäsi järkyttävä, räjäytän kohta sukat päästäsi: kaikki analyytikkosi ottavat jo nyt käyttöön tuotantoon joka päivä. Käyn läpi suosikkini2ja vastenmielisimmän. Ihmiset rakastavat minua juhlissa. kysymyksenasettelua:
- BI-työkalu, jonka konfiguroit tarjoamaan raportointia yrityksen käyttäjille – eikö se ole tuotantoa?
- R-skripti, joka kokoaa tiedot, puhdistaa ne ja tarjoaa visualisoinnit PPT:tä varten, joka lähetetään sähköpostitse johtoryhmälle, eikö se ole tuotantoa?
- Eikö se ole tuotantoa?
- Ei ole tuotantoa myös se Excel-tiedosto (joka on täytetty koodin kanssa), jota käytetään useiden miljoonien dollareiden arvoisen inventaariohallintapäätöksessä?
Muista: se, että sinulla ei ole kehitysympäristöä, ei tarkoita, että käyttäjälle suunnattu ympäristösi ei olisi tuotantoa!
Monissa startup-yrityksissä ihmiset käyttävät termiä ”tuotanto” lyhenteenä tarkoittaessaan käyttäjälle suunnattua web-sovellusta (yrityksen vaiheesta riippuen se voi olla tai olla olematta vielä rails-monoliitti). Sen lisäksi, että sanon, että sinun pitäisi lopettaa tällaisten epäselvien termien käyttäminen, haluan kannustaa miettimään, miksi haluaisit antaa muille kuin insinööreille, analyytikoille ja datatieteilijöille mahdollisuuden ottaa käyttöön asiakaslähtöisen sovelluksen. Lopuksi esittelen joitakin strategioita siitä, miten voisit toteuttaa tämän.
Miksi valtuuttaa analytiikkatiimi vaikuttamaan asiakkaisiin?
Tietoon perustuvien sovellusten rakentaminen on nykyaikaisen ohjelmistosuunnittelun ja tuotekehityksen pöytälaatikkotehtävä. Huomisen sovelluksissa data on integroitu alusta loppuun, ja jos data-asiantuntijoiden ja sovelluskehittäjien välissä on muuri, käy huonosti.
Tässä on muutamia esimerkkejä dataan perustuvista tuotteista, joita kannattaa rakentaa:
- Toteuta Thompsonin otanta monikätisen banditin sivustovaihtoehtojen testausta varten
- Klusteroi asiakkaat kohdennettuja markkinointisähköposteja tai laskeutumissivuvaihtoehtoja varten
- Ennusta asiakkaat, jotka todennäköisesti vaihtavat sivustoa, ja anna vain näille asiakkaille kuponkikoodi
- Ota käyttöön tuotesuositus- / hakujärjestykseen asettamista koskevia algoritmeja
Jos tahdot rakentaa näitä datalähtöisiä tuotteita, tahdot data-asiantuntijasi työskentelevän niiden kanssa. Seuraavassa on muutamia syitä miettiä rajan hämärtämistä Analytics3Kuten tavallista, käytän tässä postauksessa termiä ”Analytics” ja ”analyytikot” mahdollisimman laajasti sisältäen datatieteilijät, data-analyytikot ja muut data-asiantuntijat. tiimisi ja muun ohjelmistosuunnittelutiimisi välillä:
- Datatieteilijät ovat algoritmiasiantuntijoita ja jatkuva integraatio on tärkeää
- Tahdot, että sovelluksesi toimii datan voimin!!
- Analyytikot tuntevat datan parhaiten, joten he tekevät epätodennäköisemmin virheitä
- Jonkun toisen työn tuottaminen on paskamaista työtä
- Analytiikan iteroinnin estäminen eng-priorisoinnilla hidastaa kaikkia ja johtaa turhautumiseen
Ei ole kiistanalaista antaa tuotepäälliköiden tai suunnittelijoiden ottaa uutta sisältöä käyttöön sivustolle CMS:n kautta. Jos se tukisi markdownia, sen pitäisi olla myös triviaalia. Voisit myös antaa analyytikoiden viritellä algoritmien painotuksia CMS:n kautta, joten miksi et antaisi heidän ottaa mallia käyttöön, kunhan tuo malli on sen API:n mukainen, mitä sovellus odottaa? Koska analytiikkatiimilläsi ei ehkä ole kaikkia työkaluja tai taitoja monimutkaisen verkkosovelluksen parissa työskentelyyn, haluat tietysti varmistaa, että he voivat tehdä nämä muutokset tavalla, joka on sekä turvallinen että tehokas (eli he voivat käyttää heille tuttuja työkaluja ja muut osat on abstrahoitu pois).
Miten analytiikkatiimi valtuutetaan vaikuttamaan asiakkaisiin?
Nyt kun olemme keskustelleet siitä, miksi tämä voisi olla hyvä ajatus, voimme puhua joistakin tavoista, joilla tämä voidaan toteuttaa turvallisesti ja tehokkaasti. Tässä muutamia esimerkkejä, joita olen nähnyt aiemmin (ja kuulisin mielelläni lisää, jos tiedät hyviä malleja):
- Mikropalvelut
- Tuoteluokittelualgoritmi voi elää API:n takana, jotta analytiikkatiimi voi ottaa muutokset käyttöön koskematta muuhun sovellukseen
- Käyttäjäprofiilit
- Käyttäjän keskeiset ominaisuudet voi säilyttää taulukossa, johon web-sovelluksellasi on pääsy (esim.g., redis-välimuistin kautta), jota analytiikkatiimi hallinnoi (ETL, ML, mikä tahansa, kunhan API ei muutu)
- Painot / pisteet
- Jos sinulla on malli, joka toimii painojen tai attribuuttien avulla luodakseen ”pisteet” (esim, petosriskipisteytys), voit pitää nämä painotukset taulukossa, johon analytiikkatiimillä on kirjoitusoikeudet
Olen kirjoittanut ennenkin code-as-configuration -suunnittelumallista, ja yleisesti ottaen tämä on loistava malli, jonka avulla ei-insinöörit voivat ottaa koodia käyttöön tuotantoympäristöissä. Blogin ystävä Harlan Harris on myös kirjoittanut toimialuekohtaisten kielten käytöstä helpottamaan koneoppimismallien testausta, koordinointia ja käyttöönottoa tuotannossa.