Самае сумнае ў сённяшняй сітуацыі тое, што IT паступова становіцца галіной, дзе ўвогуле няма слова “стоп” у колькасці абавязкаў на 1 чалавека.
Чытаючы вакансіі часам ужо нават бачыш не 2-3 чалавекі, а цэлую кампанію ў 1 асобе, усё спяшаюцца, тех.долг расце, старое legacy на фоне новых прадуктаў выглядае дасканаласцю, таму што ў ім хаця б ёсць дока і каментары ў кодзе, новыя прадукты пішуцца з хуткасцю святла, але ў выніку карыстацца імі нельга яшчэ год пасля іх напісання, і часцяком гэты год прыбытку не прыносіць, больш за тое, выдаткі на "воблака" вышэй, чым продажу сэрвісу. Грошы інвестараў сыходзяць на ўтрыманне яшчэ не працуе сэрвісу, але які ўжо выпусцілі ў сетку як працоўны.
Як прыклад: вядомая кампанія, чый рэмайстар старой гульні атрымаў самыя нізкія адзнакі за ўсю гісторыю індустрыі. Я быў адным з тых, хто купіў дадзены прадукт, але нават зараз гэты прадукт працуе жудасна, і па ідэі яшчэ не павінен быў у такім выглядзе выходзіць у продажы. Зварот грошай, падзенне рэйтынгу, велізарная колькасць банаў карыстальнікаў на форумах за скаргі на працу сэрвісаў. Колькасць патчаў не захапляе, а жахае, але ўсё роўна - прадукт не юзабелен. Калі гэты падыход прыводзіць да такіх вынікаў у кампаніі, якая займаецца распрацоўкай з 91 года, то ў кампаній, якія толькі пачынаюць сваю дзейнасць, сітуацыя яшчэ горшая.
Але гэта мы паглядзелі на вынікі такога падыходу з боку карыстальніка сэрвісу, а зараз паглядзім на праблемы, якія ўзніклі ў супрацоўнікаў.
Я часта чую сцвярджэнне, што DevOps каманд не павінна быць, што гэта метадалогія і г.д., але вось бяда, кампаніі чамусьці перасталі шукаць нокаў, dba, инфруктурщиков і build інжынераў - цяпер гэта ўсё DevOps інжынер у адзінай асобе. Вядома, у асобна ўзятых кампаніях такія вакансіі яшчэ ёсць, але іх усё менш. Многія гэта назвалі развіццём, я асабіста ў гэтым бачу дэградацыю, немагчыма падтрымліваць па ўсіх напрамках добры ўзровень ведаў, і пры гэтым паспяваць працаваць не больш за 8 гадзін. Натуральна - гэта фантазіі. У рэальнасці, шматлікія ITшнікі змушаныя працаваць і па 12, і па 14 гадзін, з якіх аплачваецца 8. А часцяком і без выходных, таму што «мне паставілі задачу, докаў няма або крывыя, ды яшчэ і грошай варта сэрвіс», а за 1 памылку ў воблаку можна ў прынцыпе не атрымаць ЗП за пару месяцаў, асабліва, калі працуеш па ІП. Мы па факце губляем слова ў бізнэсе, разам з падзелам абавязкаў, я ўсё часцей сутыкаюся з тым, што менеджэры лезуць у працэсы распрацоўкі, наогул у іх нічога не разумеючы, яны блытаюць бізнэс-дадзеныя і працу дадатку, у выніку пачынаецца хаос.
Калі пачынаецца хаос, бізнэс жадае знайсці вінаватага, і тут трэба ўніверсальнага вінаватага, павесіць віну на 10+ чалавек складана, таму мэнэджары аб'ядноўваюць пазіцыі, бо чым больш абавязкаў у 1 адмыслоўца, тым прасцей давесці яго халатнасць. А ва ўмовах Agile знаходжанне «вінаватага» і лупцоўка - гэта аснова дадзены метадалогіі вядзення бізнесу ў менеджменце. Agile даўно выйшаў з IT, і асноўнай яго канцэпцыі стала - патрабаванне штодзённых вынікаў. Праблема ў тым, што ў вузкаспецыялізаваных спецыяліста не заўсёды будзе штодзённы вынік, а значыць даць справаздачу будзе складаней, і гэта яшчэ адна прычына, чаму бізнес хоча «спецыялістаў па ўсім». Але асноўная прычына вядома ж, гэта ФОП - ён асноўная прычына ўсіх змен, дзеля надбаўкі людзі згаджаліся працаваць за сябе і таго хлопца. Але ў выніку, як і ў іншых сферах, гэта проста стала зараз абавязкам, за меншую аплату большага колу прадстаўленых паслуг.
Цяпер можна часта ўбачыць нават артыкулы аб тым, што ўжо і распрацоўшчыкі павінны ўмець дэплоіць, павінны займацца інфраструктурай побач з DevOps інжынерам, але да чаго гэта прыводзіць? Правільна - да падзення якасці сэрвісаў, да падзення якасці распрацоўшчыкаў. Вось літаральна 2 дні таму я тлумачыў распрацоўніку, што пісаць і чытаць можна з розных хастоў, а мне з пенай у рота даказвалі, што ніколі такога не бачылі, вось ёсць у settings orm host, port, db, user, password і ўсё…. Затое распрацоўшчык умее запускаць дэплоі, пісаць ямлы…. Але ўжо забываецца пра юніт тэсты і каментары ў кодзе.
Па выніку мы бачым наступнае - пастаянныя перапрацоўкі, пошукі рашэнняў праблем па-за працоўным часам, пастаяннае навучанне ў выходныя, і не для росту даходаў, а для падтрымкі сябе на плаву. Распрацоўнікі змушаныя дапамагаць DevOps інжынеру з CI/CD, а калі ў распрацоўніка няма часу, той пачынае зашывацца, і мэнэджары пачынаюць кампаставаць мазгі, а, калі гэта не дапамагае павялічыць жаданне працаваць звышурочна, то ўжываць спагнанні і штрафы, чалавек шукае новае месца працы, пакідаючы пасля сябе тех.долг памерам з Эверэст, у выніку абавязак пачынае расці і ў распрацоўнікаў, т.я. яны змушаныя пісаць код з малодшым яго рэфактарынгам, каб паспець дапамагчы альбо старому ці новаму DevOps інжынеру, а мэнэджараў усё суцэль уладкоўвае, бо вінаваты ёсць і яго відаць адразу, а значыць асноўнае правіла пры Agile у менеджменце выканана, вінаваты знойдзены, вынікі па ім лупцоўцы бачныя.
Калісьці на ITGM я выступаў з дакладам "калі мы навучымся казаць "не"" - яго вынікі былі вельмі паказальнымі. Вялікая колькасць людзей лічыць, што гэтае слова табу, і пакуль мы не перастанем так лічыць, праблемы будуць толькі расці.
Часткова на дадзены артыкул мяне падштурхнула, Але я пазней магчыма распішу яе менш абыходлівымі тэрмінамі.
Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. , Калі ласка.
Ці сутыкаліся вы ў працы, калі працадаўца спрабаваў замяніць вамі некалькі чалавек?
-
65,6%Так, сутыкаюся рэгулярна183
-
5,4%Так, сутыкаўся 1 разоў15
-
15,4%Не заўважаў43
-
13,6%Я працаголік, сам працую звышурочна38
Прагаласавалі 279 карыстальнікаў. Устрымаліся 34 карыстальніка.
Крыніца: habr.com