Cerca e troverai

Molti pensano ai problemi che li preoccupano prima di andare a dormire o appena svegli. Io non faccio eccezione. Oggi, questa mattina, un pensiero è tornato alla mia mente commento da Habr:

Un collega in chat ha condiviso una storia:

Un cliente fantastico che avevo due anni fa, proprio quando stavo affrontando una crisi.
Il cliente ha due team nel gruppo di sviluppo, ognuno si occupa di una parte del prodotto (in termini semplici, back office e front end, cioè software che si occupa della creazione degli ordini e software che gestisce l'esecuzione degli ordini), integrandosi tra di loro solo occasionalmente.
Il team del back office stava proprio andando a fondo: sei mesi di errori continui, i proprietari minacciavano di licenziare tutti, hanno ingaggiato un consulente e dopo di lui un altro (me). Il secondo team (front end) lavorava normalmente e continuava a farlo, ma il back office, che prima funzionava bene, ha iniziato a commettere errori. I team si trovano in uffici diversi e si erano abituati a screditarsi a vicenda.

Motivo: lo store e il back end sono un'unica sistema, con molte dipendenze, le squadre negli uffici diversi non comunicavano tra loro. I proprietari controllano costantemente il front end dello store, quindi hanno nuove funzionalità, idee e controllo. C'era un ragazzo polivalente che fungeva da BA, designer e "portami un caffè". Questo ragazzo, senza che la sua squadra se ne accorgesse, svolgeva molte piccole attività come "avvisare il secondo team del deploy", "aggiornare la documentazione" e altre routine, fino a "inserire su Jira vari numeri di versione e componenti". Ma il ragazzo non scriveva codice, e a un certo punto i proprietari decisero di ottimizzare la situazione, licenziandolo. Per il team dello store non cambiò nulla, semplicemente non inserivano e non aggiornavano i documenti, mentre il team del back office si ritrovò in una situazione in cui i rilasci dello store rompevano qualcosa per loro, ed erano problemi loro, e se i loro rilasci rompevano qualcosa per lo store, erano di nuovo problemi loro, perché lo store è sotto gli occhi dei proprietari 🙂

Cosa mi ha colpito di questo commento e cosa troverà chi cerca nel titolo - sotto.

Ho lavorato nello sviluppo di applicazioni web per circa 20 anni, quindi per me front-end e back-end non sono solo parole. Sono aspetti strettamente correlati. Ad esempio, non riesco a immaginare una situazione in cui il front-end venga sviluppato in totale (o molto) distacco dal back-end. Entrambi operano con gli stessi dati e svolgono operazioni molto simili. Ho un'idea del volume di informazioni che circola tra gli sviluppatori di entrambe le squadre per coordinare lo sviluppo, e di quanto tempo e quanto spesso sia necessario fare questi coordinamenti. I team non possono non comunicare intensamente, anche se si trovano in diversi fusi orari. Tanto più con JIRA a disposizione.

So che è inutile avvisare i programmatori back-end del deploy del front-end. Una nuova versione del front-end non può rompersi a causa del back-end, mentre viceversa sì. Sono gli sviluppatori del front-end a dover informare quelli del back-end che necessitano di nuove funzionalità o di modifiche. Il front-end dipende dai deploy del back-end, e non il contrario.

Cosa può fare un ragazzo che "portaci un caffè" non può essere un BA (se con BA si intende "business analyst"), e un BA non può essere "un ragazzo, portaci un caffè". E sicuramente, "inserire in un documento vari numeri di versione e componenti" senza discuterne con i team di sviluppo né "il ragazzo", né il BA possono. È come mettere il carro davanti ai buoi.

Poiché "il ragazzo" è stato licenziato, queste funzioni, da "portami un caffè" fino a "inserire in documentazione", avrebbero dovuto essere ridistribuite tra gli altri membri dei team. In un gruppo consolidato, i flussi di informazioni e i ruoli sono stabiliti; se l'esecutore di uno o più ruoli è uscito di scena, gli altri membri del gruppo continuano ad avere bisogno di ricevere informazioni abituali dai ruoli abituali. Non possono semplicemente non notare che le informazioni necessarie al lavoro hanno smesso di arrivare a loro. È come se un tossicodipendente non potesse non notare il fatto che l'approvvigionamento di droghe è cessato. E come un tossicodipendente cerca e trova altri canali, così i membri del gruppo cercheranno di trovare fonti delle informazioni di cui hanno bisogno "da" quella parte e nuovi esecutori dei vecchi ruoli. E sicuramente troveranno qualcuno. Almeno colui che, secondo loro, deve fornire loro le informazioni necessarie.

Anche se si suppone che i canali di informazione abituali siano andati in onda, e chi deve non considera di doverlo fare, gli sviluppatori del backend, sotto minaccia di licenziamento, non nasconderanno per sei mesi le ragioni dei propri insuccessi al proprietario, sapendo che gli errori derivano dalla mancanza delle informazioni necessarie. I proprietari non rimarranno "fissi" per sei mesi, vedendo che prima le informazioni necessarie "erano nel grasso", e ora nessuno le sta inserendo. Ed è poco probabile che il primo consulente fosse così poco professionale da non parlare con gli sviluppatori del backend e non arrivare alla fonte del problema: la mancanza di coordinamento tra i team. Questo è il motivo delle difficoltà descritte, e non l'allontanamento del "ragazzo".

La banale mancanza di comunicazione tra gli sviluppatori è una causa tipica di una moltitudine di problemi nello sviluppo e non solo. Non è necessario essere un consulente eccezionale per individuarla. È sufficiente essere semplicemente razionali.

Ritengo che tutta questa storia sia inventata e ben raccontata. Beh, non è completamente inventata: tutti gli elementi sono tratti dalla vita (frontend, backend, sviluppo, ragazzo, caffè, "grasso", …). Ma sono connesse in modo tale che una costruzione del genere non si incontra nella vita reale. Separatamente, tutto ciò può essere trovato nel mondo che ci circonda, ma in questa combinazione - no. Ho scritto sopra il perché.

Tuttavia, è presentato in modo molto plausibile. Si legge con interesse e c'è un coinvolgimento personale. Compassione per "il ragazzo-tuttofare", un piccolo meccanismo sottovalutato in una grande macchina (è proprio di me!). C'è condiscendenza verso gli sviluppatori, così intelligenti e esperti, ma incapaci di vedere oltre il proprio naso (sono proprio intorno a me!). Leggera derisione verso i proprietari, i ricchi zii, che si sono fatti da soli il "bo-bo" e non comprendono le cause (è proprio il mio manuale!). Disprezzo per il primo "consulente", che non è riuscito a trovare una causa così semplice dei problemi (ah, è venuto recentemente uno con gli occhiali, si aggirava con un’aria intelligente), e un'esaltata unione con il "vero" consulente, che è l'unico in grado di valutare il vero ruolo del ragazzo-tuttofare (cioè me!).

Senti una certa soddisfazione interiore dopo aver letto questo commento? Il nostro ruolo di piccoli ingranaggi in un grande meccanismo non è poi così piccolo! Eloquentemente espresso, anche se non del tutto vero. Ma che piacevole retrogusto!

Non so chi sia quel collega e in quale chat abbia condiviso questa rivelazione con un altro collega mkrentovskiy e perché il collega mkrentovskiy ha deciso di pubblicarlo sotto l'articolo "Quanti anni passi nella taiga — capisci, non c'è" di un eccezionale autore di Habra nmivan‘(che, tra l'altro, attualmente occupa il primo posto nella classifica di Habra!), ma ammetto che il collega mkrentovskiy lo ha fatto con grande successo. Il messaggio del commento e lo stile di esposizione coincidono così bene con il messaggio e lo stile di altre pubblicazioni nmivan‘che si potrebbe pensare che il consulente di crisi del commento e il protagonista di molte pubblicazioni nmivan‘siano la stessa persona.

Ho letto molte pubblicazioni di Ivan Belokamentsev quando l'autore ha iniziato la sua attività su Habra (nel 2017). Alcune persino con piacere (una volta, due volte). Ha un buon stile e un'interessante presentazione del materiale. Le sue storie sono molto simili a racconti di vita, ma hanno praticamente zero possibilità di accadere realmente, nella realtà. Ecco come con questa storia nel commento.

A dire il vero, personalmente non penso che con le pubblicazioni Ivan abbia migliorato Habr. Ma il suo punteggio e le opinioni degli altri abitanti di Habr dicono il contrario:

Non capisco il tuo lamento. Habr è già sceso da un bel po', e l'autore porta un po' di vivacità e solleva il morale dei lettori ) estraendo la risorsa dall'abisso.

Sì, Habr non è una beneficenza, Habr è un progetto commerciale. Habr è uno specchio che riflette i nostri desideri. Non i miei desideri personali né quelli di ogni singolo visitatore, ma la somma di tutti i nostri desideri — "la media dell'ospedale". E Ivan Belokamencev sente meglio di chiunque altro cosa desideriamo complessivamente e ce lo offre.

Forse non avrei scritto questo articolo se non avessi iniziato a guardare la serie "Il Giovane Papa".

"Abbiamo perso Dio" (c)

Questo è della serie. Ed è di noi.

La realtà creata dal Creatore ha smesso di affascinarci.

Dio, Natura, Grande Esplosione — come preferisci. La realtà è presente. È attorno a noi e indipendentemente da noi.

Noi viviamo in essa secondo le leggi della natura (il Progetto Divino). Scopriamo le leggi (il Progetto) e impariamo a utilizzare la realtà in cui viviamo per vivere ancora meglio. Mettiamo alla prova le nostre congetture attraverso la pratica, scartando quelle errate e mantenendo quelle valide. Interagiamo con la realtà e la cambiamo.

E abbiamo fatto notevoli progressi in questo.

Ci sono molte persone sul pianeta. Veramente molte. Con l'attuale produttività lavorativa, non abbiamo bisogno di lottare per la sopravvivenza: una minoranza può fornire a molti tutto il necessario. Per la maggior parte, è importante avere qualcosa da fare. Storicamente, l'eccedenza delle risorse destinate alla creatività andava ai talenti più spiccati (o ai più intraprendenti, che è pur sempre una forma di talento). Oggi, invece, ci sono così tante risorse disponibili che tutto ciò che è minimamente talentuoso può accedervi, indipendentemente dal livello. Confronta quanti film vengono realizzati ogni anno in tutto il mondo e quanti di essi sono davvero fruibili. Quante libri vengono scritti e quali di essi sono leggibili. Quanta informazione viene riversata su internet e quale di essa è davvero utile.

Perché la professione di IT è così popolare? Perché nell'IT si possono spendere una miriade di risorse senza che nessuno batta ciglio (basti pensare al problema dell'anno 2000). Infatti, nell'IT si possono sviluppare applicazioni per anni, che diventeranno obsolete ancor prima del lancio, si possono cercare di integrare componenti incompatibili e farle funzionare, si possono inventare ripetutamente le proprie biciclette, e si può persino dedicarsi ora alla manutenzione di programmi in Fortran, un linguaggio che è stato abbandonato ormai da 20 anni. Nell'IT si può passare tutta la vita senza realizzare nulla di utile. E la parte migliore è che nessuno se ne accorgerà! Anche tu stesso.

