🥇DevOps или како ги губиме платите и иднината на ИТ индустријата

Најтажното нешто во денешната ситуација е што ИТ постепено станува индустрија каде што нема збор „стоп“ во бројот на обврски по човек.

Кога читате слободни работни места, понекогаш дури не гледате 2-3 луѓе, туку цела компанија во еден човек, сите брзаат, техничкиот долг расте, старото наследство на позадината на новите производи изгледа како совршенство, бидејќи барем има доковите и коментарите во шифрата, новите производи се пишуваат со брзина на светлината, но на крајот не можат да се користат уште една година откако ќе се запишат, а често оваа година не носи профит, згора на тоа, трошоците на „облакот; “ се повисоки од продажбата на услугата. Парите на инвеститорите се трошат за одржување на услуга која сè уште не работи, но која веќе е пуштена на интернет како работна.
Како пример: добро позната компанија чиј ремастер на стара игра доби најниски оценки во целата историја на индустријата. Јас бев еден од оние кои го купија овој производ, но и сега овој производ работи ужасно и теоретски не требаше да излезе во продажба во оваа форма. Враќање пари, пад на рејтингот, огромен број забрани на корисници на форуми за поплаки за работата на услугите. Бројот на закрпи не е неверојатен, но застрашувачки, но сепак, производот не е употреблив. Ако овој пристап води до такви резултати за компанија која се развива од 91 година, тогаш за компаниите кои штотуку почнуваат ситуацијата е уште полоша.

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

Често ја слушам изјавата дека тимовите на DevOps не треба да постојат, дека ова е методологија итн., но проблемот е што компаниите поради некоја причина престанаа да бараат noks, dba, инфраструктура и градежни инженери - сега сето тоа е единствен инженер за DevOps . Секако дека се уште има вакви слободни работни места во поединечни фирми, но ги има се помалку. Многумина го нарекоа овој развој, јас лично гледам деградација во ова, невозможно е да се одржи добро ниво на знаење во сите области, а во исто време да се успее да се работи не повеќе од 8 часа. Нормално, тоа се фантазии. Во реалноста, многу ИТ работници се принудени да работат 12 или 14 часа, од кои 8 се платени, а честопати и без слободни денови, затоа што „добив задача, нема документи или криви, а услугата чини“. а за 1 грешка во облакот, во основа не можеш да земеш плата за неколку месеци, особено ако работиш како индивидуален претприемач. Во суштина го губиме зборот во бизнисот, заедно со поделбата на одговорностите, сè повеќе се соочувам со фактот дека менаџерите се мешаат во развојните процеси без воопшто да разберат ништо за нив, ги мешаат деловните податоци и работата на апликацијата; како резултат, започнува хаосот.

Кога започнува хаосот, бизнисот сака да го најде виновникот, а тука им треба универзален виновник, тешко е да се закачи вината на 10+ луѓе, па затоа менаџерите ги комбинираат позициите, бидејќи колку повеќе одговорности има еден специјалист, толку е полесно; ја докаже својата небрежност. А во Агилни услови, пронаоѓањето на „виновникот“ и камшикувањето е основата на оваа методологија за водење бизнис во менаџментот. Agile одамна излезе од ИТ, а неговиот главен концепт стана услов за дневни резултати. Проблемот е што високо специјализираниот специјалист нема секогаш да има дневни резултати, што значи дека ќе биде потешко да се пријави, а ова е уште една причина зошто бизнисите сакаат „експерти за сè“. Но, главната причина, се разбира, е платниот список - тоа е главната причина за сите промени, за доброто на бонусот, луѓето се согласија да работат за себе и за тој човек. Но, на крајот, како и во другите области, сега едноставно стана одговорност, за помала наплата за поголем број дадени услуги.

Во денешно време често можете дури и да видите написи во кои се наведува дека програмерите исто така треба да можат да распоредуваат, дали треба да работат на инфраструктура заедно со инженерот DevOps, но до што води ова? Така е - до пад на квалитетот на услугите, до пад на квалитетот на програмерите. Пред само 2 дена му објаснив на девелоперот дека можеш да пишуваш и читаш од различни хостови и тие се пенаа од устата за да докажат дека никогаш не виделе вакво нешто, но во подесувањата има orm host, port, db, user. , лозинка и тоа е тоа…. Но, развивачот знае како да работи распоредувања, да пишува јамс... Но, тој веќе заборава на единечните тестови и коментари во кодот.

Како резултат на тоа го гледаме следното - постојана прекувремена работа, барање решенија за проблемите надвор од работното време, постојана обука за викенди, а не за зголемување на приходите, туку за одржување на живот. Програмерите се принудени да му помогнат на инженерот DevOps со CI/CD, а ако развивачот нема време, тој почнува да се заглавува, а менаџерите почнуваат да го компостираат мозокот, а ако тоа не помогне да се зголеми желбата за прекувремена работа, потоа применувајте казни и парични казни, лицето бара нова работа, оставајќи зад себе технички долг со големина на Еверест, како резултат на тоа долгот почнува да расте кај програмерите, бидејќи тие се принудени да пишуваат код со помалку рефакторирање за да имаат време да му помогнат или на стар или нов инженер DevOps, а менаџерите се сосема задоволни од се, бидејќи виновникот е таму и веднаш се гледа, што значи основно правило во Агил управување е следено, виновникот е пронајден, резултатите од камшикувањето се видливи.

Еднаш дадов презентација на ITGM „кога ќе научиме да кажеме „не“ - неговите резултати беа многу откривачки. Огромен број луѓе веруваат дека овој збор е табу и додека не престанеме да мислиме така, проблемите само ќе растат.

Оваа статија беше делумно инспирирана од мене Оваа статија, но подоцна можеби ќе го опишам со помалку учтиви зборови.

Само регистрирани корисници можат да учествуваат во анкетата. Најави се, вие сте добредојдени.