Hallo! Mijn naam is Alexey Pyankov, ik ben de hoofduitvoerder bij Sportmaster. Laat me je vertellen, dat 'hoofd' niet betekent 'de belangrijkste van alle uitvoerders', nee, het is alleen maar een benaming, een charmante vertaling voor 'Senior+'.
Bij Sportmaster werk ik sinds 2012, en in die tijd heeft het ontwikkelingsteam veel technische oplossingen bedacht. Maar vandaag wil ik het hebben over ons werk met de nadruk op de manier waarop we dachten in bepaalde ambiguĂŻteitsituaties.
In dit artikel zullen geen specifieke technische oplossingen worden gepresenteerd (en eigenlijk niets technisch) dat je zomaar in je eigen project kunt toepassen. Het is eerder een reflectie op het werk dat we hebben verzet. Er waren enkele bijzondere momenten die ons als team beĂŻnvloedden â die ons verenigden, versterkten en op de proef stelden. Over deze momenten, de sfeer in het team, onze valkuilen en een aantal psychologische valstrikken waar we onszelf soms in betrekken, wil ik vandaag proberen te vertellen.
En ik begin precies in 2012.
Ik kwam in 2012 met het hoofddoel op dat moment â werken aan onze vlaggenschipwebsite. Toen was het een 'Frankenstein-monster': een deel van het team werkte met ons oude systeem, dat niet echt goed omging met de belasting (Bitrix), terwijl een ander deel van het team (waaronder ik) probeerde een nieuw systeem te implementeren dat was gekozen op basis van het criterium 'Aangezien dit het duurste e-commerce systeem ter wereld is, nemen we het'. Het was echt 'proberen te implementeren' â omdat het systeem zich wanhopig verzet, en op elk moment dat we dachten het opgelost te hebben, kwam er altijd een 'verrassing' als antwoord. We werkten hard, maar vorderden met de snelheid van een slak.
Voor mij was de laatste druppel de kennismaking met de code van een bepaalde methode in dit 'duurste e-commerce systeem ter wereld', toen enkele uren geconcentreerd werken aan een ingewikkelde bug leidde tot de ontdekking dat de oorzaak ergens lag in een custom-tag, die wordt uitgevoerd tijdens de generatie van HTML in JSP. De taak van deze custom-tag is het weergeven van de som van bepaalde waarden. Dat is op zich niet slecht, daarvoor zijn custom-tags bedoeld. Maar de verrassing lag in het feit dat daarbij bepaalde gegevens in de database worden gewijzigd, wat het gedrag op volgende pagina's beĂŻnvloedt, en als je op F5 drukt â wordt de oproep herhaald, wat de consistentie van de gegevens schendt. Bovendien manifesteert dit zich pas na enkele stappen, op de derde pagina van de volgorde. Nee, ik ben er niet tegen dat zo'n 'master ninja' in het team zit en zijn code de aandacht van collega's scherp houdt. Maar zoiets in de bibliotheek van het duurste systeem!
Het was vrijdag. Zaterdag en zondag hebben mijn collega en ik op kantoor doorgebracht om te begrijpen welke taken het bedrijf vandaag aan het systeem stelt en welke taken we over een jaar zouden kunnen bedenken. Uiteraard, hoe zouden we deze taken oplossen, als we niet vastzaten aan het gebruik van datzelfde dure en irritante systeem.
Gezegd â gedaan. We hebben een pilot gemaakt waarin we de fundering hebben gelegd voor de ontwikkeling van de nieuwe Sportmaster-website. Veel van deze ideeĂ«n zijn een succes gebleken en hun voortzetting draait momenteel actief op de site.
Fases van de pilot en tijdslijnen
2 dagen. We hebben een microprototype gemaakt â in het weekend hebben we onze database naar ElasticSearch gemigreerd, en faceted search opgezet. VoilĂ ! In datzelfde aangekochte systeem kostte zo'n configuratie 2 weken. En hier â letterlijk in een paar uur! Het werkt bovendien sneller. En met een aanzienlijke snelheid.
2 weken. We 'bouwen' het prototype en voegen functionaliteit toe voor een adekwate gepersonaliseerde output.
Bijvoorbeeld, als een gebruiker verschillende kortingen en acties heeft die specifiek voor hem gelden â dan moet in de zoekresultaten van de producten precies die prijs worden weergegeven die kan worden verkregen door alle beschikbare voordelen op de meest voordelige manier toe te passen.
Met aanbiedingen is het niet zo eenvoudig. Bijvoorbeeld, je koopt een paar ski's en krijgt 40% korting op een muts, maar de welkomstkorting van 10% op de hele bestelling vervalt. Ja, dit is een echte case đ En om zo'n aanbieding te configureren in het aankoopsysteem, zijn er 3 consultaties met de leverancier betaald, waaruit we veel voorbeelden hebben gehaald van hoe verschillende andere aanbiedingen te maken. Heel diplomatiek en, rekening houdend met de kosten van de consultaties, economisch gezien best goed.
We hebben de zakelijke demo in detail getoond. Ze beloofden snel een pilot op te zetten en gingen meteen aan de slag.
2 maanden. Het pilotproject â we maken het in de vorm van een live website met cataloguszoekfunctie. Zoekfunctie met facetten, zoekresultaten â met persoonlijke kortingen, de pilot lijkt bijna op de website van Sportmaster, en de producten die we hebben uploaden zijn dezelfde. Heerlijk!
We voegen âRetoriek:100â van onze afdelinghoofd toe, en de presentatie aan het bedrijf gaat als een trein! We krijgen carte blanche om zelf een eCommerce-platform te ontwikkelen.
En dat betekent, jongens, houdt het team bij elkaar, houdt het budget in de gaten. Geweldig, toch!
2 jaar. De website gaat live. Ja, het heeft lang geduurd. Alles wat we toen konden, hebben we alleen op prototypen getest. Twee mensen vormen gemakkelijk een goed teamsamenhang. En de taken die we 'afwerkten' - dat waren in wezen kleine verbeteringen van 'Hello World' in nieuwe technologieën. We genereerden gemakkelijk nieuwe hypotheses, testten ze snel, raakten ze niet gehecht en daarom 'vermoorden' we ze zonder spijt. Toen we met 10 mensen waren, extrapoleerden we onze werktempo ineen keer naar de rest. We beloofden ook zulke termijnen voor het uitvoeren van taken, die gelijk waren aan ons idee van het perfecte, vermenigvuldigd met onze enthousiasme.
Herkenbaar, nietwaar? đ
Dus, weten jullie al wat er daarna gaat gebeuren?
Valstrik #1. 'De super-extrapoleerder'
Het is duidelijk dat nieuwe technologieën er geweldig uitzien in presentaties en uitstekend presteren in een Hello World-toepassing. Maar de realiteit ligt meestal iets verder van dit.
Dus. We nemen een bibliotheek, schrijven een hoop toepasselijke code. Eenheidstests beschouwen we als een last (we zijn tenslotte geweldig en werken hier supersnel, moderne code en zo). We passen de API constant aan â welke tests, serieus? En dit alles onder het mom van âwe hebben het ontwikkelingsproces fantastisch geoptimaliseerdâ (ja, het is zelfs beangstigend om dit nu te beschrijven).
En dan is het allemaal vrij duidelijk.
We are rolling out a new build on uat. The business team is enthusiastically testing everything and clicking buttons. Sometimes they click quite creativelyâsomething breaks. Here, you would want to find out what was done about it. But on the other side of the monitor, it's not a worn-out tester who will give you all the environment specifications, taking the regional weather into account, but a business client. They simply say, 'it's not working.' And that means they are unhappy. Ask them, and they will be terrified unhappy!
So, to reproduce the bug, you have to go and try everything one by one. Of course, we did not ignore a single complaint and fixed everything. We abandoned planned tasks but were 'putting out fires.'
This is how we dug ourselves the next little pit.
Trap No. 2. 'Stakhanovite'
A rather unpleasant bug has arrived. You start to figure it out. No successâfuryâattempt to sort it out againâanother failureâyou clarify everything possibleâstill not rightâyou think about how you are already old and everyone has kids and mortgagesâyou try againâstill not right. A few cups of coffee later, and it all repeats. 12-14 hours of continuous workâalmost normal. And just when everything is at the limitâboom, an epiphany!
From the outside, the assessment of the effectiveness of such a day may seem good and correct. But from the inside, it can be quite different.
In my case, the impression from such work contained 'I did well, I'm cool, I handled it.' Not always consciously, but unconsciouslyâalways!
And you really get hooked on this, no kidding. It turns out that internal metrics of success shift from results to the amount of effort applied and the level of heroic deeds you accomplished, how much you suffered trying to solve a task.
Perhaps this is the scariest trap.
It will get easier and more fun from here đ
Trap No. 3. 'The Power of Hello World'
Our tech stack during that period included: ElasticSearch, Hazelcast, Pentaho, freemarker (and proven Java, Spring, Tomcat, nginx). Freemarker didn't provide very informative error messages. However, we had to patch ElasticSearch, Hazelcast, and Pentaho several timesâwe creatively found cases where they did not work as specified in the documentation.
Een snelle start en de positieve effecten van nieuwe technologieĂ«n zijn goed, maar ze kunnen ook euforisch maken en ons waakzaamheidsgevoel verlagen. Nieuwe technologie bevat altijd bugs, absoluut altijd. En als ze nog niet ontdekt zijn â wees blij, jij bent degene die vroeg of laat iets vreemds zal tegenkomen en gaat googelen of op Stack Overflow kijken. Natuurlijk, je kunt 'vreemd' tegenkomen in bewezen producten, maar bij nieuwe is dat veel eenvoudiger.
Ondanks alle uitdagingen zijn we live gegaan. Ja, met lag. Ja, niet erg stabiel. Maar over het algemeen â zonder catastrofes.
Nogmaals wil ik de valkuilen benoemen die een vertekend beeld van het werkproces geven.
- «De super extrapoleerder». Onder invloed van onze huidige successen gaan we verder en extrapoleren we vrolijk de ontwikkelsnelheid naar toekomstige projecten.
- «De ijverige werknemer». We werken tot het uiterste, zijn tevreden met onszelf, maar merken niet dat de problemen die we oplossen â het gevolg zijn van onze eigen fouten / tekortkomingen / nalatigheden. Taken die nog gedaan moeten worden.
- «De kracht van Hello world». We haasten ons om alles nieuws en interessants in productie te brengen.
Waarom het gelukt is
Natuurlijk heb ik niet alle fouten opgesomd die we in deze periode hebben gemaakt, maar de meest algemene en waarschijnlijke voor projecten van elke specificiteit. Het vastleggen van fouten helpt om deze in de toekomst te vermijden.
Een beetje over hoe we erin zijn geslaagd om zo'n mini-startup binnen het bedrijf te creëren en het management te overtuigen om over te stappen van een al aangeschafte systeem naar iets eigens.
Voorwaarde â0. Een gezonde sfeer binnen het bedrijf. Het gaat niet alleen om de 'vuur ogen' van medewerkers en communicabiliteit onder stressvolle omstandigheden, nee. Het gaat om alle interacties.
Voorwaarde â1. Geloven in wat je doet. Seriously, ik denk echt niet dat we enige kans zouden hebben gehad als we niet de aangeschafte systeem 'tot op de draad' hadden uitgezocht â met andere woorden, ons terugtrekkend en onbewust wisten dat dit systeem beter is en ons zal overtreffen.
Wat we deden: 1) we verdiepten ons in het koop systeem en losten de belangrijkste verzoeken van de business op met de hulp ervan 2) we stelden een lijst op van taken die niet alleen nu bestaan, maar ook in de nabije toekomst zullen zijn 3) we zochten een oplossing die het beste past. En toen onze evaluatie van de oplossing â dat was de evaluatie van experts.
Zou men ons iets geven als we gewoon kwamen en zeiden: "jongens, alles is rotzooi, we willen hier niet mee omgaan en hebben besloten om het zelf vanaf nul te doen"? Waarschijnlijk niet. En de reactie zou komen in een vorm die goed bijblijft đ
Voorwaarde nr. 2. We beginnen met een kleine stap. We genereren de eerste hypothese en testen die. Je kunt daar ook je eigen persoonlijke tijd aan besteden. Als je geen tijd wilt verspillen, dan moet je echt niet aan zo'n project beginnen. En als je geen kleine hypothese wilt testen, maar meteen iets geweldig wilt maken â blijf dan uit de buurt van zulke mensen!
We hadden geluk, en de allereerste hypothese werkte. Maar dat gebeurt niet altijd. Bijvoorbeeld, in een van de volgende projecten, toen we een adminpaneel promoteerden binnen een vergelijkbaar proefproject, werkte alleen variant 18 voor ons. En de eerste 17 benaderingen waren tevergeefs. Trouwens, in het verhaal van het maken van het adminpaneel waren de plotwendingen op het niveau van Braziliaanse soapseries, omdat het team bestond uit jongens die tegen die tijd al veteranen waren, echte âdoorgewinterde rottenâ.
Voorwaarde nr. 3. We maken een MVP en zoeken naar de pijnpunten van de besluitvormer. Natuurlijk kan de schrik al op zijn gezicht staan als je hem voor de dertigste keer weer iets presenteert. Maar dat maakt niet uit. En we laten absoluut zien hoe wij zijn problemen met ons product oplossen.
Voorwaarde nr. 4. Snel een pilot maken die eruitziet ongeveer als het eindresultaat. Alles helemaal perfect maken is verleidelijk, maar je kunt vastlopen in perfectionisme, waardoor het lijkt dat je in plaats van een pilot al een perfecte versie wilt laten zien. En die bestaat gewoon niet. Dus maak tenminste iets van takken.
Voorwaarde nr. 5. Product. Het project groeit, krijgt financiering, en er komen specialisten met een solide ervaring bij.
En als je een klassieke startup-ondernemer bent, is dit het moment om met een vaart te vertrekken. Want het gevoel van een gemakkelijke vlucht bovenin en de algemene prettige sfeer vervaagt snel.
De uitrol naar productie is een confrontatie met de echte belasting, integratie met een tiental systemen, en terwijl je nieuwe functionaliteit creëert, werk je tegelijkertijd aan de oude versies. Dit zijn allemaal uitdagingen die veel serieuzer zijn dan alleen een idee verzinnen en misschien een goed, maar slechts één probleem van de klant oplossen.
Dit zijn de uitdagingen, en de groei van vaardigheden vindt precies in deze fase plaats.
Bedankt voor het lezen. Happy New Code!
Bron: habr.com
