Sebagian Besar Masalah Teknis adalah Masalah Manusia

• Di perusahaan dengan utang teknis yang besar, inefisiensi muncul akibat duplikasi kode dan framework yang usang
• Selama proyek berjalan, hilangnya kepercayaan manajemen dan resistensi terhadap perubahan di dalam organisasi menjadi hambatan utama
• Akar penyebab utang teknis adalah faktor manusia seperti kebutuhan yang tidak jelas, jadwal yang tidak realistis, preferensi pada teknologi usang, respons jangka pendek dari manajemen, dan ego pribadi
• Bukan hanya hasil teknis, tetapi juga pengelolaan persepsi dan komunikasi sangat penting bagi keberhasilan proyek
• Selain kemampuan teknis, engineer juga harus memiliki kemampuan berkolaborasi dalam organisasi dan mengelola hubungan antarmanusia

---

Masalah utang teknis dan duplikasi kode

• Di sebuah perusahaan tempat penulis pernah bekerja, terdapat utang teknis yang serius: jutaan baris kode, tidak adanya unit test, dan penggunaan framework yang sudah berusia lebih dari 10 tahun
  • Untuk menjalankan modul khusus Windows di Linux, mereka menanganinya dengan menyalin-tempel ratusan ribu baris kode
  • Akibatnya terbentuk dua codebase, sehingga penambahan fitur dan perbaikan bug harus dilakukan secara terpisah pada masing-masing
• Situasi seperti ini menghasilkan struktur yang tidak mungkin dipelihara, dan dalam jangka panjang jurang perbedaan antar kode makin melebar

Utang teknis yang disebabkan oleh masalah manusia

• Proyek utang teknis sulit meyakinkan manajemen, dan pada akhirnya kurang menunjukkan hasil yang terlihat karena hampir tidak ada perubahan fitur
  • Proyek pun tertunda dan kepercayaan manajemen hilang
• Inti persoalannya bukan teknologi, melainkan sikap manusia dan budaya organisasi
  • Banyak developer menolak perubahan dan merasa nyaman dengan cara lama
  • Struktur kode mencerminkan kepribadian penulisnya dan tingkat penerimaan terhadap perubahan
• Utang teknis muncul dari kebutuhan yang tidak jelas, janji yang tidak realistis, pemilihan teknologi usang, keputusan manajemen untuk menghentikan di tengah jalan, dan harga diri pribadi
  • Semakin kuat kecenderungan sebuah tim untuk menghindari perubahan, semakin tercermin pula sifat penolakan perubahan itu dalam kodenya
• Banyak developer selama bertahun-tahun tetap bekerja dengan cara yang sama, bahkan sampai mengatakan, “Saya tidak ingin belajar hal baru”
• Dalam lingkungan seperti ini, kecepatan penumpukan utang lebih tinggi daripada kecepatan merapikannya, sehingga sebelum menguranginya, prioritas utamanya adalah mencegah agar utang baru tidak terus menumpuk
  • Seperti analogi triage (prioritas penanganan) di IGD, dibutuhkan tahap untuk terlebih dahulu “menghentikan pendarahan”

Kesenjangan antara dunia ideal dan kenyataan

• Hampir tidak ada lingkungan ideal tempat masalah engineering bisa diselesaikan terpisah dari politik atau konteks organisasi
  • Sebagian besar proyek memiliki pemangku kepentingan non-teknis
  • Sikap “percaya saja karena kami sedang mengerjakannya” tidak akan berhasil
• Pengelolaan persepsi terhadap hasil sama pentingnya dengan hasil itu sendiri
  • Karena pihak non-teknis tidak secara intuitif memahami perlunya merapikan utang teknis, hal itu harus dijelaskan dengan nilai kuantitatif dan nilai bisnis
  • Jika kepemimpinan tidak memiliki latar belakang engineering, maka perlu menunjukkan angka dan dampak yang terlihat
• Pada akhirnya, tim terlihat produktif itu sendiri sama pentingnya dengan produktivitas yang sesungguhnya

Kemampuan yang dibutuhkan engineer senior

• Pada level senior ke atas, kemampuan kolaborasi lintas departemen dan mengelola hubungan antarmanusia adalah hal yang wajib
  • Pendidikan ilmu komputer tidak mengajarkan cara menangani orang seperti kepribadian, ego, dan pengelolaan relasi
• Bahkan engineer dengan kemampuan teknis luar biasa pun bisa kesulitan menghadapi masalah yang membutuhkan perubahan berskala besar dan terorganisasi
  • Produktivitas pribadi bisa tinggi, tetapi pengaruh organisasional tetap terbatas
