Eine Rückschau auf unsere Herausforderungen: Wie eine eigene Lösung besser war als die kostenpflichtigen Alternativen

Hallo! Mein Name ist Alexey Pjankov, ich bin der Hauptprogrammierer bei Sportmaster. Ich möchte gleich klarstellen, dass "Haupt" nicht bedeutet "der wichtigste Programmierer", es ist einfach ein charmantes Übersetzung für "Senior+".

Ich arbeite seit 2012 bei Sportmaster, und in dieser Zeit hat unser Entwicklungsteam viele technisch interessante Lösungen entwickelt. Heute möchte ich jedoch darüber sprechen, wie wir in bestimmten mehrdeutigen Situationen gedacht haben.

In diesem Artikel wird es keine konkreten technischen Lösungen geben (und eigentlich auch nichts Technisches), das man einfach übernehmen und in eigenen Projekten anwenden kann. Es ist vielmehr eine Reflexion über die geleistete Arbeit. Es gab besondere Momente, die uns als Team geprägt haben — uns zusammengeschweißt, gestärkt und auf die Probe gestellt haben. Über diese Momente, die Atmosphäre in unserem Team, unsere Herausforderungen und einige psychologische Fallen, in die wir uns manchmal selbst hineinmanövrieren, möchte ich heute berichten.

Ich beginne genau im Jahr 2012.

Ich kam 2012 mit dem Hauptziel, an unserer Flaggschiff-Website zu arbeiten. Damals war das ein "Frankenstein-Monster": Ein Teil des Teams arbeitete mit unserem alten System, das nicht gut mit den Lasten zurechtkam (Bitrix), während der andere Teil des Teams (zu dem auch ich gehörte) versuchte, ein neues System zu implementieren, das nach dem Kriterium "Wenn es das teuerste E-Commerce-System der Welt ist, nehmen wir es" ausgewählt wurde. Genaugenommen "versuchten wir es zu implementieren" – denn das System wehrte sich verzweifelt, und zu jedem Fortschritt, den wir machten, kam garantiert eine "Überraschung" als Antwort. Wir arbeiteten hart, aber unser Fortschritt war schneckenlangsam.

Für mich war die letzte Grenze das Kennenlernen des Codes einer Methode in diesem "teuersten E-Commerce der Welt", als stundenlanges konzentriertes Arbeiten an einem kniffligen Bug dazu führte, dass die Ursache irgendwo in einem Custom-Tag gefunden wurde, das bei der HTML-Generierung in JSP ausgeführt wird. Diese Custom-Tag hat die Aufgabe, die Summe bestimmter Größen anzuzeigen. Das ist nicht schlecht, dafür sind solche Custom-Tags ja gedacht. Doch die Überraschung lag darin, dass dabei einige Daten in der Datenbank verändert werden, und das Verhalten auf den folgenden Seiten davon abhängt. Wenn man F5 drückt, wiederholt sich dieser Aufruf, was die Konsistenz der Daten stört. Und zwar so, dass es erst nach mehreren Schritten auffällt, nämlich auf der 3. Seite der Sequenz. Nein, ich habe nichts dagegen, dass so ein "Ninja-Meister" im Team ist und mit seinem Code die Aufmerksamkeit der Kollegen aufrechterhält. Aber so etwas in der Bibliothek eines der teuersten Systeme ist wirklich problematisch!

Es war Freitag. Am Samstag und Sonntag haben mein Kollege und ich im Büro gearbeitet, um zu klären, welche Aufgaben das Unternehmen heute an das System stellt und welche Aufgaben wir uns in einem Jahr vorstellen können. Daher haben wir überlegt, wie wir diese Herausforderungen angehen würden, wenn wir nicht an die Nutzung dieses kostspieligen und frustrierenden Systems gebunden wären.

Gesagt, getan. Wir haben ein Pilotprojekt erstellt, das die Grundlage für die Entwicklung der neuen Sportmaster-Website legt. Viele dieser Ideen haben sich bewährt und ihre Fortsetzung wird derzeit aktiv auf der Website umgesetzt.

Phasen des Pilotprojekts und Zeitrahmen

2 Tage. Wir haben ein Mikroprototyp erstellt – am Wochenende übertragen wir unsere Datenbank nach ElasticSearch und implementieren die facettierte Suche. Voilà! In dem teuren System hätte diese Einstellung 2 Wochen gedauert. Hier jedoch dauert es nur ein paar Stunden! Und es funktioniert sogar schneller. Tatsächlich um ein Vielfaches schneller.

