Jangan mencoba menghindari pekerjaan mendengarkan ucapan orang lain dengan pendekatan rekayasa

• Hambatan inti di lapangan pengembangan software bukanlah kurangnya percakapan itu sendiri, melainkan kurangnya mendengarkan, dan upaya menyelesaikannya dengan mengganti persoalan ini ke istilah seperti framework atau system justru menghindari aktivitas mendengarkan yang benar-benar dibutuhkan
• Menjalankan persis apa yang diminta seseorang berbeda dengan memahami kebutuhan yang sebenarnya, dan efek keahlian serta dikotomi technical/non-technical membuat kita mudah melewatkan pengetahuan dan konteks pihak lain
• Jika kita menganggap semua orang punya energi, keterampilan, dan dana yang sama, atau menggeneralisasi ciri satu orang ke seluruh kelompok, kita tidak akan mampu menangkap batasan dan kriteria penilaian yang berbeda pada tiap individu secara tepat
• Manusia dan organisasi berubah sesuai waktu, peran, stres, dan dinamika kelompok, dan apa yang diucapkan tidak selalu sama dengan apa yang benar-benar dipikirkan, sehingga kebutuhan yang tetap/fixed requirements mudah meleset dari proses pembuatan software
• Kegagalan mendengarkan membuat kita kehilangan insight yang paling berharga, lalu berujung pada hilangnya peluang pendapatan dan keunggulan kompetitif, serta meningkatnya tech debt akibat akumulasi kesalahpahaman

---

Argumen inti

• Dalam pengembangan software, isu yang lebih besar daripada tidak adanya percakapan antarmanusia adalah kurangnya mendengarkan, dan upaya menyelesaikannya dengan mengganti masalah ini ke istilah seperti framework atau system adalah cara untuk menghindari pekerjaan yang sebenarnya diperlukan
• Desainer dan pihak product sering mencoba mengubah percakapan dengan manusia ke bentuk yang lebih mudah diterima oleh engineering, tetapi yang dibutuhkan bukan sistem yang lebih baik, melainkan kemampuan untuk benar-benar mendengarkan orang
• Dengan premis bahwa mendengarkan ucapan orang lebih sulit daripada sekadar berbicara dengan orang, berikut rangkuman jebakan-jebakan utama yang menghambat proses mendengarkan

Jebakan utama yang menghambat proses mendengarkan

• Melakukan persis yang dikatakan bukan berarti mendengarkan

  • Menjalankan apa yang seseorang katakan mereka inginkan tidak sama dengan mendengarkan kebutuhan yang sebenarnya
  • Sebagai pendekatan yang sudah ada untuk topik ini, disebutkan Jobs To Be Done, Outcome Driven Innovation, dan empathy mapping di ranah UX

• Meremehkan sudut pandang sendiri karena efek keahlian

  • Jika seseorang mempelajari suatu bidang dalam waktu lama, mudah muncul asumsi seperti “tentu mereka setidaknya tahu ini”
  • Bahkan jika lawan bicara adalah ahli di bidang tersebut, belum tentu mereka memiliki pengetahuan yang sama, dan sebaliknya mereka bisa saja memiliki pengetahuan lain
  • Untuk mendengarkan dengan baik, kita perlu lebih memahami apa yang sebenarnya diketahui pihak lain

• Menganggap technical sebagai satu kategori tunggal

  • Ini jebakan yang sangat umum terutama bagi software developer; technical bukan satu sifat tunggal, melainkan spektrum luas dari area pengetahuan yang heterogen
  • Jika kita melihat orang dengan dikotomi “technical / non-technical”, kita akan kehilangan insight dan makin besar kemungkinan gagal mendengarkan dengan benar

• Mengasumsikan semua orang memiliki sumber daya yang sama

  • Jika kita menganggap semua orang punya energi, keterampilan, dan cadangan dana yang sama, kita akan membuat penilaian yang keliru
  • Bahkan orang dengan kondisi kesehatan yang sama pun bisa berbeda dalam cara mengelola diri atau tindakan yang sungguh mampu mereka lakukan
  • Ada orang yang kuat di matematika, ada yang unggul di kemampuan lain, ada juga yang punya uang atau ruang gerak lebih sedikit sehingga bertindak lebih menghindari risiko

