Retrospektiva problémů. Jak se ukázalo, že vlastní řešení bylo lepší než placené

Ahoj! Jmenuji se Alexej Pjankov, jsem hlavní programátor ve společnosti Sportmaster. Hned na úvod musím říct, že „hlavní“ neznamená „nejhlavnější ze všech programátorů“, ne, je to jen název, takový okouzlující překlad pro „Senior+".

Ve společnosti Sportmaster pracuji od roku 2012, a za tu dobu tým vývoje vytvořil mnoho zajímavých technických řešení. Dnes bych však rád hovořil o naší práci se zaměřením na to, jak jsme uvažovali v určitých nejasných situacích.

V tomto článku nebudou konkrétní technická řešení (ani vlastně nic technického), která byste měli vzít a aplikovat ve svém projektu. Spíše se jedná o reflexi na vykonanou práci. Byly zde zvláštní momenty, které na nás jako tým měly vliv — spojily nás, zpevnily a prověřily naši odolnost. O těchto momentech, o atmosféře práce v týmu, o našich úskalích a řadě psychologických pastí, do kterých se občas sami dostáváme, bych dnes rád mluvil.

Retrospektiva problémů. Jak se ukázalo, že vlastní řešení bylo lepší než placené

A začnu právě od roku 2012.

Přišel jsem v roce 2012 s hlavním cílem tehdy — pracovat na našem vlajkovém webu. V té době to byl „Frankensteinův monster“: část týmu pracovala se starým systémem, který si nevedl příliš dobře při zatížení (Bitrix), zatímco druhá část týmu (kam jsem patřil i já) se snažila implementovat nový systém, který jsme vybrali na základě kritéria „Když už je to nejdražší e-commerce na světě, vezmeme to“. Přesně „se snažili implementovat“ — protože systém zoufale odporoval, a na každý moment, se kterým se nám podařilo vypořádat, se nevyhnutelně objevoval nějaký „překvapení“ v odpovědi. Pracovali jsme hodně, ale postupovali jsme rychlostí šneka.

Osobně pro mě byla poslední kapkou znalost kódu jedné metody v této „nejdražší e-commerce na světě“, kdy několik hodin soustředěné práce na zamotaném bugu vedlo k tomu, že příčina byla nalezena někde v custom-tag, který se spouští při generování html v jsp. Úkolem tohoto custom-tag je zobrazit součet nějakých veličin. To není špatné, pro to je custom-tag určen. Ale překvapení se skrývalo v tom, že přitom se mění některá data v databázi, na tom závisí chování na následujících stránkách, a pokud stisknete F5 — volání se opakovalo, což narušovalo konzistenci dat. Navíc k narušení docházelo tak, že se projevovalo pouze po několika krocích, na 3. stránce posloupnosti. Ne, nejsem proti tomu, aby takový „master-ninja“ byl v týmu a svým kódem udržoval pozornost kolegů na uzdě. Ale takto, v knihovně nejdražšího systému!

Bylo to v pátek. A sobotu a neděli jsme s kolegou strávili v kanceláři s cílem pochopit, jaké úkoly si podnik klade před systém dnes a jaké úkoly by mohl vymyslet za rok. Podle toho, jak bychom je řešili, kdybychom nebyli tlačeni do používání tohoto nejdražšího a nejvíce frustrujícího systému.

Řečeno — uděláno. Udělali jsme pilot, v němž jsme položili základ pro vývoj nového webu Sportmaster. Mnoho z těchto nápadů se uchytilo a právě teď jejich pokračování aktivně běží na webu.

Fáze pilota a časové rámce

2 dny. Vytvořili jsme mikroprototyp — o víkendu jsme převedli naši databázi do ElasticSearch, udělali jsme facetingové vyhledávání. Voilà! V té samé zakoupené soustavě takové nastavení „sežralo“ 2 týdny. A zde — doslova za několik hodin! A navíc to funguje rychleji. Rychlejší o řád.

