Hal yang paling menyedihkan dalam situasi saat ini adalah TI secara bertahap menjadi industri di mana tidak ada kata "berhenti" sama sekali dalam jumlah tugas per orang.
Saat membaca lowongan, terkadang Anda bahkan melihat bukan 2-3 orang, tetapi seluruh perusahaan dalam satu orang, semua orang terburu-buru, hutang teknis bertambah, warisan lama terlihat sempurna dengan latar belakang produk baru, karena setidaknya ada dokumen dan komentar di kodenya, baru Produk ditulis dengan kecepatan cahaya, tetapi pada akhirnya tidak dapat digunakan untuk satu tahun lagi setelah ditulis, dan seringkali tahun ini tidak membawa keuntungan, apalagi, biaya "awan" lebih tinggi daripada penjualan layanan. Uang investor digunakan untuk pemeliharaan layanan yang belum berfungsi, tetapi telah dirilis ke jaringan sebagai pekerja.
Sebagai contoh: sebuah perusahaan terkenal yang remaster dari sebuah game lama menerima peringkat terendah dalam sejarah industrinya. Saya adalah salah satu orang yang membeli produk ini, tetapi bahkan sekarang produk ini bekerja dengan sangat buruk, dan secara teori seharusnya tidak dijual dalam bentuk ini. Pengembalian dana, penurunan peringkat, sejumlah besar larangan pengguna di forum untuk keluhan tentang layanan. Jumlah tambalan tidak luar biasa, tetapi menakutkan, tetapi semuanya sama - produk tidak dapat digunakan. Jika pendekatan ini mengarah pada hasil seperti itu untuk perusahaan yang telah berkembang sejak 1991, maka untuk perusahaan yang baru memulai, situasinya bahkan lebih buruk.
Tapi kami melihat hasil dari pendekatan ini pada bagian pengguna layanan, dan sekarang mari kita lihat masalah yang dimiliki karyawan.
Saya sering mendengar pernyataan bahwa tim DevOps seharusnya tidak ada, bahwa ini adalah metodologi, dll., Tetapi masalahnya adalah, perusahaan karena alasan tertentu berhenti mencari simpul, dba, insinyur infrastruktur dan insinyur bangunan - sekarang semuanya adalah insinyur DevOps dalam satu orang. Tentu saja, masih ada lowongan seperti itu di masing-masing perusahaan, tetapi jumlahnya semakin sedikit. Banyak yang menyebut perkembangan ini, saya pribadi melihat penurunan dalam hal ini, tidak mungkin untuk mempertahankan tingkat pengetahuan yang baik di semua bidang, dan pada saat yang sama berhasil bekerja tidak lebih dari 8 jam. Secara alami, ini adalah fantasi. Pada kenyataannya, banyak spesialis TI dipaksa untuk bekerja 12 atau 14 jam, 8 jam di antaranya dibayar. Dan seringkali tujuh hari seminggu, karena "Saya diberi tugas, tidak ada dermaga atau kurva, dan bahkan biaya layanan uang", dan untuk 1 kesalahan di cloud pada prinsipnya bisa tidak mendapatkan gaji dalam beberapa bulan, terutama jika Anda bekerja pada IP.Faktanya, kami kehilangan kata-kata kami dalam bisnis, seiring dengan pemisahan tugas, saya semakin menemukan fakta bahwa manajer merangkak ke dalam proses pengembangan, umumnya tidak memahami apa pun tentang mereka, mereka membingungkan data bisnis dan pengoperasian aplikasi, akibatnya kekacauan dimulai.
Ketika kekacauan dimulai, bisnis ingin menemukan pelakunya, dan di sini Anda membutuhkan pelakunya yang universal, sulit untuk menyalahkan 10+ orang, oleh karena itu manajer menggabungkan posisi, karena semakin banyak tanggung jawab yang dimiliki seorang spesialis, semakin mudah untuk membuktikan kelalaiannya. Dan dalam kondisi Agile, menemukan "pelakunya" dan cambuk adalah dasar dari metodologi berbisnis dalam manajemen ini. Agile meninggalkan TI untuk waktu yang lama, dan konsep utamanya menjadi - persyaratan hasil harian. Masalahnya adalah spesialis yang sangat terspesialisasi tidak selalu mendapatkan hasil harian, yang berarti akan lebih sulit untuk melaporkan, dan ini adalah alasan lain mengapa bisnis menginginkan “ahli dalam segala hal”. Tapi alasan utamanya, tentu saja, adalah gaji - itu adalah alasan utama untuk semua perubahan, demi bonus, orang setuju untuk bekerja untuk diri mereka sendiri dan orang itu. Tapi pada akhirnya, seperti di daerah lain,sekarang ini hanya menjadi tugas, dengan pembayaran yang lebih sedikit untuk sejumlah besar layanan yang diberikan.
Sekarang Anda bahkan sering dapat melihat artikel tentang apa yang seharusnya sudah dapat diterapkan oleh pengembang, harus berurusan dengan infrastruktur di sebelah insinyur DevOps, tetapi apa yang mengarah pada hal ini? Itu benar - penurunan kualitas layanan, penurunan kualitas pengembang. Hanya 2 hari yang lalu, saya menjelaskan kepada pengembang bahwa Anda dapat menulis dan membaca dari host yang berbeda, dan mereka membuktikan kepada saya dengan berbusa mulut bahwa mereka belum pernah melihat hal seperti itu, di sini mereka ada di pengaturan orm host, port, db, user, password dan hanya itu .... Tetapi pengembang tahu cara menjalankan penerapan, menulis yamls .... Tapi dia sudah lupa tentang tes unit dan komentar di kode.
Akibatnya, kita melihat hal-hal berikut - kerja berlebihan terus-menerus, mencari solusi untuk masalah di luar jam kerja, pelatihan terus-menerus di akhir pekan, dan bukan untuk meningkatkan pendapatan, tetapi untuk menjaga diri kita tetap bertahan. Pengembang dipaksa untuk membantu insinyur DevOps dengan CI / CD, dan jika pengembang tidak punya waktu, dia mulai menjahit, dan manajer mulai meninju otak mereka, dan jika ini tidak membantu meningkatkan keinginan untuk bekerja lembur, kemudian menerapkan hukuman dan denda, orang tersebut mencari pekerjaan baru. meninggalkan utang teknis sebesar Everest, sebagai akibatnya, utang mulai tumbuh di antara pengembang, karena mereka dipaksa untuk menulis kode dengan refactoring yang lebih sedikit agar memiliki waktu untuk membantu insinyur DevOps lama atau baru, dan manajer cukup senang dengan semuanya, karena ada orang yang bersalah dan dia langsung terlihat, yang berarti bahwa aturan utama dalam manajemen Agile diperhatikan, orang yang bersalah ditemukan,hasil cambuknya terlihat.
Suatu ketika di ITGM saya memberikan ceramah “kapan kita akan belajar untuk mengatakan tidak” - hasilnya sangat terbuka. Banyak orang percaya bahwa kata ini tabu, dan sampai kita berhenti berpikir seperti itu, masalah hanya akan berkembang.
Sebagian dari artikel ini terinspirasi oleh artikel ini , tetapi nanti saya mungkin akan menuliskannya dengan istilah yang kurang ramah.
DevOps atau bagaimana kita kehilangan gaji dan masa depan industri TI
All Articles