• Menggeneralisasi ciri satu orang ke seluruh kelompok

  • Hanya karena kita bertemu satu orang dengan ciri tertentu, bukan berarti yang lain juga sama
  • Sebagai contoh, disebutkan sikap yang langsung menganggap orang lanjut usia tidak memahami komputer
  • Sikap yang mereduksi seluruh perempuan ke citra relasi keluarga pribadi juga merupakan kesalahan yang sama

• Menganggap manusia dan organisasi itu tetap

  • Pada level makro, kepribadian berubah seiring waktu
  • Pada level mikro, persona seseorang di tempat kerja bisa berbeda dari dirinya di rumah, dan penilaian juga berubah ketika berada di bawah stres atau kondisi tertentu

• Menganggap ucapan sama dengan pikiran

  • Ada orang yang memang memaksudkan persis apa yang mereka katakan, tetapi ada juga yang tidak
  • Banyak orang mengira mereka berbicara dengan jujur, padahal kenyataannya tidak selalu begitu

• Menghakimi orang

  • Jika kita membenci atau menyepelekan seseorang yang salah paham terhadap dokumentasi yang buruk, kemungkinan untuk benar-benar mendengarkan mereka akan turun drastis
  • Sikap yang menganggap pihak lain tidak kompeten atau menjalani hidup dengan cara yang salah juga menjadi penghalang untuk mendengarkan

• Memperlakukan 80 orang sebagai satu kelompok, bukan 80 individu

  • B2B justru sering lebih manusiawi daripada B2C, karena ada relasi, dinamika, dan faktor seperti soft power di luar struktur organisasi formal
  • Dengan adanya dinamika kelompok, variabel yang muncul menjadi lebih kompleks daripada sekadar level individu

Ketidakselarasan antara kebutuhan yang tetap dan software

• Karena manusia dan organisasi berubah, fixed project management tidak cocok untuk pembuatan software
• Sekalipun requirement ditetapkan di awal, orang-orang berubah selama proses berjalan, dan saat hasilnya selesai, paling-paling ia hanya sesuai dengan permintaan pada titik awal proyek
• Pada saat rilis, itu mungkin sudah bukan lagi yang diinginkan, dan selama menunggu orang-orang menambahkan ekspektasi mereka masing-masing, sehingga kenyataan tidak akan cocok dengan semua ekspektasi tersebut

Hasil dan dampak

• Jika kita gagal benar-benar mendengarkan orang, kita akan kehilangan insight yang paling berharga, dan ini berujung pada hilangnya peluang pendapatan serta keunggulan kompetitif
• Semakin banyak kesalahpahaman yang menumpuk, semakin banyak elemen baru yang nanti harus ditambahkan ke kode yang harus dikerjakan bersama, sehingga mendengarkan juga terkait dengan meminimalkan sebagian penyebab tech debt
• Semakin kita mampu menyadari momen saat kita gagal mendengarkan, semakin besar peluang kita untuk mendengarkan dengan lebih baik

[GN⁺]

Opini Hacker News

