Ciao! Mi chiamo Aleksey Pyankov, sono il programmatore capo dell'azienda Sportmaster. Dico subito che "capo" non significa "il più importante di tutti i programmatori", no, è solo un titolo, una traduzione affascinante per "Senior+".
Lavoro in Sportmaster dal 2012 e nel frattempo il nostro team di sviluppo ha realizzato molte soluzioni, interessanti dal punto di vista tecnico. Ma oggi vorrei parlare del nostro lavoro, ponendo l'accento su come abbiamo ragionato in situazioni ambigue.
In questo articolo non ci saranno soluzioni tecniche specifiche (e nemmeno qualcosa di tecnico) che dovresti adottare nel tuo progetto. Piuttosto, si tratta di una riflessione sul lavoro svolto. Ci sono stati momenti speciali che ci hanno influenzato come team: ci hanno uniti, temprati e messi alla prova. Di questi momenti, dell'atmosfera di lavoro in team, dei nostri scivoloni e di una serie di trappole psicologiche in cui ci cadiamo a volte, cercherò di parlare oggi.
E comincerò proprio dal 2012.
Sono arrivato nel 2012 con l'obiettivo principale di quel tempo: lavorare sul nostro sito web di punta. All'epoca era un "mostro di Frankenstein": parte del team lavorava con il nostro vecchio sistema, che non gestiva molto bene i carichi (Bitrix), mentre un'altra parte del team (di cui facevo parte io) cercava di implementare un nuovo sistema che avevamo scelto perché "Essendo il più costoso e-commerce al mondo, lo prendiamo". Proprio "provare a implementare" — perché il sistema resisteva strenuamente e per ogni problema che riuscivamo a risolvere, appariva inevitabilmente una "sorpresa" in risposta. Lavoravamo molto, ma avanzavamo alla velocità di una lumaca.
Personalmente, l'ultima goccia è stata la scoperta del codice di un metodo in questo "e-commerce più costoso al mondo", quando diverse ore di lavoro concentrato su un bug ingarbugliato hanno portato alla luce una causa da qualche parte in un custom-tag, che viene eseguito durante la generazione dell'html in jsp. Il compito di questo custom-tag è visualizzare la somma di alcune quantità. Non è male, a questo servono i custom-tag. Ma l'imprevisto è stato che durante questo processo alcuni dati nel database cambiano, questo influisce sul comportamento delle pagine successive, e se premi F5 - la chiamata si ripeteva, compromettendo la consistenza dei dati. Inoltre, questo si manifestava solo dopo alcuni passaggi, nella terza pagina della sequenza. No, non ho nulla in contrario a che un tale "master-ninja" sia in squadra e mantenga alta l'attenzione dei colleghi. Ma così, nella libreria del sistema più costoso di tutti!
Era un venerdì. E sabato e domenica io e un collega siamo stati in ufficio per capire quali compiti il business assegni al sistema proprio oggi e quali compiti potrebbe immaginare tra un anno. Di conseguenza, come li risolveremmo, se non fossimo stati costretti a utilizzare questo sistema così costoso e frustrante.
Detto e fatto. Abbiamo realizzato un pilota, nel quale abbiamo gettato le basi per lo sviluppo del nuovo sito di Sportmaster. Molte di queste idee sono state adottate e attualmente il loro seguito è attivamente presente sul sito.
Fasi del pilota e scadenze
2 giorni. Abbiamo realizzato un micro-prototipo - nel fine settimana stiamo trasferendo il nostro database in ElasticSearch, stiamo implementando la ricerca facettata. Voilà! In quel sistema di acquisto tale configurazione ha richiesto 2 settimane. Qui - letteralmente in poche ore! E funziona anche più velocemente. Anzi, più veloce di un ordine di grandezza.
2 settimane. Stiamo "creando" un prototipo, aggiungendo funzionalità per un'adeguata visualizzazione personalizzata.
Ad esempio, l'utente ha diversi sconti e promozioni che sono pertinenti solo per lui - quindi nei risultati di ricerca dei prodotti è necessario visualizzare il prezzo che può essere ottenuto applicando tutti i vantaggi disponibili nel modo più vantaggioso.
Con le promozioni non è così semplice. Ad esempio, ho comprato degli sci, ora c'è uno sconto del 40% sul berretto, ma viene annullato lo sconto di benvenuto del 10% su tutto il carrello. Sì, questo è un caso reale 🙂 E per impostare una tale promozione nel sistema di acquisto, sono state pagate 3 consulenze con il fornitore, da cui abbiamo ricevuto molti esempi su come realizzare altre promozioni. Molto diplomaticamente e, considerando il costo delle consulenze, è stato un buon risparmio dal punto di vista economico.
Abbiamo mostrato al business una demo dettagliata. Hanno promesso di allestire rapidamente un pilota e si sono messi subito al lavoro.
2 mesi. Il progetto pilota — lo stiamo facendo come un sito web dal vivo con ricerca nel catalogo. Ricerca con faccette, risultati di ricerca — con sconti personali, il pilota sembra quasi il sito di Sportmaster, e abbiamo caricato gli stessi prodotti. Una delizia!
Aggiungiamo "Krasnorechie:100" del nostro capo reparto, e la presentazione al business va a meraviglia! Ci danno carta bianca per sviluppare la piattaforma eCommerce noi stessi.
E questo significa, tenete duro, ragazzi, team, tenete duro, ragazzi, budget. È fantastico!
2 anni. Il rilascio del sito in produzione. Sì, è stato lungo. Tutto ciò che sapevamo allora, l'abbiamo provato solo su scala prototipale. Due persone formano facilmente un team affiatato. E le attività che 'fissavamo' erano per lo più piccoli affinamenti di 'Hello World' nelle nuove tecnologie. Generavamo facilmente nuove ipotesi, le verificavamo rapidamente, non ci attaccavamo troppo e quindi le 'uccidevamo' senza rimpianti. Quando siamo diventati 10 persone, per inerzia abbiamo estrapolato la nostra velocità di lavoro a tutti gli altri. E promettemmo tempi di consegna che erano pari a un'idea perfetta moltiplicata per il nostro entusiasmo.
Situazione familiare? 🙂
Allora, sapete già cosa succederà dopo?
Trappola n. 1. "Estrapolatore figo"
È chiaro che le nuove tecnologie sembrano fantastiche nelle presentazioni e si comportano bene nell'applicazione del tipo 'Hello World'. Ma la realtà di solito è un po' più lontana da questo.
Ecco. Prendiamo una libreria, scriviamo un sacco di codice applicativo. Consideriamo i test unitari un onere (siamo fighi e lavoriamo a velocità supersonica qui, il codice è moderno e altro). Cambiamo e rifiniamo continuamente l'API al volo — ma quali test ci sono qui, sul serio. E tutto questo sotto il vessillo 'abbiamo ottimizzato in modo fantastico il processo di sviluppo' (sì, ora è persino spaventoso descriverlo).
E poi tutto è piuttosto ovvio.
Stiamo lanciando una nuova versione su uat. I ragazzi del business sono entusiasti e si mettono subito a testare tutto, premendo pulsanti. A volte lo fanno in modo piuttosto creativo — qualcosa si disconnette. Qui sarebbe utile andare a scoprire cosa hanno fatto per risolvere. Ma dall'altra parte dello schermo non c'è un tester impegnato, che ti elencherebbe tutte le caratteristiche dell'ambiente considerando le condizioni meteo nella regione, ma un cliente del business. Per lui è semplicemente "non funziona". Questo significa che non è soddisfatto. Chiedilo e lui sarà terribilmente insoddisfatto!
Quindi, per riprodurre il bug, bisogna andare e provare tutto. Certo, non abbiamo ignorato nemmeno un reclamo e abbiamo risolto tutto. Abbiamo abbandonato le attività pianificate, ma stavamo "spegnendo incendi".
Così ci siamo scavati una nuova buca.
Trappola n. 2. "Il lavoratore instancabile"
Ti è giunto un bug piuttosto sgradevole. Cominci a indagare. Non riesci — rabbia — tentativo di risolvere ancora — un altro flop — chiarisci tutto il possibile — di nuovo non è giusto — pensi che sei già vecchio e che tutti hanno figli e mutui — provi di nuovo — ancora non è giusto. Dopo alcune tazze di caffè, tutto si ripete. 12-14 ore di lavoro di fila — quasi nella norma. E quando ormai tutto è al limite — ecco, illuminazione!
Forse, dall'esterno, la valutazione dell'efficacia di una giornata simile è chiara e corretta. Ma da dentro — potrebbe essere diverso.
Nel mio caso, la sensazione di un lavoro del genere includeva "Sono bravo, sono fantastico, ce l'ho fatta". Non sempre in modo consapevole, ma inconsapevolmente — sempre!
E ci si abitua, senza scherzi. Risulta che le metriche interne di successo si spostano dal risultato al numero di sforzi applicati e al livello di gesta compiute, a quanto hai sofferto nel tentativo di risolvere il compito.
Probabilmente, questa è la più grande trappola.
D'ora in poi sarà più facile e divertente 🙂
Trappola n. 3. "Il potere del Hello world"
Il nostro stack tecnologico di quel periodo: ElasticSearch, Hazelcast, Pentaho, freemarker (e le più collaudate Java, Spring, Tomcat, nginx). Freemarker forniva messaggi di errore non molto informativi. Mentre ElasticSearch, Hazelcast e Pentaho hanno dovuto essere patchati più volte — trovavamo abilmente casi in cui non funzionavano come specificato dalla documentazione.
Un avvio facile e biscotti veloci grazie all'uso di una nuova tecnologia è bello, ma può generare euforia e ridurre la vigilanza. Perché la nuova tecnologia contiene bug, sicuramente ne contiene. E se non ne hanno ancora scritto, rallegrati, toccherà a te essere il pioniere che sicuramente scova qualcosa di storto e andrà a cercare su Google o su SO. Certamente, "storto" si può trovare in prodotti collaudati, ma nei nuovi è molto più facile.
Nonostante tutte le difficoltà, siamo arrivati in produzione. Sì, con lag. Sì, non molto stabile. Ma nel complesso — senza catastrofi.
Riassumendo, sottolineo ancora una volta le trappole in cui la percezione sana del processo lavorativo viene distorta.
- «Estrattore di velocità». Sotto l'impressione dei successi attuali, proseguiamo e proiettiamo felicemente la velocità di sviluppo sui progetti futuri.
- «Lavoratore instancabile». Lavoriamo al massimo, siamo soddisfatti di noi stessi, ma non ci accorgiamo che i problemi che affrontiamo sono conseguenza dei nostri errori/omissioni/disattenzioni personali. Lavori da non fare.
- «La forza del Hello world». Ci affrettiamo a implementare in produzione tutto il nuovo e interessante.
Perché tutto ha funzionato
Certo, non ho elencato tutti gli errori che abbiamo avuto in questo periodo, ma quelli più comuni e probabili per un progetto di qualsiasi tipo. Tale registrazione degli errori aiuta a evitarli in futuro.
Qualche parola su come siamo riusciti a creare una mini-startup all'interno dell'azienda e convincere il business a lasciare un sistema già acquistato per qualcosa di nostro, sviluppato internamente.
Condizione n°0. Un ambiente sano in azienda. Non si tratta solo degli "occhi brillanti" dei dipendenti e della comunicabilità in condizioni di stress nella raccolta dei biscotti, no. Si tratta di tutte le interazioni.
Condizione n°1. Credere in ciò che si fa. Sul serio, non penso che avremmo avuto alcuna possibilità se avessimo iniziato il progetto senza analizzare il sistema acquistato "fino all'ultima vite" — cioè, allontanandoci e sapendo inconsciamente che quel sistema è migliore e ci avrebbe superato.
Cosa abbiamo fatto: 1) abbiamo analizzato il sistema acquistato, usando esso per soddisfare le principali richieste del business; 2) abbiamo stilato un elenco di compiti che non solo esistono ora, ma anche che ci saranno in un futuro prevedibile; 3) abbiamo selezionato una soluzione che si adatta meglio. E allora, la nostra valutazione della soluzione è stata una valutazione di esperti.
Ci darebbero qualcosa se venissimo semplicemente e dicessimo: “ragazzi, tutto fa schifo, non vogliamo occuparci di questo e abbiamo deciso di farne uno da zero”? Molto improbabile. E riceveremmo una risposta in una forma che rimarrebbe ben impressa 🙂
Condizione n. 2. Facciamo il primo passo in piccolo. Generiamo la prima ipotesi e la verifichiamo. Possiamo dedicarci anche il nostro tempo personale. Se non si vuole perdere tempo — allora non vale la pena di intraprendere tale impresa. E se non si vuole verificare una piccola ipotesi, ma si vuole subito fare qualcosa di fantastico e brillante — state lontani da queste persone!
Siamo stati fortunati e la prima ipotesi ha funzionato. Ma non è sempre così. Ad esempio, in uno dei progetti successivi, quando promuovevamo il pannello di amministrazione nell'ambito di un pilota simile, ci è servita solo la diciottesima opzione. E i primi 17 approcci al problema sono stati inutili. A proposito, nella storia della creazione del pannello di amministrazione, gli sviluppi della trama erano a livello di soap opera brasiliane, perché il team era composto da ragazzi che, a quel tempo, erano già veterani, veri e propri “navigati”.
Condizione n. 3. Creiamo un MVP e cerchiamo le lamentele della persona che prende le decisioni. Certamente, potrebbe già mostrare terrore sul suo volto solo per il fatto che gli state presentando per la trentaesima volta un'idea. Ma comunque. E mostriamo sempre come esattamente il nostro prodotto risolve i suoi problemi.
Condizione n. 4. Realizziamo velocemente un pilota che sembri circa il risultato finale. Fare tutto in modo perfetto è allettante, ma si può incappare nel perfezionismo, il che significherebbe voler mostrare già la versione ideale di un prodotto pilota. E non esistono. Quindi, basta fare qualcosa anche solo con bastoni.
Condizione n. 5. Prodotto. Il progetto cresce, ottiene finanziamenti, arrivano specialisti con una solida esperienza.
E se siete un classico startupper, questo è proprio il momento in cui dovete andare via con un fischio. Perché i voli leggeri in alto e la sensazione di un generale benequismo di ciò che sta accadendo si dissipano rapidamente.
Uscire in produzione significa affrontare carichi reali, integrazione con una decina di sistemi, e quando crei nuove funzionalità, contemporaneamente, nell'ambito del supporto, perfezioni le versioni precedenti. Tutto ciò rappresenta sfide ben più serie che inventare un'idea e risolvere, sia pure bene, ma solo un problema per il cliente.
Questi sono sfide e la crescita delle competenze avviene proprio in questa fase.
Grazie per aver letto. Happy New Code!
Fonte: habr.com
