Ceea ce este cel mai trist în situația de astăzi este că IT-ul devine treptat o industrie în care cuvântul „stop” nu există în ceea ce privește numărul de responsabilități pentru o persoană.
Citind anunțurile de angajare, uneori observi că nu mai sunt 2-3 oameni, ci o întreagă companie într-o singură persoană, toți se grăbesc, datoria tehnică crește, vechiul sistem legacy, în comparație cu noile produse, pare o capodoperă, pentru că măcar are documentație și comentarii în cod, noile produse sunt dezvoltate cu viteza luminii, dar de obicei nu pot fi utilizate timp de un an după ce sunt scrise, iar adesea acest an nu aduce profit, dimpotrivă, cheltuielile pentru „cloud” sunt mai mari decât vânzările serviciului. Banii investitorilor se duc în întreținerea unui serviciu care încă nu funcționează, dar care a fost deja lansat online ca fiind operațional.
Ca exemplu: o companie cunoscută, a cărei remasterizare a unui joc vechi a primit cele mai scăzute evaluări din întreaga istorie a industriei. Am fost unul dintre cei care au cumpărat acest produs, dar chiar și acum acest produs funcționează groaznic și, teoretic, nu ar fi trebuit să iasă la vânzare în această formă. Returnările de bani, scăderea ratingului, un număr uriaș de banări ale utilizatorilor pe forumuri din cauza plângerilor referitoare la funcționarea serviciilor. Numărul de patch-uri nu este impresionant, ci terifiant, dar totuși – produsul este inutilizabil. Dacă această abordare conduce la astfel de rezultate pentru o companie care dezvoltă din 1991, situația pentru companiile care abia își încep activitatea este și mai rea.
Dar am analizat rezultatele unei astfel de abordări din perspectiva utilizatorului serviciului; acum să ne uităm la problemele care au apărut pentru angajați.
Adesea aud afirmația că nu ar trebui să existe echipe DevOps, că este doar o metodologie și așa mai departe, dar problema este că companiile au încetat să caute ingineri de rețea, DBA, specialiști în infrastructură și ingineri de build – acum toate aceste roluri sunt deținute de un singur inginer DevOps. Desigur, în unele companii aceste posturi mai există, dar numărul lor este în scădere. Mulți spun că este o evoluție, dar eu personal văd în aceasta o degradare, deoarece nu este posibil să menții un nivel bun de cunoștințe în toate direcțiile și să reușești să lucrezi mai puțin de 8 ore. Evident – aceasta este o fantezie. În realitate, mulți IT-iști sunt nevoiți să lucreze 12 sau 14 ore, din care sunt plătiți doar 8. Iar adesea, fără zile libere, pentru că „am primit o sarcină, documentația lipsește sau este incompletă și serviciul costă”, iar pentru o singură eroare în cloud, poți pierde practic salariul pentru câteva luni, mai ales dacă lucrezi ca persoană fizică autorizată. De fapt, pierdem cuvântul în afacere, odată cu împărțirea sarcinilor, mă confrunt tot mai des cu situația în care managerii se amestecă în procesele de dezvoltare, fără să înțeleagă nimic despre ele, confundând datele de afaceri cu funcționarea aplicației, iar în rezultat, haosul începe.
Când începe haosul, afacerea vrea să găsească un vinovat, iar aici este nevoie de un vinovat universal, este dificil să pui vina pe 10+ oameni, așa că managerii unifică pozițiile, deoarece cu cât un specialist are mai multe responsabilități, cu atât este mai ușor să îi dovedești neglijența. În condiții Agile, găsirea „vinovatului” și pedepsirea acestuia este baza acestei metodologii de conducere a afacerii în management. Agile a ieșit de mult din IT, iar conceptul său principal a devenit – cerința de rezultate zilnice. Problema este că un specialist foarte specializat nu va avea întotdeauna un rezultat zilnic, ceea ce face raportarea mai dificilă, și aceasta este încă o altă cauză pentru care afacerea caută „specialiști care să se ocupe de toate”. Dar motivul principal este, desigur, fondul de salarii – acesta este motivul principal al tuturor schimbărilor, pentru o suplimentare, oamenii acceptau să lucreze în locul lor și al altora. Dar, în final, ca în alte domenii, aceasta a devenit pur și simplu o obligație, pentru o plată mai mică pentru un număr mai mare de servicii oferite.
Acum se pot observa frecvent chiar și articole despre faptul că dezvoltatorii ar trebui să fie capabili să efectueze deploy-uri, să se ocupe de infrastructură alături de inginerii DevOps, dar la ce conduce asta? Corect – la scăderea calității serviciilor, la scăderea calității dezvoltatorilor. Chiar acum două zile am explicat unui dezvoltator că se poate scrie și citi din diferite gazde, iar el a insistat că nu a văzut așa ceva niciodată, iată, există în setările orm gazda, portul, db, utilizator, parolă și atât... Dar dezvoltatorul știe cum să efectueze deploy-uri, să scrie yaml-uri... Dar deja uită de testele unitare și comentariile în cod.
În rezultat, vedem următoarele – ore suplimentare constante, căutarea soluțiilor la probleme în afara timpului de lucru, învățare constantă în weekend, și nu pentru a crește veniturile, ci pentru a se menține pe linia de plutire. Dezvoltatorii sunt nevoiți să ajute inginerul DevOps cu CI/CD, iar dacă dezvoltatorului nu îi ajunge timpul, acesta începe să se sufocă, iar managerii încep să-și frece mințile, iar dacă asta nu ajută la creșterea dorinței de a lucra ore suplimentare, atunci se aplică sancțiuni și penalizări, iar omul caută un nou loc de muncă, lăsând în urmă o datorie tehnică de mărimea Everestului; rezultatul este că datoria începe să crească și pentru dezvoltatori, deoarece sunt nevoiți să scrie cod cu mai puțin refactoring, pentru a reuși să ajute fie vechiului, fie noului inginer DevOps, iar managerii sunt complet mulțumiți, pentru că există un vinovat care se vede imediat, ceea ce înseamnă că regula principală în Agile în management este respectată, vinovatul a fost găsit, iar rezultatele pedepsirii sale sunt vizibile.
Cândva pe ITGM am susținut o prezentare „când vom învăța să spunem „nu”” – rezultatele au fost foarte revelatoare. Un număr foarte mare de oameni consideră că acest cuvânt este tabu, și până nu vom înceta să mai credem asta, problemele vor continua să crească.
Parțial, în scrierea acestui articol m-a inspirat, dar poate că mai târziu voi descrie asta cu termeni mai direcți.
Numai utilizatorii înregistrați pot participa la sondaj. , vă rugăm.
Te-ai confruntat vreodată în muncă cu un angajator care a încercat să te înlocuiască cu mai mulți oameni?
65,6%Da, mă confrunt regulat183
5,4%Da, m-am confruntat o dată15
15,4%Nu am observat43
13,6%Sunt dependent de muncă, lucrez ore suplimentare38
Au votat 279 de utilizatori. S-au abținut 34 de utilizatori.
Sursa: habr.com