• Saya cenderung memilih kata dengan sangat presisi, dan kalau saya memakai ungkapan tertentu, saya benar-benar memang bermaksud seperti itu. Tapi menurut saya banyak orang berbicara seperti puisi nada, berputar-putar di sekitar kata-kata yang terasa pas di tangan dan berharap dipahami lewat nuansa yang sama, sehingga proses menafsirkannya sendiri melelahkan. Saat saya menulis, setiap kata saya pilih dengan sengaja, tetapi bahkan di tempat kerja pun hampir selalu berulang kejadian bahwa ungkapan saya ditafsirkan seolah tidak akurat, dan itu cukup menyakitkan. Mungkin saya ada kecenderungan spektrum, tapi belum pernah didiagnosis. Sekitar setengah tahun lalu saya membuat RPC kecil dan menulis dokumentasinya agar departemen lain bisa memulai pekerjaan yang panjang. Isinya kurang dari satu halaman, tapi lengkap, akurat, dan ringkas. Namun manajer saya, tanpa menjelaskan alasannya, memasukkan dokumen itu ke AI lalu meneruskannya, dan saya bahkan tidak tahu itu terjadi. Kurang dari sehari kemudian, banjir umpan balik yang tidak masuk akal berdatangan, dan ketika saya melihat contoh request yang sebenarnya, ternyata terjadi manipulasi endpoint. Bukan typo, melainkan alamat yang sepenuhnya dikarang; di dokumen itu endpoint dan parameter wajib semuanya salah, bahkan ada fungsi yang tidak ada ikut diciptakan. Biasanya saya cukup sabar, tapi saya belum pernah semarah itu, dan sampai sekarang pun masih marah. Kalau pasar kerja tidak seperti sekarang, saya rasa saya akan langsung resign. Menyerahkan bahasa—yang seharusnya dibaca dan ditafsirkan sendiri oleh orang—kepada AI terasa seperti kematian bahasa yang ketat, dan selama beberapa bulan ini saya serius memikirkan apakah AI generatif mungkin merupakan semacam Great Filter yang menghancurkan peradaban

  • Sudut pandang ini terasa agak asing bagi saya. Saya tidak yakin bahasa itu memotong batas pikiran dengan presisi sempurna; bahasa adalah alat untuk mengekspresikan dunia dan pemahaman masing-masing orang, jadi wajar kalau konsep yang mirip dijelaskan dengan kata-kata yang berbeda. Bagi orang yang menuangkan pikirannya ke kata-kata, itu mungkin tampak lebih jelas, tapi bagi pendengarnya belum tentu begitu. Karena itu saya rasa kerja penafsiran tidak bisa dianggap sepele. Mungkin kalau berbicara dengan pihak lain dalam situasi itu, mereka juga pada akhirnya akan mengatakan hal serupa: bahwa ucapan Anda memang sulit ditafsirkan
  • Premis ini begitu kuat sampai saya langsung terpikir novel. Gagasan yang mengaitkan Great Filter dengan AI generatif sangat bagus, dan terasa seperti cerita yang harus segera ditulis oleh Cory Doctorow
  • Menurut saya, pertama-tama Anda harus bertanya kenapa manajer Anda memasukkan dokumen itu ke AI. Kadang makin tinggi tingkat presisi, makin turun keterbacaannya, dan semakin padat bahasanya, semakin besar biaya kognitif yang harus dikeluarkan pembaca untuk setiap kata. Membaca adalah proses menerjemahkan model mental penulis ke model mental pembaca; itu tidak otomatis terjadi hanya karena ada kata-kata, melainkan memerlukan tindakan penafsiran. Jika terlalu ringkas, perangkat yang membantu pembaca bisa hilang. Bisa jadi dokumen satu halaman itu terlalu pendek bagi pembaca umum sehingga tidak cukup membantu pemahaman, lalu muncullah jalan pintas seperti ringkasan AI. Menulis untuk pembaca adalah pekerjaan yang sama sekali berbeda dari membuat catatan akurat untuk pembaca dengan konteks tertinggi, dan khususnya saat menulis untuk khalayak luas, menurut saya Anda perlu membantu pemahaman dengan pengulangan, contoh yang mudah, konteks yang akrab, pemecahan langkah-langkah, kadang bahkan humor dan penjelasan latar belakang
  • Saya juga baru-baru ini mengalami hal serupa. Saya menulis spesifikasi 4 halaman, tetapi penerimanya tidak membacanya dan hanya meminta LLM membuat beberapa ringkasan bullet, lalu yang kembali adalah proposal yang tidak sesuai dengan kebutuhan. Saat saya menolak, dia bilang hal itu seharusnya ada di spesifikasi awal, padahal sebenarnya sudah ada; itu cuma tidak muncul di ringkasan LLM miliknya. Saya bukan tipe yang terobsesi pada tiap kata, tapi saya merasa informasi dalam dokumen 4 halaman memang tidak mungkin utuh masuk ke dalam 10 bullet
  • Justru menurut saya ini contoh yang sangat pas untuk prompt khusus atau LLM kustom yang mengubah tulisan seperti ini menjadi bahasa orang awam

