Ringkasan
Sering kali sebuah dokumen teknis terlihat sederhana.
Ada daftar komponen, estimasi biaya, risiko, rekomendasi arsitektur, atau target operasional. Sekilas terlihat seperti informasi yang bisa ditulis dalam beberapa jam.
Namun setelah ditelusuri lebih dalam, banyak dokumen sebenarnya merupakan hasil kompresi pengalaman yang berlangsung bertahun-tahun.
Yang terlihat hanya kesimpulan. Proses belajar yang menghasilkan kesimpulan tersebut sering kali tidak terlihat.
Insight Utama
Bayangkan sebuah dokumen yang berisi rekomendasi:
- Gunakan MongoDB untuk event tracking
- Monitoring harus menjadi komponen wajib
- Lost Tracking Rate ditargetkan di bawah 5%
- Gunakan queue untuk mengurangi event loss
Bagi pembaca, poin-poin tersebut mungkin terlihat sebagai rekomendasi teknis biasa.
Padahal di belakangnya bisa saja terdapat sejarah yang panjang:
- Keterbatasan database sebelumnya
- Tracking yang pernah hilang tanpa terdeteksi
- Attribution yang tidak lengkap
- Dashboard yang terlihat normal tetapi datanya tidak valid
- Query analytics yang membebani sistem
- Kesalahan pengambilan keputusan akibat data yang tidak lengkap
Pada akhirnya pengalaman tersebut tidak ditulis ulang satu per satu.
Pengalaman tersebut dikompresi menjadi prinsip, aturan, dan rekomendasi.
Mengapa Ini Penting
Ketika membaca dokumentasi, mudah untuk berasumsi bahwa isi dokumen hanyalah kumpulan informasi.
Padahal sering kali yang sedang dibaca adalah kumpulan pelajaran yang sudah disaring.
Perbedaannya dapat digambarkan sebagai berikut:
Pengalaman
↓
Observasi
↓
Kegagalan
↓
Perbaikan
↓
Keputusan
↓
Dokumentasi
Semakin matang sebuah sistem, semakin besar kemungkinan dokumentasinya merupakan hasil kompresi pengalaman yang panjang.
Karena itu nilai sebuah dokumen tidak hanya terletak pada jumlah halamannya, tetapi juga pada banyaknya pengalaman yang berhasil dipadatkan ke dalamnya.
Tanda-Tanda Knowledge Compression
Beberapa ciri bahwa sebuah dokumen merupakan hasil knowledge compression:
- Menjelaskan trade-off, bukan hanya rekomendasi
- Menjelaskan risiko, bukan hanya fitur
- Memiliki target operasional yang jelas
- Menjelaskan konsekuensi jika suatu komponen dihilangkan
- Berisi keputusan yang dapat ditelusuri alasannya
- Fokus pada masalah nyata, bukan sekadar best practice generik
Checklist Saat Membuat Dokumentasi
Sebelum menyelesaikan sebuah dokumen, pertimbangkan beberapa pertanyaan berikut:
- Mengapa keputusan ini diambil?
- Masalah apa yang ingin dicegah?
- Risiko apa yang pernah muncul sebelumnya?
- Trade-off apa yang sedang diterima?
- Apa yang akan terjadi jika rekomendasi ini diabaikan?
- Pengalaman apa yang sebenarnya sedang dikompresi ke dalam dokumen ini?
Jika pertanyaan-pertanyaan tersebut dapat dijawab, kemungkinan besar dokumen tersebut lebih dari sekadar dokumentasi teknis.
Penutup
Dokumentasi yang baik bukan hanya alat komunikasi.
Ia adalah mekanisme transfer pengetahuan.
Tujuannya bukan sekadar menjelaskan bagaimana sesuatu bekerja, tetapi juga mewariskan pelajaran yang diperoleh dari pengalaman sebelumnya.
Dalam banyak kasus, nilai terbesar sebuah dokumen bukan terletak pada informasi yang tertulis, melainkan pada pengalaman bertahun-tahun yang berhasil dikompresi ke dalam beberapa halaman yang dapat dibaca dalam hitungan menit.