2 týdny. „Šijeme“ prototyp, přidáváme funkčnost pro adekvátní personalizované zobrazení.

Například, pokud má uživatel několik slev a akcí, které jsou platné právě pro něj — pak je třeba v výsledcích vyhledávání zboží zobrazit právě tu cenu, kterou může získat, pokud využije všechny dostupné výhody tím nejvýhodnějším způsobem.

S akcemi to není tak jednoduché. Například jsem koupil lyže a nyní mám slevu 40% na čepici, ale zároveň je zrušena welcome sleva 10% na celou objednávku. Ano, to je skutečný případ 🙂 A abychom nastavili takovou akci v nákupním systému, zaplatili jsme za 3 konzultace s dodavatelem, během nichž jsme získali mnoho příkladů, jak vytvořit různé další akce. Velmi diplomaticky a vzhledem k nákladům na konzultace — to je ekonomicky velmi výhodné.

Ukázali jsme podnikání podrobnou ukázku. Slíbili, že rychle sestaví pilotní projekt a hned se do toho pustili.

2 měsíce. Pilotní projekt — vytvoříme ho jako živou stránku s vyhledáváním v katalogu. Vyhledávání s facety, výsledky hledání — s osobními slevami, pilot vypadá skoro jako stránka Sportmasteru, a my jsme nahráli ty samé produkty. Skvost!

Přidáváme "Rétorika:100" našeho vedoucího oddělení a prezentace pro podnikání probíhá na výbornou! Dostáváme carte blanche, abychom si sami vyvinuli platformu eCommerce.

A to znamená, držte se, kluci, týmu, držte se, kluci, rozpočtu. To je super!

2 roky. Nasazení webu do produkce. Ano, trvá to dlouho. Vše, co jsme tehdy uměli, jsme zkoušeli pouze v měřítku prototypu. Dva lidé snadno tvoří sehraný tým. A úkoly, které jsme ‚odškrtávali‘ — ve skutečnosti to byly drobné úpravy ‚Hello World‘ v nových technologiích. Snadno jsme generovali nové hypotézy, rychle je ověřovali, nebyli jsme schopni se k nim přivázat a proto jsme je bez lítosti ‚zabíjeli‘. Když nás bylo deset, setrvačností jsme extrapolovali naši pracovní rychlost na všechny ostatní. A slíbili jsme takové termíny dokončení úkolu, které se rovnaly představení o dokonalém násobeného naším nadšením.

Znáte tuto situaci? 🙂

Takže už víte, co bude dál?

Past č. 1. „Extrapolátor-superstar“

Je jasné, že nové technologie vypadají v prezentacích velmi skvěle a v aplikaci ‘Hello World’ se ukazují v dobrém světle. Ale realita je obvykle o něco dále.

Takže. Bereme knihovnu, píšeme hromadu aplikačního kódu. Unit testy považujeme za zátěž (jsme přece skvělí a pracujeme na nadzvuku tady, kód je moderní a tak dále). Neustále měníme a dolaďujeme API za pochodu — no jaké testy, vážně. A to všechno pod heslem „skvěle jsme optimalizovali vývojový proces“ (ano, teď je to dokonce děsivé popisovat).

A dál je to docela zřejmé.

Nasazujeme novou verzi na uat. Chlapci z byznysu se s vervou vydávají testovat a mačkat tlačítka. Někdy klikají docela kreativně — něco přestane fungovat. Chtělo by to zjistit, co se pro to udělalo. Ale na druhé straně monitoru není pouhý tester, který ti podá všechny charakteristiky prostředí, včetně počasí v regionu, ale zákazník z byznysu. Ten má jen „nefunguje“. A to znamená, že je nespokojený. Zeptej se ho — a on bude zděšený nespokojený!

Retrospektiva problémů. Jak se ukázalo, že vlastní řešení bylo lepší než placené