• Bahkan hanya melihat kolom komentar ini, saya merasa ironis karena banyak orang justru mengulang masalah yang ditunjuk tulisan tersebut. Saya ingin menambahkan beberapa hal. Pertama, sebanyak apa pun pengetahuan dan diskusi dibangun, kalau seseorang tidak ingin menerima sesuatu, dia tidak akan mudah menerimanya. Kedua, mendengarkan sungguh-sungguh berarti menempatkan diri dalam keadaan rentan, baik secara mental maupun fisik. Itu karena kita akan mendengar hal-hal yang berbenturan dengan pengalaman, keyakinan, dan pandangan dunia kita; sikap menghakimi orang lain sering kali merupakan mekanisme perlindungan diri, dan justru karena itu orang jadi tidak benar-benar mendengar. Ketiga, mendengarkan sering kali berarti tidak langsung melompat ke solusi, melainkan menyerap rasa sakit lawan bicara dan memprosesnya. Misalnya product manager mudah sekali mereduksinya langsung menjadi fitur baru atau tiket, padahal yang seharusnya dilakukan adalah mendengar use case, menemukan titik sakitnya, lalu menyelesaikannya—bukan sekadar mencoba memahami nama fitur yang diminta pengguna

  • Menurut saya berbahaya kalau premis ini dijadikan asumsi awal. Kebanyakan hal masih punya ruang untuk dinegosiasikan, dan kalau tahu cara bernegosiasi dengan benar, hasilnya bisa berbeda
  • Saya terutama merasa poin nomor 2 ini sangat dalam. Saya benar-benar ingin mengirimkan kalimat ini kepada seseorang yang berharga bagi saya, dan berharap dia juga benar-benar mau mendengarkan
  • Saya setuju bahwa mendengarkan berarti menjadi rentan, tetapi kalau ada jaminan bahwa kerentanan itu tidak akan disalahgunakan setiap kali, saya dengan senang hati akan meluangkan waktu untuk selalu benar-benar mendengar
  • Saya benar-benar penasaran. Secara praktis, apa artinya menyerap rasa sakit orang lain, dan bagaimana dari situ kita bisa beralih secara alami ke pendefinisian fitur atau penulisan tiket?
  • Penjelasan ini justru terasa seperti inti dari presales discovery. Ini wilayah yang lebih dekat ke seni daripada benar-benar sekadar keterampilan teknis

• Saya setuju dengan keprihatinan dasarnya, tetapi daftar ini agak terbaca seperti curahan keluh kesah. Komunikasi yang efektif nyaris merupakan masalah inti umat manusia secara keseluruhan, dan tulisan ini bernuansa seperti memarahi developer karena tidak bisa mendengarkan, jadi terasa agak menggurui. Masalah mendasarnya adalah orang tidak tahu apa yang tidak mereka ketahui. Komunikator terbaik itu seperti penerjemah, dan orang baru benar-benar mendengar ketika pesan menjadi jelas dengan sendirinya di dalam kerangka pemahaman mereka. Saya tidak melihat ini sebagai keruntuhan sederhana karena semua orang bertingkah seperti balita yang menutup telinga. Itulah kenapa kita mencari sistem dan rekayasa, dan mencoba membuat sistem yang punya deteksi kesenjangan serta kerangka penerjemahan di dalamnya. Meski tidak sempurna, menurut saya mengubah lingkungan di tingkat tim, perusahaan, dan sistem jauh lebih penting daripada sekadar menasihati individu agar mendengarkan lebih baik

  • Saya teringat seorang pria tua yang dulu bilang bahwa ini sebaiknya dilihat sebagai noisy system. Sinyal selalu lebih lemah daripada noise, dan di dalamnya ada manusia-manusia yang terbatas. Masing-masing punya batas atas pada apa yang bisa mereka lakukan, ada juga batas pada kecepatan model mental seseorang bisa diperbarui, dan batas kelompok bahkan lebih rendah daripada batas individu. Organisasi besar khususnya bisa memerlukan puluhan tahun untuk mengubah model yang ada meskipun kenyataan sudah berubah total. Jadi menurut saya penting untuk mengakui batasan-batasan ini, lalu memutuskan ke mana saya akan menghabiskan waktu dan energi
  • Menurut saya tulisan ini cuma terlihat seperti tulisan self-help yang biasa saja, bahkan agak lebih mengecewakan karena kurang contoh
  • Saya seorang developer yang juga cukup banyak mengerjakan hal lain, jadi saya sangat paham pentingnya komunikasi dan betapa seringnya developer lemah di sana. Pola yang umum adalah developer bertindak seperti dokter yang buruk: berpura-pura mendengar lalu membuat diagnosis terlalu dini. Sebelum lawan bicara selesai menyampaikan hal penting, mereka sudah menyatakan tahu apa yang dibutuhkan. Dalam software, yang lebih penting daripada apa yang diinginkan pelanggan sering kali adalah apa yang sebenarnya dibutuhkan pelanggan. Jarang ada pelanggan yang benar-benar tahu cara memecahkan masalah dengan elegan lewat software; biasanya yang datang adalah seseorang yang belum pernah memikirkan software secara mendalam tetapi membawa ide. Bukan berarti ide itu tak bernilai, melainkan bahwa perumusan requirement dan penemuan solusi masih belum selesai. Cara menyelesaikannya adalah observasi, penjelasan, dan percakapan. Menurut pengalaman saya, banyak developer memang tidak mendengarkan dengan baik, dan dokter atau profesi teknis lain pun mirip. Mereka ingin cepat tampak kompeten dengan menunjukkan seberapa banyak mereka tahu, lalu mengklasifikasikan lawan bicara sebagai salah satu tipe masalah yang sudah sering mereka lihat. Kadang berhasil, tapi akan ada saatnya itu pasti gagal
  • Kalau bercanda, kalau komunikasi memang benar-benar masalah utama umat manusia, mestinya ada setidaknya satu ayat soal itu di Bible

• Saya rasa kita tidak boleh begitu saja berasumsi bahwa apa yang dikatakan orang sama dengan apa yang sebenarnya mereka pikirkan. Sebaliknya, pembicara juga mudah keliru dengan mengira pendengar membayangkan hal yang sama dan memahaminya dengan cara yang sama. Karena itu penting untuk menulis segala sesuatu sedetail dan sejelas mungkin. Jika dalam rapat seseorang mencoba menjelaskan tujuan hanya dengan satu bullet enam kata, bagi saya itu pada dasarnya sinyal bahwa tidak ada yang benar-benar memahami tujuannya. Kalau seseorang masuk rapat tanpa dokumen satu halaman pun, berarti dia sendiri belum cukup memahaminya, dan jika kemajuan saya bergantung pada hasil itu, saya rasa saya berhak meminta gambaran yang lebih jelas

  • Saya sering berada dalam situasi di mana saya harus bertanya tentang apa? beberapa kali sehari kepada rekan kerja. Dalam banyak kasus saya sampai harus bertanya 4 atau 5 kali, sampai mereka menyebut pelanggan yang mana, fitur yang mana, atau produk yang mana secara spesifik. Bahkan saat saya sebenarnya sudah tahu persis apa yang mereka maksud, kadang saya tetap harus melakukannya
  • Saya juga merasa validitas requirement harus selalu diperiksa. Cara termudah untuk menyembunyikan bahwa seseorang tidak tahu kebutuhan sebenarnya adalah dengan permintaan yang berlebihan. Menurut pengalaman saya, meminta 10 kali lipat dari yang dibutuhkan itu umum, dan saya pernah mendengar argumen bahwa kita harus membeli spesifikasi tertinggi agar tidak perlu khawatir soal masa depan, padahal selisih biayanya 500 kali lipat
  • Menulis dengan detail dan tanpa ambigu mungkin memang syarat awal bagi saling pengertian yang mendalam, tetapi dalam beberapa tahun terakhir saya merasa orang hampir tidak pernah benar-benar membaca lebih dari kalimat pertama pesan, tiket, atau email. Akibatnya kita sering harus menyuapi informasi dalam potongan yang sangat kecil, dan saya cukup membencinya
  • Saya merasa ini terlalu sering terjadi di dunia nyata. Ketika saya mengatakan belum siap untuk production, manajemen sering mendengarnya sebagai bahwa itu berarti masih bisa dijual ke pelanggan sebagai acceptance testing
  • Tiba-tiba saya teringat film era Soviet Kin-dza-dza. Di situ ada tokoh yang menggambarkan orang lain sebagai seseorang yang mengatakan apa yang tidak dia pikirkan dan memikirkan apa yang tidak dia pikirkan, dan rasanya itu cukup pas untuk menggambarkan kekacauan percakapan ini

• Saya terutama bekerja dalam peran pengelolaan hubungan pelanggan, jadi saya melihat tugas paling penting adalah menyelaraskan ekspektasi pelanggan dengan kenyataan. Jika apa yang mungkin dilakukan, berapa lama waktunya, berapa biayanya, dan kapan bisa masuk production sudah diselaraskan dengan ekspektasi pelanggan, maka meskipun mereka tidak suka tanggal mulai atau biayanya, pada akhirnya mereka tetap menjadi pelanggan yang puas. Khususnya biaya sering menjadi faktor yang menggagalkan transaksi, jadi saya biasanya menyamakan kisaran kasar sejak awal. Sebagus apa pun kita mendengar dan berempati, realitas tetaplah realitas, dan pelanggan juga harus mengakui atau menerima batasan itu. Petugas akun yang selalu mengiyakan semua keinginan pelanggan pada akhirnya justru membuat pelanggan lebih tidak bahagia, dan menurut saya penghubung yang baik harus mendengarkan baik pelanggan maupun tim internal, lalu memastikan apa yang benar-benar bisa dikirim selaras dengan ekspektasi pelanggan

• Saya merasa mungkin kita justru menghabiskan terlalu banyak waktu untuk komunikasi. Kalau waktu yang dialokasikan berlebihan, fokus jadi buyar, dan orang mudah menunda dengan pikiran bahwa toh nanti bisa diperjelas lagi di kesempatan berikutnya. Kalau rapat yang tidak perlu dikurangi dan kita hanya mengalokasikan minimum viable time, saya rasa semua orang justru akan mendengarkan lebih baik

  • Saya sendiri hampir tidak pernah melihat fenomena itu di dunia nyata. Kebanyakan rapat sebenarnya bukan komunikasi, melainkan instruksi dan pemberitahuan, dan kemampuan mendengar adalah keterampilan terpisah yang tidak ada hubungannya dengan durasi rapat. Mendengarkan adalah kemampuan yang diasah lewat latihan, bukan sesuatu yang otomatis muncul karena waktu rapat dipersingkat
  • Saya terlalu sering masuk rapat yang hasil akhirnya cuma menjadwalkan rapat berikutnya. Saya bahkan pernah melihat pola di mana lebih banyak orang ditarik masuk, lalu tim yang anggotanya lebih banyak mengarahkan keputusan ke pihak mereka demi memperoleh pengaruh politik, dan itu pada gilirannya memicu lebih banyak perekrutan dan rapat yang tidak perlu. Jalan keluarnya menurut saya bukan menambah komunikasi, melainkan membangun visi tunggal dan mengurangi ketergantungan antar tim agar tiap tim bisa bekerja secara independen
  • Dalam pekerjaan arsitektur software, saya sering melihat satu diagram menghemat lebih dari 60 menit diskusi dan beberapa kali rapat. Bahkan kalau tidak digambar sempurna, gambar yang setia pada fakta sudah cukup; logika yang rumit atau tidak gamblang jauh lebih jelas lewat diagram daripada kata-kata. Untuk rapat jarak jauh, saya rasa cepat menggambarnya dengan AI agent dan Mermaid.js sudah memadai, dan untuk tatap muka, whiteboard atau kertas dan pena saja cukup
  • Menurut saya, meluangkan waktu untuk komunikasi dan benar-benar berkomunikasi adalah dua hal yang sama sekali berbeda
  • Menurut saya, masalahnya bukan kita terlalu banyak menghabiskan waktu untuk komunikasi, melainkan terlalu banyak waktu untuk berpura-pura berkomunikasi. Saya sering melihat rapat dipaksakan meski bahkan tidak memenuhi kuorum, berjalan tanpa prasyarat, lalu melemparkan dokumen sampah AI yang dibuat tanpa pikir panjang, dan ketika orang tidak paham, yang dibodoh-bodohi justru pembacanya. Tiga puluh menit pertama rapat mengalir seperti gaslighting, lalu baru di sepuluh menit terakhir diakui bahwa itu membuang waktu dan mulai dibereskan. Seharusnya rapat adalah tempat berbagi pemikiran yang sudah matang dan arah yang konsisten, serta menerima umpan balik bermakna atas klaim yang jelas, tetapi kenyataannya sering kali rapat cuma menjadi ajang kolektif menangani upaya seseorang mengubah pekerjaannya sendiri menjadi proyek kelompok ala stone soup. Jika sejak awal Anda bertanya apa tujuan rapat ini, akan cepat terlihat apakah penyelenggaranya sebenarnya cuma membuka kelompok belajar. Manajer yang hanya punya pandangan dari ketinggian sering mengira pekerjaan terjadi di rapat, tetapi mereka tidak melihat kerja berpikir yang dibutuhkan sebelum rapat yang baik bisa terjadi. Jika komunikasi dipaksa sebelum pikiran tertata, rapat hanya menjadi noise. Dalam situasi seperti ini, respons paling kuat adalah sikap mari kita cari tahu sekarang, dan saya memaksa ketergantungan berurutan Why, What, How, Who, When. Kalau bagian depan kosong, kita tidak bisa maju ke belakang, dan entah itu intern atau VP, saya tidak mengizinkan pengaburan yang mudah. Kalau setelah memecah masalah dan berpikir di tempat tim tetap tidak berubah, pada akhirnya memang lebih tepat mencari tim lain

