Komodifikasi yang Gagal atas Pekerjaan Teknis
(ludic.mataroa.blog)- Ekspektasi manajemen dan vendor untuk menstandarkan pekerjaan teknis seperti pabrik dan menjadikannya output yang dapat direproduksi memang besar, tetapi banyak tempat kerja masih belum berhasil mengkomodifikasikannya secara stabil dengan cara seperti itu
- Operasi ala McDonald's lebih mirip disiplin yang membuat lokasi dan tenaga kerja berbeda menghasilkan hasil yang sama, ketimbang soal kualitas itu sendiri; berbagai buku manajemen juga memandang operasi IT sebagai alur produksi semacam ini
- Penjualan perangkat lunak enterprise pada dasarnya menjanjikan penggantian SQL, data, dan pekerjaan pengembangan dengan drag-and-drop serta antarmuka yang konsisten, agar tenaga kerja menjadi dapat saling menggantikan
- Dalam organisasi nyata, lisensi perangkat lunak yang buruk dan abstraksi yang keliru tidak menyelesaikan masalah teknis; pada akhirnya sering kali engineer yang sangat hebat harus turun langsung memperbaiki model data dan keputusan teknis yang buruk
- Pekerjaan yang membutuhkan kreativitas, selera, keahlian, dan koneksi antarmanusia tidak bisa sepenuhnya direduksi menjadi papan Jira atau poin Agile, dan bahkan di dalam infrastruktur produksi skala besar, individu tetap menggerakkan sistem
Sulitnya standardisasi yang ditunjukkan McDonald's
- Manajer pertama saya, seorang data engineer yang hebat, adalah orang yang sangat mendalami memasak dan berkali-kali menilai tinggi kompleksitas operasi McDonald's
- Nilai McDonald's bukan terutama pada kualitas output itu sendiri, melainkan pada optimasi dan disiplin yang membuat karyawan dengan tingkat pendidikan dan wilayah berbeda membuat burger yang sama
- Membuat tenaga kerja tidak terampil di berbagai lokasi menghasilkan hasil yang konsisten bukanlah hal sederhana, dan contoh ini berlanjut ke pembahasan komodifikasi pekerjaan teknis
Buku manajemen memperlakukan IT seperti pabrik
- The Phoenix Project menempatkan operasi IT sebagai masalah yang mirip dengan pekerjaan pabrik manufaktur, dengan fokus pada alur kerja dan pengelolaan komunikasi di dalam organisasi
- Buku-buku bernuansa serupa seperti The Unicorn Project, Investments Unlimited, dan The Goal juga mengikuti garis ini
- The Goal adalah cerita tentang mengubah operasi pabrik nyata, dan diperlakukan sebagai karya yang menginspirasi buku-buku lainnya
- High Output Management juga memakai contoh bagaimana pekerjaan mengalir di restoran; misalnya, jika telur direbus pada waktu yang salah, roti panggang sudah dingin saat sampai ke pelanggan, untuk menjelaskan alur kerja
- Dalam pola pikir semacam ini, tema seperti skala ekonomi, throughput, dan alur kerja muncul berulang kali
Inti pitch vendor adalah substitutabilitas, bukan teknologi
- Banyak pitch produk di sebuah konferensi vendor berfokus bukan pada detail teknis, melainkan pada janji untuk menyampaikan output kerja yang cukup baik secara dapat direproduksi
- Sebuah produk tertentu dipromosikan dapat mengatur dependensi dengan editor drag-and-drop tanpa menulis SQL secara langsung
- Kenyataannya, karena aplikasi terhubung ke Postgres, SQL tidak menghilang; yang terjadi adalah lapisan abstraksi berlisensi menuliskan SQL sebagai gantinya
- Pitch semacam ini dapat terdengar bagi para eksekutif sebagai pesan bahwa “SQL yang lambat dan penuh masalah” bisa diganti dengan antarmuka konsisten dan para ahli tool dari pasar, sehingga pengiriman data di dalam organisasi menjadi mulus
- Cara Agile diterapkan dalam organisasi disfungsional rata-rata juga menunjukkan masalah serupa
- Engineer dihitung seperti mesin, output seperti komponen, dan story point seperti unit produksi, lalu tingkat pencapaian target minggu berikutnya diperiksa
Mengapa banyak pekerjaan teknis masih belum terkomodifikasi
- McDonald's umumnya bisa menyajikan kentang goreng dengan kualitas konsisten dalam 5 menit, tetapi banyak organisasi teknis membeli lisensi perangkat lunak yang buruk tanpa mampu merilis sesuatu yang bernilai
- Jalan untuk menyelesaikan masalah teknis dan model data yang buruk dengan uang pada dasarnya adalah mendapatkan engineer yang sangat hebat yang hanya berfokus pada pemecahan masalah
- Ada banyak area yang tampak mungkin dikomodifikasi, tetapi dalam praktiknya sering berupa kombinasi perusahaan yang menjual produk yang tidak bekerja dan pengambil keputusan yang tidak paham namun membelinya
- Sebagian pengambil keputusan dapat memilih memanfaatkan dukungan telepon dari wilayah berupah rendah atas nama memenuhi kepatuhan hukum, sambil tidak peduli pada pelanggan yang ingin membatalkan layanan
- Juga diceritakan pengalaman bahwa ketika harus menghubungi staf dukungan, langkah pertama adalah menelepon lini penjualan untuk mencoba cepat tersambung ke staf lokal yang memiliki wewenang
Unsur manusia tetap ada dalam pekerjaan teknis kreatif
- Hammock Driven Development dari Rich Hickey membahas alur kerja seperti memasukkan riset ke alam bawah sadar, bermeditasi, tidur, lalu mendapatkan jawaban desain
- Programmer sering mengalami fenomena jawaban muncul ketika mereka sedang menjauh dari masalah, dan ini berbeda dari pekerjaan sekadar memproduksi widget lebih cepat
- Di masyarakat ada banyak pekerjaan yang memang bertipe menghasilkan sesuatu lebih cepat, tetapi banyak hasil yang bernilai muncul di titik temu antara kreativitas yang sulit didefinisikan dan realitas produksi
- Dalam contoh seperti buku, makanan, dan operasi restoran, produksi massal atau sistem pengiriman memang bisa disempurnakan, tetapi hasil yang indah membutuhkan selera dan perhatian
- Meski pengembangan fitur hendak direduksi menjadi papan Jira dan cerita Agile, sulit mendapatkan hasil bernilai jika tidak terhubung dengan manusia
- Seperti contoh seorang kenalan yang merancang chip untuk iPhone, sekalipun ada infrastruktur pengujian dan produksi massal, individu tetap memainkan peran penting sampai-sampai rilis berikutnya bisa tertunda jika orang tertentu sakit
- Memang ada kenyataan bahwa masyarakat berjalan di atas komodifikasi, tetapi pekerjaan teknis tidak dapat dijalankan hanya dengan komodifikasi murni yang mengabaikan pemahaman atas suatu kerajinan tertentu serta kompleksitas, kebutuhan, dan kerentanan manusia
1 komentar
Komentar Hacker News
Penulis tampaknya melewatkan bahwa sebagian besar hal yang dulu disebut pekerjaan teknis kini sudah menjadi komoditas umum
Dulu mail merge benar-benar berarti mencetak banyak label alamat lalu menempelkannya satu per satu ke surat dan amplop, sekitar Word 2.0 memecahkan masalah itu pada 1990-an, lalu MailChimp mengomoditisasikannya pada abad ke-21
Pembukuan berpasangan juga dulu merupakan pekerjaan teknis yang dilakukan orang dengan pelatihan tinggi, tetapi sekarang pemilik toko cukup memindai barcode dan pelanggan membayar dengan tap
Belum ada antarmuka drag-and-drop yang bisa dipakai untuk hal yang lebih rumit daripada Scratch, tetapi bagian sulitnya bukan lagi pekerjaan teknis merangkai library melainkan pengumpulan kebutuhan
Memasukkan library kriptografi berkualitas tinggi, membawa peta interaktif ke sebuah website, atau mengedit website secara WYSIWYG sekarang lebih mudah daripada sebelumnya
Penulis benar bahwa kita tidak bisa mendudukkan anak 18 tahun yang bosan di depan IDE lalu menyuruhnya membuat ERP, tetapi banyak pekerjaan remeh di IT kini memang sudah menjadi produk
Saya melihat pekerjaan remeh di industri teknologi lebih banyak bertambah daripada berkurang: saat ini ada pekerjaan remeh sebesar X, lalu teknologi baru Z muncul dan menurunkannya menjadi 0.1X, tetapi pada saat yang sama Z memungkinkan cara kerja baru sehingga sebagai efek samping muncul pekerjaan remeh lain. Maka jumlah pekerjaan remeh saat ini menjadi Y, dan Y kira-kira tetap dekat dengan X
Jika kemajuan teknologi berhenti pada 2000-an, pekerjaan remeh yang berasal dari 1990-an mungkin hari ini nyaris menjadi 0, tetapi teknologi baru membawa otomatisasi sekaligus pekerjaan remeh baru
Contoh terbaru adalah alat AI. Ada alat untuk menghasilkan suara, gambar, video, dan teks, tetapi untuk membuat produk atau pengalaman yang benar-benar berbeda tetap dibutuhkan pekerjaan remeh untuk menggabungkan alat seperti ChatGPT dan Stable Diffusion
Semakin banyak yang dikomoditisasi, masalahnya naik ke tingkat yang lebih tinggi, dan engineer spesialis yang direkrut juga bergerak ke lapisan stack yang lebih atas
Di antara produk startup yang baru-baru ini dijadikan SaaS, tampaknya ada proporsi tinggi produk yang masih belum benar-benar bisa melakukan hal yang diinginkan. Mereka membuat orang membayar untuk memakai layanan, lalu mengumpulkan use case pelanggan sebagai target implementasi agar bisa dikomoditisasi untuk pelanggan lain; akibatnya lead time memanjang dan kekayaan intelektual ikut bocor
Templatisasi SQL adalah hal yang selalu disalahpahami oleh para eksekutif. SQL bertahan sangat lama di industri secara mengejutkan, dan sebenarnya bekerja cukup baik. Sebanyak 99% wrapper atau DSL yang diletakkan di atasnya justru membuatnya jauh lebih buruk, dan untuk pekerjaan yang sedikit saja tidak biasa pada akhirnya tetap harus turun ke SQL. Akhirnya, alih-alih merekrut ahli SQL, kita harus membina ahli wrapper SQL bergaya SaaS DSL X yang bahkan sebenarnya tidak ada
Masalah mendasarnya mungkin adalah produk-produk seperti ini dirancang agar bagi pembeli yang tidak bekerja di bidang tersebut tampak seperti peralatan rumah tangga yang “tinggal beli, colok, lalu masalah selesai”
Banyak produk sebenarnya tidak menyelesaikan masalah; hanya terlihat seolah menyelesaikannya karena orang lain juga membelinya. Dan agar bisa naik jabatan, orang harus berbohong bahwa implementasinya berhasil. Hal seperti mail merge memang benar-benar sudah merupakan masalah yang selesai seperti ketel listrik, dan untuk masalah seperti itu cukup dicoba langsung saja
Masalah yang lebih besar adalah pemberi kerja saya membeli Workday dengan keyakinan bahwa itu seperti ketel listrik, padahal struktur organisasi kami terlalu kacau untuk bisa dimodelkan sama sekali
Tahun ini untuk pertama kalinya saya sadar bahwa struktur organisasi yang cukup buruk di perusahaan besar adalah semacam utang teknis. Kita akhirnya harus melakukan segala macam hal aneh untuk mengetahui siapa bekerja di bawah siapa, dan apa yang boleh dilihat pengguna ini di database tersebut
Dibandingkan 1994 atau 2004, seberapa sederhanakah sekarang menjalankan bisnis, membuat website, merencanakan perjalanan, dan membayar tagihan?
Kadang terasa generasi sebelumnya menjalani hidup dengan tempo yang lebih santai dan karena itu hidupnya lebih penuh. Sekarang waktu terasa berjalan terlalu cepat dan stres juga lebih tinggi
Belum lama ini saya melihat setidaknya tiga orang berusia di atas 60 tahun di bank kebingungan menangani urusan sederhana dan meminta bantuan pegawai. Itu seharusnya mudah dilakukan lewat online banking, tetapi karena situasinya pengecualian sistem tidak mendukungnya, akhirnya mereka harus membuat janji, dan jadwal paling cepat baru tersedia 3~4 bulan kemudian
Salah satu dari mereka perlu menarik uang dari rekening yang diblokir untuk membeli kayu bakar agar bisa menghangatkan rumah, tetapi pegawai bank hanya menyuruhnya menunggu 3 bulan
Dua tahun lalu ayah saya tidak bisa menemukan cara untuk menelepon rumah secara sederhana dari Sisilia. Pada 1970-an, itu cukup dengan masuk ke bar terdekat dan memasukkan beberapa koin
Dulu orang biasa umumnya bisa memperbaiki sendiri lampu, mobil, pemanas, dan pintu yang bukan pintu otomatis, tetapi sekarang harus memanggil ahli
Upaya untuk mengomoditisasi pekerjaan teknis sepenuhnya adalah ide yang buruk, dan semoga akan terus gagal
Meski begitu, saya sudah membaca The Phoenix Project dua kali dan sangat tidak suka sebagian besar Scrum, tetapi saya tidak merasa buku itu mengajukan hal seperti itu
Inti yang saya dapat adalah: punya sistem yang jelas untuk menjalankan dan mengelola pekerjaan yang bisa diulang, mengotomatisasi jika memungkinkan, mengurangi pekerjaan yang sedang berjalan agar orang tidak terikat pada begitu banyak tugas, membagikan informasi secara luas agar beberapa anggota tim bisa mengerjakan tugas yang sama, memastikan kita benar-benar mengerjakan hal yang dibutuhkan bisnis, serta mengurangi kebisingan dan pekerjaan tak terencana agar karyawan bisa melakukan pekerjaan bernilai tinggi yang mereka nikmati alih-alih tersesat di rawa kekacauan
Inti The Phoenix Project bukanlah mengubah orang menjadi boneka otomatis yang bisa diganti-ganti, melainkan membangun sistem yang memberi keleluasaan dan waktu untuk melakukan pekerjaan yang benar-benar bernilai, yang tidak bisa diotomatisasi atau disistematisasi
Saya pernah mengelola pabrik dan juga pernah menjadi developer, jadi saya melihat kedua sisinya: menjadikan developer seperti buruh pabrik produksi itu tidak masuk akal, tetapi pekerjaan yang tampak seperti kerja pabrik—seperti tugas yang sudah dikenal dan langkah yang bisa diulang—memang harus diperlakukan dengan cara yang mirip
s/manufacturing/IT/gdan memperbaruinya dengan referensi modernBukan berarti saya membenci bukunya. Saya membacanya setengah, dan berusaha membuat tiap tim membacanya agar pola pikir mereka bergeser ke arah berpikir berbasis sistem. Hanya saja, saya tidak bisa bilang buku itu jauh lebih dalam atau lebih penuh wawasan daripada The Goal
Saya memang mengolok-olok gaya penulisannya, tetapi tetap layak dibaca. Banyak hal yang salah dilakukan orang dalam tugas yang sudah dikenal atau langkah yang bisa diulang tidak bisa disalahkan pada cara berpikir ala Phoenix Project
Hanya saja, dalam pemrograman jarang ada pekerjaan berupa menjalankan tugas yang sudah dikenal dalam langkah-langkah berulang. Kalau itu sampai terjadi, sering kali penyebabnya adalah kesalahan taktis dalam mengelola pemangku kepentingan sehingga tidak ada waktu untuk otomatisasi
Kalau dibaca dengan cermat, kesimpulannya memang mengarah ke paragraf terakhir itu, tetapi saya juga tahu pasti bahwa kebanyakan manajer yang saya temui tidak memahami perbedaan antara produksi widget dan perancangan sistem
Pembelajaran berkelanjutan, otomatisasi, dan instrumentasi adalah alat yang memungkinkan poin 1~5 di atas
Saya tidak menangkap pesan “bekerjalah lebih keras agar bisa menyelesaikan lebih banyak pekerjaan lebih cepat” dari The Phoenix Project
https://scrumguides.org/scrum-guide.html
Biasanya yang mengerikan adalah berbagai macam hal yang ditambahkan orang di atasnya sambil menyebutnya Scrum. Cara terbaik yang pernah saya temukan untuk melawan Scrum abal-abal bukanlah dengan berdebat, melainkan berpura-pura sangat setia secara puritan pada ajaran aslinya. Terlihat kurang seperti pembangkang, dan lebih mudah memberi pengaruh
Judulnya membingungkan. Bukankah “commodify” berarti “membuat sesuatu bisa dijual”, yaitu mengomersialkannya? Teknologi bukannya sudah menghasilkan miliaran dolar?
Sepertinya yang dimaksud penulis adalah commoditization, yakni menjadikan pekerjaan teknis sebagai pekerjaan umum yang bisa dilakukan oleh karyawan mana pun yang bisa saling menggantikan
Menurut https://en.wikipedia.org/wiki/Commoditization, commoditization adalah ketika sesuatu yang tadinya eksklusif menjadi barang umum, sedangkan commodification adalah ketika sesuatu yang tadinya tak bisa dijual menjadi bisa dijual
Apakah saya terlalu cerewet? Saya pikir keduanya punya arti yang berbeda
Edit: Setelah melihat Wiktionary, di https://en.wiktionary.org/wiki/commodification tertulis bahwa keduanya kadang dipakai saling menggantikan. Mungkin ini cuma kebingungan yang umum
https://www.merriam-webster.com/dictionary/commodify
Artinya adalah “mengubah sesuatu seperti nilai intrinsik atau karya seni menjadi komoditas”, jadi commodify lebih dekat dengan pembicaraan tentang commoditization
Minyak adalah komoditas karena ada banyak produsen dan semuanya membuat hal yang sama, jadi tidak terlalu penting membeli dari pihak yang mana pun
Dalam analogi McDonald’s, pengembang bukanlah remaja yang bekerja di depan mesin, melainkan insinyur yang merancang mesinnya. Dalam analogi itu, komputerlah yang menjadi remajanya
Pemrograman bukan pekerjaan, melainkan meta-pekerjaan. Sekali saya membuat daftar instruksi, komputer akan terus menjalankan pekerjaan itu 24 jam sehari, dan saya pergi menulis daftar instruksi baru untuk pekerjaan lain
Jika saya menulis daftar instruksi yang sama dua kali, pada dasarnya saya sedang melakukan sesuatu dengan keliru. Karena itu saya selalu mengerjakan hal baru, dan karena tidak melakukan hal yang sama dua kali, sulit untuk memperkirakan berapa lama waktunya
TI bukan pabrik, melainkan pekerjaan membangun pabrik
Saya rasa banyak konflik antara pengembang dan manajer berasal dari istilah “manajer” yang terlalu disamaratakan. Manajer McDonald’s mengawasi apakah karyawan mengikuti proses yang menghasilkan produk. Jelas apakah proses itu diikuti atau tidak, prosesnya diasumsikan valid, dan jelas pula apakah hasilnya keluar atau tidak
Sebaliknya, programmer dipekerjakan untuk mengembangkan proses yang akan diikuti mesin. Orang yang mengelola karyawan ini mungkin juga memiliki proses yang harus diikuti programmer, dan mungkin jelas apakah itu diikuti atau tidak, tetapi tidak pasti apakah proses itu valid, apakah tindakan tertentu akan mengarah pada hasil yang ditentukan, atau bahkan apakah hasil itu sendiri jelas
Namun kedua peran itu sama-sama disebut “manajer”
Dalam analogi mesin ini, programmer adalah tipe manajer lain yang bukan mengelola manusia, melainkan mengarahkan mesin. Hanya saja mesin-mesin itu dilepas ke dunia, dan programmer tidak terus-menerus mengawasinya
Tentu saja, seperti komentar lain, ada kemungkinan konsep ini sepenuhnya omong kosong. Namun bahkan jika beberapa tahun lagi saya sadar ini ide yang bodoh, setidaknya lebih baik ada orang lain yang sama-sama ikut merasa malu daripada malu sendirian
Sekitar 10 tahun lalu, beberapa teman saya yang insinyur mesin terkejut melihat saya belajar pengembangan perangkat lunak
Mereka berkata hal-hal seperti, “Masih banyak pekerjaan yang tersisa? Bukannya semua yang dibutuhkan sudah bisa dilakukan dengan sistem yang ada?”
Kesalahpahamannya adalah anggapan bahwa membuat sistem untuk menyelesaikan masalah baru itu mudah dan sudah dikomoditisasi, sehingga tidak perlu lagi menulis kode
Kenyataannya, membangun perangkat lunak jarang semudah mengatur UI. Kita tetap memerlukan teks untuk mengekspresikan aturan logika dan alur, membutuhkan version control untuk melacak dan me-roll back perubahan sistem, dan pada akhirnya tetap membutuhkan programmer
Coding tidak akan hilang; hanya tingkat abstraksinya yang naik
Industri teknologi sudah lama berusaha mengomoditisasi pengembang, dan menurut saya COBOL maupun Java juga berada dalam arus itu
Namun apa pun yang kita abstraksikan, selalu ada sifat mendasar yang muncul kembali. Walaupun requirement tampak sederhana dan ada framework tingkat tinggi, banyak perangkat lunak kita tetap tidak bekerja dengan baik
Seperti kata penulis, solusi yang sesungguhnya adalah pengembang yang kompeten dan peduli. Dari situlah orang bisa membangun karier
Jika bekerja cukup lama di bidang yang sama, pola-pola yang mirip memang terus berulang, tetapi requirement bisnis masing-masing selalu sedikit berbeda. Di tiap lapisan stack, perbedaan ini membesar, dan secara keseluruhan muncullah sangat banyak pekerjaan yang non-komoditas dan bersifat kustom
Itulah sebabnya tidak ada dua produk yang benar-benar sama, dan mengapa tidak hanya ada satu perusahaan raksasa global yang memproduksi semuanya
Saya sudah tak terhitung sering melihat pengembang bersemangat ketika muncul peluang komoditisasi diri dalam bentuk memecah diri sendiri secara Tayloristik
Industri kesehatan adalah contoh tandingan yang terpikir oleh saya saat muncul pembahasan tentang komoditisasi otomatis. Secara emosional ada dua daya tarik. Pasien tidak suka dipindah-pindahkan dari satu dokter ke dokter lain. Mereka memahami bahwa komoditisasi sampai tingkat tertentu disertai peningkatan spesialisasi, dan setiap tambahan satu serah terima berarti tambahan satu titik kegagalan
Yang kedua adalah bahwa status dan cara kerja bisa dikemas agar tampak seperti status yang lebih tinggi. Jika poin pertama dijadikan yang utama dan poin kedua dibiarkan terbaca sebagai subteks, biasanya itu cukup efektif. Para pekerja lalu mempertahankan kemampuan yang lebih umum, dan lebih mengandalkan saling berkonsultasi daripada serah terima
Jalur perakitan adalah spesialisasi berurutan; lihat saja kesalahan serah terima yang berkaitan dengan jam kerja residen medis
Operasi, inovasi, pemeliharaan. Pilih tiga dari ketiganya
Lebih baik jika dikerjakan oleh tim yang sama atau tim-tim yang sangat berdekatan
Idealnya, setiap orang dalam tim harus menjalankan ketiga fungsi itu semua dalam kadar yang berbeda-beda. Dari situlah inspirasi untuk perbaikan muncul
Anda bisa membagi tiga fungsi ini menjadi tiga grup dan tiga lapisan manajemen, tetapi hasilnya biasanya biasa-biasa saja dan orang-orang menjadi tidak bahagia. Terutama mereka yang terjebak di tim pemeliharaan, yang melakukan pekerjaan penting tetapi jarang dihargai
Anda juga bisa membuat satu tim bertanggung jawab atas ketiganya, tetapi sering kali yang direkrut justru manajer yang terlalu teroptimasi untuk salah satu saja. Dan kebetulan, yang satu itu adalah fungsi yang menghasilkan imbalan lebih baik pada kuartal berikutnya
Sulit untuk sekaligus membela keunggulan operasional, pemeliharaan yang telaten, dan waktu untuk berpikir mendalam dalam satu budaya yang sama. Memang wajar kalau itu sulit
Jika melihat peran business intelligence/analis, industri mencoba mengganti orang yang memakai SQL dengan orang yang memakai alat seperti Tableau
Polanya seperti, “cukup hubungkan ke penyimpanan data apa pun, lalu staf nonteknis bisa melakukannya dengan drag-and-drop”
Ada beberapa masalah. Pertama, mereka lupa bahwa output hanya bertambah secara linear, jadi harus merekrut lebih banyak tenaga kerja berupah rendah. Semuanya berbasis UI sehingga orang tetap harus memutar engkolnya secara manual
Kedua, kode transformasi logika bisnis yang sangat rumit dan berantakan tetap muncul, hanya saja sekarang tersembunyi di dalam UI. Orang yang tahu logikanya apa hanyalah PM atau tim bisnis
Organisasi engineering menyediakan dataset berkualitas tinggi yang teruji, meski cukup mentah, untuk menjawab pertanyaan bisnis. Bagian sulitnya adalah memecahkan masalah bagaimana menghasilkan output bisnis dari data sumber dengan cara-cara yang aneh
Sekarang solusinya disimpan di workbook Tableau dan tidak bisa dipakai sebagai input lain. Harus disalin-tempel lewat UI ke workbook Tableau yang baru
Karena sudah membeli layanan cloud Tableau, tim BI memang bisa membuat ekstraksi SQL lebih ketat dan lebih terpelihara. Tableau tampak seperti ingin mengambil sebagian bisnis Databricks, tetapi sekarang pekerjaan itu dilakukan oleh tim non-engineering. Entah apakah ini akan berhasil
Misalnya ada pertanyaan umum, “pengguna kita berasal dari negara mana?” Apakah yang dimaksud negara yang mereka isi di formulir pendaftaran, negara tempat mereka sedang mengakses layanan, negara dari metode pembayaran mereka, negara kelahiran, negara kewarganegaraan, negara tempat tinggal saat ini, alamat pengiriman, atau alamat penagihan—semuanya berbeda
Jika dataset cukup besar, masing-masing akan menghasilkan jawaban yang berbeda. Di ranah “global fintech”, kasus-kasus aneh seperti ini akan menjadi hal yang biasa
Pengguna Tableau berupah rendah yang tipikal kemungkinan besar akan mencari kode negara yang terlihat, menjalankan count, lalu menyatakannya sebagai kebenaran
Pengguna Tableau yang sedikit lebih cerdas akan meminta engineer menuliskan SQL untuknya
Harus ada orang yang memahami dataset dan sistem sumber agar bisa balik bertanya ke pihak bisnis, serta memaksakan pertanyaan dan konteks yang tepat
Alat-alat sejenis Tableau bagus untuk menggantikan “pekerjaan teknis” seperti menempelkan query SQL yang sama ke pgAdmin setiap hari lalu mengirim CSV lewat email, tetapi tidak akan membuat pekerja berkeahlian rendah yang berpusat pada UI jadi berpikir lebih baik
Skala linear output terhadap biaya bisa dimodelkan di spreadsheet, lalu dibebankan ke pelanggan atau ditagihkan. Semua orang di lapisan bisnis merasa nyaman dengan dinamika seperti ini
Sebaliknya, situasi ketika seorang spesialis khusus bisa menghasilkan output 1000 kali lipat dengan sedikit usaha, tetapi tidak yakin apakah itu akan memakan waktu sehari atau seminggu, membuat semua orang tidak pasti dan membuat para pemimpin gelisah. Jika semua orang menginginkan mediokritas yang terasa aman, ini sulit dijual
Poin nomor 2 secara ironis justru membutuhkan lebih banyak spesialis, hanya saja jenis spesialis yang berbeda. Karena semua logika itu tetap harus dipelihara
Pada akhirnya ini akan berjalan seperti program penciptaan kerja dan menjadi lebih mahal, tetapi akan mendistribusikan nilai sesuai dengan wilayah kekuasaan yang berpengaruh secara politik, dan karena itu akan berhasil
Mula-mula semua orang backend dipecat dengan alasan mereka tidak memahami bisnis, lalu Tableau dijadikan backend yang baru. Fakta bahwa orang backend selama ini menyerap dan merapikan kebutuhan bisnis diabaikan
Setelah orang bisnis terjebak dalam jaring kusut yang mereka buat sendiri, mereka memanggil konsultan Tableau, dan para konsultan itu menyedot uang tanpa membangun apa pun yang bernilai
Saya datang dari bidang teknik struktur, dan perangkat lunak tampak lebih mirip perencanaan kota daripada bidang teknik lain
Skalanya terlalu besar. Seiring waktu, tidak mengherankan jika makin banyak jabatan berbeda yang menjelaskan jenis pekerjaan tertentu, seperti backend, frontend, firmware, engineer machine learning, data scientist, analis keamanan, atau pengembang kernel
Saat standar berkembang, saya bisa membayangkan bahwa pada suatu titik nanti orang mungkin memerlukan sertifikasi yang sangat spesifik untuk bekerja di posisi-posisi seperti ini. Bisa juga berubah ke bentuk lain, tetapi efek kristalisasinya jelas terlihat
Memikirkan perangkat lunak sebagai pabrik juga mungkin dan bisa berguna. Namun tidak semuanya cocok dengan metafora itu. Misalnya ketika memikirkan integrasi produk, atau ketika yang dimaksud adalah layanan, bukan aplikasi
Pabrik mengandaikan bahwa ada sesuatu yang diproduksi, tetapi dalam banyak kasus perangkat lunak bukanlah hasil akhir; ia sendiri adalah sarana yang memungkinkan sesuatu terjadi
Dalam perangkat lunak, sebagian besar pekerjaan telah diotomatisasi secara asimtotik. Karena itu kita lupa bahwa pekerjaan itu dulu pernah merupakan tenaga kerja
Cukup pikirkan penyalinan file yang sederhana. Bisa dibilang itu adalah “juru tulis otomatis”
Penyalinan telah diotomatisasi sedemikian rupa sehingga salinan dalam jumlah sangat besar yang dilakukan sistem kita menjadi tak terlihat, dan juga lenyap sebagai titik diferensiasi ekonomi
Selain itu, secara meta ini juga berguna. Program penyalin itu sendiri pun mudah disalin dengan algoritme yang sama
Intinya, menulis perangkat lunak seperti matematika karena selalu menghabiskan waktu di perbatasan antara yang diketahui dan yang belum diketahui. Sebab semua wilayah yang sudah sepenuhnya diketahui dan terkarakterisasi akan diotomatisasi dengan cara yang sekaligus menyelesaikan masalah untuk semua orang dan membakar habis tanah ekonomi dari aktivitas itu sendiri
Pekerjaan perangkat lunak selalu mengandung unsur eksplorasi, yaitu riset, untuk masuk ke wilayah yang belum diketahui dan mencari kekayaan di sana. Entah wilayah baru itu mulia atau tragisnya biasa-biasa saja
Wilayah yang dapat diautomatisasi oleh manajer tanpa keahlian perangkat lunak ibarat pohon buah yang sudah dijinakkan agar buahnya mudah dipetik. Namun pohon seperti itu sudah tidak berbuah lagi
Jika definisi masalah dari manajer itu tidak naik lagi ke wilayah yang menyebalkan karena menuntut kreativitas dan keahlian, yakni wilayah yang sulit diautomatisasi, maka yang dilakukan bukan lagi pekerjaan yang terdiferensiasi atau bernilai