Pak, abys reprodukoval chybu, musíš jít a zkoušet všechno možné. Samozřejmě jsme nevěnovali pozornost žádné stížnosti a všechno jsme opravili. Pustili jsme se do naplánovaných úkolů, ale „hasil jsme požár“.

Tak jsme si vykopali další jámu.

Past č. 2. „Sakahnovec“

Přiletěla k tobě ne příliš příjemná chyba. Začínáš se v tom vyznat. Nedaří se — hněv — pokusit se to znovu vyřešit — další zklamání — ujasňuješ si vše, co můžeš — opět to není ono — uvažuješ o tom, že už jsi starý a všichni mají děti a hypotéky — zkoušíš to znovu — opět to není ono. Pár šálků kávy a všechno se opakuje. 12-14 hodin práce v kuse — skoro jako norma. A když už je všechno na pokraji — bum, osvícení!

Retrospektiva problémů. Jak se ukázalo, že vlastní řešení bylo lepší než placené

Možná, že zvenčí je hodnocení efektivity takového dne viditelné a správné. Ale zevnitř — může to být různé.

V mém případě dojem z takové práce obsahoval „Jsem skvělý, jsem úžasný, zvládl jsem to“. Ne vždy vědomě, ale nevědomě — vždy!

A na to si zvykáš, bez legrace. Zřejmě se tedy vnitřní metriky úspěšnosti posouvají z výsledku na množství vynaloženého úsilí a úroveň toho, jaké hrdinské kousky jsi vykonal, jak moc jsi trpěl, když jsi se snažil vyřešit úkol.

Možná je to ta nejstrašnější past.

Dál to bude snazší a veselejší 🙂

Past č. 3. „Síla Hello world“

Náš technologický stack v té době: ElasticSearch, Hazelcast, Pentaho, freemarker (a ověřené Java, Spring, Tomcat, nginx). Freemarker nevydával příliš informativní zprávy o chybách. Ale ElasticSearch, Hazelcast, Pentaho jsme museli patchovat několikrát — talentovaně jsme nacházeli případy, ve kterých pracovaly jinak, než uváděla dokumentace.

Snadný start a rychlé úspěchy spojené s novou technologií jsou skvělé, ale také nás mohou zavést do euforie a snížit naši ostražitost. Protože nová technologie má chyby, jistě má chyby. A pokud o nich ještě nebylo napsáno — raduj se, právě ty se staneš tím, kdo určitě narazí na něco špatného a půjde to googlit nebo na SO. Samozřejmě, že ‚špatné‘ můžeš najít i v ověřených produktech, ale u nových to je daleko jednodušší.

Retrospektiva problémů. Jak se ukázalo, že vlastní řešení bylo lepší než placené

I přes všechny potíže jsme se dostali do produkce. Ano, s prodlevami. Ano, není to moc stabilní. Ale celkově — bez katastrof.

Ještě jednou zdůrazním úskalí, ve kterých se zkresluje zdravé vnímání pracovního procesu.

  1. ‚Super extrapolátor‘. Pod vlivem aktuálních úspěchů se radostně snažíme extrapolovat rychlost vývoje na nadcházející projekty.
  2. ‚Pracant‘. Pracujeme za hranicí svých sil, jsme spokojeni sami se sebou, ale nevšímáme si, že problémy, které řešíme, jsou důsledkem našich osobních chyb/chybějících prvků/opomíjení. Práce, které se měly vykonat.
  3. ‚Síla Hello world‘. Spěcháme na to, abychom do produkce uvedli všechno nové a zajímavé.

Proč se to všechno podařilo

Samozřejmě, že jsem nezmínil všechny chyby, které jsme měli za tuto dobu, ale ty nejběžnější, které jsou pravděpodobné pro projekt jakékoli specifičnosti. Takové zaměření na chyby pomáhá vyhnout se jim v budoucnu.