2 Wochen. Wir entwickeln den Prototypen weiter und fügen Funktionen für eine angemessene personalisierte Ausgabe hinzu.

Beispielsweise hat ein Benutzer mehrere Rabatte und Aktionen, die speziell für ihn gelten – daher sollte in den Produktergebnissen genau der Preis angezeigt werden, den er durch die Nutzung aller verfügbaren Angebote auf die vorteilhafteste Weise erzielen kann.

Bei Aktionen ist das nicht so einfach. Zum Beispiel kauft man Ski, und jetzt gibt es 40 % Rabatt auf die Mütze, aber dafür entfällt der Willkommensrabatt von 10 % auf die gesamte Bestellung. Ja, das ist ein echter Fall 🙂 Um eine solche Aktion im Einkaufssystem einzurichten, wurden 3 Beratungen mit dem Anbieter bezahlt, aus denen viele Beispiele hervorgingen, wie man andere Aktionen gestalten kann. Sehr diplomatisch und angesichts der Kosten für die Beratungen – wirtschaftlich gesehen sehr gut.

Wir haben dem Unternehmen eine detaillierte Demo gezeigt. Wir haben versprochen, das Pilotprojekt schnell zu erstellen, und sofort mit der Arbeit begonnen.

2 Monate. Das Pilotprojekt – wir erstellen es in Form einer Live-Website mit Katalogsuche. Die Suche mit Facetten, die Suchergebnisse – mit persönlichen Rabatten, sieht die Pilotversion fast wie die Website von Sportmaster aus, und die Produkte, die wir hochgeladen haben, sind dieselben. Ein Traum!

Wir fügen unserem Abteilungsleiter "Redekunst:100" hinzu, und die Präsentation beim Unternehmen läuft hervorragend! Wir erhalten den Freiraum, um die eCommerce-Plattform selbst zu entwickeln.

Das bedeutet, haltet euch bereit, Leute, haltet den Budgetrahmen ein. Cool, oder?

2 Jahre. Der Launch der Website. Ja, das hat lange gedauert. Alles, was wir zu diesem Zeitpunkt konnten, haben wir nur im Rahmen eines Prototyps ausprobiert. Zwei Personen können problemlos ein eingespieltes Team bilden. Die Aufgaben, die wir „abgearbeitet“ haben, waren größtenteils kleine Anpassungen von „Hello World“ in neuen Technologien. Wir haben schnell neue Hypothesen generiert, sie zügig getestet, konnten uns nicht festlegen und haben sie deshalb ohne Bedauern „beerdigt“. Als wir zehn Personen wurden, haben wir aus Gewohnheit unsere Arbeitsgeschwindigkeit auf alle anderen extrapoliert. Und haben Fristen für die Aufgaben versprochen, die unser Bild vom Ideal multipliziert mit unserem Enthusiasmus entsprachen.

Kennen Sie die Situation? 🙂

Wissen Sie dann schon, was als Nächstes kommt?

Falle Nr. 1. „Der coole Extrapolator“

Es ist klar, dass neue Technologien in Präsentationen sehr beeindruckend aussehen und in der Anwendung des Typs „Hello World“ hervorragend funktionieren. Doch die Realität ist meistens ein Stück davon entfernt.

Also, wir nehmen eine Bibliothek, schreiben eine Menge Anwendungscode. Unit-Tests sehen wir als lästige Pflicht an (wir sind schließlich die Besten und arbeiten hier mit Schallgeschwindigkeit, der Code ist modern und so weiter). Wir ändern und erweitern ständig die APIs on the fly – wozu gibt es da Tests, ernsthaft? Und das alles im Zeichen von "wir haben den Entwicklungsprozess toll optimiert" (ja, darüber jetzt zu sprechen, macht mir Angst).

Und dann wird alles ziemlich offensichtlich.

Wir bringen einen neuen Build auf UAT. Die Kollegen aus der Geschäftswelt gehen fröhlich los, um das alles zu testen und auf die Knöpfe zu drücken. Sie drücken manchmal ziemlich kreativ – irgendetwas fällt aus. An dieser Stelle sollten wir herausfinden, was dafür getan wurde. Aber auf der anderen Seite des Bildschirms sitzt kein engagierter Tester, der dir alle Umgebungsparameter unter Berücksichtigung des Wetters in der Region auflisten kann, sondern der Geschäftskunde. Für ihn funktioniert es einfach nicht. Und das bedeutet, dass er unzufrieden ist. Frag ihn – und er wird extrem unzufrieden sein!

