9  UAS-4 My Knowledge

9.1 Pengetahuan untuk Kolaborasi: Dari “Tahu” ke “Bisa Dipakai”

Di bagian ini saya menulis tentang pengetahuan yang paling penting ketika membangun sistem informasi pendidikan berbantuan AI. Bagi saya, pengetahuan bukan sekadar banyak informasi. Pengetahuan adalah pemahaman yang cukup jelas untuk dipakai mengambil keputusan, menjelaskan alasan, dan memprediksi akibatnya.

Dalam proyek pendidikan, masalah utama sering bukan “kurang ide”, tetapi “pengetahuan yang tidak sinkron”. Guru, tim teknis, relawan, dan pengguna bisa sama-sama merasa paham, tetapi yang dipahami berbeda. Karena itu, pengetahuan harus dibuat eksplisit, dibagi, lalu diverifikasi.

9.2 Beban yang Ingin Saya Atasi

Beban yang sering muncul dalam implementasi sistem pendidikan AI:

  • Definisi “kemajuan belajar” berbeda-beda.
  • AI dipakai tanpa batas yang jelas, sehingga tim sulit bertanggung jawab.
  • Informasi tersebar di chat, tidak menjadi rujukan keputusan.
  • Saat konflik muncul, tidak ada “peta bersama” untuk balik ke akar masalah.

Beban ini terlihat sebagai rework, miskom berulang, dan keputusan lambat.

9.2.1 Definisi operasional (biar “knowledge” tidak abstrak)

Dalam konteks kolaborasi, saya memakai definisi praktis:

  • Informasi: potongan fakta atau pesan (misalnya chat, brief, catatan).
  • Pengetahuan bersama: informasi yang sudah disepakati maknanya, ditulis ringkas, dan bisa dirujuk untuk keputusan.
  • Sinkron: semua anggota bisa mengulang definisi kunci (misalnya definisi “selesai”) dengan isi yang sama.

Kalau pengetahuan tidak sinkron, tim biasanya tidak gagal karena kurang bekerja, tetapi gagal karena bekerja ke arah yang berbeda.

9.2.2 Indikator observabel (agar validitas naik)

Saya menilai “pengetahuan bersama” sudah terbentuk jika:

  1. Semua anggota bisa menyebut definisi selesai yang sama (ya/tidak).
  2. Semua anggota tahu siapa PIC untuk bagian inti (ya/tidak).
  3. Semua anggota tahu aturan keputusan ketika beda pendapat (ya/tidak).
  4. Keputusan bisa dijelaskan dengan format: “kita memilih X karena Y, dengan asumsi Z”.

Kalau indikator ini tidak terpenuhi, saya anggap tim masih berada di level “informasi”, belum menjadi “pengetahuan bersama”.

9.3 Beban yang Ingin Saya Atasi

Beban yang sering muncul dalam kolaborasi:

  • Orang menganggap semua sudah jelas, padahal definisi dan asumsi berbeda.
  • Keputusan diambil dari “katanya” atau intuisi, tanpa dasar yang bisa dijelaskan.
  • Informasi tersebar di chat, tidak menjadi pengetahuan bersama yang bisa dirujuk.
  • Saat konflik muncul, tim tidak punya rujukan yang sama untuk kembali ke akar masalah.

Beban ini biasanya terlihat sebagai rework, miskom yang berulang, dan keputusan yang lambat.

9.4 Opini Pengetahuan Saya: Pengetahuan yang Baik Harus “Terstruktur” dan “Teruji”

Saya punya dua prinsip sederhana supaya pengetahuan tidak cuma jadi hafalan.

9.4.1 1) Pengetahuan harus terstruktur (biar jelas dan bisa dipakai)