• Menurut saya, penunjukan tulisan ini pada efek spesialisasi cukup diremehkan. Saya juga pernah frustrasi karena pengguna tidak memahami hal-hal yang sudah saya serap selama bertahun-tahun, tetapi lalu saya sadar masalahnya bukan mereka tidak punya pengetahuan—melainkan pengetahuan itu terakumulasi di tempat lain. Mereka hanya mendalami hal yang sama sekali berbeda selama waktu yang sama

• Saya tidak sepenuhnya setuju bahwa penjelasannya berakar pada orang yang tidak berbicara dan tidak mendengarkan. Meminjam analogi komik, saya rasa banyak orang sejak awal lebih menginginkan pemotongan pita daripada jalannya sendiri, dan karena mereka akhirnya mendapatkan itu, jadilah situasi seperti ini

• Saya pernah cukup sering mengalami hal yang lucu: orang berkata mereka memaksudkan persis seperti yang mereka katakan, tetapi kenyataannya tidak demikian. Saya memparafrasekan ucapan mereka hampir kata demi kata untuk memastikan pemahaman, dan respons yang saya dapat justru penolakan keras bahwa itu sama sekali bukan maksud mereka

• Saat berbicara dengan peran nonteknis, saya merasa inti banyak masalah adalah mereka hanya berkata tambahkan X dan ubah Y tanpa konteks biaya. Tentu hampir semua permintaan bisa dikerjakan, tetapi setiap permintaan punya biaya, dan jika itu tidak dipahami, sulit untuk selaras dengan peluncuran produk yang andal

  • Menurut saya respons ini justru menunjukkan inti tulisan tersebut apa adanya. Bukan berarti mereka tidak memahami biaya, hanya saja konteksnya berbeda, dan peran orang teknis bukan berharap mereka sudah datang dengan pemahaman biaya, melainkan membantu mereka membuat tradeoff yang terinformasi
  • Dalam situasi seperti ini, saya merasa penting untuk menanyakan mengapa sesuatu dibutuhkan. Begitu kita memahami proses nonteknisnya, bisa jadi penambahan atau perubahan itu sebenarnya sama sekali tidak perlu. Saya juga setuju bahwa kalau semuanya dimasukkan, hasil akhirnya akan menjadi monster seperti klon Excel/Email yang Turing-complete
  • Saya rasa dalam situasi seperti ini ada asimetri: orang nonteknis tidak tahu biayanya, sementara orang teknis tidak tahu manfaatnya. Pada akhirnya harus ada komunikasi dua arah agar ditemukan titik biaya-manfaat yang masuk akal
  • Menurut saya ini masalah yang cukup bisa diselesaikan. Untuk setiap permintaan, cukup jawab dengan estimasi berapa bulan yang dibutuhkan dan berapa dolar biayanya
  • Namun saya juga merasa kenyataannya sekarang AI sudah menangani urusan coding, sehingga biaya implementasi memang turun cukup banyak. Suka atau tidak, perubahan itu tetap harus diakui