• Peran Heads up coder itu penting
  • Sosok yang tetap mempertahankan kedalaman teknis sekaligus mampu mengenali risiko proyek lebih awal dan mengoordinasikan tim
  • Alih-alih bekerja sendirian dengan cepat seperti single core, ia memimpin seluruh tim agar bekerja efisien
  • Berbeda dari engineer yang murni teknis, ia mampu bergerak sambil membaca konteks organisasi dan risikonya

Ringkasan

• Di akar masalah teknis, selalu ada manusia
  • Sebagian besar masalah teknis pada akhirnya bermuara pada masalah manusia, budaya, dan komunikasi
• Utang teknis bukan masalah kode, melainkan hasil dari pola perilaku dan budaya organisasi
  • Untuk menyelesaikan utang teknis, penerimaan perubahan secara organisasional dan pemahaman dari kepemimpinan harus lebih dulu ada
• Dan ada masalah-masalah yang tidak bisa diselesaikan hanya dengan keunggulan teknis, yang menunggu di panggung lebih besar pada tahap lanjut karier
  • Engineer senior yang sejati adalah pemimpin yang seimbang, yang mampu menangani teknologi sekaligus memahami manusia

[GN⁺]

Opini Hacker News

• Saya merasa sebagian besar masalah adalah masalah komunikasi
  Engineer terputus dari visi produk maupun pelanggan, dan tim produk memperlakukan engineer seperti sekadar tim outsourcing internal
  Tim sales dan CS tidak memahami bagaimana janji yang mereka buat memengaruhi roadmap produk
  Akhirnya tujuan dan metrik keberhasilan jadi tidak selaras, dan semua orang mendayung ke arah masing-masing
  Solusinya bukanlah “orang yang lebih baik”, melainkan membuat semua orang fokus pada tujuan yang sama dan memahami bagaimana peran masing-masing terhubung dengan keseluruhan
  Utang teknis yang lama juga sama; itu tidak akan hilang hanya karena diabaikan. Biaya dan risiko yang ditimbulkannya bagi perusahaan harus dikuantifikasi, lalu diseimbangkan dengan tujuan lain dan dibuat rencana untuk melunasinya

  • Karena itu saya membuat program Shadow Sessions untuk tim internal tooling di BigCo
    Ini adalah sesi di mana pengguna ada tepat di sebelah kita, jadi kita bisa bertemu langsung, berteman, dan mempelajari keseharian serta konteks mereka
    Dijadwalkan otomatis setiap 3 minggu, dan berjalan tanpa action item khusus. Setiap kali, orang-orang terkejut, bug-bug kecil terselesaikan, dan koneksi pun terbentuk
    Saya menjalankannya dengan auto-scheduler yang terintegrasi dengan Slack API, dan bagian tersulitnya adalah mencocokkan jadwal serta mendorong partisipasi
  • Saya rasa itu karena perusahaan tidak memberi insentif agar orang saling mendengarkan
    Manajemen tidak mendengarkan bawahan, dan bawahan saling bersaing untuk mendapat perhatian
    Baru-baru ini di departemen kami, seorang konsultan mengusulkan migrasi ke platform baru. Tidak ada yang setuju, tetapi kami juga tidak bisa menghentikannya. Pada akhirnya, tak ada yang benar-benar mendengar
  • Kalimat “hitung biaya yang ditimbulkan utang teknis itu bagi perusahaan” sangat membekas, dan saya penasaran bagaimana cara konkretnya
  • Tentu saja, “orang yang lebih baik” memang menyelesaikan banyak masalah. Bukan semuanya, tetapi cukup banyak
  • Alasan tim produk memperlakukan engineer seperti vendor adalah karena ada rasa superioritas: “Ini ide saya, dan kalian yang mengeksekusinya”
    Saat ditanya “kenapa kita melakukan ini?”, jawabannya hanya semacam “percaya saja sama saya”
    Saya rasa perilaku PM seperti ini tidak akan berubah. Karena itu engineer mulai mengambil peran produk secara langsung untuk menutup kesenjangan komunikasi

