Dokumentasi Teknis untuk Tim Kecil

Di tim kecil, dokumentasi sering jadi proyek sampingan yang dikerjakan sekali lalu ditinggal. Saya sendiri pernah menghabiskan waktu berhari-hari menulis dokumen arsitektur lengkap, lalu beberapa bulan kemudian dokumen itu sudah tidak sinkron dengan kode karena tidak ada yang sempat memperbaruinya. Masalahnya bukan pada niat menulis dokumentasi, tapi pada bentuknya: dokumen besar dan terpisah dari kode nyaris pasti akan basi, karena update kode dan update dokumen jadi dua pekerjaan terpisah yang gampang dilupakan salah satunya. Di tim dengan sumber daya terbatas, pendekatan yang bertahan justru dokumentasi kecil-kecil yang menempel erat pada kode dan proses sehari-hari.

Kenapa dokumentasi tebal biasanya mati duluan

Dokumen tebal punya beberapa masalah struktural. Pertama, ia butuh effort besar untuk ditulis sehingga jarang direvisi ulang secara menyeluruh, akibatnya begitu satu bagian berubah, seluruh dokumen jadi meragukan kebenarannya. Kedua, dokumen semacam ini biasanya hidup di tempat terpisah dari kode—wiki, dokumen kolaborasi, atau drive—sehingga tidak ada yang otomatis mengingatkan penulis untuk memperbaruinya saat kode berubah. Ketiga, di tim kecil, satu orang sering merangkap banyak peran; waktu yang habis menulis dokumentasi panjang adalah waktu yang tidak dipakai untuk hal yang langsung berdampak. Kalau dokumentasi tidak dibaca ulang atau tidak dipercaya, ia kehilangan fungsinya sebagai sumber kebenaran.

Prinsip dokumentasi minimal yang saya pakai

Prinsip yang saya pegang: dokumentasikan hal yang paling sering ditanyakan atau paling sering bikin bingung, taruh sedekat mungkin dengan kode yang bersangkutan, dan jaga agar panjangnya cukup singkat untuk benar-benar dibaca. Beberapa bentuk yang saya pakai:

• README per proyek yang isinya hanya: cara menjalankan lokal, variabel environment penting, dan siapa yang bisa dihubungi kalau macet. Bukan penjelasan arsitektur lengkap.
• Komentar singkat di file konfigurasi, misalnya di docker-compose.yml atau .env.example, untuk menjelaskan kenapa sebuah nilai dipilih—bukan hanya apa nilainya.
• Catatan keputusan singkat (semacam ADR ringkas) setiap kali ada pilihan teknis yang tidak jelas alasannya kalau hanya dilihat dari kode, misalnya kenapa memilih mekanisme antrian tertentu atau kenapa suatu proses dijalankan secara sinkron, bukan asinkron.
• Runbook operasional pendek untuk skenario yang berulang, seperti langkah memulihkan layanan setelah restart, ditulis sebagai daftar langkah, bukan narasi panjang.

Menjaga dokumentasi tetap hidup

Dokumentasi yang bertahan lama biasanya punya satu sifat: ia diperbarui sebagai bagian dari pekerjaan, bukan sebagai tugas terpisah. Cara paling praktis adalah menjadikan update dokumentasi bagian dari definisi selesai suatu perubahan—kalau sebuah pull request mengubah cara suatu layanan dijalankan, README atau file konfigurasi terkait ikut diperbarui di pull request yang sama, bukan ditunda "nanti". Cara lain yang saya pakai adalah menghapus dokumentasi yang sudah tidak relevan begitu ketahuan, daripada membiarkannya menumpuk dan membingungkan pembaca berikutnya. Dokumentasi yang salah lebih berbahaya daripada tidak ada dokumentasi sama sekali, karena orang akan mempercayainya dan mengambil keputusan yang keliru berdasarkan itu.

Intinya

Untuk tim kecil, dokumentasi yang berguna bukan yang paling lengkap, tapi yang paling mungkin dibaca dan diperbarui. Fokus pada hal yang sering ditanyakan, taruh sedekat mungkin dengan kode, jaga tetap singkat, dan jadikan update dokumentasi bagian dari alur kerja normal—bukan pekerjaan tambahan yang gampang dilewatkan.