Saya membagi pengetahuan kerja tim menjadi tiga jenis:

  1. Fakta (what)
    Apa yang benar, apa yang terjadi, apa yang dibutuhkan.

  2. Prosedur (how)
    Bagaimana cara mengerjakan, alur kerja, siapa melakukan apa.

  3. Konteks dan alasan (why)
    Kenapa kita memilih cara itu, nilai apa yang dijaga, trade-off apa yang diterima.

Kalau cuma punya fakta tanpa prosedur, tim bingung eksekusi. Kalau punya prosedur tanpa alasan, tim gampang pecah saat ada perubahan kondisi.

9.4.2 2) Pengetahuan harus teruji (biar valid, bukan sekadar yakin)

Saya menganggap pengetahuan itu valid kalau:

  • bisa dijelaskan ulang dengan kalimat sendiri
  • bisa dipakai untuk membuat prediksi kecil (misalnya: “kalau kita ubah X, dampaknya Y”)
  • bisa diuji lewat contoh, data, atau percobaan kecil
  • tetap masuk akal walaupun dikritik

Dengan cara ini, saya menghindari dua ekstrem: sok yakin tanpa dasar, atau ragu terus padahal sudah cukup informasi.

9.5 Cara Saya Membangun Pengetahuan dalam Kerja Tim

Saya pakai alur yang konsisten supaya pengetahuan cepat jadi “milik bersama”, bukan cuma ada di kepala satu orang.

flowchart TD
  A[Informasi mentah] --> B[Seleksi: relevan untuk keputusan]
  B --> C[Ubah jadi klaim yang jelas]
  C --> D[Verifikasi: ringkasan bersama]
  D --> E[Dokumentasi: canvas / catatan keputusan]
  E --> F[Pengetahuan bersama]
  F --> G[Keputusan lebih cepat & stabil]
  F --> H[Eksekusi lebih rapi]
  F --> I[Konflik turun karena parameter jelas]

9.5.1 Langkah 1: Kumpulkan informasi yang relevan (bukan semua informasi)

Saya cari informasi yang langsung mempengaruhi keputusan, misalnya:

  • kebutuhan tugas dan kriteria penilaian
  • batasan waktu, resource, kemampuan tim
  • contoh output yang diharapkan
  • risiko yang paling mungkin terjadi

Tujuannya supaya tim tidak tenggelam di detail yang tidak berdampak.

9.5.2 Langkah 2: Ubah informasi jadi klaim yang jelas

Saya biasakan mengubah “informasi mentah” menjadi kalimat klaim yang tegas, misalnya:

  • “Definisi selesai kita adalah: laporan + slide + demo.”
  • “Batasan kita: waktu kerja efektif 3 hari, jadi scope harus diperkecil.”
  • “Risiko terbesar: integrasi terakhir. Jadi integrasi harus mulai lebih awal.”

Kalimat klaim ini memudahkan orang untuk setuju atau tidak setuju.

9.5.3 Langkah 3: Verifikasi pemahaman dengan ringkasan (mutual check)

Saya minta setiap orang bisa merangkum kesepakatan dengan versi mereka sendiri. Kalau ringkasannya berbeda, berarti pengetahuan belum sinkron, dan harus diperbaiki sebelum eksekusi.

9.5.4 Langkah 4: Dokumentasikan dalam format ringkas yang bisa dirujuk

Pengetahuan yang tidak ditulis biasanya menguap. Jadi saya suka menulis versi singkatnya, misalnya dalam bentuk canvas satu halaman atau catatan keputusan.

9.6 Contoh Knowledge Card yang Terisi (untuk Validity)

Contoh ini saya buat dari skenario tugas kelompok agar terlihat nyata.