• Saya menyadari banyak orang sebenarnya tidak bangga dengan pekerjaannya
  Bagi sebagian orang, itu cuma soal gaji
  Terutama rekan kerja yang lebih tua pernah melihat sistem runtuh, jadi mereka berusaha agar situasi seperti itu tidak terulang lagi
  Setiap kali pindah kerja saya mencoba menetapkan panduan yang jelas dalam rencana 90 hari, tetapi pada akhirnya inti utamanya tetap tim
  Ada tim yang haus akan perubahan, dan ada tim yang menghambat perubahan
  Jika pemimpin tidak paham atau hanya memilih opsi yang paling cepat dan murah, semuanya jadi lebih sulit
  Saya juga teringat kasus seperti skandal Post Office di Inggris, ketika masalah di dalam sudah diketahui tetapi tetap dibungkam

  • Alasan orang kehilangan kebanggaan terhadap pekerjaan adalah karena hilangnya rasa memiliki
    Dulu lebih dari setengah orang bekerja mandiri, sekarang tinggal sekitar 10%
    Sekarang yang kita buat bukanlah “milik kita”, melainkan “milik pemberi kerja”
    Bekerja lebih keras pun tidak dihargai, malah biasanya hanya membuat kita menanggung lebih banyak pekerjaan
    Pada akhirnya orang diperlakukan sebagai sumber daya, dan dibuang saat tidak lagi dibutuhkan
  • Sebagian besar perusahaan tidak peduli pada karyawan, dan karyawan tahu itu
    Saat krisis, yang pertama di-PHK adalah karyawan, sementara CEO menerima jutaan dolar
    Dalam struktur seperti ini, mustahil berharap karyawan berkomitmen pada perusahaan
  • Alasan hilangnya kebanggaan itu jelas
    Orang yang bekerja lebih sedikit mendapat gaji lebih tinggi, dan Anda bisa dipecat lalu diganti orang lain dengan setengah gaji
    Interview makin berat, kredit atas kerja kita dicuri, dan inflasi menggerus gaji
    Akhirnya pertanyaan “mengapa kebanggaan itu hilang” tampak seperti misteri, padahal jawabannya sebenarnya jelas
  • “Kebanggaan” tidak bisa dipakai untuk membeli bahan makanan, dan bekerja keras pun gaji tetap sama
  • Orang hanya akan peduli jika mereka merasa pekerjaannya menarik
    Namun perusahaan tahu bahwa kebanyakan orang tidak bisa mengerjakan pekerjaan yang mereka inginkan, jadi mereka lebih fokus pada proses dan workflow
    Bagi individu, yang terbaik adalah mengerjakan hal yang disukai sambil tetap dibayar dengan baik

• Ucapan developer “saya tidak ingin belajar hal baru” tidak selalu buruk
  Kelelahan terhadap framework yang berubah setiap hari seperti di ekosistem JavaScript berbeda dengan stabilitas teknis berbasis Go atau LTS
  Stabilitas juga membantu kelincahan produk
  Kita mungkin harus bernegosiasi dengan engineer senior yang menangani codebase C++ lama, tetapi menyebutnya sekadar utang teknis adalah bentuk bias
  Hanya lead IC yang bertanggung jawab atas codebase itu dan manajer yang membinanya yang bisa menilai apakah itu benar-benar utang teknis

• Menyebut masalah manusia dalam interview adalah cara bagus untuk gagal lolos
  Banyak interviewer menganggap hanya jawaban teknis yang benar, dan mengabaikan wawasan tentang manusia
  Saya justru sangat menghargai sudut pandang seperti itu, tetapi saya harus berdebat dengan rekan-rekan untuk meyakinkan mereka

  • Untungnya, tulisan blog tidak perlu dinilai seperti interview :)
  • Dalam interview baru-baru ini, semua interviewer memberi nilai lolos, tetapi satu orang menolak
    Ketika saya bilang bahwa batch processing mungkin sudah cukup tergantung throughput pesan, dia langsung menyimpulkan bahwa saya “tidak paham queue”
    Saya bilang saya sudah lebih dari 10 tahun menangani produk data skala petabyte, tetapi tetap ditolak karena itu tidak cocok dengan desain sistem versinya
    Sekarang tim itu akhirnya sedang membungkus semua microservice di balik satu API tunggal
  • Di interview, saya biasanya menyampaikan trade-off dari kedua sisi sekaligus
    Jika tim itu tidak memahami keseimbangan tersebut, saya tidak perlu bergabung dengan mereka
  • Sedikit selingan, Graph DB sering terlihat keren sehingga dipakai berlebihan