Um den Bug zu reproduzieren, müssen wir also alles durchprobieren. Natürlich haben wir keine Beschwerde unbeachtet gelassen und alles behoben. Geplante Aufgaben wurden aufgegeben, aber wir "löschen das Feuer".

So haben wir uns das nächste Loch gegraben.

Falle Nr. 2. „Stachanowarbeiter“

Es gibt einen unangenehmen Bug, der dich erreicht hat. Du versuchst, ihn zu verstehen, aber es klappt nicht — Wut kommt auf — ein weiterer Versuch, es zu klären — wieder ein Rückschlag — du klärst alles, was du kannst — es passt wieder nicht — du denkst daran, dass du alt bist, während alle anderen Kinder haben und Hypotheken abzahlen — du probierst es erneut — es ist immer noch nicht richtig. Nach ein paar Tassen Kaffee wiederholt sich alles. 12-14 Stunden Arbeit am Stück — das ist fast schon die Norm. Und dann, wenn alles an seine Grenzen stößt — zack, die Erleuchtung!

Vielleicht ist die Beurteilung der Effizienz eines solchen Tages von außen gut und richtig sichtbar. Von drinnen kann es jedoch ganz anders sein.

In meinem Fall beinhaltete der Eindruck dieser Arbeit das Gefühl: „Ich bin großartig, ich habe das gemeistert“. Nicht immer bewusst, aber unbewusst — immer!

Und daran gewöhnt man sich, ohne Witz. Es stellt sich heraus, dass die internen Erfolgsmetriken sich von den Ergebnissen auf die Anzahl der aufgebrachten Anstrengungen und das Niveau der Heldentaten verschieben, die man vollbracht hat, wie sehr man gelitten hat, während man versucht hat, das Problem zu lösen.

Wahrscheinlich ist das die schlimmste Falle.

Danach wird es leichter und fröhlicher 🙂

Falle Nr. 3. „Die Kraft von Hello World“

Unser Technologiestack aus dieser Zeit: ElasticSearch, Hazelcast, Pentaho, Freemarker (und bewährte Java, Spring, Tomcat, nginx). Freemarker gab nicht sehr informative Fehlermeldungen aus. Aber ElasticSearch, Hazelcast und Pentaho mussten wir mehrfach patchen - wir hatten ein Talent dafür, die Fälle zu finden, in denen sie nicht so funktionierten, wie es die Dokumentation vorgab.

Ein leichter Start und schnelle Vorteile durch die Nutzung neuer Technologien sind gut, aber sie führen zu Euphorie und senken die Wachsamkeit. Denn neue Technologien haben Bugs, sie enthalten definitiv Bugs. Und wenn noch nichts darüber geschrieben wurde, freuen Sie sich - Sie werden derjenige sein, der als Pionier etwas Fehlerhaftes entdeckt und dann gegoogelt oder auf Stack Overflow nachsehen muss. Sicherlich gibt es auch Fehler in bewährten Produkten, aber in neuen ist es viel einfacher, sie zu finden.

Trotz aller Schwierigkeiten sind wir in die Produktion gegangen. Ja, mit Verzögerungen. Ja, nicht sehr stabil. Aber insgesamt – ohne Katastrophen.

Ich möchte noch einmal die Fallstricke hervorheben, die die gesunde Wahrnehmung des Arbeitsprozesses verzerren.

1. »Extrapolator-Superstar«. Inspiriert von den aktuellen Erfolgen gehen wir fröhlich weiter und extrapolieren die Entwicklungsgeschwindigkeit auf bevorstehende Projekte.
2. «Stachanowiec». Wir arbeiten bis zur Erschöpfung, sind mit uns selbst zufrieden, merken jedoch nicht, dass die Probleme, die wir lösen, die Folge unserer persönlichen Fehler / Versäumnisse / Nachlässigkeiten sind. Arbeiten, die nicht erledigt werden müssen.
3. «Die Kraft von Hello World». Wir eilen, um alles Neue und Interessante in die Produktion einzuführen.

Warum es geklappt hat

Natürlich habe ich nicht alle Fehler aufgelistet, die wir in dieser Zeit gemacht haben, sondern nur die häufigsten, die für Projekte jeder Art wahrscheinlich sind. Solch eine Dokumentation von Fehlern hilft, diese in Zukunft zu vermeiden.

Ein bisschen darüber, wie es uns überhaupt gelungen ist, ein solches Mini-Startup innerhalb des Unternehmens zu gründen und das Geschäft davon zu überzeugen, von einem bereits gekauften System auf etwas Eigenes umzusteigen.