Trochu o tom, jak se nám vlastně podařilo vytvořit takový mini-startup uvnitř společnosti a přesvědčit byznys, aby přešel z již zakoupeného systému na něco vlastního.

Podmínka č. 0. Zdravé klima ve společnosti. To není jen ‚zářící oči‘ zaměstnanců a komunikativnost ve stresových podmínkách, ne. Jde o všechny interakce.

Podmínka č. 1. Věřit tomu, co děláš. Opravdu, nemyslím si, že bychom měli jakoukoli šanci, kdybychom se pustili do pilotu, aniž bychom podrobně prozkoumali zakoupený systém ‚do posledního šroubku‘ — tedy, kdybychom ustoupili a podvědomě věděli, že tento systém je lepší a převyšuje nás.

Co jsme udělali: 1) podívali jsme se na zakoupený systém, s jeho pomocí vyřešili hlavní požadavky od byznysu 2) sestavili seznam úkolů, které jsou aktuální i ty, které se objeví v blízké budoucnosti 3) vybrali jsme řešení, které se nejlépe hodilo. A pak, naše hodnocení řešení — to bylo hodnocení expertů.

Dali by nám něco, kdybychom jednoduše přišli a řekli: „Kluci, všechno je špatně, nechceme se tím zabývat a rozhodli jsme se to udělat od začátku sami”? To by se pravděpodobně nestalo. A odpověď by přišla v takové formě, že by se nám dobře zapsala do paměti 🙂

Podmínka č. 2. První krok udělejme malý. Generujeme první hypotézu a ověřujeme ji. Můžete na to využít i svůj osobní čas. Pokud nechcete trávit svůj čas — pak se do takového projektu vůbec neodvažujte. A pokud nechcete ověřit malou hypotézu, ale hned chcete udělat něco úžasného a skvostného — držte se od takových lidí dál!

Měli jsme štěstí, a naše prvotní hypotéza vyšla. Ale to se nestává vždy. Například v jednom z dalších projektů, kdy jsme propagovali administraci v rámci podobného pilota, nám fungoval až osmnáctý variant. A prvních sedmnáct pokusů o to byly marné. Mimochodem, v příběhu o vzniku administrace byly zvraty na úrovni brazilských seriálů, protože tým byl složen z kluků, kteří už v té době byli opravdoví veteráni, doslova „osvědčení matadoři“.

Podmínka č. 3. Tvoříme MVP a hledáme bolesti u rozhodovací osoby. Samozřejmě, že na jeho tváři se může odrážet hrůza už z toho, že mu po třicáté přinášíte nějaký nápad. Ale i tak. A nezapomeňte mu ukázat, jak přesně vyřešíme jeho problémy naším produktem.

Podmínka č. 4. Na koleni rychle provádíme pilot, který vypadá přibližně jako finální výsledek. Udělat všechno úplně skvělé — je lákavé, ale můžete se dostat do pasti perfekcionismu, kvůli kterému místo pilota chcete ukázat pilotní verzi už ideálního produktu. A takové nejsou. Proto prostě vytvořte alespoň něco základního.

Podmínka č. 5. Produkt. Projekt roste, získává finance, přicházejí specialisté se solidními zkušenostmi.
A pokud jste klasický startupista, pak je to ten správný okamžik, kdy je třeba s hukotem utéct. Protože lehké létání po vrcholcích a pocit celkového blaha se velmi rychle rozptýlí.

Vstup do produkce — je to střetnutí s reálnými zátěžemi, integrace s desítkami systémů, přičemž když vytváříte novou funkčnost, zároveň, v rámci podpory, vylepšujete staré verze. To vše jsou výzvy mnohem vážnější než vymyslet nápad a zdánlivě dobrým, ale vlastně pouze jedním problémem klienta vyřešit.

Tyto výzvy a rozvoj dovedností se dějí právě v této fázi.

Děkuji, že jste si přečetli. Šťastný nový kód!

Zdroj: habr.com

Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster