- Ini adalah pertanyaan yang menanyakan alat dan teknik yang efektif untuk menyampaikan model mental dalam memahami sistem atau produk kepada orang lain dan mengembangkannya bersama
- Pengalaman membangun dan memelihara sistem secara langsung disebut sebagai salah satu cara untuk mengembangkan model mental
- Cara penyampaiannya lebih dekat ke penjelasan informal seperti mencoret-coret di serbet, menjelaskan dengan gestur di samping seseorang, atau menguraikannya dengan kata-kata sambil berpikir bersama
- Dokumen yang merangkum daftar fitur atau area permukaan secara lengkap bisa saja komprehensif, tetapi mungkin tidak cukup untuk membangun atau menyampaikan model mental tentang topik tersebut
- Pengalaman menggunakan langsung alat atau produk yang dirancang dengan baik dapat sekaligus membantu proses mengembangkan dan menyampaikan model mental
Fokus pertanyaan
- Intinya adalah alat atau teknik apa yang efektif untuk menyampaikan dan menumbuhkan model mental
- Pertanyaan ini membahas dua arah sekaligus
- cara mengembangkan model mental
- cara menyampaikan model mental kepada orang lain
Contoh dan pokok persoalan
- Sebagai contoh untuk mengembangkan model mental, disebut pendekatan membangun dan memelihara sistem
- Cara menyampaikan model mental digambarkan sebagai bentuk penyelarasan pemahaman langsung di lapangan seperti berikut
- mencoret-coret di serbet
- menjelaskan dengan gestur di samping seseorang
- menjelaskan dalam situasi saat berpikir bersama
- Dokumen yang hanya mencantumkan fitur atau mengatalogkan cakupan permukaan bisa bersifat komprehensif
- Namun, dokumen seperti itu belum tentu berlanjut menjadi sarana untuk membangun atau menyampaikan model mental tentang subjek tersebut
- Pengalaman menggunakan langsung alat atau produk yang dirancang dengan baik dibahas sebagai pendekatan yang dapat sekaligus mencapai pertumbuhan dan penyampaian model mental
- Pertanyaan penutupnya meminta contoh alat dan teknik yang dirasa efektif oleh masing-masing orang, serta alasan mengapa itu efektif
1 komentar
Pendapat Lobste.rs
Olog adalah formalisme yang baik untuk menyampaikan ontologi
Jika ini adalah proses jangka panjang yang berjalan dengan banyak state internal, diagram state dan statechart berguna untuk dokumentasi sistem
Pengguna sistem biasanya tidak menyadari struktur sistem yang sebenarnya. Salah satu alasannya adalah karena Nakatomi space hanya terlihat bagi pengguna yang menyalahgunakan sistem, dan karena ada wilayah ruang state tersendiri untuk perilaku yang tidak dimaksudkan seperti weird machines
Alasan lain adalah sudut pandang the purpose of a system is what it does, yaitu pengguna bisa membentuk alasan keberadaan versi pribadi berdasarkan apa yang sistem lakukan untuk mereka, tetapi mungkin tidak menyadari tujuan keseluruhan yang dimaksudkan oleh perancang dan pemelihara
Tulis buku, lalu pekerjakan editor
Rasanya ini dekat dengan persoalan inti pendidikan. Saya pernah mendengar dua kategori, yaitu belajar sambil melakukan dan bimbingan dari ahli, dan yang ketiga adalah mengajar
Pertanyaan yang lebih penting adalah apakah kita bisa membuat model yang lebih mudah dipahami dengan terus memakai ulang prinsip dan rancangan yang serupa, atau apakah kita bisa mengurangi kebutuhan untuk memahaminya secara penuh lewat abstraksi. Namun, harus terdefinisi dengan baik di mana abstraksi itu bocor
Terkait itu, The Programmer's Brain karya Felienne Hermans cukup menarik. Saya terkesan bahwa pendekatan “biarkan saya menyelesaikan beberapa contoh lalu kamu lihat” yang dipakai saat mengajar matematika kepada anak kecil ternyata juga cukup efektif dalam pendidikan pemrograman
Dalam lingkungan kerja, untuk onboarding, bentuknya mungkin seperti “lihat bagaimana saya menyelidiki bug ini” atau “lihat bagaimana saya memahami kembali subsistem ini yang sudah lama tidak saya sentuh”
Dalam rekayasa perangkat lunak, akan membantu jika mental model dibagi menjadi user story dan implementasi teknis
Biasanya user story adalah kebutuhan primer, yaitu nilai yang ingin dicapai, sedangkan implementasi teknis adalah unsur sekunder yang diperlukan untuk mencapai tujuan itu
User story menjelaskan nilai yang disampaikan kepada pelanggan, dan implementasi teknis menjelaskan bagaimana batasan sistem yang dibuat membatasi user story
Kadang keduanya tumpang tindih sehingga user story dibatasi oleh implementasi teknis, atau sebaliknya implementasi teknis dipilih untuk mencapai user story. Namun banyak perilaku sistem bisa dibingkai dalam salah satu dari keduanya
Setelah itu, tinggal pilih alat yang paling cocok. UML bagus untuk menggambar peta objek, flowchart bagus untuk menjelaskan alur. Diagram state bagus untuk menjelaskan state dan transisi yang diizinkan atau tidak diizinkan, dan variabel serta tabel state bagus untuk mencantumkan semua nilai yang mungkin
Cara terbaik untuk belajar menggambar sistem adalah meminta tiga orang berbeda menggambar versi mereka masing-masing. Bahkan gagasan yang sama bisa diekspresikan dengan cara yang sangat beragam, dan kebanyakan sama-sama valid, tetapi menyoroti sisi topik yang berbeda. Mirip seni
Saya terutama memakai diagram yang lebih formal. Meski begitu, saat coret-coret langsung sambil screen sharing, kadang saya membuka jspaint, dan kalau isinya layak dilihat orang lain nanti, saya juga memakai sesuatu seperti Figjam
Diagram dan menunjuk bekerja sangat baik karena itu adalah alat pengarah perhatian tertua yang kita miliki dan masih berguna. Sebelum bisa berbicara, kita menunjuk dan menangis, dan dalam hal lokasi serta navigasi, menunjuk jauh lebih langsung daripada bahasa, sehingga pasar laser pointer tetap ada
The Geometry of Meaning: Semantics of Conceptual Spaces karya Peter Gårdenfors membahas topik ini dengan cukup rinci. Barbara Tversky juga punya banyak riset tentang diagram dan penataan struktur ruang kognitif, dan “What Constitutes an Effective Representation?” karya Peter Cheng memberi kriteria yang cukup kuantitatif untuk representasi yang efektif
Shadowing, pairing, dan sesi whiteboard itu bagus. Dalam proses ini, kedua belah pihak harus sama-sama menggambar dan bertanya
Memilih dan menjalankan bersama proyek untuk memperluas atau mengubah model, kuis, pembelajar mengajar kembali, menghafal dan menuliskannya dengan tangan, semua itu juga bisa dipakai
Hafalan murni harus selalu dipakai bersama metode lain, dan tidak boleh dijadikan satu-satunya metode. Membuat diagram atau coretan di luar whiteboard, analisis kesenjangan dengan membandingkan model atau solusi lain, serta hammock time berupa perenungan yang reflektif dan setengah tidak sadar juga membantu
Menurut saya perlu dibedakan antara representasi untuk menyampaikan sesuatu dan representasi untuk benar-benar menjalankan tugas. Yang terakhir, meski tidak disebut di sini, lebih dekat ke “eksekusi”
Model yang dapat dijalankan sering kali kurang bagus untuk penyampaian, biasanya karena batas abstraksinya buruk. Dalam komputasi, abstraksi hampir selalu bocor
Memahami apa yang dilakukan sesuatu bisa tertutupi oleh gunung upaya yang ditumpuk agar hal itu bisa dilakukan secara efisien. Karena itu muncul kebutuhan untuk mencoret di atas serbet sambil menjelaskan, “pada level abstraksi yang cocok dengan mental modelmu saat ini, beginilah cara sistem ini bekerja”
Dokumentasi adalah artefak terpisah, jadi cenderung tertinggal dari model yang berjalan, dan untuk mencegahnya perlu perawatan yang sangat serius. Cara yang lebih sulit adalah mengikat dokumentasi langsung ke kode, atau seperti literate programming, menempatkan dokumentasi di depan kode
Jadi saat menyampaikan mental model, biasanya pendekatan dengan usaha dan pemeliharaan minimal yang paling masuk akal, yaitu coretan di serbet dan bersama-sama menangani sistem nyata seiring waktu
Ada alasan mengapa orang baru memulai dengan perbaikan bug yang mudah, bukan dengan menulis dokumen desain
Orang baru perlu belajar sambil melakukan, jadi tutorial mungkin paling cocok. Tetapi setelah mulai menyentuh sistem, kemungkinan besar sudah muncul beberapa kesalahpahaman, dan itu bisa diurai lewat penjelasan di atas coretan serbet
Jadi kalau memutuskan menulis tutorial, jangan mencoba membuat dokumen untuk “semuanya”, melainkan tulislah tutorial yang bagus dengan fokus yang jelas
Jawabannya adalah menulis
Perangkat lunak cukup menarik karena merupakan medium dinamis yang bersifat personal
Saya rasa sistem interaktif membantu. Misalnya debugger visual yang mengajarkan Python dan variabel yang ditampilkan dalam kotak