Hallo Habr! Wie ich im vorherigen Beitrag versprochen habe, stelle ich Ihnen weiterhin Delivery Club Tech vor. Heute werden wir über Produkttransformation sprechen.
Zufälligerweise war meine Ankunft in DC im Oktober 2018 durch eine vollständige Umstrukturierung aller Prozesse im Team gekennzeichnet. In diesem Moment standen die IT-Abteilung und das gesamte Unternehmen vor neuen Herausforderungen. Es war klar, dass die alten Prozesse die neuen Anforderungen nicht erfüllten. Sie betrafen hauptsächlich den Rückgang der Time-to-Market.
Es geht um diese Veränderungen, neue Herausforderungen, eine neue Teamstruktur, wie wir ohne Projektmanager und technische Analysten arbeiten und um die Ansätze zur Produktentwicklung, die ich Ihnen heute vorstellen möchte.
Im Oktober 2018 übernahm ich die Position des Head of Consumer. Dies war der Beginn meiner Reise zum Delivery Club. Es war notwendig, Produktteams innerhalb der Richtung zusammenzustellen, die Prozesse zu beschreiben, sie zu formalisieren und auf alle anderen Bereiche zu skalieren. Darüber hinaus bestand die Aufgabe darin, Leistungskennzahlen für Teams abzuleiten und ein Rahmenwerk für die Einstellung von Grund auf neu zu entwickeln.
Teamfunktionen
Die wichtigste Herausforderung bestand darin, Vorhersehbarkeit und Transparenz im Entwicklungsprozess zu erreichen. Die Situation wurde durch die Tatsache kompliziert, dass es zu diesem Zeitpunkt keine Leistungsmetriken gab. Aber was war sicher: Die Veröffentlichungen fanden nicht in regelmäßigen Abständen statt und ihre Zusammensetzung war erst zum Zeitpunkt der Veröffentlichung selbst klar.
Ein weiteres Problem war, dass die Teams nicht um das Produkt herum gebildet wurden. Diese komplizierte Kommunikation mit dem Unternehmen, da derselbe Entwickler an völlig unterschiedlichen Projekten teilnehmen konnte, gab es keinen klaren Fokus auf eine bestimmte Aufgabe. Daher wurde zunächst beschlossen, die Struktur der IT-Abteilung neu aufzubauen und von Plattformteams zu Produktteams zu wechseln.
Mit dem Plattformansatz waren die Backend-Mitarbeiter getrennt, die Front-End-Mitarbeiter getrennt und jedes Team hatte einen Teamleiter, der die Aufgaben verteilte. Die offensichtlichen Mängel dieser Struktur: Die Entwickler waren nicht in den Prozess und das Produkt eingetaucht, sie interessierten sich nicht für das gemeinsame Ziel, die Teams hatten einen anderen Fokus und es gab auch keine dedizierten Ressourcen für das Produkt. Infolgedessen war der Entwickler defokussiert, die Ziele blieben unerreichbar. Auch wenn es durch ein Wunder möglich war, das Ziel zu erreichen, stellte sich heraus, dass die mangelnde Kommunikation zwischen Produktmanagern und Stakeholdern oft nicht das war, was ursprünglich geplant war.
Das erste, was beschlossen wurde: ein Team - ein Produkt. Ressourcen werden zugewiesen, dh das Team führt Aufgaben nur für dieses und kein anderes Produkt aus. Teams, die an ähnlichen Produkten arbeiten, bilden die Entwicklungsrichtung. Die erste Transformation ergab 4 Richtungen:
- Verbraucher
- Logistik
- Verkäufer
- Intern
Als zweites wurde beschlossen, jedem Team einen Produktmanager zuzuweisen. Er ist auch einer aus dem Team. Der Produktmanager entwickelt eine Strategie für Produktänderungen, erstellt Produktmetriken, auf die sich das Team konzentriert, und legt Sprintziele fest.
Als Ergebnis haben wir die folgende Zelle erhalten: "Produktmanager - Teamleiter - Entwickler - Qualitätssicherung". Wir schließen Backend- und Frontend-Entwickler als Entwickler ein, aber es gibt auch Teams ohne Fronten. Frontender sind entweder Web Angular und JS oder iOS / Android.
Jetzt hat jedes Team durchschnittlich 5 ± zwei Personen. Warum so? Wir sind nicht sofort zu dieser Formel gekommen. Unsere Statistiken zeigen, dass dies die Zusammensetzung des Teams ist, mit der Sie das vorhersehbarste Ergebnis erzielen können. Das heißt, das Team kann genügend Funktionen übernehmen, um wesentliche Änderungen am Produkt vorzunehmen, gleichzeitig bleibt die Komplexität der Planung jedoch geringer als bei mehr Mitarbeitern. Das heißt, der Planungsfehler wird minimal.
Für eine Weile experimentierten wir mit Rollen innerhalb des Teams, wir hatten Teamleiter für mobile Entwicklung (iOS / Android) und einen Backend-Teamleiter. Am Ende hatten wir jedoch eine Matrixstruktur:
- Ein Teamleiter (in der Regel jemand aus dem Backend) hat QS-, Backend- und Frontend-Manager direkt unter seiner Aufsicht.
- product- « — — QA».
- — . . , QA- , CI/CD, QA- .
- - , .
- .
Ein weiteres Merkmal von uns: Wir haben keine Projektmanager und technischen Analysten. Dies war ursprünglich im Delivery Club der Fall, und wir haben beschlossen, dies nicht zu ändern. Erinnern Sie sich, dass wir ein Problem mit den Teams hatten, die sich auf das Produkt konzentrierten? Warum also Zwischenhändler zwischen dem Team und dem Produktmanager schaffen? Für uns ist es wichtig, dass sich die Teams in erster Linie darum kümmern, wie sich ihre Funktionen auf den Endbenutzer auswirken, und nicht nur darum, Tickets in Jira zu schließen. Dazu müssen die Mitarbeiter in Kontext-, Domänen-, Geschäfts- und sogar Produkt- und Finanzkennzahlen eintauchen.
Infolgedessen wird der Dialog zwischen dem Entwicklungsteam und dem Produktmanager fortgesetzt. Entwickler nehmen nicht nur eine Liste der Aufgaben vom Produktmanager entgegen und lassen dies alles entwickeln, sondern können auch in ein paar Stunden zu ihm kommen und beispielsweise sagen: „Hey, wir können den Button hier etwas einfacher, aber eine Woche schneller machen“ auf den Zahlen, und der Produktmanager wird OK sagen.
Somit führt das technische Team die Aufgabe der technischen Analyse, Bewertung und Zerlegung unabhängig aus und plant dann einen Sprint mit dem Produktmanager. Damit dies funktioniert, starten wir den Sprint sozusagen eine Woche vor dem Start. Dies ist der nächste Abschnitt.
Sprintentwicklung und -planung
Vorplanung
Eine Woche vor dem Start des Sprints bringt der Produktmanager Fälle und Design mit und beantwortet die Frage "Was muss getan werden?" Das technische Team entscheidet, wie es gemacht wird und wann es fertig sein wird.
Zu diesem Zweck hat das Team eine Woche Zeit, in der der Teamleiter, die Entwickler und die Qualitätssicherung zusammenkommen, technische Details besprechen, eine Zerlegung durchführen und einen Reset durchführen, indem sie Poker zur Bewertung planen. Während dieser Zeit erstellt die Qualitätssicherung eine Liste von Testfällen, die dann getestet werden.
Planung
Sobald das Team die Zerlegung und Bewertung durchgeführt hat, beginnt die Planung. Alle Aufgaben sind in 8 Stunden unterteilt. Um die Anzahl der Aufgaben in einem Sprint zu zählen, multiplizieren wir die Anzahl der Mitarbeiter mit 80 Stunden einer zweiwöchigen Iteration, und das Ergebnis wird mit einem Fokusfaktor von 0,8 multipliziert.
Weitere Aufgaben werden in Eimern geschlagen, es gibt nur drei davon:
- Produkt 60%
- Tech-Schulden 20%
- Unterstützung 20%.
Lassen Sie mich Ihnen ein Beispiel geben. Wir haben ein Team von 3 Backendern. Dies sind 80 * 3 * 0,8 = 192 Nutzstunden. Wir werden 116 Stunden (60%) für die Produktentwicklung, 38 Stunden für technische Schulden (20%) und 38 Stunden für den Support (20%) aufwenden.
Pflege
Am Montag planen wir Aufgaben und mitten im Sprint, also eine Woche später, findet die Pflege statt. Wir rufen die Pflege an, analysieren die Ergebnisse der ersten Woche und entscheiden, ob wir Zeit haben, um das Sprintziel zu erreichen, oder ob etwas abgeschnitten werden sollte. Wenn das Ziel erreicht ist, präsentiert der Produktmanager in derselben Besprechung Pläne für den nächsten Sprint, und der gesamte Zyklus wird wiederholt.
Demo
Der logische Abschluss des Sprints ist die Demo, in der wir alle Entwicklungsteams, Stakeholder, Geschäftskollegen und sogar den Leiter des Delivery Clubs einladen.
Die für die Veröffentlichung verantwortlichen Kollegen bereiten Präsentationen vor, sprechen über die Erfolge des Sprints und die überwundenen Schwierigkeiten. Wir teilen eine Produktgeschichte und Einblicke, wie neue Funktionen dem Benutzer zugute kommen.
Dies ist ein wichtiger Tag für das gesamte Team!
Retro
Retro ist für uns ein Weg, die Effizienz zu verbessern. Zunächst betrachten wir die Metriken der Teamleistung, wie erfolgreich wir den Sprint abgeschlossen haben. Wir überprüfen das Verhältnis der Aufgaben im Status "erledigt" zu denen, die zu Beginn der Iteration ausgeführt wurden, und zeichnen diese Daten per Bucket auf.
Zum Beispiel haben wir in Produkt 20 Probleme gelöst und 17 beendet. Daher beträgt die Erfolgsquote für diesen Eimer 85%. Gute Fortschritte in der Produktentwicklung sind für uns ein Indikator für 90% oder mehr. Wenn es niedriger ist, diskutieren wir bei Retro, wie wir diese Metrik verbessern können.
Sprintarbeit
Wir werden oft nach der Codeüberprüfung und der Funktionsweise von Tests gefragt. Hier ist alles ziemlich normal.
Der Tag beginnt mit einem Aufstehen. 15 Minuten lang bespricht das Team, was sie gestern getan haben und was sie heute tun werden.
Wir verwenden Jira Flow und Git Flow, um an Aufgaben zu arbeiten. Wir haben einen Atlassian-Stack. Es gibt auch ein Scrum-Board mit Spalten, die ausgeführt werden können - in Bearbeitung - bereit für die Codeüberprüfung - bereit für die Qualitätssicherung - bereit für das Leben - erledigt.
Wenn der Entwickler den Code vorbereitet hat, erstellt er in Jira einen Zweig mit der aktuellen Ausgabenummer - dies ist ein Feature-Zweig. Er sendet es auch an eine Pull-Anfrage in Bitbucket. Der Entwickler benötigt mindestens zwei Genehmigungen. Wir haben auch eine Integration mit Jenkins. Wenn der Build grün ist, können Sie ihn zusammenführen. Der technische Leiter und der Teamleiter haben das Recht, sich zusammenzuschließen. Manchmal müssen Sie einen Unit-Test für eine Pull-Anfrage vorbereiten. Und manchmal schreiben wir sie absichtlich nicht, wenn wir wissen, dass dies unkritische Geschäftsbereiche, eine unkritische Domäne oder ein experimentelles Merkmal sind, und wir können sie dann ausschneiden.
Wenn alles stinkt, schicken wir es zum Testen. Ein Testingenieur schreibt Autotests oder führt Testfälle manuell aus. Kommt wieder darauf an, wie kritisch die Domain ist. Und dann bereitstellen.
Wir können sagen, dass dieser Prozess wie eine Uhr funktioniert. Tatsächlich gibt es in diesem Moment eine ständige Kommunikation innerhalb der Teams. Das Hauptaugenmerk liegt auf dem Sprintziel und der pünktlichen Veröffentlichung. Um das Ziel zu erreichen, können wir entweder Produktänderungen diskutieren oder die technische Implementierung überarbeiten. All dies geschieht während der Arbeit an Aufgaben - es ist immer ein Dialog zwischen Entwicklern, Teamleiter, Produktmanager und Qualitätssicherung.
Entwicklungsrichtungen und Struktur der IT-Abteilung
Im Transformationsprozess kamen wir zu einer neuen Struktur von Entwicklungsrichtungen. Wie Sie sich erinnern, haben wir ganz am Anfang ungefähr vier geschrieben. Ferner wurde klar, dass für eine qualitativ hochwertige und zeitnahe Umsetzung der Ziele zwei weitere Bereiche identifiziert werden müssen. Somit gibt es jetzt 6 von ihnen:
- Beim Verbraucher dreht sich alles um kundenspezifische Produkte: Website und mobile Apps.
- Logistik - über Logistiker, Kuriere und Lieferung.
- Anbieter - über die Integration mit unseren Partnern (Restaurants / Geschäfte).
- Intern - Call Center und Support.
- F & E - wissenschaftsintensive Aufgaben lösen.
- Plattform - Verbesserung der Architektur und der Plattform insgesamt.
Jede Richtung hat ihre eigenen Aufgaben und ihre eigenen Schwierigkeiten.
Verbraucher
Die Priorität dieser Richtung ist das Glück des Benutzers. Die wichtigsten Produktmetriken sind hier: Aufbewahrung, Auftragsumwandlungsrate, Verbraucher-NPS. Aus technischer Sicht ist es uns wichtig, dass alle Daten schnell gesendet werden. In dieser Richtung vielleicht die größte Hochlast, da wir direkt mit dem Endbenutzer zusammenarbeiten. Und es gibt auch eine große Anzahl von Mikrodiensten, von denen es die meisten hier gibt.
Die Hauptprodukte sind eine Website, einschließlich einer mobilen Version, sowie Anwendungen für iOS und Android. Die beiden Hauptströme sind die Lieferung von Lebensmitteln und Restaurants. Technologischer Stack plus oder minus wie überall: PHP, Go, Postgres, Redis und Memcache für Cache, Kafka für asynchrone Kommunikation.
Logistik
Die Aufgabe dieser Anweisung ist es, eine schnelle Lieferung einer Bestellung an einen hungrigen Benutzer sicherzustellen. Darüber hinaus entwickeln wir eine Schnittstelle für Disponenten, die Kurieren bei Bedarf bei der manuellen Steuerung helfen.
Eine der größten Herausforderungen in der Logistik ergibt sich, wenn die Anzahl der Bestellungen und damit die Belastung des Systems zunimmt. Um mit den Belastungen fertig zu werden, müssen Sie Qualitätsänderungen an der Architektur vornehmen. Darüber hinaus unterscheidet sich die Lieferung von Lebensmitteln stark von der Lieferung von beispielsweise Büromaterial, Kleidung, Büchern und mehr. Dort ist alles etwas einfacher: Wir haben ein Routenblatt erstellt, es geplant und sind losgefahren.
Bei der Lieferung von Lebensmitteln funktioniert eine solche Nummer nicht. Wir sind alle auf Anfrage, die Situation ändert sich alle 5-15 Minuten. Wenn es anfängt zu regnen oder zu schneien, steigt die Nachfrage immer. Und wenn es draußen sonnig ist und Sie nicht zu Hause bleiben möchten, sinkt die Nachfrage. An Feiertagen und Wochenenden unterscheidet sich das Nachfrageprofil von den Wochentagen. Die Verkehrssituation und Staus nehmen auch ihre eigenen Anpassungen vor, insbesondere in den Bereichen, in denen Auto- / Motorradkuriere vorherrschen. Morgen-, Nachmittags- und Abendstunden haben unterschiedliche Nachfrageprofile.
Diese Nachfragemigration wird von unseren Monitoren verfolgt. Wenn die Nachfrage zurückgegangen ist, ändern wir die Suchergebnisse und geben im Abschnitt "Werbeaktionen" relevantere Angebote heraus. Um die Relevanz zu verbessern, verbinden wir ML-Modelle, die die Sortierung sowohl für den Benutzer als auch für die Logistikzone, in der wir eine Änderung beobachten, personalisieren.
Eine der Hauptanwendungen in der Logistik ist die Rider App. Es ist eine Android-Anwendung, in der Kuriere sehen, wo sie eine Bestellung abholen und wo sie geliefert werden soll.
Verkäufer
Dieser Bereich arbeitet mit unseren internen Partnern zusammen: Restaurants und Geschäfte. Genauer gesagt mit ihren Managern, die das Menü über ihr persönliches Konto verwalten und auf Statistiken in den Suchergebnissen reagieren.
Dank der gesammelten Daten und Statistiken zu Bestellungen haben wir ein gutes Verständnis für die Zielgruppe und die Merkmale von Restaurants. Wir arbeiten partnerschaftlich mit ihnen zusammen und bieten ihnen ein Tool, mit dem sie besser verstehen, wer ihre Kunden sind, und Marketingmechanismen ermöglichen. Wir helfen Restaurants auch dabei, Modelle zur Preisoptimierung zu entwickeln und zu verstehen, welche Gerichte zu welchem Zeitpunkt und in welcher Reihenfolge am besten angezeigt werden können.
Ein weiteres Produkt, an dem in Richtung Verkäufer gearbeitet wird, ist ein Dashboard, in das Bestellungen für die Küche fallen. Die Küche nimmt die Bestellung an, sieht ihre Zusammensetzung, bestimmt, wie sie zubereitet wird, und bereitet sie tatsächlich vor. Wenn die Bestellung vorbereitet ist, bestätigt die Küche dies in der App und überträgt die Bestellung an den Kurier. Und dann arbeitet der Kurier mit der Rider App.
Intern
Dieser Bereich ist für die Tools für unser Callcenter verantwortlich, das Benutzerunterstützung bietet. In der Tat ist dies der "Admin-Bereich" für alles, was mit Bestellungen zu tun hat. Der Bediener kann dem Kunden helfen, zusätzliche Informationen über den aktuellen Status der Bestellung geben und Anpassungen an der Bestellung vornehmen, bevor diese an das Restaurant übergeben wird.
Die Herausforderung dieser Richtung besteht darin, ein solches System zu entwickeln, das zum einen bequem ist und alle Bedürfnisse des Bedieners abdeckt, zum anderen schnell, da dem Kunden so schnell wie möglich geholfen werden muss. Zusätzlich zur Hauptaufgabe arbeiten die Mitarbeiter von Internal daran, die Zeit zu verkürzen, die ein Bediener für ein Problem benötigt, und die Anzahl der Anrufe zu verringern.
F & E.
Wenn Sie einen Geschäftsprozess ändern und gleichzeitig verstehen müssen, wie sich diese Änderungen auf die gesamte Plattform auswirken, ist Research & Development beteiligt. Die Jungs führen Experimente durch, bauen Modelle, zählen und wiegen. Sie interagieren auch am engsten mit der BI-Abteilung, wo sie mit Big Data, ML-Modellen, dem Entwurf neuronaler Netze und der prognostizierten Nachfrage arbeiten. In diesem Zusammenhang unterstützt BI F & E mit Forschung und Tools.
In der Forschung geht es hauptsächlich um die Arbeit mit Daten. Zum Beispiel, wie sich das System verhält, wenn Sie einen Faktor ändern. Die meisten Aufgaben für F & E kommen jetzt aus der Logistik, da dieser Bereich die höchste Unsicherheit aufweist.
Plattform
Dies ist eine technische Richtung. Zunächst konzentrieren sich die Jungs darauf, den Kern des Systems zu verbessern, die Auftragsabwicklung umzugestalten und unseren Monolithen zu zerlegen. Dies ist keine Produktentwicklung im klassischen Sinne, aber alle Verbesserungen zielen auf die eine oder andere Weise darauf ab, den Benutzern die Interaktion mit der Delivery Club-Anwendung bequemer und einfacher zu machen: Reduzieren Sie die Antwortzeit, damit Seiten schneller geöffnet werden, und erhöhen Sie die Plattformkapazität, damit mehr Benutzer sie erstellen können Ordnung und gleichzeitig war das Nutzungserlebnis für sie so angenehm wie möglich.
Transformationsergebnisse und neue Herausforderungen
Unsere Aufgabe war es, einen Entwicklungsprozess aufzubauen, der alle Anforderungen eines wachsenden Unternehmens erfüllt: Die Teams sind in das Geschäft involviert, kommunizieren viel miteinander, sind für die von ihnen selbst festgelegten Fristen verantwortlich und verstehen, wie sich ihre Arbeit auf den Endbenutzer auswirkt. Der Prozess muss transparent, messbar und vor allem skalierbar sein.
Nach einer Produkttransformation und der Optimierung des Entwicklungsprozesses kamen wir zu dem Schluss, dass jede unserer Versionen vorhersehbar wurde. Zuerst wussten wir mit einer Genauigkeit von 80%, wann und in welcher Zusammensetzung die Veröffentlichungen veröffentlicht werden würden. Jetzt ist der durchschnittliche Leistungsindikator für alle Teams innerhalb der Abteilung auf 90% gestiegen. Die Beteiligung der Teams, dh die Motivation der Jungs, hat stark zugenommen, sie verstehen, was sie tun und warum, für wen es wichtig ist.
Der Prozess umfasst die Fähigkeit, so schnell wie möglich auf Aufgaben zu reagieren, ohne die Produktentwicklung zu beeinträchtigen. Es gibt genügend Kommunikationspunkte, um die Arbeitskosten flexibel abzuschätzen und rechtzeitig auf Änderungen der Anforderungen des Produktmanagers zu reagieren. In der Praxis haben wir dafür gesorgt, dass der Prozess skalierbar ist: Wir haben es geschafft, mit demselben Entwicklungsprozess und ohne Leistungseinbußen von 40 auf 170 Mitarbeiter zu wachsen.
Gleichzeitig hören wir nicht auf und glauben, dass die Produkttransformation noch andauert. Ende 2019 begannen wir darüber nachzudenken, wie Teams das Geschäft noch stärker beeinflussen könnten. Die Teams verfügen über eine Menge Produktkompetenz. Es scheint, dass Sie diese nutzen können, um eine Art Symbiose aus Technologie und Wirtschaft zu entwickeln. Darüber hinaus mussten wir einen Mechanismus zur Überprüfung von Produkthypothesen entwickeln. Das heißt, den Wert der Aufgaben zu kontrollieren, die in unsere Entwicklung fallen. Zu diesem Zweck haben wir den GIST-Prozess beschrieben - einen Rahmen zur Überprüfung von Produkthypothesen, den wir in einem der folgenden Artikel diskutieren werden.
Danke fürs Lesen!