• Sebagai data engineer di Big Tech, ada dua masalah yang paling sulit
  Pertama, karena Conway’s Law, tiap departemen punya toolchain dan filosofi data yang berbeda
  Kedua, tiap silo bersikeras bahwa hanya caranya sendiri yang benar, sambil tetap ingin memakai data dari silo lain
  Alasan standardisasi jadi mustahil adalah karena para pemimpin tiap departemen percaya bahwa hanya pendekatan merekalah satu-satunya solusi
  Kalau dilihat langsung, kebanyakan pendekatan itu sekaligus benar dan salah
  Dari luar kelihatannya seperti masalah teknis, tetapi pada akhirnya ini masalah manusia

  • Ditambah lagi, requirement sejak awal tidak jelas, otomatisasi kurang, sehingga kita tenggelam dalam permintaan-permintaan kecil
    Tidak ada pemberitahuan saat sistem upstream berubah, jadi kita baru tahu ketika alarm berbunyi di downstream
    Ada begitu banyak permintaan dadakan sampai-sampai sprint menjadi tidak berarti, dan pengetahuan yang tidak terdokumentasi menumpuk di mana-mana
    Pengalaman seperti ini justru memotivasi saya untuk mempelajari ilmu komputer di level yang lebih rendah
  • Masalah seperti ini adalah masalah mendasar yang berpusat pada manusia dalam IT
    Untuk mendorong perubahan, kita harus membangun jaringan, menyatukan orang, dan secara transparan menyebarkan perubahan
    Namun untuk perubahan yang benar-benar nyata, kita butuh dukungan pemimpin tingkat atas seperti director atau VP
    AWS pernah menerbitkan panduan untuk perubahan organisasi seperti ini, dan AWS Prescriptive Guidance adalah blueprint yang sangat bagus
  • Hambatan terbesar saat mengimplementasikan sistem untuk institusi besar adalah ketidakpercayaan antar-departemen
    Semuanya dimulai dengan “mari satukan semua orang dalam satu solusi”, tetapi segera pecah menjadi proyek terpisah per departemen
    Untuk mencegahnya, dibutuhkan pemimpin dengan otoritas yang kuat
    Terutama di sektor publik, orang-orang sering benar-benar saling tidak suka, sehingga lebih sulit; di sektor swasta setidaknya masih ada tujuan bersama berupa mempertahankan pekerjaan

• Seperti yang dikatakan Jerry Weinberg dalam 『Secrets of Consulting』,
  “Meskipun tampak seperti masalah teknis, selalu itu masalah manusia”
  Akar dari masalah teknis pada akhirnya adalah pilihan manusia, komunikasi, manajemen, dan kompetensi

  • Saya juga datang untuk mengatakan ini. Wawasannya tetap relevan meski waktu berlalu

• Saya pernah bekerja sebagai analis di proyek penggantian sistem
  Sistem lama membagikan pekerjaan dengan metode round-robin yang sederhana, tetapi sistem baru membagikannya secara adil dengan mempertimbangkan beban kerja masing-masing
  Namun beberapa pegawai memanipulasi sistem agar terlihat sibuk, sehingga pegawai yang rajin justru harus menanggung lebih banyak pekerjaan
  Kami sudah menjelaskan dengan sangat jelas bahwa inti masalahnya bukan teknologi, melainkan kurangnya pengawasan, tetapi pada akhirnya kami tetap dipaksa mencari solusi teknis

  • Menurut saya ini adalah masalah di antara dua pilihan teknis
    Karena sifat dasar manusia, pekerjaan akan selalu mengembang memenuhi waktu yang tersedia, dan insentif yang salah arah seperti ini harus dikendalikan secara teknis
    Jika kita merancang sistem dengan asumsi manusia itu ideal, hasilnya akan gagal

• Sejak 『The Psychology of Computer Programming』 (1971), Jerry Weinberg
  terus menekankan prinsip bahwa “meskipun tampak seperti masalah teknis, selalu itu masalah manusia”
  Buku-bukunya masih sangat layak dibaca sampai sekarang

  • Begitu melihat judulnya, saya langsung teringat Jerry

• Saya tidak suka sikap yang menyalahkan orang karena “tidak punya kebanggaan terhadap pekerjaannya”
  Sebagian besar karyawan bukan pemilik pekerjaan itu, perusahaanlah pemiliknya
  Jika perusahaan memaksakan arah tertentu dan memberi sanksi saat kita menentangnya, mengapa kita harus melawan
  Kita ini hanya roda gigi dalam mesin, dan jika diperlakukan seperti itu, kita hanya akan bertindak sesuai perlakuan tersebut
  Sikap egois penulis terasa menjengkelkan bagi saya

  • Ini akan lebih jelas kalau Anda pernah bekerja di negara yang bukan negara maju. Semua orang pada dasarnya hanya bekerja untuk bertahan hidup

• Saya sekarang sudah cukup senior, jadi saya bekerja langsung dengan sponsor pendanaan dan penanggung jawab requirement
  Mereka bertanya, “kerjakan ini, biayanya berapa?”, dan saya harus memberi perkiraan kasar hanya dalam 18 menit dari rapat 30 menit
  Mereka tidak paham teknologi, tetapi sangat paham bahasa uang dan politik
  Ada masalah yang saya selesaikan hanya dengan satu pesan teks, tetapi anggarannya 6 juta dolar
  Ada juga proyek yang diambil tim lain, lalu membakar 35 juta dolar dan gagal
  Sponsor yang memegang anggaran kebanyakan lebih mengutamakan politik, dan tujuannya adalah “jabatan berikutnya”
  Kalau melihat karier mereka, sering kali kita bertanya-tanya, “bagaimana mereka bisa sampai ke posisi itu”

[chebread]

Bagi yang ingin tahu lebih detail soal ini, saya merekomendasikan untuk membaca Peopleware!