- Perusahaan menghabiskan biaya besar untuk mengejar kapabilitas operasional seperti kemampuan manufaktur ala Toyota, kualitas six-sigma, dan rantai pasok ala Dell, tetapi program perbaikan jarang berujung pada kinerja yang berkelanjutan
- TQM adalah contoh yang pernah digunakan luas lalu cepat tersisih; kurang dari 10% perusahaan Fortune 1000 memiliki program TQM yang berkembang baik
- Penyebab kegagalan bukan terutama pilihan alat tertentu, melainkan cara program baru bertaut dengan struktur fisik, ekonomi, sosial, dan psikologis; pada akhirnya perbaikan menjadi masalah sistem
- Ketika kesenjangan kinerja membesar, organisasi memilih antara Work Harder, yaitu bekerja lebih lama, dan Work Smarter, yaitu membangun kapabilitas, tetapi opsi kedua mudah tersisih karena jeda waktu dan risiko kegagalan
- Shortcuts yang mengurangi waktu perbaikan menarik karena menaikkan output jangka pendek, tetapi jika penurunan kapabilitas yang terlambat terlihat terus menumpuk, organisasi dapat terjebak dalam Capability Trap
Paradoks kegagalan program perbaikan
- Perusahaan berinvestasi aktif dalam perbaikan proses untuk mengembangkan kapabilitas operasional seperti manufaktur, kualitas, pemahaman pelanggan, dan manajemen rantai pasok
- Pada 1997, total belanja perusahaan AS untuk konsultan manajemen dan pelatihan mencapai lebih dari 100 miliar dolar, dan sebagian besar digunakan untuk mengejar kapabilitas operasional perusahaan-perusahaan unggul
- Meski ada beberapa keberhasilan dramatis, banyak program perbaikan gagal menghasilkan dampak yang berarti
- TQM memperlihatkan paradoks ini dengan jelas
- Terinspirasi oleh keberhasilan perusahaan Jepang pada 1980-an, TQM menjadi sangat populer di kalangan perusahaan AS
- Pada pertengahan 1990-an, minat akademisi dan media bisnis menurun, dan TQM tersisih oleh inovasi baru seperti re-engineering
- Perusahaan yang secara serius berkomitmen pada disiplin dan metode TQM mencatat kinerja lebih tinggi dibanding pesaing
- Dalam satu studi, kurang dari 10% perusahaan Fortune 1000 memiliki program TQM yang berkembang baik
- Dalam studi lain, TQM adalah alat bisnis ketiga yang paling banyak digunakan pada 1993, tetapi turun ke peringkat ke-14 pada 1999
- Teknik perbaikan lama kadang muncul kembali dengan nama baru
- Disiplin inti pengendalian proses statistik dan pengurangan variasi berlanjut sebagai six-sigma
- quality circle kembali disebut sebagai high-performance work team
Yang lebih sulit daripada alat adalah struktur implementasi
- Alat dan teknik peningkatan kinerja berkembang pesat, dan peningkatan teknologi informasi serta konsultan membuat lebih mudah mempelajari teknik apa yang digunakan oleh siapa
- Bagi sebagian besar manajer, hambatan yang lebih besar bukanlah mengetahui metode baru, melainkan mengimplementasikannya dengan sukses dalam pekerjaan sehari-hari
- Kapabilitas seperti program kualitas six-sigma tidak dapat dibeli seperti produk turnkey; kapabilitas itu harus dikembangkan di dalam organisasi
- Selama lebih dari 10 tahun, lebih dari 12 studi kasus mendalam dilakukan di industri telekomunikasi, semikonduktor, kimia, minyak, otomotif, dan produk rekreasi
- Observasi, wawancara peserta, bahan arsip, dan metrik kuantitatif digunakan
- Model untuk menangkap dinamika implementasi dan perbaikan juga dikembangkan bersama
- Alasan kebanyakan organisasi tidak memperoleh manfaat penuh dari inovasi perbaikan hampir tidak terkait dengan pilihan alat perbaikan tertentu
- Program perbaikan baru bekerja di tempat alat, peralatan, pekerja, manajer, serta struktur fisik, ekonomi, sosial, dan psikologis saling bertaut, sehingga menjadi masalah sistemik
Fisika dasar perbaikan: waktu dan kapabilitas
- Kinerja nyata suatu proses ditentukan oleh waktu yang dihabiskan untuk bekerja (Time Spent Working) dan kapabilitas proses (Capability) untuk menjalankan pekerjaan tersebut
- Dalam manufaktur, output bersih yang dapat digunakan ditentukan oleh hasil perkalian jam kerja harian dan produktivitas, yaitu output yang dapat digunakan per jam kerja
- Kinerja dapat ditingkatkan dengan bekerja lebih banyak atau berinvestasi lebih banyak dalam perbaikan, tetapi hasil kedua cara itu berbeda
- Jika jam kerja mingguan dinaikkan 20%, output dapat naik 20% selama lembur dipertahankan
- Perbaikan kapabilitas proses meningkatkan output dari semua jam kerja yang dimasukkan setelahnya
- Lembur untuk mengerjakan ulang produk cacat hanya meningkatkan output selama lembur berlanjut, sedangkan menghilangkan akar penyebab cacat secara berkelanjutan mengurangi kebutuhan pengerjaan ulang
- Kapabilitas diperlakukan sebagai aset (stock) yang terakumulasi seiring waktu
- Waktu yang digunakan untuk perbaikan meningkatkan investasi kapabilitas
- Karena butuh waktu untuk menemukan akar penyebab serta menemukan, menguji, dan mengimplementasikan solusi, ada jeda antara aktivitas perbaikan dan perubahan kapabilitas
- Kapabilitas yang tidak dipelihara secara berkala akan menurun akibat keausan mesin, penyimpangan proses, penuaan desain, dan prosedur yang menjadi usang
- Jeda perbaikan bergantung pada kompleksitas teknis dan organisasi dari proses
- Jeda perbaikan proses yang relatif sederhana, seperti yield mesin di job shop, berada pada skala beberapa bulan
- Jeda perbaikan proses yang kompleks seperti pengembangan produk bisa mencapai beberapa tahun atau lebih
- Di organisasi dengan tingkat perubahan produk dan personel yang tinggi, masa pakai kapabilitas yang telah diperbaiki juga menjadi lebih pendek
Ketegangan antara Work Harder dan Work Smarter
- Manajemen menetapkan target seperti permintaan pelanggan, volume pemrosesan klaim asuransi, atau jumlah peluncuran produk baru per kuartal sebagai Desired Performance
- Selisih antara kinerja aktual dan target menjadi Performance Gap, dan di organisasi yang diteliti jarang ditemukan proses yang melampaui ekspektasi
- Di organisasi yang enggan menambah sumber daya atau merekrut tambahan, ada dua pilihan dasar untuk menutup kesenjangan kinerja
-
Loop Work Harder
- Ketika ada kesenjangan kinerja, manajer meningkatkan tekanan kerja melalui cara seperti menaikkan kecepatan kerja, lembur, target yang lebih agresif, atau penalti untuk target yang tidak tercapai
- Cara yang lebih halus seperti frekuensi tinjauan kinerja, tingkat detail tinjauan, dan jabatan peninjau juga termasuk dalam tekanan kerja
- Di satu perusahaan, seorang wakil presiden senior meninjau kinerja tiap mesin di lantai pabrik, dan ini menjadi pesan agar mesin terus dijalankan berapa pun biayanya
- Seorang manajer proyek, ketika jadwal subsistem yang ia tangani terlambat, diminta melakukan panggilan laporan status setiap jam sampai prototipe memenuhi spesifikasi
-
Loop Work Smarter
- Manajer dapat mencoba meningkatkan kapabilitas proses dengan memulai program perbaikan, mendorong eksperimen ide baru, dan berinvestasi dalam pelatihan
- Jika berhasil, seiring waktu kapabilitas membaik dan throughput meningkat, sehingga kesenjangan kinerja berkurang
- Investasi perbaikan dapat menghasilkan dampak yang lebih besar dalam jangka panjang, tetapi ada jeda yang cukup lama sebelum efeknya terlihat dan ada risiko gagal menemukan akar penyebab atau menerapkan alat baru
- Dalam masalah yang mendesak, Work Harder sering dipilih
- Jika lini manufaktur yang menangani pelanggan penting berhenti, manajer cenderung lebih mudah menghidupkan kembali lini dan mendorong lembur sampai pengiriman selesai daripada memberikan pelatihan peningkatan keandalan
- Jika setelah respons sementara selesai organisasi tidak kembali ke aktivitas perbaikan, cara bekerja lebih keras menjadi cara operasi standar
Loop reinvestasi dan perangkap kapabilitas
- Karena organisasi hampir tidak memiliki sumber daya longgar, ketika tekanan kerja meningkat orang mengurangi aktivitas non-kerja seperti istirahat dan menambah lembur
- Lembur pekerja pengetahuan sering kali tidak dibayar dan berlanjut sampai malam dan akhir pekan, merampas waktu untuk keluarga dan aktivitas komunitas
- Ketika waktu tidak bisa lagi ditambah, satu-satunya pilihan untuk mengejar kesenjangan kinerja yang terus membesar adalah mengurangi waktu perbaikan
-
Loop Reinvestment
- Jika investasi perbaikan berhasil, kinerja naik dan kesenjangan kinerja menyusut, sehingga lebih banyak waktu dapat digunakan untuk perbaikan dan tercipta siklus baik
- Sebaliknya, jika kesenjangan throughput ditanggapi dengan tekanan kerja, waktu perbaikan berkurang, kapabilitas menurun, dan kesenjangan kinerja makin membesar, yang berujung pada siklus buruk berupa tekanan kerja yang lebih kuat dan perbaikan yang lebih sedikit
- Dalam kasus perbaikan yang berhasil, sumber daya yang diperoleh dari peningkatan produktivitas secara eksplisit dialokasikan kembali ke aktivitas perbaikan, sehingga memperkuat proses reinvestasi
- Di banyak organisasi, tekanan biaya dan jadwal berujung pada downsizing atau target kinerja yang lebih tinggi, merampas sumber daya perbaikan, dan membuat kapabilitas mandek atau turun
-
Loop Shortcuts
- Jalan pintas seperti melewatkan rapat perbaikan, menunda preventive maintenance yang sudah dijadwalkan, atau mengabaikan persyaratan dokumentasi segera menambah waktu kerja
- Karena penurunan kapabilitas tidak langsung terlihat, jalan pintas tampak efektif dan menarik dalam jangka pendek
- Manajer yang menunda preventive maintenance memperoleh masa tenggang berupa terhindarnya downtime terjadwal dan penghematan biaya perawatan, tetapi kemudian yield dan waktu operasi turun akibat penuaan dan keausan peralatan
- Insinyur perangkat lunak yang melewatkan dokumentasi dapat menyelesaikan proyek tepat waktu, tetapi membayar biayanya ketika memperbaiki bug yang ditemukan dalam pengujian beberapa minggu atau beberapa bulan kemudian
-
Capability Trap
- Work Harder pada awalnya langsung meningkatkan total throughput dan biaya dari berkurangnya waktu perbaikan baru muncul belakangan, sehingga menciptakan situasi better-before-worse
- Work Smarter mengurangi output jangka pendek, tetapi seiring waktu peningkatan kapabilitas mengimbangi penurunan upaya kerja dan menaikkan kinerja; dinamikanya adalah worse-before-better
- Interaksi Shortcuts dan Reinvestment dapat menciptakan Capability Trap yang menjebak organisasi dalam siklus buruk penurunan kapabilitas
2 komentar
Komentar Hacker News
Ingatan saya agak kabur, tetapi ada contoh yang bagus.
Di sebuah organisasi ada pemrosesan pesanan yang penting, tetapi situasinya tidak memungkinkan untuk percaya bahwa semua informasi yang diperlukan akan datang, atau datang dengan akurat. Jadi kami membuat logika validasi yang merapikan input dan mengubah cara pemrosesan, lalu mencatat metrik tentang validasi apa yang terpicu pada tiap pesanan. Jika validasi baru ditambahkan, tanggalnya juga dicantumkan.
Dengan memublikasikan metrik ini dan sesekali membagikannya, ketika seseorang bertanya, “Apa yang terjadi kalau XYZ?”, kami bisa menjawab, “Itu sudah ditangani, dan kami mencegah #### pesanan tertahan karena XYZ.”
Ini menunjukkan bahwa tim bekerja dengan hati-hati, bahwa pekerjaan semacam ini diperlukan agar sistem terus berjalan baik, dan bahwa semua itu bisa didukung dengan data. Berkat itu, percakapan di dalam organisasi bergeser dari “Kenapa tidak terpikirkan?” menjadi “Apa yang harus kita lakukan sekarang?”, dan pengakuan terhadap kualitas preventif juga naik ke tingkat yang lebih tinggi.
Kebanyakan tim mungkin hanya akan melihat metrik seperti tingkat keberhasilan pesanan lalu selesai, tetapi jika jumlah kali data buruk ditangani dijadikan metrik, kita bisa keluar dari jebakan ketika hal-hal baik tidak terlihat.
Baru-baru ini saya mengalami hal yang persis sama di tempat kerja.
Sebagai tech lead/arsitek organisasi, saya meninjau proyek-proyek yang baru dirilis dan menemukan bagian-bagian yang mutlak harus diperbaiki karena masalah keandalan/performa yang serius. Beberapa rilis dari satu tim berada di urutan teratas daftar, tetapi PM dan engineering manager tim itu, serta orang-orang di atas, mengabaikan semua kekhawatiran karena mereka mengatakan pembaruan fitur harus diprioritaskan.
Beberapa bulan kemudian, saat saya sedang cuti, masalahnya meledak, terjadi eskalasi sev 1, beberapa pelanggan marah, dan CEO/CTO ikut terlibat. Tim yang sama, yang menulis kode ceroboh itu dan mengabaikan peringatan, bekerja siang malam untuk memulihkan layanan, dan sekarang mereka menjadi pahlawan. Khususnya manajer itu mendapatkan reputasi baik di perusahaan karena aktif berkomunikasi dan menunjukkan kepemimpinan selama insiden.
Yang lebih mengesankan adalah memperbaiki masalah yang dibuat orang lain. Saya tidak ingin membanjiri pujian kepada seseorang yang memperbaiki kesalahannya sendiri, dan saya juga tidak berharap dipuji karena memperbaiki kesalahan saya sendiri. Saya akan meminta maaf kepada semua orang karena sudah mengacaukannya sejak awal.
Saya terus memikirkan masalah pada judul ini dalam kaitannya dengan nilai saya.
Jika seseorang tertahan selama 3 bulan lalu saya membantunya dalam 40 menit, nilai saya jelas bagi semua orang. Namun jika saya bekerja bersama mereka sepanjang waktu sehingga tidak ada yang tertahan selama 3 bulan, nilai saya menjadi tidak jelas. Saya tidak tahu bagaimana harus menghadapi paradoks ini.
Jika kita mencurahkan lebih banyak usaha dan waktu, sering kali imbalannya tertinggal sementara kita justru diharapkan mencurahkan lebih banyak usaha dan waktu lagi. Nilai dan peluang lebih mirip proses yang kacau terhadap usaha dan waktu.
Pada akhirnya, kita harus berusaha menjaga beban kerja agar pikiran cukup jernih untuk menangkap peluang ketika peluang itu muncul. Rekan kerja yang jujur dan seimbang membantu, tetapi pada akhirnya itu adalah hal yang harus dilakukan sendiri.
Sekalipun atasan saya mencoba menjelaskan, pada PHK berikutnya bisa saja kepala saya yang terpotong.
Mereka memang memberi tahu perusahaan lain bahwa saya bagus dalam hal semacam ini, tetapi tidak ada yang berlanjut. Itu adalah hari pertama sekaligus terakhir saya sebagai kontraktor untuk perusahaan kecil.
Karena itu, moral anggota tim tidak patah. Secara psikologis, anggota tim perlu kontribusi individualnya diakui.
Atasan seperti ini sering kali sebelumnya adalah individual contributor yang kompeten lalu menjadi team lead, dan karena mereka sendiri adalah orang yang mahir dalam keterampilan itu, mereka berada pada posisi terbaik untuk menilai individual contributor yang mereka kelola.
Gambarkan bencana yang berhasil dihindari secara jelas agar orang-orang bisa membayangkan gambaran yang konkret.
Variasi lainnya adalah mengalokasikan sumber daya secara berlebihan untuk mencegah masalah yang benar-benar pernah terjadi sekali, sementara masalah yang lebih serius tetapi belum pernah terjadi justru kurang diperhatikan.
Ini adalah masalah manajemen. Sebab, meskipun secara rasional lebih masuk akal mengerjakan hal lain yang lebih penting, tidak ada orang yang ingin bertanggung jawab ketika insiden yang sama terulang.
Seperti luka kecil yang digantikan oleh jaringan organisasi yang keras dan tidak fleksibel. Hanya karena sesuatu pernah terjadi sekali, bukan berarti organisasi harus selalu berubah agar hal itu tidak pernah terjadi lagi; reaksi berlebihan seperti itu bisa menjadi beban besar di masa depan.
Menerima kerugian itu dan mengakui bahwa hal tersebut bisa terjadi lagi mungkin lebih baik daripada melakukan pencegahan berlebihan demi memastikan itu tidak terjadi.
Kebijakan untuk tidak mengalokasikan sumber daya pencegahan sampai sesuatu benar-benar terjadi punya tingkat rasionalitas tertentu.
Saya menghabiskan satu tahun yang menyedihkan untuk meyakinkan orang bahwa mereka bereaksi berlebihan terhadap outage, dan bahwa masalah yang benar-benar terjadi punya solusi yang sangat sederhana. Namun jika manajer senior melihat posisinya terancam karena kemungkinan kejadian berulang, ia akan memerintahkan seluruh departemen meninjau dan memperbaiki kode untuk masalah serupa. Dan anehnya, mereka mendengarkan suara paling keras yang mengusulkan solusi yang luar biasa over-engineered.
Di lain waktu, trading stack mengalami gangguan karena kedaluwarsanya kata sandi. Upaya yang dicurahkan ke solusi buatan sendiri yang sangat rumit sampai menggelikan demi membuatnya “tidak pernah terjadi lagi” itu absurd. Pada akhirnya, setelah dikerjakan lebih dari setahun, semuanya dibuang dan diganti dengan solusi terpusat yang jauh lebih sederhana, yang seharusnya dilakukan sejak awal.
Ini mengingatkan saya pada tempat kerja saya dulu. Setiap kali kami meminta masukan, mereka berulang kali mengatakan, “Di sini tidak ada yang menjadi prioritas tanpa PIR (post-incident response).”
Menjelang akhir, setiap kali ada tiket terkait PIR, saya menandainya sebagai duplikat dari tiket nyata yang sudah sekarat di backlog padahal bisa mencegah insiden itu. Tidak punya pengaruh apa pun untuk mencegah masalah yang dapat diprediksi di area tanggung jawab kami benar-benar merusak moral tim.
Sebagian besar anggota tim berhenti sama sekali mengusulkan perbaikan. Karena manajemen tidak mengizinkan kami menarik tiket sendiri.
Ini menggambarkan dengan sangat baik neraka macam apa yang sedang menjadi Scrum ala korporat.
Agile secara harfiah dimaksudkan untuk bekerja cepat dan meningkatkan kapabilitas dalam siklus yang cepat. Tetapi Scrum menjadi versi yang lebih buruk dari proses perencanaan yang hendak digantikannya.
Cara Scrum memecah pekerjaan menjadi masalah yang tepat di depan mata justru memperparah siklus ini. Dalam jangka panjang, ia menjadi sistem tiket di mana api didorong ke atas dan utang teknis didorong ke bawah.
Selain itu, ia juga memuntahkan angka efisiensi yang mudah dilacak tetapi tidak bermakna, yang mudah dipakai konsultan dan eksekutif untuk bermain optimasi.
Saya boleh mengatakan ini. Beberapa teman dekat saya juga scrum master.
Saya paham alasannya. Dari sekian banyak hal yang bisa dikerjakan, seseorang harus memutuskan apa yang akan dilakukan. Apakah fitur ini akan menghasilkan uang? Bagaimana dengan pekerjaan yang bukan fitur tetapi mengurangi biaya sumber daya? Bagaimana dengan utang teknis yang katanya memperlambat pengiriman fitur?
Saya bukan manajer senior, tetapi pada akhirnya seseorang di atas sana bertanggung jawab memastikan perusahaan bertahan, menghasilkan uang, dan membayar gaji kita. Mereka juga harus mengambil keputusan dengan sedikit informasi yang bisa mereka dapatkan, sama seperti kita. Jadi mereka butuh cara untuk membandingkan “ini biayanya berapa dan nilainya berapa” dengan “itu biayanya berapa dan nilainya berapa.”
Mereka membutuhkan cara untuk memperkirakannya, dan ketika industri teknologi mempromosikan Agile sebagai sarana itu, mereka pun berpegangan padanya. Salah siapa?
Dari situ muncullah estimasi yang sering, pelacakan jadwal, dan ritual-ritual. Ada orang yang tidak percaya bahwa semua itu harus otomatis menyertainya, dan saya setuju. Tetapi bagaimanapun, ritual-ritual itu menjadi bagian dari kultusnya.
Kami meninggalkan Scrum, dan juga meninggalkan rapat refinement, estimasi story, serta story point. Sekarang sebulan sekali kami bertemu PM secara resmi dan, sebagai tim, hanya melihat posisi kami saat ini dengan estimasi ukuran kaus. Di luar itu, kami memberi update ketika PM meminta atau ketika kami merasa perlu. Berkat itu wewenang ada pada kami, tetapi sebagai gantinya kami bertanggung jawab memberi tahu tepat waktu jika situasi mulai terlihat tidak aman. Kami tetap harus melakukan “estimasi”. Bagaimanapun, manajer senior harus mengambil keputusan. Namun secara keseluruhan ini cukup ringan, dan benar-benar terasa membebaskan.
Semua orang berkomitmen pada prosesnya, dan tim Scrum menetapkan 20% upaya untuk memprioritaskan pelunasan utang. Kecepatan masing-masing juga cukup akurat sehingga 20% tambahan untuk pekerjaan minat pribadi dapat diperhitungkan, dan prioritas pemangku kepentingan mengisi 60% sisanya.
Dalam sprint tertentu, jika perlu mendorong untuk menyelesaikan epic atau tujuan tim, atau jika harus mengubah prioritas karena keadaan darurat/bug, mereka berbelok arah.
Menambahkan banyak proses hanya karena ingin menambahkan proses tidak menciptakan nilai.
Saya teringat komik yang ditempel di kantor ini: https://naksecurity.medium.com/the-detriments-of-hero-cultur...
Karena itu, dalam banyak budaya perusahaan, jika suatu masalah bukan area tanggung jawab langsung seseorang, lebih menguntungkan secara reward untuk tidak mencegahnya secara proaktif meskipun tahu cara memperbaikinya. Biarkan masalah itu muncul, jadikan ia keadaan darurat seseorang, lalu perbaiki.
Tentu saja, dalam jangka panjang organisasi seperti itu tidak mungkin berjalan baik, jadi sebaiknya juga menyusun rencana untuk pergi.
Teringat pada [pdf] “Tidak ada yang mendapat pengakuan karena memperbaiki masalah yang tidak pernah terjadi” (2001)
Setiap kali YouTuber atau clickbait media sosial mengklaim bahwa bug Y2K bukan masalah besar, pikiran ini selalu teringat
Alasan itu bukan masalah besar adalah karena banyak veteran seperti saya begadang berbulan-bulan sebelumnya agar semuanya tetap berjalan
Saya masih ingat ketegangan saat hitung mundur tengah malam UTC. Lalu tegang lagi saat hitung mundur waktu Eastern, dan sekali lagi saat waktu lokal. Baru setelah waktu Pasifik memasuki tahun 2000 kami akhirnya bisa sedikit rileks
Kita akan tahu pada 2038
Kalau dari periode yang sama, Y2K juga contoh yang sangat bagus. Hampir tidak ada kejadian yang mencolok, tetapi kalau orang-orang mengabaikannya begitu saja, kemungkinan besar banyak hal bisa terjadi
Bukan juga karena gaji saya bergantung pada itu. Tentu ada banyak peluang kerja lain. Itu benar-benar masalah yang bisa melumpuhkan industri energi, dan akan berdampak pada perusahaan-perusahaan besar serta banyak sekali organisasi yang bergantung pada mereka. Dari pengalaman ini, saya rasa berbagai industri seperti keuangan atau pengembangan sumber daya juga akan terkena dampak yang sama, baik langsung maupun tidak langsung
Jadi ini contoh yang bagus. Saya masih bertemu orang yang mengingat Y2K sebagai kehebohan yang bukan apa-apa. Bukan begitu. Itu bukan masalah bagi Anda karena banyak orang bekerja keras mencegahnya
Masalah-masalah itu tidak sangat rumit, tetapi tersebar luas, penting, dan membutuhkan beban kerja besar. Ini bukan semacam masalah rekayasa setara pendaratan di Bulan yang bisa dibanggakan sebagai prestasi umat manusia, melainkan lebih seperti memperbaiki banyak masalah O-ring Challenger yang bodoh sebelum meledak
Jadi pada hari-H hanya tersisa sedikit bug kecil. Ada beberapa lelucon di koran, tetapi publik pada umumnya melewatinya begitu saja
Saya bekerja di bidang iklim dan dulu, atau masih, berharap hal yang sama terjadi. Namun tampaknya ini akan segera mau tidak mau menarik perhatian semua orang
Jika sudah siap, tidak ada hal menarik yang terjadi, hidup terus berjalan, dan orang-orang mengingatnya sebatas membuka laptop lalu menekan beberapa tombol
Jika tidak siap, jaringan listrik Texas membeku, orang-orang meninggal, tabungan hilang, dan jadinya “tidak ada yang membayangkan akan seburuk ini”
Saya akui saya juga ikut dalam pekerjaan itu. Lucunya, saya dipanggil kembali ke klien lama untuk memperbaiki masalah yang secara harfiah diciptakan oleh pekerjaan saya sendiri di masa lalu. Begitu melihat masalahnya, saya memperbaikinya dalam 20 menit. Lalu berlanjut dengan “mumpung Anda di sini, bisa tolong lihat yang ini juga…” dan itu berlangsung sekitar 2 tahun, sampai departemen itu ditutup dan dipindahkan ke New York
Setidaknya saya mendapat pengakuan dalam bentuk jam kerja yang bisa ditagihkan
Karena tulisan ini dibuat tepat setelahnya, saya kira ini akan membahas Y2K
Selama beberapa tahun di akhir 90-an, saya mengerjakan proyek Y2K dan membantu memastikan infrastruktur inti Inggris tidak berhenti pada tengah malam. Misalnya, tanpa upaya kami, Wales tidak akan punya air atau gas
Namun setelah itu saya mendengar orang berkata “tidak ada apa-apa yang terjadi, jadi jelas itu bukan masalah; kenapa uang sebanyak itu dihabiskan untuk Y2K?” atau “Y2K adalah penipuan yang dibuat industri IT”
Kami menang. Kami berhasil mencegah bug Y2K, itu pekerjaan berat, dan kami bahkan tidak yakin apakah semuanya sudah tertangani sampai tengah malam. Tetapi alih-alih diberi selamat, sebagian orang melihatnya sebagai bukti bahwa kami menipu harga. Orang-orang memang aneh
Yang menyebalkan adalah, dalam perubahan iklim pun skenario terbaiknya seperti ini. Jika kita benar-benar berhasil menghindari kiamat, semua “penyangkal iklim” akan merasa bahwa merekalah yang benar
Komentar Hacker News
Judulnya mengingatkan pada sebuah anekdot Tiongkok kuno yang menarik. Agak ironis juga bahwa Toyota baru-baru ini terseret skandal: https://www.bbc.com/news/articles/c1wwj1p2wdyo
Raja Wen dari negara Wei bertanya kepada Bian Que, “Kalau tiga bersaudara semuanya tabib, siapa yang paling hebat?” Bian Que menjawab, “Kakak tertua saya yang paling hebat, kakak kedua berikutnya, dan saya yang paling tidak hebat.”
Kakak tertuanya mengenali penyakit sebelum penyakit itu berbentuk dan menghilangkannya diam-diam, jadi namanya hanya dikenal di dalam keluarga; kakak keduanya mengobati saat penyakit baru mulai tampak, jadi namanya tidak terdengar melampaui gang-gang desa; sedangkan Bian Que sendiri menusuk pembuluh darah, memberi obat keras, dan membelah daging, sehingga karena tindakannya terlihat jelas, namanya tersebar di kalangan para penguasa feodal
Saya pernah mengalami perusahaan tempat “departemen yang menderita” mendapat pujian dan kenaikan anggaran pada kuartal berikutnya karena secara heroik membereskan masalah yang mereka buat sendiri
Sementara itu, departemen saya yang diam-diam berjalan baik bahkan kesulitan hanya untuk tetap menyalakan lampu
Ini jadi masalah serius di industri ini karena ada jurang antara manajemen nonteknis yang cuma paham setingkat double-click dan engineering yang benar-benar menopang perusahaan. Saya sulit membayangkan solusi selain manajemen berasal dari latar belakang engineering
Beberapa masalah perlu mengirim sinyal rasa sakit ke atas sebelum diperbaiki, agar jadi kesempatan belajar bagi kepemimpinan
Hanya saja, merancang insentif itu sulit, dan struktur di level eksekutif tertinggi tidak boleh membuat bawahan dan departemen tidak mampu memperlihatkan rasa sakit dan masalah. Orang yang menutupi sinyal dengan niat baik juga sering ada, jadi dalam organisasi besar perlu ada pembinaan bahwa membiarkan sebagian masalah berkembang dan tidak terlalu reaktif justru bisa lebih efisien
Saat semua orang merancang dengan asumsi kondisi normal dan operasi sempurna, penting ada orang yang mencari cara merusak desain, layanan, infrastruktur, dan aplikasi
Seorang rekan di departemen IT bisa mendapat sedikit di atas 2.000 euro dengan mengganti sertifikat komersial ke Let’s Encrypt dan menghapus persyaratan EV, tetapi pada akhirnya tidak mendapatkannya. Alasannya, itu dianggap “bagian dari pekerjaan”
Tim yang benar-benar membangun layanan yang bekerja justru anggarannya dibekukan dan orang-orangnya malah dikurangi
Saat masalah meledak di tim lain, tim kami bisa menunjukkan daftar pekerjaan yang sudah diselesaikan sebagai alasan kenapa kami tidak mengalami masalah yang sama. Pekerjaannya sudah dilakukan, hanya saja dilakukan pada waktu yang lebih baik sehingga bisa menghindari downtime
Hal seperti ini sering terjadi. Saya terutama suka pada kenyataan bahwa solusi yang elegan biasanya tampak sederhana kalau dilihat belakangan
Setelah lama memikirkannya lalu menemukan solusi cerdas dan menjelaskannya, orang lain bereaksi, “Ya, jelas dong”
Orang di sebelah yang membuat masalahnya jauh lebih rumit justru dipuji karena telah menciptakan sesuatu yang begitu sulit
Perusahaan besar mungkin masih tertinggal dan tetap mengagumi kompleksitas, tetapi bagi orang yang menerima hasil AI, baik langsung maupun tidak langsung, kompleksitas tidak lagi seimpresif dulu
Untuk pemulihan yang terasa ajaib sekalipun, mereka akan bercerita tentang “keponakan yang langsung menyelesaikan masalah kecil,” seolah menekankan bahwa saya tidak bisa melakukannya
Atasannya menyarankan agar memakai cara yang rumit, karena dengan begitu akan diterbitkan. Bukan karena lebih pintar, tetapi karena solusi harus terdengar rumit agar diakui
Ini tepat bersinggungan dengan kenyataan bahwa proses yang rumit lebih dipuji daripada solusi yang indah, dan mungkin begitulah birokrasi lahir
Kode itu dilupakan 15 menit setelah dirilis dan tidak pernah dibaca lagi oleh siapa pun, tetapi dipakai selama bertahun-tahun. Karena itu saya rasa AI bisa mengambil alih banyak pekerjaan jauh lebih cepat daripada yang dipikirkan banyak orang
Hal-hal seperti kode bersih, pemisahan concern, dan maintainability—yang selama ini paling banyak menyita waktu kita—ternyata tidak benar-benar dihargai. Selama “cukup lumayan”, manajer sudah puas, dan saat muncul masalah, AI bisa menambalnya meski dengan gaya spaghetti
Di tempat kerja lama, ada masalah yang mirip. Aku menghabiskan hampir seluruh waktuku untuk pekerjaan administratif di balik layar seperti menjadwalkan rapat dan memastikan orang-orang punya informasi yang dibutuhkan sebelum rapat
Namun saat evaluasi kinerja, yang dianggap penting hanya bahwa aku terlalu sibuk menjaga semuanya agar tidak berantakan sehingga tidak banyak menyelesaikan story point
Jadi aku menghentikan semua pekerjaan administratif dan hanya fokus menyelesaikan story point, lalu 1–2 minggu kemudian manajer bertanya kepada tim, “Kenapa semua rapat jadi berantakan? Setiap masuk rapat, tidak ada yang tahu apa yang sedang terjadi?”
Setelah hampir 2 tahun bekerja mati-matian di jaringan, perangkat keras, dan IT untuk persiapan Y2K, aku mulai pindah ke pemasaran. Pada akhirnya, hampir semua perusahaan menganggap waktu dan uang itu terbuang sia-sia karena “tidak terjadi apa-apa”
Bahkan ada satu perusahaan yang meminta pengembalian dana penuh, dan ketika kukatakan akan kukembalikan danaku jika mereka setuju pekerjaanku dibatalkan, mereka setuju. Keesokan harinya, seluruh sistem perusahaan itu runtuh
Bahkan dukungan jaringan untuk perusahaan ayahku sulit kutangani karena mereka sama sekali tidak mau membayar tarifku. Setelah dua orang lain gagal menyelesaikan masalahnya dan aku memperbaikinya dalam 15 menit, mereka malah makin tidak mau membayar karena hanya butuh 15 menit
Kemampuan menjaga agar semuanya tidak rusak tidak dihargai, dan yang diakui hanya memperbaiki setelah rusak. Pemasaran bayarannya lebih baik, dan setiap hari aku bisa membenarkan gajiku dengan angka nyata. Jauh lebih tidak kusukai, tetapi lebih dihormati daripada pekerjaan IT mana pun yang pernah kulakukan
Yang justru dihargai adalah hal-hal sederhana seperti memperbaiki printer, memperbaiki masalah komputer A/B/C, atau Android Sudoku tanpa iklan yang kubuat untuk teman-teman
Pekerjaan inti yang kulakukan untuk dibayar tidak dihargai. Di banyak industri, ketika uang terlibat, menjalankan peran kontraktual seolah jadi hal yang sudah sewajarnya sehingga rasa terima kasih berkurang
Orang yang tidak paham teknologi mengira developer kerja dari rumah dan cuma bekerja 30 menit sehari, dan AI membuat citra itu jadi lebih buruk
Ian Rush pernah mengatakannya dengan baik: “Striker itu yang terbaik. Bisa gagal lima kali lalu jadi pahlawan kalau mencetak gol penentu. Kiper bisa melakukan penyelamatan gemilang, tapi kalau kebobolan satu gol saja dia jadi penjahat”
Di semua tempatku bekerja, mereka memberi imbalan kepada pemadam kebakaran alih-alih orang yang memastikan tidak ada kebakaran. Yang lebih buruk, semua orang jelas tahu hitung-hitungan itu, kecuali orang-orang yang menentukan insentif
Ada sisi sebaliknya juga. Ada orang yang menghabiskan seluruh waktunya mengkhawatirkan hal-hal yang sebenarnya tidak akan pernah terjadi, jadi ini bukan masalah yang bisa diselesaikan hanya dengan memberi imbalan pada sikap defensif
Promosi di tempat kerja memang terjadi seperti ini. Merusak sesuatu, lalu diekskalasi hingga jadi terlihat, dan email sampai ke eksekutif. Lalu setelah itu “diperbaiki”, semua orang berterima kasih dan bilang kerja bagus
Versi lainnya adalah sengaja menunda lama pekerjaan yang memang seharusnya dilakukan agar visibilitasnya meningkat. Eksekutif tidak melihat pekerjaan orang-orang yang bertanggung jawab menyelesaikan semuanya sebelum menjadi masalah besar
Sebaliknya, mereka mengingat nama orang yang merusak sesuatu lalu “menyelamatkan” harinya
Sambil menjilat eksekutif, mereka bilang “lebih baik jangan serahkan ke doublerabbit”, “sepertinya dia bukan pemain tim”. Padahal semua itu infrastrukturnya milikku
Itulah alasan orang bertanya kenapa aku membenci manusia
Ini pelajaran yang sudah kupahami sejak kelas 1 SD. Anak-anak yang duduk tenang di kelas dan mengerjakan PR tidak terlalu menyita waktu dan tenaga guru
Yang justru mendapat perhatian guru adalah anak bermasalah yang tidak mengikuti aturan dan butuh terus dipuji setiap kali mereka berusaha sedikit saja dalam belajar
Waktuku di IT bergerak di antara dua kutub
“Semua berjalan baik di sekitar sini. Kenapa kita membayar IT?”
“Semuanya berantakan. Kenapa kita membayar IT?”
Secara pribadi aku lebih memilih yang pertama daripada yang kedua. Aku sering bilang, “Kalau aku melakukan pekerjaanku dengan benar, kalian bahkan tidak akan tahu aku ada di sini.” Tapi justru karena itu aku dipecat
Dari sisi karma, aku masih berhubungan dengan orang-orang di perusahaan lamaku, dan sekarang tempat itu benar-benar kacau. Itu setidaknya sedikit menghibur
Begitu tahu tentang jebakan kapabilitas, kamu akan melihatnya di mana-mana
Sterman, Repenning, dan kolaborator lain menulis beberapa makalah lagi setelah paper ini, dan semuanya menarik, tetapi hampir semuanya suram
Terutama karena MIT Sloan, tempat system dynamics pertama kali mapan sebagai disiplin ilmu, letaknya sangat dekat dengan Harvard Business School, tempat system dynamics pertama kali diabaikan