Jangan jawab pertanyaan pertama

 (lalitm.com)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Dalam alat debugging performa, untuk permintaan yang terlihat aneh sebaiknya tanyakan latar belakangnya terlebih dahulu alih-alih langsung menjawab, karena dari situlah masalah nyata pengguna dan celah pada alat bisa terlihat
  • Ini melampaui sekadar menangani masalah XY; kebingungan yang melahirkan pertanyaan keliru itu sendiri dijadikan titik awal untuk memperdalam pemahaman baik di sisi pengguna maupun produk
  • Di Perfetto, memakai trace untuk menghitung semua metrik mungkin saja dilakukan, tetapi tidak efisien, dan sistem pengumpulan metrik khusus bisa jadi lebih tepat
  • Saat jawaban yang tampak benar berbeda dari kebutuhan sebenarnya, seperti pada permintaan membagi trace, fitur yang sudah ada seperti periodic trace snapshots bisa menjadi jalur yang lebih baik
  • Perubahan produk lebih baik diputuskan setelah kebutuhan yang berulang benar-benar terlihat jelas, karena penambahan fitur yang tergesa-gesa dapat berujung pada utang teknis yang besar

Mengapa tidak langsung menjawab pertanyaan pertama

  • Dalam alat debugging performa seperti Perfetto, ketika pengguna mengajukan pertanyaan yang terdengar janggal seperti “Bagaimana membagi Perfetto trace menjadi beberapa file?”, lebih baik bertanya dulu, “Apa alasan Anda sampai perlu mengumpulkan trace sebesar itu?” daripada langsung memberi caranya
  • Pendekatan ini melangkah satu tahap lebih jauh daripada sekadar menyelesaikan masalah XY
    • Alih-alih hanya mengubah pertanyaan pengguna menjadi “niat yang sebenarnya” lalu menjawabnya, pendekatan ini menjadikan kebingungan itu sendiri yang melahirkan pertanyaan keliru sebagai titik awal percakapan
    • Pengguna memperoleh model mental yang lebih baik tentang alat tersebut, dan pihak pembuat alat bisa melihat dengan lebih jelas di mana produk menimbulkan kebingungan
    • Di akhir percakapan, kadang kesimpulannya justru bahwa produk itu sendiri perlu diubah
  • Cara ini sangat relevan khususnya bagi orang yang membuat alat untuk engineer
    • Untuk produk konsumen atau layanan B2B, penerapannya mungkin tidak sedirect itu, tetapi pendekatan dasarnya tetap bisa berguna

Cara mendiagnosis permintaan

  • Tidak semua pertanyaan membutuhkan percakapan yang mendalam
    • Pertanyaan sederhana dan berulang yang cukup dijawab dengan menunjuk ke dokumentasi bukan fokus pembahasan di sini
    • Kasus yang menarik adalah ketika konteks dari permintaan awal saja belum cukup, dan pertanyaannya sendiri terlihat tidak biasa
  • Untuk pertanyaan aneh, caranya adalah mencari di mana letak ketidaksesuaian berdasarkan kriteria berikut
    • Periksa apakah ini pertanyaan yang pernah terlihat sebelumnya; jika belum, anggap sebagai permintaan yang langka dan perlambat tempo
    • Bandingkan dengan pertanyaan lain untuk melihat apakah permintaan ini masuk akal; jika tidak, cari apakah ada pertanyaan yang lebih umum di bawahnya
    • Periksa apakah permintaan itu cocok dengan struktur alat, atau apakah pengguna tanpa sadar sedang melawan arsitekturnya
  • Setelah titik ketidaksesuaian ditemukan, ajukan pertanyaan yang bisa menyingkap konteks yang hilang
    • Mulailah percakapan dengan pola seperti: jawaban langsungnya memang X, tetapi karena alasan Y permintaan ini terlihat cukup aneh, jadi mohon jelaskan masalah yang lebih luas
    • Setelah itu, kecepatannya bergantung pada seberapa baik pengguna dapat menyampaikan pikirannya
  • Percakapan biasanya berujung pada salah satu dari tiga kesimpulan
    • Pengguna melewatkan filosofi alat
    • Jalur yang benar ada di dalam produk, tetapi tidak terlihat jelas
    • Produknya sendiri perlu diubah

Saat filosofi alat terlewat

  • Sering kali pengguna mencari alat tanpa benar-benar tahu secara tepat apa yang mereka inginkan atau masalah apa yang hendak dipecahkan
    • Ini bukan untuk menyalahkan pengguna
    • Tim biasanya mencoba memecahkan masalah dengan waktu dan sumber daya yang terbatas, lalu mencari alat debugging baru saat tidak ada kemajuan
    • Walaupun alat itu menyediakan banyak dari fungsi yang diinginkan, jika tidak sesuai dengan model pengguna tentang “alat ini seharusnya bekerja seperti apa”, hasilnya bisa menjadi permintaan fitur
  • Contoh yang umum di Perfetto adalah ketika trace dianggap sebagai solusi serbaguna untuk menghitung semua metrik
    • Perfetto trace mencatat dengan sangat rinci apa yang dilakukan perangkat selama rentang waktu tertentu
    • Karena metrik bisa dihitung dari trace, pengguna lalu mencoba menghitung semua nilai seperti frame rate dan penggunaan memori aplikasi dari trace juga
    • Secara prinsip, metrik apa pun memang bisa dihitung dari trace
  • Namun, menghitung semua metrik dari trace itu tidak efisien
    • Trace mahal dari sisi biaya pengumpulan dan pemrosesan
    • Bahkan jika hanya butuh satu angka, data dari seluruh sistem tetap harus dikumpulkan
    • Sistem pengumpulan metrik khusus bisa menangani hal yang sama jauh lebih efisien
  • Setiap alat punya filosofi desain, dan pengguna mudah melewatkannya karena sedang fokus pada masalah yang mendesak
    • Yang penting bukan hanya mengajarkan cara memakai Perfetto, tetapi juga cara mendekati performance engineering itu sendiri
    • Perlu diajarkan bagaimana memikirkan dan menangani topik seperti waktu startup, frame drop, memori, dan daya
    • Pengguna harus bisa memahami alat apa yang dipakai, baik saat kondisi normal maupun saat ada masalah

Saat jalur yang benar tersembunyi

  • Ada juga kasus ketika pengguna memahami masalahnya, tetapi tidak tahu bagaimana menggabungkan alat yang sudah ada
    • Alat dibuat kuat secara sengaja, dan tidak realistis mengharapkan tim lain memahami seluruh cakupan fungsinya
    • Begitu kebutuhan sebenarnya dipahami, sering kali fitur yang dibuat untuk tujuan lain ternyata bisa memenuhi kebutuhan pengguna
  • Permintaan membagi trace adalah contoh yang representatif
    • Pengguna mengatakan mereka punya bagian yang menarik di dalam trace panjang dan ingin memotongnya
    • Alasannya adalah agar performa dan visualisasi menjadi lebih mudah
    • Namun dalam kasus ini, pendekatan yang lebih tepat bisa jadi justru tidak mengumpulkan trace panjang sejak awal
  • Perfetto sudah memiliki periodic trace snapshots
    • Ini adalah fitur untuk merekam potongan pendek secara berulang, bukan satu rekaman panjang
    • Fitur ini menghilangkan kebutuhan untuk lebih dulu mengumpulkan trace panjang lalu membaginya
  • Jawaban yang ditanyakan pengguna dan jawaban yang sebenarnya dibutuhkan bisa berbeda
    • Respons seperti “Itu persis yang saya butuhkan” adalah sinyal bahwa yang ditemukan bukan permintaan yang dipikirkan pengguna, melainkan kebutuhan yang sebenarnya

Saat produk memang harus berubah

  • Beberapa respons bisa mengungkap kebutuhan baru yang layak mengarah pada perubahan besar pada produk
    • Kasus seperti ini rumit
    • Meski permintaannya baru, orang yang memintanya belum tentu bisa menjelaskan dengan jelas apa yang sebenarnya dibutuhkan
  • Biaya mengambil keputusan yang salah pada software fondasi sangat besar
    • Karena itu, lebih baik tidak membuat sesuatu sampai benar-benar terasa sakit karena belum ada
    • Saat beberapa tim mulai menyuarakan kebutuhan yang sama, biasanya inti yang memang layak dibangun mulai terlihat
    • Sangat sulit menemukan inti itu hanya dari satu permintaan, sehingga menunggu bisa menjadi strategi yang kuat
  • Kustomisasi UI ad-hoc di Perfetto adalah contoh keputusan yang salah
    • Orang ingin meretas UI agar cocok dengan workflow mereka, dan terus mengeluh bahwa itu sulit dilakukan
    • Begitu hal itu diizinkan, utang teknis yang sangat besar langsung muncul
    • Setiap fitur baru harus berinteraksi dengan semua fitur lama, dan keseluruhan struktur dengan cepat menjadi tidak skalabel
    • Butuh sekitar satu tahun untuk keluar dari masalah ini dengan merancang plugin API yang benar
  • Kebutuhan sebenarnya adalah “cara mempersonalisasi UI sesuai tim atau use case tanpa memengaruhi semua pengguna”
    • Kebutuhan ini tidak terungkap dengan jelas sejak awal
    • Menangkapnya lebih dini di tengah alur permintaan adalah tanggung jawab pihak yang membuat produk
  • Fitur untuk bisa merge Perfetto trace adalah contoh yang ditangani dengan baik
    • Banyak orang terus memintanya, tetapi fitur itu tidak langsung dibuat
    • Sebagai gantinya, mereka diberi solusi sementara sambil terus diamati
    • Sudah diketahui bahwa implementasi yang benar akan membutuhkan banyak kerja dan mudah salah jika dibuat terburu-buru
    • Setelah ruang masalahnya cukup dipahami, fitur itu diimplementasikan tahun lalu dengan cara yang bisa dipelihara

Pelajaran utama

  • Pertanyaan pertama sering kali bukan pertanyaan yang sebenarnya
    • Sebelum menjawab, tanyakan dulu mengapa pertanyaan itu muncul
    • Dalam beberapa kasus, pengguna jadi belajar bagaimana alat itu seharusnya digunakan
    • Dalam beberapa kasus, terungkap bahwa jalur yang benar di dalam produk tersembunyi
    • Dalam beberapa kasus, kesimpulannya adalah belum ada hal yang cukup layak untuk dibuat
    • Dalam beberapa kasus, ini menyiapkan landasan untuk membuat fitur besar berikutnya dengan benar dalam satu kali, bukan dua kali
  • Ini teknik yang sederhana, tetapi mudah dilewatkan
    • Tekanan untuk merespons dengan cepat akan selalu ada
    • Jawaban cepat hampir selalu terasa produktif
    • Meski begitu, ketika mundur selangkah, hampir selalu ada kemungkinan kedua belah pihak mendapatkan lebih banyak daripada saat awal

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Lobste.rs

  • Penulis mengatakan tulisan ini melampaui masalah XY, tetapi menurut saya justru ini tampak seperti tulisan yang menjelaskan cara menangani masalah XY secara rinci dengan wawasan yang menarik

    • Saya tidak berpikir tulisan ini benar-benar tentang masalah XY. Ini berlaku jauh lebih luas daripada masalah XY, dan juga tidak seberbahaya pihak yang menjawab langsung berasumsi “ini masalah XY”.
      Jika pertanyaan dibingkai sebagai masalah XY, besar kemungkinan kita kembali pada heuristik yang kontraproduktif yang biasa dipakai orang saat menjawab pertanyaan yang terlihat seperti masalah XY.
      Saya tak terhitung seringnya harus terus menjelaskan diri hanya karena saat meminta saran, orang-orang di sekitar langsung memutuskan bahwa saya sedang mengalami masalah XY, sampai akhirnya saya bertemu seseorang yang benar-benar membaca apa yang saya tulis. Saya merasa cara budaya pemrograman merespons masalah XY itu salah kalibrasi, dan tulisan ini terbaca seperti sanggahan terhadap koreksi berlebihan itu.
      Bahkan ketika terasa si penanya tahu jauh lebih sedikit daripada saya, yang penting adalah melambat dan tidak langsung pattern matching. Kemungkinan bahwa ini memang masalah XY sejak awal juga tidak sedominan itu, dan bahkan kalau benar pun, mungkin lebih baik memperlakukannya seolah bukan begitu

  • Tulisan yang bagus. Saya jadi teringat sisi lain dari koin yang sama: kita juga harus hati-hati agar tidak mengubah pertanyaan yang diajukan menjadi pertanyaan yang lebih sederhana lalu menjawab yang itu.
    Misalnya, untuk pertanyaan “berapa jarak antara Amsterdam dan San Francisco?”, kita menjawab “dengan pesawat perlu 12 jam”.
    Pertanyaannya tentang jarak, tetapi karena mengetahui jarak lebih sulit dan waktu tempuh penerbangan lebih mudah terlintas, si penjawab menggantinya dengan pertanyaan yang lebih mudah lalu menjawab itu.
    Hal seperti ini cukup sering terlihat, dan tampaknya lebih umum terutama ketika ada jarak kekuasaan antara penanya dan penjawab

  • Saat memodernisasi sistem karena berbagai alasan, kami menambahkan halaman 404 ke router ingress dan malah muncul masalah. Seorang developer meminta agar perilaku 404 lama dikembalikan, karena halaman lama punya navigation bar dan menu.
    Setelah digali lebih jauh, ternyata pada beberapa konfigurasi pelanggan, login selalu menghasilkan 404, dan para pelanggan benar-benar memakai halaman 404 lama itu untuk berpindah ke tempat yang sebenarnya harus mereka tuju.
    Untuk momen seperti inilah lolcry diciptakan 🤣😭

    • > GET /hyrums-law HTTP/1.1  