Pochi di noi riusciranno a lasciare un segno nell'industria IT. E ancor meno persone saranno in grado di lasciare un buon ricordo. I risultati del nostro lavoro perderanno valore nei prossimi 10-20 anni, nella migliore delle ipotesi, e forse anche prima. E di certo durante la nostra vita (se riusciamo a raggiungere l'età pensionabile). Non potremo mostrare ai nostri nipoti i sistemi informatici su cui lavorava il loro nonno da giovani. Le persone semplicemente dimenticheranno i loro nomi. All'inizio della mia carriera, gestivo stazioni di posta. cc:Mail sotto "semiassi". Ho ancora 20 anni fino alla pensione e 10 fino ai nipoti, ma già adesso la maggior parte di voi non ha mai sentito parlare del "software di posta elettronica straordinario della metà degli anni '90" ("il miglior pacchetto software di posta elettronica della metà degli anni '90").

Forse nella realtà siamo poco consapevoli della futilità del nostro onere IT, ma nel profondo ci sforziamo di fuggire in luoghi dove ci sentiamo a nostro agio. In mondi inventati, dove l'uso di Scrum e Agile porta inevitabilmente alla creazione di prodotti che conquistano il mondo con la loro utilità per decenni. Dove non siamo semplici ingranaggi di grandi meccanismi, ma ingranaggi senza i quali i grandi meccanismi si rompono. Dove la nostra vita non scorre in un'inefficace esecuzione di azioni routine, ma è riempita di creatività e costruzione, il cui risultato possiamo essere orgogliosi.

Fuggiamo in questi meravigliosi mondi, inventati da qualcun altro, dalla nostra stessa inutilità nel mondo reale. Li cerchiamo per trovare conforto.

Cerchiamo conforto anche su Habr. E Ivan ce lo offre qui.

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster