Jeg har talt med mange analytikerkolleger, som er fast besluttet på, at de ønsker, at deres team aldrig skal røre ved “produktion”. Selv om der er gode grunde til at være forsigtig, når du foretager ændringer, der kan påvirke kunderne, mener jeg, at efterhånden som software bliver mere datadrevet, er det afgørende at finde sikre måder at give Analytics-teams mulighed for at bygge og implementere datadrevne applikationer.
Hvad er produktion?
Først en definition af nogle begreber. “Produktion” er et miljø. Almindeligvis er der et par miljøer, hvor kode kan køres (i rækkefølge af progression):
- Lokal udvikling
- Fjernudvikling
- Staging / QA
- Produktion
Hvert “program” vil have flere miljøer, hvoraf det ene vil være det miljø, der står over for brugere, der ikke er udviklere. Den, der står over for ikke-udviklerbrugere, kaldes typisk “produktion”.
Her er min tese: Der er naturligvis undtagelser til dette, og forskellige typer applikationer vil have forskellige “grader” af datadrevethed. Historisk set har nogle virksomheder tøvet med at gøre deres applikationer mere datadrevne, fordi deres softwareingeniører ikke havde de nødvendige datakompetencer, og fordi de var bange for at lade Analytics-teamet påvirke applikationen. Du bør naturligvis træffe beslutninger om at tilføje nye funktioner baseret på, hvor værdifulde de vil være, ikke blot fordi en eller anden blogger har sagt det til dig… Hvis det ikke er muligt at muliggøre det på en sikker måde, så bør du ændre din kundevendte applikation på en sådan måde, at det bliver muligt.
Hvis du fandt det sidste afsnit chokerende, er jeg ved at blæse dine sokker af: Alle dine analytikere udruller til produktion hver dag, allerede nu. Lad mig gå dig gennem min favorit2og mest modbydelige. Folk elsker mig til fester. spørgerække:
- Det BI-værktøj, som du konfigurerer til at levere rapportering til brugere i din virksomhed – er det ikke produktion?
- Det R-script, der samler data, renser dem og leverer visualiseringer til en PPT, der bliver sendt pr. e-mail til det ledende team, er det ikke produktion?
- Den Excel-fil (fyldt med kode), der bruges til at træffe en beslutning om lagerbeholdning for flere millioner dollars, er det ikke produktion?
Husk: Bare fordi du ikke har et udviklingsmiljø, betyder det ikke, at dit brugervendte miljø ikke er produktion!
For mange startups bruger folk “produktion” som en forkortelse for at henvise til deres brugervendte webapp (afhængigt af virksomhedens stadie er det måske eller måske ikke stadig en rails-monolit). Udover at sige, at du bør holde op med at bruge sådanne uklare udtryk, vil jeg gerne slå til lyd for at tænke over, hvorfor du måske ønsker at gøre det muligt for ikke-ingeniører analytikere og dataloger at implementere til en kundevendt applikation. Jeg vil slutte af med nogle strategier for, hvordan du kan operationalisere dette.
Why Empower the Analytics Team to Impact Customers?
Building data-driven applications is table-stakes for moderne software engineering and product development. Morgendagens apps vil have data integreret fra forkant til bagkant, og hvis der er en mur mellem dine dataeksperter og dine applikationsudviklere, vil du få en dårlig tid.
Her er nogle eksempler på datadrevne produkter, som du måske ønsker at bygge:
- Implementer Thompson-sampling til multi-armed bandit-testning af webstedsvarianter
- Cluster kunder til målrettede markedsføringsmails eller landingssidevarianter
- Forudsig kunder, der sandsynligvis vil blive skiftet, og giv kun disse kunder en kuponkode
- Indfør produktanbefalings-/søgningsrangordningsalgoritmer
Hvis du ønsker at bygge disse datadrevne produkter, vil du have dine dataeksperter til at arbejde på dem. Her er nogle grunde til at overveje at udviske grænsen mellem dit Analytics3Som sædvanlig bruger jeg i dette indlæg udtrykket “Analytics” og “analytikere” på den bredest mulige måde, herunder dataloger, dataanalytikere og andre dataeksperter. hold og resten af dit softwareudviklingsteam:
- Dataloger er dine algoritmeeksperter, og kontinuerlig integration er vigtig
- Du ønsker, at din app skal være drevet af data!!
- Analytikere kender dataene bedst, så de er mindre tilbøjelige til at begå fejl
- Produktionering af en andens arbejde er et lortejob
- Blokering af analytisk iteration med eng prioritering sinker alle og fører til frustration
Det er ukontroversielt at lade produktchefer eller designere udrulle nyt indhold til webstedet via et CMS. Hvis det understøttede markdown, burde det også være trivielt. Du kunne også lade analytikere justere algoritmevægte via et CMS, så hvorfor ikke lade dem udrulle en model, så længe denne model er i overensstemmelse med det API, som appen forventer? Da dit Analytics-team måske ikke har alle værktøjer eller færdigheder til at arbejde på en kompleks webapplikation, vil du naturligvis sikre dig, at de kan foretage disse ændringer på en måde, der er både sikker og effektiv (dvs. at de kan bruge de værktøjer, de er fortrolige med, og at de andre dele er abstraheret væk).
Hvordan giver du Analytics-teamet mulighed for at påvirke kunderne?
Nu da vi har diskuteret, hvorfor dette kan være en god idé, kan vi tale om nogle måder at få dette til at ske sikkert og effektivt. Her er nogle eksempler, som jeg tidligere har set (og jeg vil meget gerne høre om flere, hvis du kender til gode mønstre):
- Mikrotjenester
- Produktklassificeringsalgoritmen kan leve bag et API, så analysteamet kan implementere ændringer uden at røre resten af appen
- Brugerprofiler
- Du kan persistere vigtige brugerattributter i en tabel, som din webapp har adgang til (f.eks.g., via en redis-cache), som administreres af analyseholdet (ETL, ML, hvad som helst, så længe API’et ikke ændres)
- Vægte / Scoringer
- Hvis du har en model, der arbejder ud fra vægte eller attributter for at skabe en “score” (f.eks, en svindelrisikoscore), så kan du holde disse vægte i en tabel, som analyseteamet kan have skriveadgang til
Jeg har skrevet om kode-as-konfigurationsdesignmønsteret før, og generelt er det et godt mønster til at give ikke-ingeniører mulighed for at sikre, at kode kan implementeres sikkert i produktionsmiljøer. Friend-of-the-blog Harlan Harris har også skrevet om at bruge domænespecifikke sprog til at lette testning, koordinering og udrulning af maskinlæringsmodeller i produktion.