Die Philosophie von DevOps, bei der Entwicklung mit Softwarewartung kombiniert wird, ĂŒberrascht niemanden mehr. Ein neuer Trend â DevOps 2.0 oder BizDevOps â gewinnt an Bedeutung. Hier verschmelzen drei Komponenten: GeschĂ€ft, Entwicklung und Support zu einer Einheit. So wie im DevOps ingenieurtechnische Praktiken die Verbindung zwischen Entwicklung und Support schaffen, ĂŒbernimmt in BizDevOps die analytische Arbeit die Rolle des "Klebers", der Entwicklung und GeschĂ€ft miteinander verbindet.
Ich möchte gleich zugeben: Dass wir echten BizDevOps geschaffen haben, wurde uns erst jetzt klar, nachdem wir einige kluge BĂŒcher gelesen haben. Es hat sich durch die Initiative der Mitarbeiter und die unbĂ€ndige Leidenschaft fĂŒr Verbesserungen irgendwie von selbst ergeben. Jetzt ist Analytics ein Teil des Produktionsprozesses der Entwicklung, der die Feedback-Schleifen erheblich verkĂŒrzt und regelmĂ€Ăig mit Erkenntnissen versorgt. Ich werde ausfĂŒhrlich erzĂ€hlen, wie alles bei uns organisiert ist.
Nachteile des klassischen DevOps
Wenn neue Kundenprodukte entwickelt werden, erstellt das Unternehmen ein ideales Kundenverhalten und rechnet mit einer guten Conversion, auf deren Grundlage es seine GeschÀftsziele und Ergebnisse festlegt. Das Entwicklerteam hingegen strebt danach, sehr guten, qualitativ hochwertigen Code zu erstellen. Der Support hofft auf eine vollstÀndige Automatisierung der Prozesse und darauf, dass die Wartung des neuen Produkts einfach und benutzerfreundlich ist.
Die RealitÀt sieht hÀufig so aus, dass die Kunden einen recht komplexen Prozess durchlaufen, das GeschÀft mit niedriger Conversion konfrontiert ist, die Entwicklungsteams Bugfix nach Bugfix veröffentlichen und der Support in einem Strom von Kundenanfragen ertrinkt. Kommt Ihnen das bekannt vor?
Der Ursprung des Ăbels liegt in der langen und qualitativ schlechten Feedback-Schleife, die in den Prozess integriert ist. Bei der Anforderungserhebung und dem Feedback wĂ€hrend der Sprints kommunizieren das GeschĂ€ft und die Entwickler mit einer begrenzten Anzahl von Kunden, die erheblichen Einfluss auf das Schicksal des Produkts haben. Oft ist das, was fĂŒr einen wichtig ist, fĂŒr die gesamte Zielgruppe vollkommen irrelevant.
Das VerstĂ€ndnis darĂŒber, ob sich das Produkt in die richtige Richtung entwickelt, kommt mit den Finanzberichten und den Ergebnissen der Marktforschung Monate nach dem Start. Diese sind aufgrund der begrenzten Stichprobe nicht in der Lage, Hypothesen bei einer groĂen Kundenzahl zu ĂŒberprĂŒfen. Insgesamt ist das also langwierig, ungenau und ineffektiv.
Trophy-Tool
Wir haben einen guten Weg gefunden, um hiervon wegzukommen. Ein Tool, das frĂŒher nur den Marketingfachleuten half, ist nun in den HĂ€nden von Unternehmen und Entwicklern gelandet. Wir haben begonnen, Web-Analytics aktiv zu nutzen, um den Prozess in Echtzeit zu betrachten und sofort zu verstehen, was passiert. Auf dieser Grundlage planen wir das Produkt selbst und dessen EinfĂŒhrung fĂŒr eine groĂe Kundenzahl.
Wenn eine Produktverbesserung geplant ist, kann man sofort sehen, welche Kennzahlen damit verbunden sind und wie sich diese auf die VerkĂ€ufe und fĂŒr das GeschĂ€ft wichtigen Merkmale auswirken. Dadurch lassen sich Hypothesen mit geringem Effekt sofort aussortieren. Oder man kann beispielsweise eine neue Funktion an einer statistisch signifikanten Anzahl von Nutzern ausrollen und in Echtzeit die Kennzahlen beobachten, um zu verstehen, ob alles so funktioniert, wie es gedacht war. Man wartet nicht auf RĂŒckmeldungen wie Anfragen oder Berichte, sondern verfolgt selbststĂ€ndig und korrigiert den Produktentwicklungsprozess schnell. Wir können eine neue Funktion herausbringen, innerhalb von drei Tagen statistisch valide Daten sammeln, innerhalb von weiteren drei Tagen Ănderungen vornehmen â und schon nach einer Woche ist ein groĂartiges neues Produkt bereit.
Man kann den gesamten Funnel nachverfolgen, alle Kunden, die mit dem neuen Produkt in Kontakt gekommen sind, und die Punkte identifizieren, an denen der Funnel plötzlich eng wurde, um die Ursachen zu verstehen. Sowohl die Entwickler als auch das GeschÀft beobachten dies nun, es ist Teil der tÀglichen Arbeit. Sie sehen denselben Kundenweg und können gemeinsam Ideen und Hypothesen zur Verbesserung generieren.
Eine solche Integration von GeschÀft und Entwicklung zusammen mit Analytik ermöglicht es, Produkte kontinuierlich zu erstellen, stÀndig zu optimieren, EngpÀsse zu identifizieren und den gesamten Prozess im Blick zu behalten.
Es geht um die KomplexitÀt
Wenn wir ein neues Produkt entwickeln, beginnen wir nicht bei Null, sondern integrieren es in das bereits bestehende Geflecht von Services. Bei der AnnĂ€herung an ein neues Produkt hat der Kunde hĂ€ufig Kontakt mit mehreren Abteilungen. Er kann mit Mitarbeitern des Kontaktcenters sprechen, mit Managern im BĂŒro kommunizieren oder den Support und Online-Chats kontaktieren. Anhand von Kennzahlen können wir beispielsweise sehen, welche Belastung im Kontaktcenter besteht, wie eingehende Anfragen am besten bearbeitet werden und wie viele Personen den Weg ins BĂŒro finden, sodass wir beraten können, wie der Kunde weiter unterstĂŒtzt werden sollte.
Mit Informationssystemen verhĂ€lt es sich ganz Ă€hnlich. Unsere Bank existiert seit ĂŒber 20 Jahren, und in dieser Zeit wurde eine groĂe Anzahl heterogener Systeme erstellt und funktioniert bis heute. Die Interaktion zwischen den Backend-Systemen kann manchmal unvorhersehbar sein. Zum Beispiel gibt es in einem alten System fĂŒr ein bestimmtes Feld EinschrĂ€nkungen hinsichtlich der Zeichenanzahl, und manchmal verursacht dies einen Absturz des neuen Services. Bugs mit Standardsystemen nachzuvollziehen ist ziemlich schwierig, aber mit Web-Analytics ist es ganz einfach.
Wir sind so weit gegangen, dass wir aus allen beteiligten Systemen die Fehlertexte abholen und analysieren, die dem Kunden angezeigt werden. Es stellte sich heraus, dass viele davon veraltet waren, und wir hÀtten uns nie vorstellen können, dass sie irgendwie an unserem Prozess beteiligt sind.
Arbeit mit Analysen
Unsere Web-Analytiker und SCRUM-Entwicklerteams befinden sich im selben Raum. Sie interagieren stÀndig miteinander. Wenn es nötig ist, helfen die Fachleute, die Metriken einzurichten oder Daten zu extrahieren; meistens arbeiten die Teammitglieder jedoch selbststÀndig mit dem Analysetool, das ist nichts Schwieriges.
Hilfe wird benötigt, wenn beispielsweise AbhĂ€ngigkeiten oder zusĂ€tzliche Filter fĂŒr bestimmte Kundentypen oder Quellen erforderlich sind. In der aktuellen Architektur begegnen wir dem aber selten.
Interessant ist, dass die Implementierung der Analytik keine neue IT-Systemeinrichtung erforderte. Wir verwenden dieselbe Software, die zuvor von unseren Marketingmitarbeitern genutzt wurde. Es war nur nötig, die Nutzung abzustimmen und sie in das GeschĂ€ft und die Entwicklung zu integrieren. NatĂŒrlich konnten wir nicht einfach alles nehmen, was im Marketing vorhanden war; wir mussten alles neu einrichten und dem Marketing Zugang zur neuen Umgebung geben, damit sie mit uns in einem Informationsfeld arbeiten konnten.
In Zukunft planen wir den Kauf einer verbesserten Version der Software fĂŒr Web-Analytik, die es uns ermöglichen wird, mit den wachsenden Volumina an verarbeiteten Sitzungen umzugehen.
DarĂŒber hinaus erfolgt bei uns aktiv die Integration von Web-Analytik und internen Datenbanken aus CRM und Buchhaltungssystemen. Durch die ZusammenfĂŒhrung der Daten erhalten wir ein vollstĂ€ndiges Bild des Kunden in allen relevanten Dimensionen: nach Quellen, Kundentypen und Produkten. BI-Tools, die zur Visualisierung der Daten beitragen, werden bald allen Abteilungen zur VerfĂŒgung stehen.
Was haben wir letztendlich erreicht? TatsÀchlich haben wir die Analyse und Entscheidungsfindung zu einem Teil des Produktionsprozesses gemacht, was sichtbare Ergebnisse geliefert hat.
Analyse: Treten Sie nicht in die gleichen Fallen.
AbschlieĂend möchte ich Tipps teilen, die Ihnen helfen, Stolpersteine beim Aufbau von BizDevOps zu vermeiden.
- Wenn die Analyse nicht schnell erfolgt, machen Sie die falsche Analyse. Gehen Sie den einfachen Weg mit einem Produkt und skalieren Sie dann weiter.
- Sie mĂŒssen unbedingt ein Team oder eine Person haben, die die zukĂŒnftige Architektur der Analyse gut versteht. KlĂ€ren Sie im Voraus, wie Sie die Analyse skalieren, in andere Systeme integrieren und Daten wiederverwenden werden.
- Erzeugen Sie keine ĂŒberflĂŒssigen Daten. Webstatistik umfasst neben nĂŒtzlichen Informationen auch eine riesige Menge an MĂŒll mit minderwertigen und unnötigen Daten. Dieser MĂŒll wird bei Entscheidungsfindungen und Bewertungen im Weg stehen, wenn keine klaren Ziele festgelegt sind.
- Machen Sie Analysen nicht um der Analyse willen. Zuerst die Ziele, die Wahl des Werkzeugs, und erst danach die Analyse nur dort, wo sie einen Effekt hat.
Das Material wurde gemeinsam mit Olga Tschebotar erstellt ().
Quelle: habr.com
