🥇DevOps или как губим заплатите си и бъдещето на IT индустрията

Най-смъртната част от днешната ситуация е, че IT постепенно се превръща в индустрия, в която изобщо не съществува думата "стоп" за количеството задължения на един човек.

Четейки обяви за работа, понякога виждаш не 2-3 души, а цяла компания в едно лице; всички са в бързина, техническият дълг нараства, старият legacy на фона на новите продукти изглежда като съвършенство, защото поне в него има документация и коментари в кода, новите продукти се пишат с невероятна скорост, но в крайна сметка не могат да бъдат използвани дори година след написването им, и често тази година не носи печалба; освен това разходите за "облак" са по-високи от продажбите на услугата. Парите на инвеститорите отиват за поддържане на все още неработеща услуга, която вече е пусната в мрежата като работеща.
Например: известна компания, чието ремастериране на стара игра получи най-ниски оценки в историята на индустрията. Аз бях един от онези, които купиха този продукт, но дори сега той работи ужасно, и по принцип дори не трябваше да излиза в продажба в такова състояние. Възстановяване на пари, спад на рейтинга, огромно количество бани на потребители по форумите за оплаквания относно работата на услугите. Броят на пачовете не вдъхновява, а ужасява, но все пак – продуктът не е полезен. Ако този подход води до такива резултати при компания, която се занимава с разработка от 91-ва година, то при компании, които едва започват дейността си, ситуацията е дори по-лоша.

Но това е, когато погледнем резултатите от такъв подход от страната на потребителя на услугата, а сега да разгледаме проблемите, които възникват при служителите.

Често чувам твърдението, че не трябва да има DevOps екипи, че това е методология и т.н., но за съжаление, компаниите по някаква причина спряха да търсят ноков, DBA, инфраструктурни инженери и build инженери – сега всичко това е DevOps инженер в единствено число. Разбира се, в отделни компании все още има такива обяви, но те стават все по-малко. Много хора наричат това развитие, но лично аз виждам в това деградация, невъзможно е да се поддържа добър ниво на знания във всички направления и същевременно да се успее да се работи не повече от 8 часа. Естествено – това са фантазии. В реалността много IT специалисти са принудени да работят и по 12, и по 14 часа, от които се заплаща 8. А често и без почивки, защото „имам задача, документите липсват или са некоректни, а и услугата струва пари“, а за 1 грешка в облака може в принципе да не получиш заплата за два месеца, особено ако работиш по ИП. Всъщност, губим думата в бизнеса, заедно с разделението на задълженията, все по-често се сблъсквам с факта, че мениджърите се намесват в процесите на разработка, без изобщо да разбират от тях, бъркат бизнес данните с работата на приложението, в резултат на което започва хаос.

Когато започва хаос, бизнесът иска да намери виновния, а тук трябва универсален виновен, да се накаже повече от 10 души е трудно, затова мениджърите обединяват позиции, защото колкото повече задължения има един специалист, толкова по-лесно е да се докаже неговата небрежност. А в условията на Agile, намирането на „виновния“ и наказанието са основа на тази методология управления на бизнеса. Agile отдавна излезе от ИТ, и основната му концепция стана – изискване за ежедневни резултати. Проблемът е, че при много специализирания специалист не винаги ще има ежедневен резултат, а това означава, че отчетът ще бъде по-труден, и това е още една причина, поради която бизнесът иска „специалисти по всичко“. Но основната причина е, разбира се, ФОТ – той е основната причина за всички промени, заради доплатите хората се съгласяваха да работят вместо себе си и вместо другите. Но в крайна сметка, както и в други сфери, това просто стана задължение за по-малко заплащане на повече предоставени услуги.

Сега често можем да видим дори статии, които твърдят, че разработчиците трябва да могат да извършват деплой, да се занимават с инфраструктура, заедно с DevOps инженерите. Но до какво води това? Правилно - до спад в качеството на услугите и до понижаване на качеството на разработчиците. Преди два дни обяснявах на един разработчик, че е възможно да се пише и чете от различни хостове, а той упорито ми доказваше, че никога не е виждал такова нещо, ето тук в settings orm host, port, db, user, password и това е всичко... Вместо това, разработчикът умее да стартира деплой, да пише YAML файлове… Но вече забравя за юнит тестовете и коментарите в кода.

На краят виждаме следното - постоянни преработки, търсене на решения за проблеми извън работното време, постоянно обучение в почивните дни, и не за повишаване на доходите, а за поддържане на себе си на повърхността. Разработчиците са принудени да помагат на DevOps инженера с CI/CD, а ако разработчикът няма време, започва да се задъхва, мениджърите започват да му вземат главата, а ако това не помага за увеличаване на желанието да работи извънредно, прилагат санкции и глоби. Човекът търси ново работно място, оставяйки след себе си технически дългове, размерът на които е като Еверест. В резултат на това дългът започва да нараства и за разработчиците, тъй като те са принудени да пишат код с по-малко рефакторинг, за да успеят да помогнат или на стария, или на новия DevOps инженер. А мениджърите са напълно удовлетворени, защото виновният е открит и видим веднага, което означава, че основното правило на Agile в мениджмънта е спазено - виновният е намерен, резултатите от наказанието му са видими.

Някога в ITGM изнесох доклад на тема „Кога ще научим да казваме „не“?“ - резултатите бяха много показателни. Огромен брой хора смятат, че тази дума е табу, и дотогава, докато не спрем да го считаме за такова, проблемите само ще нарастват.

Частично на тази статия ме подтикна тази статия, но по-късно може би ще я изложа с по-малко заобикалящи термини.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.