Sing paling sedhih ing kahanan saiki yaiku IT mboko sithik dadi industri sing ora ana tembung "mandheg" ing jumlah tanggung jawab saben wong.
Nalika maca lowongan, kadhangkala sampeyan ora weruh 2-3 wong, nanging kabeh perusahaan ing siji wong, kabeh wong cepet-cepet, utang teknis saya akeh, warisan lawas ing latar mburi produk anyar katon kaya sampurna, amarga paling ora ana. dermaga lan komentar ing kode kasebut, produk anyar ditulis kanthi cepet, nanging pungkasane ora bisa digunakake kanggo taun liyane sawise ditulis, lan asring taun iki ora nggawa bathi, uga biaya "awan ” luwih dhuwur tinimbang dodolan layanan kasebut. Dhuwit investor digunakake kanggo njaga layanan sing durung bisa digunakake, nanging wis dirilis online minangka layanan sing bisa digunakake.
Minangka conto: perusahaan kondhang sing remaster saka game lawas nampa ratings paling murah ing kabeh sajarah industri. Aku minangka salah sawijining sing tuku produk iki, nanging saiki produk iki kerjane banget, lan ing teori mesthine ora bisa didol ing wangun iki. Pengembalian dana, peringkat sing mudhun, akeh larangan pangguna ing forum kanggo keluhan babagan karya layanan. Jumlah patches ora apik tenan, nanging medeni, nanging isih, produk ora bisa digunakake. Yen pendekatan iki nyebabake asil kasebut kanggo perusahaan sing wis berkembang wiwit taun 91, mula kanggo perusahaan sing lagi miwiti, kahanan kasebut luwih elek.
Nanging kita ndeleng asil pendekatan iki saka sisih pangguna layanan, lan saiki ayo ndeleng masalah sing dialami karyawan.
Aku kerep krungu pratelan manawa tim DevOps ora ana, manawa iki minangka metodologi, lan liya-liyane, nanging masalahe, perusahaan-perusahaan amarga sawetara alasan mandheg nggoleki noks, dba, infrastruktur lan insinyur mbangun - saiki kabeh dadi insinyur DevOps siji. . Mesthi, isih ana lowongan kasebut ing perusahaan individu, nanging ana sing luwih sithik. Akeh sing diarani pembangunan iki, aku pribadi ndeleng degradasi iki, ora mungkin kanggo njaga tingkat pengetahuan sing apik ing kabeh wilayah, lan ing wektu sing padha bisa kerja ora luwih saka 8 jam. Alamiah, iki minangka fantasi. Ing kasunyatan, akeh buruh IT sing kepeksa kerja 12 utawa 14 jam, sing dibayar 8. Lan asring tanpa dina libur, amarga "Aku diwenehi tugas, ora ana dokumen utawa sing bengkok, lan layanan biaya dhuwit," lan kanggo 1 kesalahan ing méga, sampeyan bisa Sejatine ora gaji ing saperangan saka sasi, utamané yen sampeyan bisa minangka pengusaha individu. Intine kita kelangan ujare babagan bisnis, bebarengan karo divisi tanggung jawab; Aku tambah akeh ngadhepi kasunyatan manawa manajer campur tangan ing proses pangembangan tanpa ngerti apa-apa, dheweke mbingungake data bisnis lan operasi aplikasi, lan minangka asil, lam wiwit.
Nalika kekacauan diwiwiti, bisnis pengin nemokake panyebabe, lan ing kene dheweke butuh panyebab universal; angel nyalahake 10+ wong, mula manajer nggabungake posisi, amarga luwih akeh tanggung jawab sing diduweni spesialis, luwih gampang ditindakake. mbuktekaken kelalaianipun. Lan ing kahanan Agile, nemokake "guilty" lan flogging minangka basis metodologi iki kanggo nindakake bisnis ing manajemen. Agile wis suwe metu saka IT, lan konsep utamane dadi syarat asil saben dina. Masalahe yaiku spesialis sing khusus banget ora mesthi duwe asil saben dina, tegese bakal luwih angel dilaporake, lan iki minangka alesan liyane kenapa bisnis pengin "ahli ing kabeh." Nanging alesan utama, mesthi, payroll - iku alesan utama kanggo kabeh owah-owahan, marga saka bonus, wong sarujuk kanggo bisa kanggo awake dhewe lan wong. Nanging ing pungkasan, kaya ing wilayah liyane, saiki mung dadi tanggung jawab, kanggo mbayar luwih murah kanggo jumlah layanan sing luwih akeh.
Saiki sampeyan bisa uga asring ndeleng artikel sing nyatakake yen pangembang uga kudu bisa nyebarake, kudu nggarap infrastruktur bebarengan karo insinyur DevOps, nanging apa sing nyebabake? Sing bener - kanggo nyuda kualitas layanan, kanggo nyuda kualitas pangembang. Mung 2 dina kepungkur aku nerangake pangembang sing bisa nulis lan maca saka macem-macem sarwa dumadi, lan padha foamed ing tutuk kanggo mbuktekaken sing padha ora tau weruh kaya iki, nanging ing setelan ana orm host, port, db, pangguna. , sandi lan iku wae…. Nanging pangembang ngerti carane mbukak penyebaran, nulis ubi ... Nanging dheweke wis lali babagan tes unit lan komentar ing kode kasebut.
Akibaté, kita ndeleng ing ngisor iki - lembur pancet, nggoleki solusi kanggo masalah njaba jam kerja, latihan pancet ing akhir minggu, lan ora kanggo nambah income, nanging kanggo njaga awake dhewe. Pangembang dipeksa kanggo bantuan engineer DevOps karo CI / CD, lan yen pangembang ora duwe wektu, kang wiwit macet, lan Managers miwiti composting otak, lan yen iki ora mbantu nambah kepinginan kanggo lembur. banjur ngetrapake denda lan denda, wong kasebut nggolek proyek anyar, ninggalake utang teknis ukuran Everest, minangka asil utang wiwit tuwuh ing antarane pangembang, amarga padha dipeksa kanggo nulis kode karo refactoring kurang supaya duwe wektu kanggo bantuan salah siji engineer DevOps lawas utawa anyar, lan manager cukup seneng karo kabeh, amarga durjana ana lan bisa langsung katon, kang tegese aturan dhasar. ing manajemen Agile wis diterusake, pelakune wis ditemokake, asil nyebat dheweke katon.
Aku tau menehi presentasi ing ITGM "nalika kita sinau ngomong "ora"" - asil banget mbukak. Akeh wong sing percaya yen tembung iki tabu, lan nganti kita mandheg mikir, masalah mung bakal tuwuh.
Artikel iki sebagian inspirasi saka aku, nanging mengko aku bisa njlèntrèhaké ing istilah kurang sopan.
Mung pangguna pangguna sing bisa melu survey. nggih.
Apa sampeyan tau nemoni ing kantor nalika majikan nyoba ngganti sawetara wong karo sampeyan?
-
65,6%Ya, aku kerep ketemu183
-
5,4%Ya, ketemu 1 wektu15
-
15,4%Ora nggatekake43
-
13,6%Aku wong kerjo, kerja lembur dhewe38
279 pangguna milih. 34 pangguna abstain.
Source: www.habr.com