Cześć! Nazywam się Alexej Pjankow, jestem głównym programistą w firmie Sportmaster. Powiem od razu, że „główny” nie znaczy „najważniejszy ze wszystkich programistów”, nie, to tylko nazwa, takie urocze tłumaczenie na „Senior+”.
W firmie Sportmaster pracuję od 2012 roku i przez ten czas zespół deweloperski stworzył wiele rozwiązań, które są interesujące od strony technicznej. Ale dzisiaj chciałbym opowiedzieć o naszej pracy, zwracając uwagę raczej na to, jak myśleliśmy w określonych niejednoznacznych sytuacjach.
W tym artykule nie będzie konkretnych rozwiązań technicznych (ani w ogóle niczego technicznego), które można by chwytać i stosować w swoim projekcie. Raczej to jest refleksja nad wykonaną pracą. Były takie wyjątkowe momenty, które wpłynęły na nas jako zespół — zjednoczyły, umocniły i przetestowały na wytrzymałość. O tych momentach, o atmosferze pracy w zespole, o naszych potknięciach i pewnych pułapkach psychologicznych, w które czasami sami się wpędzamy, spróbuję dzisiaj opowiedzieć.
I zacznę właśnie od 2012 roku.
Przyszedłem w 2012 roku z głównym celem w tamtym czasie — praca nad naszą flagową stroną internetową. Wówczas to był „potwór Frankensteina”: część zespołu pracowała z naszym starym systemem, który nie radził sobie z obciążeniem (Bitrix), w drugiej części zespołu (do której należałem i ja) staraliśmy się wprowadzić nowy system, który wybraliśmy na podstawie kryterium „Skoro to najdroższa e-commerce na świecie, bierzemy ją”. Dokładnie „staraliśmy się wprowadzić” — ponieważ system zaciekle się opierał, a na każdym etapie, w którym udawało się rozwiązać jakiś problem, zawsze pojawiał się „niespodzianka” w odpowiedzi. Pracowaliśmy dużo, ale posuwaliśmy się z prędkością ślimaka.
Osobiście ostatnią kroplą była dla mnie znajomość z kodem jednej z metod w tym „najdroższym e-commerce na świecie”, gdy kilka godzin skupionej pracy nad zawiłym błędem doprowadziło do odkrycia, że przyczyna znajdowała się gdzieś w custom-tag, który działa podczas generowania HTML w JSP. Zadaniem tego custom-tag jest wyświetlenie sumy pewnych wartości. To całkiem w porządku, do tego custom-tag jest przeznaczony. Jednak niespodzianka tkwiła w tym, że przy tym zmieniały się niektóre dane w bazie, na czym opierało się zachowanie na następnych stronach, a jeśli nacisnąć F5 — wywołanie powtarzało się, co naruszało spójność danych. A co gorsza, naruszało to w taki sposób, że ujawniało się dopiero po kilku krokach, na 3. stronie sekwencji. Nie, nie mam nic przeciwko temu, aby taki „mistrz-ninja” był w zespole i swoimi kodami utrzymywał uwagę kolegów w ciągłej gotowości. Ale tak, w bibliotece najdroższej systemu!
To było w piątek. A sobotę i niedzielę spędziliśmy z kolegą w biurze, aby zrozumieć, jakie zadania biznes stawia przed systemem dzisiaj i jakie zadania może wymyślić za rok. Oczywiście, jak byśmy je rozwiązywali, gdybyśmy nie byli ograniczeni do korzystania z tego najdroższego i najbardziej irytującego systemu.
Powiedziano — zrobiono. Zrealizowaliśmy pilota, w którym położyliśmy fundament pod rozwój nowej strony Sportmaster. Wiele z tych pomysłów się przyjęło i ich kontynuacja aktualnie działa na stronie.
Etapy pilota i ramy czasowe
2 dni. Zrobiliśmy mikroprototyp — przez weekend przenosimy naszą bazę do ElasticSearch, robimy wyszukiwanie fasetowe. Voilà! W tej zakupionej systemie taka konfiguracja zajęła 2 tygodnie. A tutaj — dosłownie w kilka godzin! I działa szybciej. Co gorsza, szybciej o rząd wielkości.
2 tygodnie. „Wyciskamy” prototyp, dodajemy funkcjonalność do adekwatnych spersonalizowanych wyników.
Na przykład użytkownik ma kilka rabatów i promocji, które są aktualne tylko dla niego — wtedy w wynikach wyszukiwania produktów trzeba wyświetlić właśnie tę cenę, którą można uzyskać, stosując wszystkie dostępne bonusy w najkorzystniejszy sposób.
Z promocjami nie jest tak prosto. Na przykład, kupiłem narty, teraz na czapkę jest zniżka 40%, ale w takim przypadku anulowana jest welcome zniżka 10% na cały zamówienie. Tak, to prawdziwy przypadek 🙂 A żeby ustawić taką promocję w systemie zakupowym, zapłacono za 3 konsultacje z dostawcą, w wyniku których otrzymaliśmy wiele przykładów, jak zrobić różne inne promocje. Bardzo dyplomatycznie i, biorąc pod uwagę koszt konsultacji — bardzo dobrze pod względem ekonomicznym.
Pokazaliśmy firmie szczegółową demonstrację. Obiecali szybko zbudować pilota i od razu przystąpili do działania.
2 miesiące. Pilotażowy projekt — robimy w formie żywej strony z wyszukiwarką w katalogu. Wyszukiwanie z facetami, wyniki wyszukiwania — z osobistymi zniżkami, wygląda jak portal Sportmaster, a produkty, które wrzuciliśmy, są te same. Cudo!
Dodajemy "Krasnorcie:100" naszego szefa działu, a prezentacja dla biznesu przebiega na Hurra! Dajemy carte blanche do samodzielnego opracowania platformy eCommerce.
A to oznacza, trzymajcie, chłopaki, zespół, trzymajcie, chłopaki, budżet. Fajnie, prawda?
2 lata. Wprowadzenie strony do produkcji. Tak, długo. Wszystko, co wtedy umieliśmy, próbowaliśmy tylko w skali prototypu. Dwóch ludzi łatwo tworzy zgrany zespół. A zadania, które "odhaczaliśmy" — w zasadzie to były małe poprawki "Hello World" w nowych technologiach. Łatwo generowaliśmy nowe hipotezy, szybko je testowaliśmy, nie zdążaliśmy się przywiązywać i dlatego bez żalu je "zabijaliśmy". Gdy było nas 10, z momentum ekstrapolowaliśmy naszą prędkość pracy na wszystkich innych. I obiecaliśmy takie terminy wykonania zadań, które odpowiadają wizji piękna pomnożonej przez nasz entuzjazm.
Znajoma sytuacja? 🙂
Więc, już wiecie, co będzie dalej?
Pułapka nr 1. "Ekstrapolator"
Jasne, że nowe technologie wyglądają bardzo dobrze w prezentacjach i świetnie pokazują się w aplikacji typu "Hello World". Ale rzeczywistość zazwyczaj jest trochę dalej od tego.
Więc. Bierzemy bibliotekę, piszemy mnóstwo aplikacyjnego kodu. Testy jednostkowe uważamy za ciężar (jesteśmy tacy fajni i pracujemy na nadświetlnych prędkościach, kod nowoczesny i tak dalej). Stale zmieniamy i dopracowujemy API w trakcie — no jakie tutaj testy, na serio. I to wszystko pod sztandarem "świetnie zoptymalizowaliśmy proces tworzenia" (tak, teraz nawet strach to opisywać).
A potem wszystko jest dość oczywiste.
Wypuszczamy nową wersję na uat. Chłopaki z biznesu z zapałem testują wszystko i naciskają przyciski. Czasami robią to dość kreatywnie — coś przestaje działać. Warto by się dowiedzieć, co w tej sprawie zrobiono. Ale po drugiej stronie monitora nie ma nawykowego testera, który dostarczy ci wszystkich charakterystyk środowiska z uwzględnieniem pogody w regionie, lecz klienta z biznesu. On po prostu mówi, że "nie działa". A to oznacza, że jest niezadowolony. Zapytasz go — i on będzie strasznie niezadowolony!
Wtedy, aby odtworzyć błąd, trzeba przejść i w każdą rzecz klikać na chybił trafił. Oczywiście, nie zignorowaliśmy żadnej skargi i wszystko naprawialiśmy. Zarzucaliśmy zaplanowane zadania, ale "gasić pożar".
Tak wygrzebaliśmy sobie kolejną pułapkę.
Pułapka nr 2. „Stachanowiec”
Przyleciał do ciebie nieprzyjemny błąd. Zaczynasz się rozglądać. Nie udaje się — złość — kolejna próba zrozumienia — kolejna porażka — wyjaśniasz wszystko, co można — znowu nie to — myślisz o tym, że jesteś już stary, a wszyscy mają dzieci i kredyty — próbujesz ponownie — znów nie to. Kilka kubków kawy, i wszystko powtarza się. 12-14 godzin pracy bez przerwy — prawie jak norma. I wtedy, kiedy wszystko jest już na granicy — bach, olśnienie!
Możliwe, że z zewnątrz ocena skuteczności takiego dnia jest widoczna i poprawna. Z wnętrza — może być różnie.
W moim przypadku wrażenie z takiej pracy zawierało „Jestem świetny, dałem radę, rozwiązałem problem”. Nie zawsze świadomie, ale podświadomie — zawsze!
I na to się uzależniasz, nie żartuję. Okazuje się, że wewnętrzne metryki sukcesu przesuwają się z wyniku na liczbę włożonych wysiłków oraz poziom tego, jakie wyczyny popełniłeś, jak bardzo cierpiałeś, próbując rozwiązać zadanie.
Pewnie, to najstraszniejsza pułapka.
Dalej będzie łatwiej i weselej 🙂
Pułapka nr 3. „Siła Hello world”
Nasz zestaw technologii z tamtego okresu: ElasticSearch, Hazelcast, Pentaho, freemarker (i sprawdzone Java, Spring, Tomcat, nginx). Freemarker niezbyt informacyjnie przekazywał komunikaty o błędach. Z kolei ElasticSearch, Hazelcast, Pentaho musieliśmy patchować kilka razy — talentem znajdowaliśmy przypadki, w których działały nie tak, jak określała dokumentacja.
Łatwe rozpoczęcie i szybkie korzyści z użycia nowej technologii to jedno, ale wprowadzają one w euforię i zmniejszają czujność. Ponieważ nowa technologia zawiera błędy, z pewnością zawiera błędy. A jeśli nikt o nich jeszcze nie napisał – ciesz się, to właśnie Ty zostaniesz pionierem, który na pewno odkryje coś wadliwego i pójdzie szukać w Google lub na SO. Oczywiście, „wadliwość” można znaleźć w sprawdzonych produktach, ale w nowych – jest to znacznie łatwiejsze.
Mimo wszystkich trudności weszliśmy do produkcji. Tak, z opóźnieniami. Tak, nie bardzo stabilnie. Ale ogólnie rzecz biorąc – bez katastrof.
Jeszcze raz podkreślę pułapki, w których zniekształcone jest zdrowe postrzeganie procesu pracy.
- „Ekstrapolator-superbohater”. Pod wpływem obecnych sukcesów idziemy naprzód i radośnie ekstrapolujemy prędkość rozwoju na nadchodzące projekty.
- „Stachanowiec”. Pracujemy na pełnych obrotach, jesteśmy z siebie zadowoleni, ale nie dostrzegamy, że problemy, które rozwiązujemy – to konsekwencje naszych osobistych błędów/niedociągnięć/zlekceważenia. Prace, których nie należy wykonywać.
- „Siła Hello world”. Pośpiesznie wprowadzamy do produkcji wszystko, co nowe i interesujące.
Dlaczego wszystko się udało
Oczywiście, wymieniłem nie wszystkie błędy, które mieliśmy w tym czasie, ale te najbardziej ogólne, prawdopodobne dla projektu dowolnej specyfiki. Tego rodzaju rejestr błędów pomaga unikać ich w przyszłości.
Kilka słów o tym, jak w ogóle udało nam się stworzyć taki mini-startup w firmie i przekonać biznes do zrezygnowania z już zakupionego systemu na coś własnego, napisanego od podstaw.
Warunek nr 0. Zdrowy klimat w firmie. To nie tylko „płonące oczy” pracowników i komunikatywność w stresujących warunkach produkcji ciasteczek, nie. To wszystko interakcje.
Warunek nr 1. Wierzyć w to, co się robi. Poważnie, nie sądzę, że mielibyśmy jakiekolwiek szanse, gdybyśmy zajęli się pilotem, nie rozbierając zakupionego systemu „do śrubki” – to znaczy, ustępując i podświadomie wiedząc, że ten system jest lepszy i pokona nas.
Co zrobiliśmy: 1) zrozumieliśmy zakupiony system, z jego pomocą rozwiązaliśmy podstawowe potrzeby biznesowe 2) sporządziliśmy listę zadań, które istnieją teraz i będą w niedalekiej przyszłości 3) wybraliśmy rozwiązanie, które najlepiej pasuje. A więc, nasza ocena rozwiązania – to była ocena ekspertów.
Czy daliby nam coś, gdybyśmy po prostu przyszli i powiedzieli: "chłopaki, wszystko do kitu, nie chcemy się tym zajmować i postanowiliśmy zbudować swoje od podstaw"? Mało prawdopodobne. Odpowiedź otrzymalibyśmy w takiej formie, że dobrze by to zapadło w pamięć 🙂
Warunek nr 2. Zaczynamy od małego kroku. Generujemy pierwszą hipotezę i sprawdzamy. Można na to poświęcić swój osobisty czas. Jeśli nie chce się tracić swojego czasu — to w ogóle nie ma sensu zabierać się za takie przedsięwzięcie. A jeśli nie chce się sprawdzać małej hipotezy, a od razu zrobić coś świetnego i z blaskiem — trzymajcie się z daleka od takich ludzi!
Mieliśmy szczęście i zadziałała nasza pierwsza hipoteza. Ale tak nie jest zawsze. Na przykład, w jednym z kolejnych projektów, gdy promowaliśmy panel administracyjny w ramach podobnego pilota, zadziałała tylko 18. wersja. A 17 pierwszych podejść do tematu okazało się bezowocnych. Swoją drogą, w historii tworzenia panelu administracyjnego zwroty akcji były na poziomie brazylijskich seriali, ponieważ zespół składał się z chłopaków, którzy w tym czasie byli już weteranami, prawdziwymi "wyjadaczami".
Warunek nr 3. Tworzymy MVP i szukamy bolączek u osoby podejmującej decyzje. Oczywiście, na jej twarzy może już odzwierciedlać się przerażenie na samą myśl, że po raz trzydziesty przynosicie jej jakiś pomysł. Ale mimo wszystko. I koniecznie pokazujemy, jak dokładnie rozwiązujemy jej problemy naszym produktem.
Warunek nr 4. Na kolanie szybko robimy pilota, który wygląda mniej więcej jak finalny wynik. Zrobienie wszystkiego super — kusi, ale można wpaść w perfekcjonizm, przez który zamiast pilota chcecie pokazać już idealną wersję produktu. A takich nie ma. Dlatego po prostu zróbcie cokolwiek, nawet byle jakie.
Warunek nr 5. Produkt. Projekt rośnie, zdobywa finansowanie, przychodzą specjaliści z solidnym doświadczeniem.
I jeśli jesteś klasycznym startupowcem, to właśnie ten moment, kiedy trzeba szybko uciekać. Bo łatwe loty na samym szczycie i uczucie ogólnej błogości szybko się rozpływają.
Wejście na rynek to zderzenie z realnymi obciążeniami, integracja z dziesiątkami systemów, a kiedy tworzysz nową funkcjonalność, to jednocześnie, w ramach wsparcia dopracowujesz stare wersje. Wszystko to — wyzwania znacznie poważniejsze niż wymyślenie pomysłu i rozwiązanie przynajmniej jednej, a nawet dobrze, ale tylko jednej, problemu klienta.
To są wyzwania, a rozwój umiejętności — odbywa się właśnie na tym etapie.
Dziękuję za przeczytanie. Szczęśliwego Nowego Kodu!
Źródło: habr.com
