Najsmutniejsze w obecnej sytuacji jest to, że IT stopniowo staje się branżą, w której nie ma w ogóle słowa "stop" w liczbie obowiązków przypadających na jedną osobę.
Czytając oferty pracy, czasami wydaje się, że nie poszukuje się 2-3 osób, ale całą firmę w jednej osobie. Wszyscy się spieszą, dług technologiczny rośnie, stare legacy w obliczu nowych produktów wygląda na doskonałość, ponieważ przynajmniej ma dokumentację i komentarze w kodzie. Nowe produkty tworzone są w zawrotnym tempie, ale w efekcie nie można z nich korzystać przez kolejny rok po ich napisaniu, a często ten rok nie przynosi dochodów. Co więcej, koszty "chmury" są wyższe niż przychody ze sprzedaży usługi. Pieniądze inwestorów idą na utrzymanie jeszcze niedziałającej usługi, która została już wydana w Internecie jako działająca.
Na przykład: znana firma, której remaster starej gry otrzymał najniższe oceny w historii branży. Byłem jednym z tych, którzy kupili ten produkt, ale nawet teraz działa on okropnie i w teorii nie powinien był jeszcze w takim stanie trafiać do sprzedaży. Zwroty pieniędzy, spadek oceny, ogromna liczba banów użytkowników na forach za skargi na działanie serwisów. Liczba poprawek nie zachwyca, a przeraża, ale mimo to – produkt jest nieużywalny. Jeśli takie podejście prowadzi do takich rezultatów w firmie, która zajmuje się rozwojem od 1991 roku, to w przypadku firm, które dopiero zaczynają działalność, sytuacja jest jeszcze gorsza.
Ale to my spojrzeliśmy na wyniki takiego podejścia z perspektywy użytkownika serwisu, a teraz przyjrzymy się problemom, które pojawiły się u pracowników.
Często słyszę stwierdzenie, że zespoły DevOps nie powinny istnieć, że to tylko metodologia itd., ale problem w tym, że firmy z jakiegoś powodu przestały szukać administratorów systemów, DBA, inżynierów infrastruktury i inżynierów build – teraz wszystko to zredukowano do jednej osoby, inżyniera DevOps. Oczywiście, w niektórych firmach takie oferty jeszcze istnieją, ale jest ich coraz mniej. Wiele osób nazywa to rozwojem, ja osobiście widzę w tym regres, niemożliwe jest utrzymanie dobrego poziomu wiedzy we wszystkich obszarach i jednoczesne nadążanie za pracą w nie więcej niż 8 godzin. Oczywiście – to fantazje. W rzeczywistości wielu specjalistów IT zmuszonych jest pracować po 12 lub 14 godzin, z czego płatne jest tylko 8. A często także bez dni wolnych, ponieważ „dostałem zadanie, dokumentacji brak lub jest wadliwa, a za usługę trzeba zapłacić”, a za jeden błąd w chmurze można tak naprawdę nie otrzymać wynagrodzenia przez kilka miesięcy, szczególnie, jeśli pracuje się na własny rachunek. W rzeczywistości tracimy głos w biznesie, wraz z podziałem obowiązków, coraz częściej stykam się z tym, że menedżerowie wtrącają się w procesy rozwoju, nie rozumiejąc nic z nich, mylą dane biznesowe z funkcjonowaniem aplikacji, w rezultacie zaczyna się chaos.
Gdy zaczyna się chaos, biznes chce znaleźć winnego, a tutaj potrzeba uniwersalnego winnego, obwinienie 10+ osób jest trudne, dlatego menedżerowie łączą stanowiska, bo im więcej obowiązków ma jeden specjalista, tym łatwiej udowodnić jego niedbalstwo. A w warunkach Agile szukanie "winnego" i jego ukaranie – to podstawa tej metodologii prowadzenia biznesu w menedżmencie. Agile od dawna wyszedł z IT, a jego główną koncepcją stało się – wymaganie codziennych wyników. Problem polega na tym, że wąsko wyspecjalizowany specjalista nie zawsze będzie miał codzienny rezultat, co sprawia, że trudniej będzie się rozliczyć, i to kolejny powód, dla którego biznes chce "specjalistów od wszystkiego". Ale główną przyczyną oczywiście jest FUNDUSZ PŁAC – to podstawowy powód wszystkich zmian, z powodu dodatków ludzie zgadzali się pracować za siebie i za innych. Ale w efekcie, jak w innych dziedzinach, stało się to po prostu obowiązkiem, za mniejsze wynagrodzenie za większą ilość świadczonych usług.
Obecnie można często spotkać nawet artykuły mówiące, że deweloperzy powinni umieć wdrażać, zajmować się infrastrukturą obok inżyniera DevOps. Ale dokąd to prowadzi? Oczywiście – do spadku jakości usług, do degradacji umiejętności deweloperów. Dosłownie dwa dni temu tłumaczyłem deweloperowi, że można pisać i odczytywać z różnych hostów, a on z determinacją dowodził, że nigdy czegoś takiego nie widział. W ustawieniach są host, port, db, user, password i to wszystko… A jednak deweloper potrafi uruchamiać wdrożenia, pisać pliki YAML… Ale już zapomina o testach jednostkowych i komentarzach w kodzie.
W rezultacie widzimy, że ciągłe przeróbki, poszukiwanie rozwiązań problemów poza godzinami pracy, nieustanne kształcenie się w weekendy nie służy wzrostowi dochodów, lecz utrzymaniu się na powierzchni. Deweloperzy muszą wspierać inżyniera DevOps przy CI/CD, a jeśli deweloper nie ma czasu, zaczyna się dusić, a menedżerowie zaczynają go przycisnąć. A jeśli to nie pomaga zwiększyć chęci do pracy w nadgodzinach, zaczynają stosować sankcje i kary, a osoba szuka nowego miejsca pracy, zostawiając po sobie dług technologiczny wielkości Evereestu. W rezultacie dług rośnie także u deweloperów, ponieważ muszą pisać kod z mniejszym refaktoryzowaniem, aby zdążyć pomóc starym lub nowym inżynierom DevOps. A menedżerowie są z tego zadowoleni, bo wina jest widoczna, a więc zasadnicza zasada Agile w zarządzaniu została zachowana – winny został znaleziony, a wyniki jego ukarania są widoczne.
Kiedyś na ITGM występowałem z wykładem „kiedy nauczymy się mówić 'nie'” – jego rezultaty były bardzo wymowne. Ogromna liczba ludzi uważa, że to słowo jest tabu i dopóki nie przestaniemy tak myśleć, problemy tylko będą rosnąć.
Częściowo na tę artykuł zainspirował mnie, ale później być może opiszę go mniej okrężnymi terminami.
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
Czy spotkałeś się w pracy z sytuacją, gdy pracodawca próbował zastąpić cię jako kilka osób?
65,6%Tak, spotykam się regularnie183
5,4%Tak, spotkałem się 1 raz15
15,4%Nie zauważyłem43
13,6%Jestem pracoholikiem, sam pracuję w nadgodzinach38
Zagłosowało 279 użytkowników. Wstrzymało się 34 użytkowników.
Źródło: habr.com
