Ներկա իրավիճակում ամենացավալին այն է, որ ՏՏ-ն աստիճանաբար վերածվում է արդյունաբերության, որտեղ մեկ անձին բաժին ընկնող պարտականությունների քանակով ընդհանրապես չկա «կանգ» բառը։
Թափուր աշխատատեղեր կարդալիս երբեմն նույնիսկ տեսնում ես ոչ թե 2-3 հոգու, այլ մի ամբողջ ընկերություն մեկ անձի մեջ, բոլորը շտապում են, տեխնիկական պարտքը մեծանում է, հին ժառանգությունը նոր ապրանքների ֆոնին կատարելության տեսք ունի, քանի որ դա առնվազն. ունի նավահանգիստ և մեկնաբանություններ կոդում, նոր ապրանքները գրվում են լույսի արագությամբ, բայց արդյունքում դրանք գրվելուց հետո չեն կարող օգտագործվել ևս մեկ տարի, և հաճախ այս տարին շահույթ չի բերում, ավելին, ինքնարժեքը. ամպը ավելի բարձր է, քան ծառայության վաճառքը: Ներդրողների գումարները գնում են ծառայության սպասարկմանը, որը դեռ չի աշխատում, բայց որն արդեն որպես բանվոր թողարկվել է ցանց:
Որպես օրինակ՝ հայտնի ընկերություն, որի հին խաղի ռեմեյստերը ստացել է ամենացածր վարկանիշը ոլորտի պատմության մեջ: Ես այս ապրանքը գնողներից մեկն էի, բայց հիմա էլ այս ապրանքը ահավոր աշխատում է, և տեսականորեն դեռ չպետք է թողարկվեր այս տեսքով։ Գումարի վերադարձ, վարկանիշի անկում, ծառայությունների աշխատանքի վերաբերյալ բողոքների համար ֆորումներում օգտագործողների մեծ թվով արգելքներ: Կարկատանների քանակը ոչ թե հիացնում է, այլ սարսափեցնում է, բայց, այնուամենայնիվ, ապրանքը օգտագործելի չէ: Եթե այս մոտեցումը բերում է նման արդյունքների մի ընկերության համար, որը զարգանում է 91 թվականից, ապա նոր սկսվող ընկերությունների համար իրավիճակն ավելի վատ է։
Բայց մենք նայեցինք այս մոտեցման արդյունքներին ծառայությունից օգտվողների կողմից, իսկ հիմա եկեք նայենք այն խնդիրներին, որոնք ունեն աշխատակիցները:
Ես հաճախ եմ լսում հայտարարություն, որ չպետք է լինեն DevOps թիմեր, որ սա մեթոդոլոգիա է և այլն, բայց խնդիրն այն է, որ ինչ-ինչ պատճառներով ընկերությունները դադարել են փնտրել noks, dba, infructors և շինարարական ինժեներներ. այժմ ամեն ինչ DevOps-ի ինժեներ է: միայնակ մարդու մեջ. Իհարկե, առանձին ընկերություններում նման թափուր աշխատատեղեր դեռ կան, բայց դրանք գնալով պակասում են։ Շատերն այս զարգացումն անվանեցին, ես անձամբ դրանում դեգրադացիա եմ տեսնում, հնարավոր չէ բոլոր ոլորտներում գիտելիքների լավ մակարդակ պահպանել, միաժամանակ հասցնես 8 ժամից ոչ ավել աշխատել։ Բնականաբար, դրանք ֆանտազիաներ են։ Իրականում ՏՏ ոլորտի շատ աշխատողներ ստիպված են աշխատել և՛ 12, և՛ 14 ժամ, որից 8-ը վարձատրվում են, և հաճախ առանց հանգստյան օրերի, քանի որ «Ինձ հանձնարարություն է տրվել, նավահանգիստներ չկան, ոլորաններ չկան, իսկ ծառայությունն արժե»: իսկ 1-ի համար ամպում սկզբունքորեն կարող ես մի երկու ամսում աշխատավարձ չստանալ, հատկապես եթե աշխատում ես IP-ով։ Փաստորեն, բիզնեսում բառը կորցնում ենք, պարտականությունների տարանջատմանը զուգահեռ, ես ավելի ու ավելի եմ բախվում այն փաստի հետ, որ մենեջերները առանց որևէ բան հասկանալու մտնում են զարգացման գործընթացների մեջ, շփոթում են բիզնեսի տվյալները և հավելվածների գործարկումը, արդյունքում՝ քաոս։ սկսվում է.
Երբ քաոս է սկսվում, բիզնեսն ուզում է գտնել մեղավորին, իսկ այստեղ պետք է համընդհանուր մեղավոր, դժվար է մեղքը բարդել 10+ հոգու վրա, ուստի մենեջերները միավորում են իրենց դիրքերը, քանի որ որքան շատ են 1 մասնագետի պարտականությունները, այնքան ավելի հեշտ է ապացուցել իր անփութությունը. Իսկ Agile-ի պայմաններում մենեջմենթում բիզնես վարելու այս մեթոդաբանության հիմքում «մեղավորին» գտնելն ու ծեծելը։ Agile-ը վաղուց դուրս է եկել ՏՏ ոլորտից, և նրա հիմնական հայեցակարգը դարձել է ամենօրյա արդյունքների պահանջը։ Խնդիրն այն է, որ բարձր մասնագիտացված մասնագետը միշտ չէ, որ կունենա ամենօրյա արդյունք, ինչը նշանակում է, որ ավելի դժվար կլինի զեկուցել, և սա ևս մեկ պատճառ է, որ բիզնեսը «ամեն ինչի մասնագետ» է ուզում։ Բայց հիմնական պատճառը, իհարկե, աշխատավարձն է՝ նա է բոլոր փոփոխությունների հիմնական պատճառը, հանուն նպաստի մարդիկ համաձայնվել են աշխատել իրենց և այդ տղայի համար։ Բայց, ի վերջո, ինչպես մյուս ոլորտներում, այն այժմ պարզապես պարտավորություն է դարձել՝ ավելի մեծ թվով մատուցվող ծառայությունների համար ավելի փոքր վճարի դիմաց։
Այժմ դուք հաճախ կարող եք նույնիսկ տեսնել հոդվածներ, որոնք մշակողները պետք է արդեն կարողանան տեղակայել, պետք է զբաղվեն DevOps ինժեների կողքին գտնվող ենթակառուցվածքով, բայց ինչի՞ է դա հանգեցնում: Ճիշտ է` ծառայությունների որակի անկում, մշակողների որակի անկում: Բառացիորեն 2 օր առաջ ես բացատրեցի ծրագրավորողին, որ կարելի է գրել և կարդալ տարբեր հոսթներից, և նրանք ինձ բերանից փրփուրով ապացուցեցին, որ երբեք նման բան չէին տեսել, ահա այն կարգավորումներում է orm host, port, db, օգտատեր, գաղտնաբառ և վերջ…. Բայց մշակողը գիտի, թե ինչպես գործարկել տեղակայումները, գրել yamls…. Բայց նա արդեն մոռանում է միավորի թեստերի ու կոդի մեկնաբանությունների մասին։
Արդյունքում մենք տեսնում ենք հետևյալը՝ մշտական մշակում, աշխատանքային ժամերից դուրս խնդիրների լուծումների որոնում, հանգստյան օրերին մշտական պարապմունքներ և ոչ թե եկամուտների ավելացում, այլ մեզ ջրի երես պահելու համար։ Մշակողները ստիպված են լինում օգնել DevOps-ի ինժեներին CI/CD-ով, և եթե մշակողը ժամանակ չունի, նա սկսում է լռել, իսկ մենեջերները սկսում են ուղեղը կոմպոստացնել, և եթե դա չի օգնում մեծացնել արտաժամյա աշխատելու ցանկությունը, ապա դիմեք: տույժեր և տուգանքներ, մարդը փնտրում է նոր աշխատանք՝ հետևում թողնելով Էվերեստի չափ տեխնիկական պարտք, արդյունքում պարտքը սկսում է աճել նաև ծրագրավորողների մոտ։ նրանք ստիպված են գրել կոդ ավելի քիչ վերամշակմամբ, որպեսզի ժամանակ ունենան օգնելու կա՛մ հին, կա՛մ նոր DevOps ինժեներին, իսկ մենեջերները գոհ են ամեն ինչից, քանի որ կա մեղավոր, և նրան անմիջապես կարելի է տեսնել, ինչը նշանակում է, որ Agile-ի կառավարման հիմնական կանոնը պահպանվում է, մեղավորը հայտնաբերվում է, նրա մտրակի հետևանքները տեսանելի են։
Մի անգամ ITGM-ում ես ներկայացրեցի «երբ մենք սովորում ենք ասել ոչ», դրա արդյունքները շատ բացահայտ էին: Հսկայական թվով մարդիկ հավատում են, որ այս բառը տաբու է, և քանի դեռ չենք դադարել այդպես մտածել, խնդիրները միայն կմեծանան։
Մասամբ ոգեշնչեց ինձ գրել այս հոդվածը:, բայց միգուցե ավելի ուշ կգրեմ ոչ այնքան հաճելի տերմիններով։
Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։ , խնդրում եմ:
Աշխատանքի ժամանակ հանդիպե՞լ եք, երբ գործատուն փորձել է ձեզ հետ փոխարինել մի քանի հոգու։
-
65,6%Այո, ես պարբերաբար բախվում եմ դրան
-
5,4%Այո, հանդիպել է 1 անգամ15
-
15,4%Չեմ նկատել43
-
13,6%Ես աշխատասեր եմ, ինքս արտաժամյա եմ աշխատում38
Քվեարկել է 279 օգտատեր։ 34 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com