NoteKnowledge Card (Contoh Terisi)
  • Klaim utama: Definisi selesai untuk tugas ini adalah “laporan + slide + demo minimal berjalan”.
  • Dasar (data / contoh / pengalaman): Rubrik butuh presentasi; pengalaman tugas sebelumnya gagal karena demo tidak siap meski laporan lengkap.
  • Asumsi yang dipakai: Tim punya waktu 3 hari; demo minimal cukup (tidak perlu polish berlebihan).
  • Risiko kalau klaim salah: Jika ternyata rubrik menuntut demo lebih lengkap, nilai turun.
  • Tes kecil berikutnya untuk memvalidasi: Dalam 24 jam pertama, buat demo skeleton (fitur inti saja) dan minta 1 orang cek sesuai brief.
  • Siapa PIC: PIC Demo = A, PIC Laporan = B, PIC Slide = C, PIC Integrasi = D.

Contoh terisi ini membantu meningkatkan validitas, karena menunjukkan pengetahuan bukan teori, tapi bisa dipakai untuk keputusan nyata.

9.7 Inovasi kecil yang saya pakai untuk membuat pengetahuan jadi berguna

Agar pengetahuan tidak berhenti di “paham”, saya pakai dua artefak sederhana.

9.7.1 1) Decision Log (catatan keputusan)

Setiap keputusan penting saya tulis dalam format:

  • Keputusan: kita memilih apa
  • Alasan: kenapa memilih itu
  • Asumsi: apa yang kita anggap benar
  • Dampak: apa yang berubah setelah keputusan

Ini membantu saat tim lupa alasan, atau saat kondisi berubah.

9.7.2 2) Knowledge Card (kartu pengetahuan)

Kartu ini saya pakai untuk menyusun pengetahuan agar jelas dan teruji.

NoteTemplate Knowledge Card (Copy-Paste)
  • Klaim utama: …
  • Dasar (data / contoh / pengalaman): …
  • Asumsi yang dipakai: …
  • Risiko kalau klaim salah: …
  • Tes kecil berikutnya untuk memvalidasi: …
  • Siapa PIC: …

Dengan format ini, pengetahuan jadi bisa diperdebatkan dengan sehat, karena yang dibahas adalah klaim dan dasarnya, bukan orangnya.

9.8 Failure Modes (kapan pengetahuan “gagal”) dan Fix-nya

  1. False agreement: semua mengangguk, tapi definisi kunci berbeda di kepala masing-masing.
    Fix: wajibkan ringkasan bergantian (mutual check) dan tulis 1 kalimat definisi “selesai”.

  2. Info tercecer: keputusan ada di chat, tapi hilang ditelan pesan baru.
    Fix: pilih satu tempat “single source of truth” (canvas/notes) dan biasakan mencatat keputusan.

  3. Dominance: satu orang menentukan “pengetahuan” tanpa ruang koreksi.
    Fix: pisahkan klaim dan orangnya; minta minimal 1 counterpoint atau risiko sebelum keputusan final.

  4. Assumption blind spot: tim tidak sadar asumsi yang mereka pakai.
    Fix: setiap keputusan harus menuliskan minimal 1 asumsi yang eksplisit.

9.9 Kenapa Pengetahuan Ini Berguna untuk Komunikasi Interpersonal

Menurut saya, komunikasi interpersonal yang baik bukan cuma “ramah” atau “lancar bicara”. Komunikasi yang baik membuat pengetahuan bersama terbentuk.

Kalau pengetahuan bersama terbentuk, maka:

  • konflik lebih cepat diarahkan ke akar masalah
  • keputusan lebih cepat diambil karena parameternya jelas
  • orang merasa dihargai karena pendapatnya masuk ke struktur pengetahuan tim
  • kerja tim lebih stabil saat ada perubahan scope

9.10 Penutup

Pengetahuan yang saya anggap paling penting adalah pengetahuan yang bisa dipakai. Artinya: jelas strukturnya, bisa diuji validitasnya, dan menghasilkan tindakan yang lebih rapi.

Dengan membuat pengetahuan eksplisit (klaim, dasar, asumsi, tes), saya merasa kerja tim jadi lebih ringan, konflik berkurang, dan komunikasi interpersonal lebih sehat karena semua orang berbicara di atas peta yang sama.