> Host: ingress.customer.doctor_eval.work  
>  
< HTTP/1.1 404 Not Found  
< Content-Type: text/plain  
<  
< Begitu jumlah pengguna API cukup banyak,  
< tidak lagi penting apa yang dijanjikan kontrak:  
< setiap perilaku sistem yang bisa diamati  
< akan diandalkan oleh seseorang.  
<

  • @lalitm, masalah ini lebih tua daripada internet dan bahkan sudah punya nama: analisis kebutuhan.
    Ed Yourdon dan lainnya membedakan antara proses, yaitu hasil yang ingin dicapai pengguna, dan prosedur, yaitu cara mendapatkan hasil itu. Misalnya, memberi tahu pelanggan bahwa pesanan telah dikirim adalah proses; mengirim informasi itu lewat email adalah prosedur.
    Pengguna sistem cenderung memikirkan solusi seolah itu adalah fungsi sistem tersebut. Programmer juga tidak terkecuali, sehingga variasi “menyelesaikan Y di X” sangat banyak. Tugas analis adalah mengekstrak kebutuhan dari bentuk implementasi tertentu, lalu sebagai engineer kita bisa mengimplementasikan solusinya setelah itu.
    Belum lama ini saya ikut dalam diskusi tentang membuat logging lebih cepat karena syslog(3) bisa backlog sehingga event kadang hilang dari log. Tetapi masalah sebenarnya bukan logging yang lebih cepat. Pengguna tidak menginginkan logging yang lebih cepat; mereka ingin masalahnya terselesaikan. Menyediakan informasi yang diperlukan adalah prosesnya, dan menulis semuanya ke log hanyalah salah satu caranya.
    Yourdon adalah salah satu orang yang mendukung tool CASE. Mungkin itu akan berhasil kalau manajemen bisa mengukur kualitas dan produktivitas, tetapi itu keluhan untuk hari lain

  • Katanya, “kebingungan yang melahirkan pertanyaan yang salah itu sendiri adalah peluang”, tetapi kalau bukan pakar terbaik di bidang itu, cukup sulit menilai sejak awal bahwa suatu pertanyaan itu salah

    • Betul. Lagi pula, kadang tidak ada gunanya bagi siapa pun meluangkan waktu untuk memahami keadaan khas suatu organisasi yang melahirkan pertanyaan yang “salah” itu

  • Sebenarnya tetap harus dijawab.
    Kecuali kalau peran kita adalah menjadi penjaga gerbang demi melindungi sumber daya mental yang berharga, lebih baik pakai taktik improv: “ya, dan…”. Tentu saja kita bisa menambahkan bahwa mungkin ada cara lain untuk mencapai hasil yang diinginkan.
    Daripada hanya memakai satu strategi untuk membongkar kebuntuan, lebih baik gunakan semua strategi yang memungkinkan

    • Saya sangat suka ungkapan itu. Ada tak terhitung banyak jalur yang bisa membuat pesan jadi membingungkan, dan membantu menemukan akar masalah memang membutuhkan berbagai pendekatan. Dan tentu saja, yang bingung juga tidak selalu pihak lawan bicara