Die DevOps-filosofie, wanneer ontwikkeling gekombineer word met sagteware-instandhouding, sal niemand verras nie. ’n Nuwe neiging kry momentum – DevOps 2.0 of BizDevOps. Dit kombineer drie komponente in 'n enkele geheel: besigheid, ontwikkeling en ondersteuning. En net soos in DevOps vorm ingenieurspraktyke die basis van die verband tussen ontwikkeling en ondersteuning, en in besigheidsontwikkeling neem analise die rol van die "gom" aan wat ontwikkeling met besigheid verenig.
Ek wil dadelik erken: ons het nou eers uitgevind dat ons 'n regte besigheidsontwikkeling het, nadat ons slim boeke gelees het. Dit het op een of ander manier bymekaar gekom danksy die inisiatief van werknemers en 'n ononderdrukbare passie vir verbetering. Analytics is nou deel van die ontwikkelingsproduksieproses, wat terugvoerlusse aansienlik verminder en gereeld insigte verskaf. Ek sal jou in detail vertel hoe alles vir ons werk.
Nadele van Classic DevOps
Wanneer nuwe kliënteprodukte bedink word, skep 'n onderneming 'n ideale model van klantgedrag en verwag goeie omskakeling, op grond waarvan dit sy besigheidsdoelwitte en resultate bou. Die ontwikkelingspan streef op sy beurt daarna om baie goeie kode van hoë gehalte te maak. Ondersteun hoop vir volledige outomatisering van prosesse, gemak en gerief om 'n nuwe produk in stand te hou.
Die realiteit ontwikkel meestal op so 'n manier dat kliënte 'n taamlik komplekse proses ontvang, die besigheid sit vas met 'n lae omskakeling, ontwikkelingspanne stel regstelling na regstelling vry, en ondersteuning verdrink in die vloei van versoeke van kliënte. Klink bekend?
Die wortel van die kwaad hier lê in die lang en swak terugvoerlus wat in die proses ingebou is. Besighede en ontwikkelaars, wanneer hulle vereistes insamel en terugvoer tydens naellope ontvang, kommunikeer met 'n beperkte aantal kliënte wat die lot van die produk grootliks beïnvloed. Dikwels is dit wat vir een persoon belangrik is, glad nie tipies vir die hele teikengehoor nie.
Om te verstaan of 'n produk in die regte rigting beweeg, kom met finansiële verslae en marknavorsingsresultate maande na bekendstelling. En as gevolg van die beperkte steekproefgrootte, bied hulle nie die geleentheid om hipoteses op 'n groot aantal kliënte te toets nie. Oor die algemeen blyk dit lank, onakkuraat en ondoeltreffend te wees.
Trofee hulpmiddel
Ons het 'n goeie manier gevind om hiervan weg te kom. ’n Hulpmiddel wat voorheen net bemarkers gehelp het, het nou sy weg in die hande van besighede en ontwikkelaars gevind. Ons het webanalise aktief begin gebruik om intyds na die proses te kyk, hier en nou om te verstaan wat aan die gebeur is. Op grond hiervan, beplan die produk self en rol dit uit na 'n groot aantal kliënte.
As jy 'n soort produkverbetering beplan, kan jy dadelik sien met watter maatstawwe dit geassosieer word, en hoe hierdie maatstawwe verkope en eienskappe wat belangrik is vir die besigheid beïnvloed. Op hierdie manier kan jy onmiddellik hipoteses met lae effek uitwis. Of, byvoorbeeld, ontplooi 'n nuwe kenmerk na 'n statisties beduidende aantal gebruikers en monitor die maatstawwe intyds om te verstaan of alles werk soos bedoel. Moenie wag vir terugvoer in die vorm van versoeke of verslae nie, maar monitor en pas dadelik self die produkskeppingsproses aan. Ons kan 'n nuwe kenmerk ontplooi, statisties korrekte data in drie dae insamel, veranderinge oor nog drie dae aanbring - en oor 'n week is 'n wonderlike nuwe produk gereed.
Jy kan die hele tregter naspoor, al die klante wat met die nuwe produk in aanraking gekom het, punte waar die tregter skerp vernou het, opspoor en die redes verstaan. Beide ontwikkelaars en besighede monitor dit nou as deel van hul daaglikse werk. Hulle sien dieselfde klantreis, en saam kan hulle idees en hipoteses vir verbetering genereer.
Hierdie integrasie van besigheid en ontwikkeling tesame met analise maak dit moontlik om voortdurend produkte te skep, voortdurend te optimaliseer, knelpunte te soek en te sien, en die hele proses as 'n geheel.
Dit gaan alles oor kompleksiteit
Wanneer ons 'n nuwe produk skep, begin ons nie van voor af nie, maar integreer dit in 'n reeds bestaande web van dienste. Wanneer 'n nuwe produk probeer word, kontak 'n kliënt meestal verskeie departemente. Hy kan met kontaksentrumwerknemers kommunikeer, met bestuurders in die kantoor, hy kan ondersteuning kontak, of in aanlyn geselsies. Deur metrieke te gebruik, kan ons byvoorbeeld sien wat die las op die kontaksentrum is, hoe om inkomende versoeke die beste te verwerk. Ons kan verstaan hoeveel mense die kantoor bereik en voorstel hoe om die kliënt verder te adviseer.
Dit is presies dieselfde met inligtingstelsels. Ons bank bestaan al meer as 20 jaar, waartydens 'n groot laag heterogene stelsels geskep is en steeds funksioneer. Interaksie tussen backend-stelsels kan soms onvoorspelbaar wees. Byvoorbeeld, in sommige ou stelsels is daar beperkings op die aantal karakters vir 'n sekere veld, en soms laat dit die nuwe diens ineenstort. Dit is nogal moeilik om 'n fout op te spoor met behulp van standaardmetodes, maar met behulp van webanalise is dit maklik.
Ons het by die punt gekom waar ons begin het om fouttekste te versamel en te ontleed wat aan die kliënt gewys word vanaf alle betrokke stelsels. Dit het geblyk dat baie van hulle verouderd was, en ons kon ons nie eers indink dat hulle op een of ander manier by ons proses betrokke was nie.
Werk met analise
Ons webontleders en SCRUM-ontwikkelingspanne is in dieselfde vertrek geleë. Hulle het voortdurend interaksie met mekaar. Wanneer nodig, help spesialiste metrieke opstel of data aflaai, maar meestal werk die spanlede self met die ontledingsdiens, daar is niks ingewikkeld daar nie.
Hulp word benodig as jy byvoorbeeld 'n paar afhanklikhede of bykomende filters benodig vir 'n beperkte tipe kliënte of bronne. Maar in die huidige argitektuur kom ons dit selde teë.
Interessant genoeg het die implementering van analise nie die installering van 'n nuwe IT-stelsel vereis nie. Ons gebruik dieselfde sagteware waarmee bemarkers voorheen gewerk het. Dit was slegs nodig om ooreen te kom oor die gebruik daarvan en dit in besigheid en ontwikkeling te implementeer. Ons kon natuurlik nie net vat wat bemarking gehad het nie, ons moes alles opnuut herkonfigureer en bemarkingstoegang tot die nuwe omgewing gee sodat hulle in dieselfde inligtingsveld met ons sou wees.
In die toekoms beplan ons om 'n verbeterde weergawe van webanalise-sagteware aan te skaf wat ons in staat sal stel om die toenemende volumes verwerkte sessies te hanteer.
Ons is ook aktief besig om webanalise en interne databasisse van CRM en rekeningkundige stelsels te integreer. Deur data te kombineer, kry ons 'n volledige prentjie van die kliënt in al die nodige aspekte: volgens bron, tipe kliënt, produk. BI-dienste wat help om data te visualiseer, sal binnekort vir alle departemente beskikbaar wees.
Waarmee het ons geëindig? Trouens, ons het ontleding en besluitneming daaroor deel van die produksieproses gemaak, wat 'n sigbare effek gehad het.
Ontleding: moenie op die hark trap nie
En laastens wil ek 'n paar wenke deel wat jou sal help om te verhoed dat jy in die moeilikheid kom in die proses om 'n besigheidsontwikkelingsonderneming te bou.
- As jy nie vinnig analise kan doen nie, doen jy die verkeerde analise. Jy moet 'n eenvoudige pad van een produk volg en dan opskaal.
- Jy moet 'n span of persoon hê wat 'n goeie begrip het van die toekomstige analitiese argitektuur. Jy moet nog steeds op die strand besluit hoe jy die analise sal skaal, dit in ander stelsels sal integreer en die data sal hergebruik.
- Moenie onnodige data genereer nie. Webstatistieke is, benewens nuttige inligting, ook 'n groot vullishoop met lae kwaliteit en onnodige data. En hierdie gemors sal inmeng met besluitneming en assessering as daar nie duidelike doelwitte is nie.
- Moenie analise doen ter wille van analise nie. Eerstens, doelwitte, keuse van instrument, en eers dan - analise slegs waar dit 'n effek sal hê.
Die materiaal is saam met Chebotar Olga ().
Bron: will.com