Hallo! Ich heiße Alexey Pjankov, ich bin der Hauptprogrammierer bei der Firma Sportmaster. Ich sage gleich, dass „Haupt-“ nicht „der wichtigste unter allen Programmierern“ bedeutet, nein, das ist nur eine Bezeichnung, so eine charmante Übersetzung für „Senior+“.
Bei Sportmaster arbeite ich seit 2012, und in dieser Zeit hat unser Entwicklungsteam viele interessante technische Lösungen geschaffen. Heute möchte ich jedoch über unsere Arbeit berichten, wobei ich eher darauf eingehen möchte, wie wir in bestimmten mehrdeutigen Situationen nachgedacht haben.
In diesem Artikel wird es keine konkreten technischen Lösungen geben (überhaupt nichts Technisches), die man einfach übernehmen und in eigenen Projekten anwenden sollte. Vielmehr handelt es sich um eine Reflexion über die geleistete Arbeit. Es gab besondere Momente, die uns als Team geprägt haben – uns zusammengeschweißt, gehärtet und auf die Probe gestellt. Über diese Momente, die Arbeitsatmosphäre im Team, unsere Stolpersteine und eine Reihe psychologischer Fallen, in die wir uns manchmal selbst treiben, möchte ich heute berichten.
Ich beginne genau im Jahr 2012.
Ich kam 2012 mit dem Hauptziel, an unserer Flagship-Website zu arbeiten. Damals war es ein 'Frankenstein-Monster': Ein Teil des Teams arbeitete mit unserem alten System, das mit den Lasten nicht besonders gut zurechtkam (Bitrix), während ein anderer Teil des Teams (zu dem auch ich gehörte) versuchte, ein neues System einzuführen, das wir nach dem Kriterium 'Da dies die teuerste E-Commerce-Lösung der Welt ist, nehmen wir sie' ausgewählt hatten. Wir 'versuchten es einzuführen' – denn das System wehrte sich verzweifelt, und auf jedes Problem, das wir lösen konnten, folgte unbedingt eine 'Überraschung' als Antwort. Wir arbeiteten viel, kamen aber nur langsam voran.
Für mich war das letzte Tropfen das Kennenlernen des Codes einer Methode in diesem "teuersten E-Commerce der Welt", als mehrere Stunden konzentrierte Arbeit an einem verworrenen Bug dazu führten, dass die Ursache irgendwo im Custom-Tag gefunden wurde, das bei der Generierung von HTML in JSP verarbeitet wird. Die Aufgabe dieses Custom-Tags ist es, die Summe bestimmter Größen darzustellen. Das ist nicht schlecht, dafür sind diese Custom-Tags ja gedacht. Doch die Überraschung verbarg sich darin, dass dabei einige Daten in der Datenbank geändert wurden, was das Verhalten auf den folgenden Seiten beeinflusste, und wenn man F5 drückte, wurde der Aufruf wiederholt, was die Konsistenz der Daten störte. Dabei trat die Störung nur nach mehreren Schritten auf, auf der 3. Seite der Sequenz. Nein, ich habe nichts dagegen, dass ein solcher "Ninja-Meister" im Team ist und seine Kollegen mit seinem Code aufmerksam hält. Aber so einfach in der Bibliothek der teuersten System!
Es war Freitag. Am Samstag und Sonntag verbrachten mein Kollege und ich im Büro mit dem Ziel herauszufinden, welche Aufgaben das Geschäft heute der System stellt und welche Aufgaben es sich in einem Jahr ausdenken könnte. Entsprechend überlegten wir uns, wie wir diese lösen würden, wenn wir nicht in die Rahmenbedingungen des Gebrauchs dieses teuersten und lästigsten Systems gezwängt wären.
Gesagt, getan. Wir haben ein Pilotprojekt gestartet, in dem wir das Fundament für die Entwicklung der neuen Sportmaster-Website gelegt haben. Viele dieser Ideen haben sich durchgesetzt und deren Fortsetzung dreht sich gerade aktiv auf der Website.
Phasen des Piloten und zeitliche Rahmenbedingungen
2 Tage. Wir haben einen Mikroprototyp erstellt — über das Wochenende migrieren wir unsere Datenbank nach ElasticSearch und implementieren die facettierte Suche. Voilà! Bei diesem käuflichen System hat eine solche Konfiguration 2 Wochen gedauert. Hier geschah es in nur wenigen Stunden! Und es funktioniert sogar schneller. Und zwar um ein Vielfaches schneller.
2 Wochen. Wir "bauen" einen Prototypen, fügen funktionale Elemente für eine angemessene personalisierte Ausgabe hinzu.
Wenn der Benutzer beispielsweise mehrere Rabatte und Aktionen hat, die speziell für ihn gelten — dann muss im Suchergebnis für die Produkte genau der Preis angezeigt werden, den man erhält, wenn man alle verfügbaren Vorteile auf die vorteilhafteste Weise anwendet.
Mit den Aktionen ist es nicht ganz so einfach. Zum Beispiel habe ich Skier gekauft, jetzt gibt es 40 % Rabatt auf die Mütze, aber gleichzeitig entfällt der Willkommensrabatt von 10 % auf die gesamte Bestellung. Ja, das ist ein echter Fall 🙂 Und um so eine Aktion im Einkaufssystem einzurichten, wurden 3 Beratungen mit dem Lieferanten bezahlt, aus denen wir viele Beispiele erhalten haben, wie man verschiedene andere Aktionen durchführt. Sehr diplomatisch und, angesichts der Kosten für die Beratungen - wirtschaftlich sehr vorteilhaft.
Wir haben dem Unternehmen eine detaillierte Demo gezeigt. Wir haben versprochen, den Pilotprojekt schnell zusammenzustellen und sofort mit der Arbeit begonnen.
2 Monate. Das Pilotprojekt - wir machen es in Form einer lebenden Website mit einer Katalogsuche. Suche mit Facetten, Suchergebnisse - mit persönlichen Rabatten, das Pilotprojekt sieht nahezu aus wie die Website von Sportmaster, und die Produkte haben wir dieselben hochgeladen. Eine wahre Freude!
Wir fügen "Красноречие:100" unseres Abteilungsleiters hinzu, und die Präsentation für das Unternehmen läuft mit Bravour! Wir bekommen das grüne Licht, um die eCommerce-Plattform selbst zu entwickeln.
Und das bedeutet, haltet euch fest, Jungs, hier ist euer Team, haltet euch fest, Jungs, hier ist euer Budget. Ist das nicht großartig!
2 Jahre. Die Veröffentlichung der Website in Produktion. Ja, es hat lange gedauert. Alles, was wir damals konnten, haben wir nur im Rahmen des Prototyps getestet. Zwei Personen bilden leicht ein eingespieltes Team. Und die Aufgaben, die wir "abarbeiteten" - im Grunde genommen waren das kleine Nachbesserungen von "Hello World" in neuen Technologien. Wir haben leicht neue Hypothesen generiert, sie schnell getestet, haben uns nicht festgebunden und daher ohne Bedauern "getötet". Als wir 10 Personen wurden, extrapolierten wir träge unsere Arbeitsgeschwindigkeit auf alle anderen. Und versprachen solche Fristen für die Aufgaben, die gleich dem Ideal multipliziert mit unserem Enthusiasmus waren.
Kommt Ihnen die Situation bekannt vor? 🙂
Wissen Sie also schon, was als Nächstes kommt?
Falle Nr. 1. "Extrapolationsguru"
Klar ist, dass neue Technologien in Präsentationen sehr cool aussehen und sich hervorragend in der Anwendung von "Hello World" präsentieren. Aber die Realität ist in der Regel etwas weiter davon entfernt.
Also. Wir nehmen eine Bibliothek, schreiben eine Menge Anwendungscode. Unit-Tests empfinden wir als Belastung (wir sind doch cool und arbeiten hier im Überschall, der Code ist modern und so weiter). Ständig ändern und überarbeiten wir die API im Vorbeigehen - na, welche Tests gibt es hier, ernsthaft. Und das alles unter dem Banner "wir haben den Entwicklungsprozess cool optimiert" (ja, es ist jetzt sogar gruselig, das zu beschreiben).
Und dann wird alles ziemlich offensichtlich.
Wir bringen ein neues Build auf uat heraus. Die Leute aus der Wirtschaft sind eifrig dabei, alles zu testen und zu klicken. Manchmal drücken sie ziemlich kreativ — es fallen Dinge aus. Hier wäre es gut, zu erfahren, was dagegen unternommen wurde. Aber auf der anderen Seite des Bildschirms sitzt kein verrückter Tester, der dir alle Umgebungsbedingungen unter Berücksichtigung des Wetters in der Region auflistet, sondern ein Kunde aus dem Geschäft. Er sagt einfach: "es funktioniert nicht." Das bedeutet, er ist unzufrieden. Frag ihn — und er wird grauenhaft unzufrieden sein!
Um den Fehler zu reproduzieren, muss man also ran und alles durchprobieren. Natürlich haben wir keines der Beschwerden ignoriert und alles behoben. Wir haben unsere geplanten Aufgaben aufgegeben, um "Feuer zu löschen".
So haben wir uns das nächste Loch gegraben.
Falle Nr. 2. "Stachanovet"
Ein unangenehmer Bug ist aufgetaucht. Du versuchst, dich damit auseinanderzusetzen. Es funktioniert nicht — Wut — Versuch es noch einmal — ein weiterer Misserfolg — du klärst alles, was du kannst — wieder stimmt es nicht — denkst darüber nach, dass du schon alt bist und alle Kinder und Hypotheken haben — versuchst es wieder — es funktioniert wieder nicht. Ein paar Tassen Kaffee, und alles wiederholt sich. 12-14 Stunden am Stück — fast wie die Norm. Und dann, wenn alle am Limit sind — bam, Erleuchtung!
Von außen erscheint die Bewertung der Effizienz eines solchen Tages gut und richtig. Aber von innen kann es ganz anders sein.
In meinem Fall enthielt der Eindruck solcher Arbeit das Gefühl: "Ich bin großartig, ich habe es geschafft." Nicht immer bewusst, aber unbewusst — immer!
Und darauf lässt man sich dann ohne Scherz ein. Es zeigt sich, dass sich die internen Metriken des Erfolgs von den Ergebnissen auf die Menge der geleisteten Anstrengungen und das Niveau der Heldentaten verschieben, die du vollbracht hast, wie sehr du gelitten hast, während du versuchst, 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 informativ Meldungen über Fehler aus. ElasticSearch, Hazelcast, Pentaho mussten wir jedoch mehrmals patchen — wir fanden geschickt Fälle, in denen sie nicht so funktionierten, wie es die Dokumentation vorschreibt.
Ein leichter Einstieg und schnelle Erfolge aus der Nutzung neuer Technologien sind gut, aber sie verleiten zur Euphorie und verringern die Wachsamkeit. Denn neue Technologien enthalten Bugs, sie enthalten definitiv Bugs. Und wenn noch nicht über sie geschrieben wurde, freue dich, genau du wirst derjenige sein, der sicher etwas Unsauberes ausgräbt und anfangen wird, Googlesuche oder SO zu nutzen. Natürlich kann man "Unsauberes" auch in bewährten Produkten finden, aber bei neuen ist es viel einfacher.
Trotz aller Schwierigkeiten sind wir in die Produktion gegangen. Ja, mit Lag. Ja, nicht sehr stabil. Aber insgesamt — ohne Katastrophen.
Ich möchte noch einmal die Fallen hervorheben, in denen die gesunde Wahrnehmung des Arbeitsprozesses verzerrt wird.
- "Der super Extrapolator". Unter dem Eindruck der aktuellen Erfolge gehen wir voran und extrapolieren fröhlich die Geschwindigkeit der Entwicklung auf bevorstehende Projekte.
- "Der Stachanovist". Wir arbeiten bis zur Erschöpfung, sind mit uns selbst zufrieden, bemerken jedoch nicht, dass die Probleme, die wir lösen, die Folge unserer eigenen Fehler/Mängel/Nichtbeachtungen sind. Arbeiten, die nicht getan werden dürfen.
- "Die Kraft von Hello World". Wir beeilen uns, alles Neueste und Interessante in die Produktion einzuführen.
Warum es gelungen ist
Natürlich habe ich nicht alle Fehler aufgezählt, die wir in dieser Zeit gemacht haben, aber die häufigsten, die für ein Projekt jeder Spezifik angängig sind. Eine solche Fixierung der Fehler hilft, sie in Zukunft zu vermeiden.
Ein wenig darüber, wie es uns gelungen ist, innerhalb des Unternehmens ein so kleines Startup zu gründen und das Geschäft davon zu überzeugen, von einem bereits gekauften System auf etwas Eigenes zu wechseln.
Bedingung Nr. 0. Ein gesundes Klima im Unternehmen. Das sind nicht nur die "glühenden Augen" der Mitarbeiter und ihre Kommunikationsfähigkeit unter stressigen Bedingungen, um Kekse zu bekommen, nein. Es geht um alle Interaktionen.
Bedingung Nr. 1. An das glauben, was man tut. Ernsthaft, ich glaube nicht, dass wir irgendeine Chance gehabt hätten, wenn wir mit dem Pilotprojekt begonnen hätten, ohne das gekaufte System "bis zur Schraube" auseinanderzunehmen — das heißt, zurückzutreten und unterbewusst zu wissen, dass dieses System besser ist und uns übertreffen wird.
Was wir gemacht haben: 1) Wir haben das gekaufte System verstanden und damit die Hauptanforderungen des Geschäfts gelöst. 2) Wir haben eine Liste von Aufgaben erstellt, die nicht nur jetzt bestehen, sondern auch in absehbarer Zeit anfallen werden. 3) Wir haben die Lösung ausgewählt, die am besten geeignet ist. Und so war unsere Bewertung der Lösung die Bewertung von Experten.
Würden sie uns etwas geben, wenn wir einfach kämen und sagen würden: „Leute, das ist alles Mist, wir wollen uns damit nicht auseinandersetzen und haben beschlossen, alles von Grund auf neu zu machen“? Eher nicht. Zudem würden wir die Antwort in einer Form erhalten, die man sich gut merkt 🙂
Bedingung Nr. 2. Den ersten Schritt machen wir klein. Wir generieren die erste Hypothese und überprüfen sie. Man kann dafür auch seine eigene Zeit nutzen. Wenn man keine Zeit verschwenden möchte, sollte man sich besser nicht an so ein Projekt heranwagen. Und wenn man nicht die kleine Hypothese überprüfen möchte, sondern sofort etwas Großes und Glänzendes machen will – dann halte dich besser von solchen Leuten fern!
Wir hatten Glück, und die allererste Hypothese hat funktioniert. Aber das passiert nicht immer. Zum Beispiel haben wir in einem der nächsten Projekte, als wir die Admin-Oberfläche im Rahmen eines ähnlichen Pilotprojekts vorantrieben, nur auf die 18. Variante erfolgreich angesprochen. Die ersten 17 Ansätze waren umsonst. Übrigens waren die Wendungen in der Geschichte der Erstellung der Admin-Oberfläche auf dem Niveau brasilianischer Seifenopern, weil das Team aus Jungs bestand, die zu diesem Zeitpunkt schon Veteranen waren, echte „alte Hasen“.
Bedingung Nr. 3. Wir erstellen ein MVP und suchen nach den Schmerzen der entscheidenden Person. Natürlich könnte sich schon der Ausdruck in seinem Gesicht gruselig verändern, nur weil Sie ihm bereits zum dreißigsten Mal irgendetwas vorschlagen. Aber trotzdem. Und unbedingt zeigen wir, wie genau wir seine Probleme mit unserem Produkt lösen.
Bedingung Nr. 4. Schnell basteln wir einen Prototypen, der aussieht ungefähr wie das endgültige Ergebnis. Alles perfekt zu machen ist verlockend, aber man könnte in den Perfektionismus verfallen, sodass man statt eines Prototyps bereits eine perfekte Version des Produkts zeigen möchte, was es nicht gibt. Also macht einfach zumindest etwas aus Stöcken.
Bedingung Nr. 5. Produkt. Das Projekt wächst, erhält finanzielle Mittel, und Experten mit solider Erfahrung kommen.
Und wenn Sie ein klassischer Startup-Gründer sind, ist das der Moment, in dem Sie schleunigst verschwinden sollten. Denn die leichten Flüge über alles und das Gefühl der allgemeinen Wohltätigkeit verfliegen schnell.
Der Gang in die Produktion ist eine Konfrontation mit realen Lasten, die Integration mit einem Dutzend Systeme, wobei man beim Erstellen neuer Funktionen gleichzeitig die alten Versionen weiterentwickelt. All das sind Herausforderungen, die viel ernster sind als nur eine Idee zu entwickeln und, wenn auch gut, aber nur ein einziges Problem des Kunden zu lösen.
Diese Herausforderungen und das Wachstum der Fähigkeiten erfolgen genau in diesem Stadium.
Vielen Dank fürs Lesen. Happy New Code!
Quelle: habr.com
