Najsmutniejsze w obecnej sytuacji jest to, że IT stopniowo staje się branżą, w której nie ma słowa „stop” w liczbie obowiązków przypadających na osobę.
Czytając oferty pracy czasami widać nawet nie 2-3 osoby, ale całą firmę w jednej osobie, wszyscy się spieszą, dług techniczny rośnie, stare dziedzictwo wygląda perfekcyjnie na tle nowych produktów, bo przynajmniej posiada stację dokującą i komentarze w kodzie, nowe produkty są pisane z prędkością światła, ale w efekcie nie można ich używać przez kolejny rok po ich napisaniu, a często ten rok nie przynosi zysków, ponadto koszt chmura jest wyższa niż sprzedaż usługi. Pieniądze inwestorów idą na utrzymanie usługi, która jeszcze nie działa, ale została już wypuszczona do sieci jako pracownik.
Przykładowo: znana firma, której remaster starej gry uzyskał najniższe oceny w historii branży. Byłem jednym z tych, którzy kupili ten produkt, ale nawet teraz ten produkt działa okropnie i teoretycznie nie powinien być jeszcze wydawany w tej formie. Zwroty pieniędzy, spadek ocen, ogromna liczba banów użytkowników na forach z powodu skarg na działanie usług. Liczba plastrów nie zachwyca, ale przeraża, ale mimo wszystko – produkt nie nadaje się do użytku. Jeśli takie podejście prowadzi do takich wyników dla firmy, która rozwija się od 91 roku, to dla firm, które dopiero startują, sytuacja jest jeszcze gorsza.
Ale przyjrzeliśmy się skutkom takiego podejścia ze strony użytkownika usługi, a teraz przyjrzyjmy się problemom, jakie mają pracownicy.
Często słyszę stwierdzenie, że nie powinno być zespołów DevOps, że to metodologia itp., ale problem w tym, że firmy z jakiegoś powodu przestały szukać noków, dba, infruktorów i inżynierów budujących - teraz wszystko to inżynier DevOps w jedną osobę. Oczywiście w poszczególnych firmach nadal są takie wakaty, ale jest ich coraz mniej. Wielu nazywało to rozwojem, ja osobiście widzę w tym degradację, nie da się utrzymać dobrego poziomu wiedzy we wszystkich obszarach, a jednocześnie dać radę pracować nie dłużej niż 8 godzin. Są to oczywiście fantazje. W rzeczywistości wielu pracowników IT jest zmuszonych pracować zarówno po 12, jak i 14 godzin, z czego 8 jest płatnych i często bez dni wolnych, bo „dostałem zadanie, nie ma doków ani zakrętów, a usługa kosztuje”, a za 1 w chmurze w zasadzie nie możesz otrzymać pensji w ciągu kilku miesięcy, zwłaszcza jeśli pracujesz na zasadzie własności intelektualnej. Tak naprawdę w biznesie tracimy słowo, wraz z rozdzieleniem obowiązków, coraz częściej spotykam się z tym, że menadżerowie wchodzą w procesy deweloperskie zupełnie niczego nie rozumiejąc, mylą dane biznesowe z działaniem aplikacji, w efekcie chaos zaczyna się.
Kiedy zaczyna się chaos, biznes chce znaleźć winowajcę, a tutaj potrzebny jest uniwersalny winowajca, trudno zrzucić winę na 10+ osób, dlatego menedżerowie jednoczą swoje stanowiska, bo im więcej obowiązków ma 1 specjalista, tym łatwiej udowodnić swoje zaniedbanie. A w warunkach Agile znalezienie „winnego” i lanie to podstawa tej metodologii prowadzenia biznesu w zarządzaniu. Agile już dawno wyszło z IT, a jego główną koncepcją stał się wymóg codziennych wyników. Problem w tym, że wysoko wyspecjalizowany specjalista nie zawsze będzie miał dzienny wynik, przez co trudniej będzie go raportować, a to kolejny powód, dla którego firmy chcą „specjalistów od wszystkiego”. Ale głównym powodem są oczywiście płace - to on jest głównym powodem wszystkich zmian, w imię zasiłku ludzie zgodzili się pracować dla siebie i tego gościa. Ale ostatecznie, podobnie jak w innych obszarach, teraz stało się to po prostu obowiązkiem, za mniejszą opłatę za większą liczbę świadczonych usług.
Teraz często można nawet spotkać artykuły, które programiści powinni już umieć wdrożyć, powinni zająć się infrastrukturą obok inżyniera DevOps, ale do czego to prowadzi? Zgadza się - do spadku jakości usług, do spadku jakości programistów. Dosłownie 2 dni temu tłumaczyłem programiście, że można pisać i czytać z różnych hostów, a oni z pianą na ustach udowodnili mi, że nigdy czegoś takiego nie widzieli, tutaj jest to w ustawieniach hosta, portu, db, użytkownik, hasło i to wszystko.... Ale programista wie, jak uruchamiać wdrożenia, pisać yaml .... Ale zapomina już o testach jednostkowych i komentarzach w kodzie.
W rezultacie widzimy, co następuje: ciągłe przetwarzanie, szukanie rozwiązań problemów poza godzinami pracy, ciągłe szkolenia w weekendy, a nie po to, aby zwiększyć dochody, ale po to, aby utrzymać się na powierzchni. Programiści zmuszeni są pomagać inżynierowi DevOps przy CI/CD, a jeśli programista nie ma czasu, zaczyna się zamykać, a menedżerowie zaczynają kompostować mózgi, a jeśli to nie pomoże zwiększyć chęci do pracy w nadgodzinach, to aplikuj kary i grzywny, osoba szuka nowej pracy, pozostawiając za sobą dług techniczny wielkości Everestu, w efekcie dług zaczyna rosnąć także wśród deweloperów. zmuszeni są pisać kod z mniejszą ilością refaktoryzacji, aby mieć czas na pomoc albo staremu, albo nowemu inżynierowi DevOps, a menedżerowie są ze wszystkiego w miarę zadowoleni, bo jest winny i od razu go widać, co oznacza, że przestrzegana jest główna zasada w zarządzaniu Agile, winny zostaje odnaleziony, widoczne są skutki jego chłosty.
Kiedyś w ITGM przeprowadziłem prezentację „Kiedy nauczymy się mówić nie” – jej wyniki były bardzo odkrywcze. Ogromna liczba osób uważa, że to słowo jest tematem tabu i dopóki nie przestaniemy tak myśleć, problemy będą tylko narastać.
Częściowo zainspirowało mnie do napisania tego artykułu., ale może napiszę to później w mniej przyjemny sposób.
W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. , Proszę.
Czy spotkałeś się w pracy, gdy pracodawca próbował zastąpić Cię kilkoma osobami?
-
65,6%Tak, wpadam na to regularnie
-
5,4%Tak, spotkałem 1 raz15
-
15,4%Nie zauważyłem 43
-
13,6%Jestem pracoholikiem, sam pracuję w nadgodzinach38
Głosowało 279 użytkowników. 34 użytkowników wstrzymało się od głosu.
Źródło: www.habr.com