Bedingung Nr. 0. Ein gesundes Klima im Unternehmen. Es geht nicht nur um die „leuchtenden Augen“ der Mitarbeiter und Kommunikationsbereitschaft in stressigen Situationen, in denen Kekse gebacken werden; es betrifft alle Interaktionen.

Bedingung Nr. 1. An das glauben, was man tut. Im Ernst, ich glaube nicht, dass wir irgendeine Chance gehabt hätten, wenn wir uns dem Piloten widmeten, ohne das gekaufte System „bis zur letzten Schraube“ zu analysieren – das heißt, einen Schritt zurückzutreten und unbewusst zu wissen, dass dieses System besser ist und uns überlegen wird.

Was wir erreicht haben: 1) Wir haben das Kaufsystem durchdrungen und damit die wichtigsten Anforderungen des Geschäfts gelöst. 2) Wir haben eine Liste von Aufgaben erstellt, die nicht nur aktuell, sondern auch in naher Zukunft anstehen. 3) Wir haben die passendste Lösung ausgewählt. Unsere Bewertung der Lösung bestand also aus einer Experteneinschätzung.

Würden Sie uns etwas geben, wenn wir einfach gekommen wären und gesagt hätten: „Leute, das ist alles Mist, wir wollen uns damit nicht beschäftigen und machen alles von Grund auf neu“? Wahrscheinlich nicht. Die Antwort wäre in einer Form gekommen, die sich gut eingeprägt hätte 🙂

Bedingung Nr. 2. Den ersten Schritt machen wir klein. Wir generieren die erste Hypothese und überprüfen sie. Man kann dafür auch seine persönliche Zeit investieren. Wenn man seine Zeit nicht aufwenden möchte – dann sollte man sich überhaupt nicht mit so etwas befassen. Und wenn man nicht bereit ist, eine kleine Hypothese zu überprüfen, sondern sofort alles großartig und glänzend machen möchte – dann halten Sie sich von solchen Leuten fern!

Wir hatten Glück, und die erste Hypothese hat funktioniert. Aber das ist nicht immer der Fall. Zum Beispiel gab es in einem der nächsten Projekte, als wir ein Admin-Panel im Rahmen eines ähnlichen Piloten voranbrachten, nur die 18. Variante. Die ersten 17 Ansätze waren umsonst. Übrigens war die Geschichte mit der Erstellung des Admin-Panels so spannend wie brasilianische Serien, da das Team aus Jungs bestand, die zu diesem Zeitpunkt bereits Veteranen waren, echte "alte Hasen".

Bedingung Nr. 3. Wir erstellen ein MVP und identifizieren die Probleme der Entscheidungsträger. Natürlich kann sich das Entsetzen bereits in ihrem Gesicht widerspiegeln, nur weil Sie ihm zum dreißigsten Mal eine neue Idee präsentieren. Aber dennoch. Und wir zeigen unbedingt, wie wir seine Probleme mit unserem Produkt lösen.

Bedingung Nr. 4. Wir entwickeln schnell einen Prototyp, der ungefähr dem Endergebnis ähnelt. Alles perfekt zu machen ist verlockend, aber das kann in Perfektionismus enden, was bedeutet, dass Sie anstelle eines Prototyps bereits eine perfekte Produktversion zeigen wollen. Die gibt es nicht. Machen Sie es deshalb wenigstens aus etwas Unfertigem.

Bedingung Nr. 5. Produkt. Das Projekt wächst, erhält Finanzierung, und Experten mit solider Erfahrung kommen ins Team.
Und wenn Sie ein typischer Startup-Gründer sind, ist jetzt der Moment, um mit Schwung zu handeln. Denn die leichten Höhenflüge und das Gefühl allgemeinen Wohlbefindens zerstreuen sich schnell.

Der Markteintritt bedeutet, sich realen Belastungen zu stellen und sich mit zahlreichen Systemen zu integrieren. Wenn Sie neue Funktionen entwickeln, müssen Sie gleichzeitig die alten Versionen weiter unterstützen. All das sind Herausforderungen, die weit schwerwiegender sind, als lediglich eine Idee zu entwickeln und ein, auch wenn gut umgesetztes, aber nur ein Kundenproblem zu lösen.

Diese Herausforderungen ermöglichen das Wachstum Ihrer Fähigkeiten – genau in diesem Stadium.

Danke fürs Lesen. Happy New Code!

Quelle: habr.com