Mulți oameni se gândesc la problemele care îi preocupă înainte de a adormi sau imediat după trezire. Eu nu fac excepție. În această dimineață, în mintea mea a apărut una. de pe Habr:
Un coleg din chat a împărtășit o poveste:
Anul trecut am avut un client grozav, atunci când am preluat un «criză» complet.
Clientul avea două echipe în grupul de dezvoltare, fiecare lucrând la partea sa a produsului (mai exact, back-office și front-end, adică software-ul care se ocupă cu crearea comenzii și software-ul care se ocupă cu realizarea comenzii), ocazional integrându-se unul cu celălalt.
Echipa de back-office a ajuns într-o situație foarte proastă: șase luni de greșeli constante, proprietarii amenințau cu concedierea tuturor, au angajat un consultant, iar după consultant au angajat un altul (pe mine). În plus, echipa a doua (front-end) lucra bine și a continuat să o facă, însă cea de back-office, care anterior lucra bine, a început să facă greșeli. Echipele lucrează în birouri diferite și s-au obișnuit să-și arunce vina una pe cealaltă.Motivul: front-end și back-end sunt un singur sistem, cu o mulțime de dependențe, echipele sunt în birouri diferite și nu comunicau între ele. Proprietarii își îndreptau mereu atenția asupra front-end-ului, având astfel funcționalități noi, idei și control. Era un tip multifuncțional, un amestec de analist de afaceri, designer și 'adu-ne cafeaua'. Acest tip, fără ca echipa sa să observe, îndeplinea o mulțime de sarcini mici, cum ar fi 'a informa cealaltă echipă despre deploy', 'a actualiza documentația' și alte sarcini de rutină, inclusiv 'a introduce în JIRA diverse numere de versiuni și componente'. Dar tipul nu scria cod și, într-o zi, proprietarii au decis să-l optimizeze, concediindu-l. Pentru echipa de front-end nu s-a schimbat nimic, ei pur și simplu nu mai înregistrau și nu mai actualizau documentele, iar echipa de back-office s-a confruntat cu o situație în care lansările front-end-ului le strica ceva și erau problemele lor, iar dacă lansările lor stricam ceva la front-end, din nou erau problemele lor, pentru că front-end-ul era în atenția proprietarilor 🙂
Ce m-a impresionat la acest comentariu și ce va găsi cel care caută în titlu - este mai jos.
Am activitate în dezvoltarea aplicațiilor web de aproximativ 20 de ani, așa că frontend/backend nu sunt doar cuvinte pentru mine. Acestea sunt lucruri strâns legate. De exemplu, nu îmi pot imagina o situație în care frontend-ul să fie dezvoltat complet (sau într-o măsură foarte mare) separat de backend. Ambele părți operează cu aceleași date, efectuează operațiuni foarte asemănătoare. Îmi imaginez ce volum de informații este transferat între dezvoltatorii ambelor echipe pentru a coordona dezvoltarea și cât timp și cât de des trebuie aceste coordonări să se facă. Echipele nu pot să nu comunice strâns, chiar și aflându-se în fusuri orare diferite. Mai ales, având în vedere JIRA.
Știu că este inutil să anunți dezvoltatorii backend despre desfășurarea frontend-ului. Noua versiune a frontend-ului nu poate strica nimic pe backend, dar invers – da. Dezvoltatorii frontend-ului sunt cei care sunt interesați să informeze dezvoltatorii backend că au nevoie de funcționalitate nouă sau modificată. Frontend-ul depinde de desfășurările backend-ului, nu invers.
Ce băiat, care "adu-ne cafea", nu poate fi BA (dacă prin BA înțelegem "analist de afaceri"), iar BA nu poate fi "băiat, adu-ne cafea". Și cu siguranță, "a introduce în Jira diverse versiuni de numerotare și componente" fără a discuta cu echipele de dezvoltare, nici "băiatul", nici BA nu pot face asta. Este ca o căruță în fața calului.
Dat fiind că "băiatul" a fost demis, atunci funcțiile respective, de la "adu cafea" până la "introduce în Jira", ar fi trebuit să fie redistribuite între ceilalți membri ai echipelor. Într-o grupă bine stabilită, fluxurile de informație și rolurile sunt consolidate, iar dacă un executant al unuia sau mai multor roluri părăsește scena, atunci ceilalți membri ai grupului vor resimți nevoia de a primi informațiile de care sunt obișnuiți de la rolurile familiare. Ei pur și simplu nu pot să nu observe că informațiile necesare pentru lucru au încetat să mai vină către ei. Este ca un dependent care nu poate să nu observe încetarea accesului la droguri. Și cum un dependent caută și găsește alte surse, tot așa și membrii grupului vor încerca să găsească surse pentru informațiile necesare pe "cealaltă" parte și noi executanți pentru rolurile vechi. Și cu siguranță vor găsi. Cel puțin pe cineva care, în opinia lor, ar trebui să le ofere informațiile necesare.
Chiar dacă s-ar presupune că canalele de informație obișnuite s-au închis, iar cel responsabil nu consideră că are această obligație, dezvoltatorii back-end nu vor ascunde timp de șase luni motivele eșecurilor lor de proprietar, știind că greșelile lor sunt cauzate de lipsa informațiilor necesare. Proprietarii nu vor "sta impasibili" timp de șase luni, observând că înainte aveau informațiile necesarese aflau în sistem", iar acum nimeni nu le mai introduce acolo. Și primii consultanți nu au fost atât de neprofesioniști încât să nu discute cu dezvoltatorii back-end și să nu ajungă la sursa problemei - lipsa colaborării între echipe. Aceasta este adevărata cauză a nenorocirilor descrise, nu plecarea "băiatului".
Absența banală a comunicării între dezvoltatori este o cauză tipică a numeroaselor probleme în dezvoltare și nu numai. Nu este nevoie să fii un consultant de excepție pentru a o descoperi. E suficient să fii pur și simplu rațional.
Consider că întreaga această poveste este inventată și frumos prezentată. Nu chiar complet inventată - toate elementele sunt luate din viață (front-end, back-end, dezvoltare, băiat, cafea, "sistem", …). Dar sunt conectate într-un mod în care, în viața reală, o astfel de construcție nu apare. Separat, toate acestea pot fi întâlnite în lumea înconjurătoare, dar într-o astfel de combinație - nu. Am explicat mai sus de ce.
Cu toate acestea, este prezentată foarte plauzibil. Se citește cu interes și există o implicare personală. Empatie față de "băiatul-de-tot", un mecanism mic neapreciat al unei mașini mari (asta este despre mine!). Indulgent față de dezvoltatori, atât de inteligenți și experimentați, dar care nu văd dincolo de propriul nas (ei sunt în jurul meu!). O ușoară ironie față de proprietari, unchișori bogați care s-au auto-invitat "bătaie" și nu înțeleg motivele (adică exact conducerea mea!). Dispreț față de primul "consultant", care nu a reușit să găsească o astfel de sursă simplă a problemelor (aha, a venit recent unul cu ochelari, mergea cu o față inteligentă), și o entuziastă comuniune cu "consultantul adevărat", care a fost singurul capabil să evalueze adevărata rol al băiatului-de-tot (adică eu!).
Simțiți o satisfacție interioară după citirea acestui comentariu? Rolul nostru ca mici rotițe într-un mecanism mare nu este, de fapt, atât de mic! Exprimat minunat, deși nu e adevărat. Dar ce gust plăcut rămâne.
Nu știu cine este colegul și în ce chat a împărtășit această revelație cu colegul. și de ce colegul mkrentovskiy a decis să o publice sub articolul "" al unui autor remarcabil de pe Habr ‘a (care, între noi fie vorba, este pe primul loc în clasamentul Habr în acest moment!), dar recunosc că colegul mkrentovskiy a făcut acest lucru cu un succes remarcabil. Mesajul comentariului și stilul de exprimare coincid atât de bine cu mesajul și stilul altor publicații nmivan‘a, încât ai putea crede că consultantul de criză din comentariu și protagonistul multor publicații nmivan‘a sunt aceeași persoană.
Am citit destul de multe publicații ale lui Ivan Belokamencev când autorul a început activitatea sa pe Habr (în 2017). Unele chiar cu plăcere (, ). Are un stil bun și o prezentare interesantă a materialului. Povestirile sale sunt foarte asemănătoare cu cele din viața reală, dar au o probabilitate aproape zero de a se întâmpla în realitate, în . Așa cum se întâmplă cu această poveste din comentariu.
Adevărul este că, personal, nu consider că publicațiile lui Ivan au făcut Habr mai bun. Dar ratingul său și altor locatari ai Habr-ului spun contrariul:
Nu înțeleg plângerea ta. Habr a scăzut de mult, dar autorul aduce un pic de energie și îmbunătățește starea de spirit a cititorilor) scoțând resursa din abis.
Da, Habr nu este caritate, Habr este un proiect comercial. Habr este o oglindă care reflectă dorințele noastre. Nu dorințele mele personale și nu dorințele fiecărui vizitator în parte, ci suma tuturor dorințelor noastre - "media spitalului". Și Ivan Belokamencev simte cel mai bine ce ne trebuie nouă tuturor în ansamblu și ne oferă asta.
Poate că nu aș fi scris acest articol dacă nu începusem să urmăresc serialul "".
"Am pierdut pe Dumnezeu" (c)
Este din serial. Și este despre noi.
Realitatea creată de Creator ne-a pierdut interesul.
De Dumnezeu, Natură, Big Bang - cum vrei. Realitatea există. În jurul nostru și independent de noi.
Trăim în conformitate cu legile naturii (Planul divin). Înțelegem legile (Planul) și învățăm să folosim realitatea în care trăim pentru a trăi și mai bine. Verificăm prin practică ipotezele noastre, excluzând cele false și păstrându-le pe cele relevante. Interacționăm cu realitatea și o schimbăm.
Și am reușit extrem de mult în acest sens.
Sunt mulți oameni pe planetă. Foarte mulți. Având în vedere productivitatea muncii actuale, nu mai avem nevoie să supraviețuim — o minoritate poate asigura majoritatea cu tot ce este necesar. Cei mai mulți au nevoie să se ocupe cu ceva. Istoric vorbind, surplusul de resurse alocat creativității a ajuns la cei mai talentați (sau cei mai insistenți, ceea ce este tot talent). Acum, există atât de multe resurse libere, încât ajung la toți cei care au măcar un pic de talent, indiferent de nivel. Compară câte filme sunt lansate anual în întreaga lume și câte dintre ele sunt vizionabile. Câte cărți sunt scrise și care dintre ele sunt de citit. Câte informații sunt aruncate pe internet și ce parte dintre acestea este valoroasă.
De ce este atât de populară profesia de specialist IT? Pentru că în IT se pot cheltui o mare cantitate de resurse fără ca nimeni să clipească (amintește-ți măcar de problema din anul 2000). În IT poți dezvolta aplicații ani de zile care vor deveni învechite chiar înainte de a fi lansate, poți încerca să integrezi componente incompatibile și să le faci să funcționeze, poți să reinventezi bicicleta din nou și din nou, sau poți pur și simplu să te ocupi de programele scrise în Fortran, care au fost uitate de 20 de ani. În IT poți petrece întreaga viață fără a realiza nimic util. Și cel mai important — nimeni nu va observa! Chiar și tu.
Puțini dintre noi vor reuși să lase o amprentă în industria IT. Și și mai puțini vor putea lăsa o amintire bună. Rezultatele muncii noastre se vor deprecia în următorii 10-20 de ani, în cel mai bun caz, poate chiar mai devreme. Și cu siguranță în timpul vieții noastre (dacă ajungem la vârsta de pensionare). Nu vom putea arăta nepoților sistemele computerizate la care lucram în tinerețe. Oamenii pur și simplu își vor uita numele. La începutul carierei mele, am ridicat stații poștale. sub "". Am până la pensie 20 de ani și până la nepoți 10, dar deja acum majoritatea dintre voi nu ați auzit de "celebrul software poștal din mijlocul anilor 90" ("pachet de software de email de vârf din mijlocul anilor 1990").
Poate că în realitate nu realizăm suficient de bine futilitatea poverii noastre IT, dar în subconștient ne străduim să fugim în locuri unde ne simțim confortabil. În lumi inventate, unde utilizarea Scrum și Agile duce invariabil la crearea de produse care cuceresc lumea timp de decenii cu utilitatea lor. Unde nu suntem doar mici rotițe în mari mecanisme, ci rotițe fără de care marile mecanisme se strică. Unde viața noastră nu se desfășoară în executarea inutilă a sarcinilor de rutină, ci este plină de creativitate și creație, rezultatele cărora ne putem mândri.
Fugim în aceste minunate lumi inventate de altcineva pentru a scăpa de propria noastră neputință în lumea reală. Căutăm consolare în ele.
Căutăm consolare inclusiv pe Habr. Iar Ivan ne oferă asta aici.
Sursa: habr.com
