Decision Log: Dokumentasi dengan Upaya Paling Rendah yang Terbayar

Sebuah tim engineering menghabiskan satu setengah hari merekonstruksi mengapa mereka memilih database tertentu 14 bulan lalu. Keputusannya ada di suatu tempat dalam thread Slack yang sudah terkubur, serangkaian email yang tidak ada yang bisa menemukan, dan ingatan dua orang yang telah meninggalkan perusahaan. Akhirnya mereka tidak yakin apakah mereka merekonstruksi pemikiran aslinya atau menciptakan pembenaran baru yang cocok dengan keputusan yang ada. Mereka akhirnya mengubah database tersebut karena tidak ada yang bisa memberi tahu mereka mengapa mereka memilihnya sejak awal.

Ini adalah biaya dokumentasi yang buruk. Bukan dokumentasi yang tidak ada — dokumentasi yang ada, tetapi tersebar, tidak terstruktur, dan tidak dapat ditemukan kembali ketika dibutuhkan.

Decision log memecahkan masalah spesifik ini. Bukan semua masalah dokumentasi. Masalah ini: "Mengapa kita memutuskan ini, dan apa yang kita pertimbangkan sebelum memilihnya?"

Apa yang perlu masuk dalam decision log (dan apa yang tidak)

Decision log bukan catatan meeting. Bukan changelog. Bukan daftar semua tindakan yang diambil tim. Itu rekaman keputusan yang cukup penting untuk perlu dipahami seseorang nanti.

Filter yang berguna: dokumentasikan keputusan yang memenuhi salah satu dari ini:

  • Seseorang akan bertanya "mengapa kita melakukan ini?" dalam enam bulan ke depan
  • Keputusan itu tidak dapat dengan mudah dibalik tanpa biaya yang signifikan
  • Keputusan itu dibuat berdasarkan konteks yang mungkin tidak lagi terlihat jelas nanti
  • Lebih dari satu pendekatan yang masuk akal dipertimbangkan sebelum memilih satu

Anda tidak perlu mendokumentasikan ke mana makan siang rapat, urutan item dalam agenda, atau keputusan rutin yang dibuat dengan kebiasaan yang mapan. Anda perlu mendokumentasikan mengapa Anda memilih vendor ini daripada itu, mengapa Anda menunda fitur tertentu ke kuartal berikutnya, mengapa Anda mengubah proses onboarding, mengapa Anda menetapkan target harga seperti itu.

Format: enam kolom, tidak lebih

Format decision log yang berhasil digunakan orang adalah yang bisa diisi dalam tiga sampai lima menit. Lebih panjang dari itu dan orang akan berhenti mengisinya. Berikut enam kolom yang menangkap apa yang benar-benar Anda butuhkan:

Tanggal: Kapan keputusan dibuat. Ini penting ketika konteks berubah — keputusan yang dibuat sebelum penguncian COVID memiliki arti yang berbeda dari keputusan yang dibuat setelahnya.

Keputusan: Satu kalimat yang menyatakan apa yang diputuskan. "Kita akan menggunakan Notion untuk dokumentasi internal" bukan "kita membahas opsi alat dokumentasi." Keputusan spesifik, bukan ringkasan diskusi.

Konteks: Mengapa keputusan ini perlu dibuat sekarang? Apa yang mendorongnya? Dua sampai tiga kalimat sudah cukup. Ini adalah bagian yang paling sering dilewati dan yang paling berharga ketika Anda membaca kembali enam bulan kemudian.

Alternatif yang dipertimbangkan: Opsi lain apa yang ada di meja? Bahkan daftar poin singkat cukup. Ini mencegah seseorang yang baru bergabung mengatakan "mengapa kita tidak pernah mempertimbangkan X?" ketika jawabannya adalah "kita pertimbangkan tetapi memilih Y karena alasan Z."

Alasan: Mengapa opsi yang dipilih menang? Satu sampai tiga alasan spesifik, bukan pernyataan umum seperti "ini yang terbaik untuk tim." Alasan buruk: "Ini lebih baik." Alasan bagus: "Ini mengurangi waktu setup 40% berdasarkan percobaan kami, dan kami memprioritaskan kecepatan lebih dari fleksibilitas pada fase ini."

Pemilik: Siapa yang membuat atau memiliki keputusan ini. Ketika seseorang ingin menyelidiki lebih lanjut nanti, mereka tahu harus menghubungi siapa.

Itu saja. Enam kolom. Spreadsheet sederhana atau tabel Notion berhasil. Anda tidak perlu software khusus.

Cara membuat orang mengisinya

Format terbaik di dunia gagal jika tidak ada yang mengisinya. Masalah yang sebenarnya bukan kemauan — hampir semua orang setuju bahwa mendokumentasikan keputusan adalah ide yang bagus. Masalahnya adalah kebiasaan.

Tiga mekanisme yang membuat pengisian decision log menjadi kebiasaan, bukan niat:

Tunjuk notulen setiap meeting yang melibatkan keputusan. Sebelum meeting berakhir, ada satu momen sederhana: "Siapa yang akan mengisi decision log untuk keputusan yang kita buat hari ini?" Menunjuk seseorang secara eksplisit lebih baik daripada harapan umum bahwa seseorang akan melakukannya.

Tambahkan ke agenda sebagai item penutup. Agenda meeting yang berakhir dengan "keputusan yang perlu didokumentasikan" membuat pengisian log menjadi bagian dari proses, bukan renungan terpisah. Tiga menit di akhir meeting lebih baik daripada mencoba mengingat detail dua hari kemudian.

Tinjau backlog setiap dua minggu. Keputusan yang baru dibuat sering terasa tidak perlu didokumentasikan karena konteksnya masih segar. Pemeriksaan dua mingguan — "keputusan apa yang kita buat dua minggu terakhir yang belum ada di log?" — menangkap keputusan yang terlewatkan sebelum konteksnya memudar.

Satu hal yang harus dihindari: jangan jadikan decision log sebagai audit yang mencari kesalahan. Jika seseorang merasa bahwa mendokumentasikan keputusan berarti mereka akan dipertanyakan nanti, mereka akan berhenti mendokumentasikan. Log ini adalah alat tim, bukan catatan akuntabilitas manajerial.

Di mana menyimpan decision log

Tempat terbaik adalah di mana orang akan mencarinya. Ini terdengar jelas tetapi terlewatkan secara konsisten.

Jika tim Anda bekerja di Notion, simpan di Notion. Jika Anda menggunakan Confluence, simpan di sana. Jika tim teknis Anda menggunakan repositori kode sebagai pusat dokumentasi, file markdown di repositori itu masuk akal. Alat yang tepat adalah yang akan digunakan orang ketika mereka mencari keputusan sebelumnya.

Yang tidak berhasil: menyimpan decision log di folder shared drive yang tidak pernah dibuka siapa pun, di email yang dikirim ke seluruh tim, atau di wiki yang tidak seorang pun tahu cara navigasinya.

Satu folder, satu file (atau satu halaman), mudah ditemukan. Kalau ada tiga tempat di mana keputusan mungkin disimpan, tidak ada yang akan memeriksa semua tiganya. Mereka akan bertanya kepada seseorang yang mungkin tahu, yang menghilangkan manfaat yang Anda coba ciptakan.

Ukuran dan granularitas

Ada dua kesalahan granularitas yang berlawanan:

Terlalu granular: Mendokumentasikan setiap keputusan kecil menciptakan log yang sangat panjang sehingga orang berhenti membacanya karena terlalu berisik untuk menemukan apa yang mereka cari. Jika decision log Anda memiliki 200 entri dalam sebulan, Anda mendokumentasikan terlalu banyak.

Terlalu jarang: Mendokumentasikan hanya keputusan besar dan strategis berarti Anda kehilangan keputusan tingkat menengah yang merupakan sumber kebingungan terbesar — keputusan implementasi, pilihan vendor, perubahan proses yang tidak cukup besar untuk mendapat memo tetapi cukup penting untuk membuat seseorang penasaran enam bulan kemudian.

Filter yang berguna: apakah keputusan ini akan membuat seseorang baru bertanya "mengapa kita melakukan ini seperti ini?" dalam enam bulan? Jika ya, dokumentasikan. Jika tidak, mungkin tidak perlu.

Untuk kebanyakan tim, ini berarti tiga sampai tujuh entri per minggu. Cukup untuk menangkap konteks yang bermakna, tidak terlalu banyak sehingga log menjadi kebisingan.

Menggunakan decision log untuk onboarding

Decision log yang dikelola dengan baik adalah salah satu alat onboarding paling efektif yang tidak pernah digunakan sebagian besar tim. Ketika seseorang baru bergabung, mereka biasanya menghabiskan minggu pertama mereka bertanya kepada orang yang berbeda mengapa hal-hal dilakukan seperti yang dilakukan. Proses ini tidak efisien, mengganggu, dan bergantung pada orang yang mungkin tidak ingat atau mungkin tidak lagi bekerja di sana.

Decision log yang mencakup enam sampai dua belas bulan terakhir memberikan karyawan baru cara untuk memahami mengapa tim bekerja seperti yang dilakukannya, tanpa perlu mengandalkan ingatan orang lain. Mereka bisa membaca konteks yang diperlukan secara mandiri dan muncul dalam percakapan onboarding dengan pertanyaan yang lebih baik.

Integrasikan ini ke dalam checklist onboarding secara eksplisit: "Baca decision log dari enam bulan terakhir. Catat keputusan yang ingin Anda pahami lebih dalam. Bawa pertanyaan tersebut ke pertemuan minggu kedua Anda."

Ketika keputusan berubah

Decision log bukan dokumen yang tidak dapat diubah. Ketika keputusan dibalik, tambahkan entri baru yang menjelaskan hal itu. Format yang sama: tanggal, keputusan (yang baru, termasuk "membalik keputusan [tanggal] untuk..."), konteks, alternatif, alasan, pemilik.

Ini lebih berharga daripada memperbarui entri asli karena Anda mempertahankan riwayat bagaimana pemikiran berubah. Ketika seseorang membaca log nanti, mereka bisa melihat bahwa tim awalnya membuat keputusan A, kemudian sembilan bulan kemudian membaliknya ke keputusan B karena alasan Z. Pemahaman tersebut seringkali lebih berharga daripada keputusan akhir itu sendiri.

Kesalahan umum

Menjadikannya terlalu formal: Decision log yang membutuhkan persetujuan, tanda tangan, atau tinjauan manajerial sebelum dikirimkan akan diisi secara tidak konsisten. Buat prosesnya seringan mungkin.

Menyimpannya di tempat yang salah: Log yang ada di wiki yang tidak pernah dibuka siapa pun tidak lebih baik dari tidak ada log. Simpan di mana orang sudah bekerja.

Tidak meninjau kembali: Decision log yang tidak pernah direferensikan akan berhenti diisi. Buat kebiasaan untuk mereferensikan log ketika keputusan terkait muncul — "kita sebenarnya mendokumentasikan ini, mari kita lihat konteksnya" memperkuat bahwa mengisi log ada manfaatnya.

Mendokumentasikan keputusan yang sudah ada, tidak yang baru: Beberapa tim mengisi decision log secara retroaktif, mencoba mendokumentasikan setiap keputusan yang pernah dibuat. Ini menguras energi dan menghasilkan dokumen yang tidak akurat. Mulai dari sekarang. Dokumentasikan ke depan, bukan ke belakang.

Apa yang harus dilakukan selanjutnya

Buat template decision log ini minggu ini. Pilih alat yang sudah digunakan tim Anda. Tambahkan enam kolom. Bagikan ke tim dengan satu kalimat konteks: "Mulai sekarang kita akan mendokumentasikan keputusan penting di sini sehingga kita tidak perlu merekonstruksi konteks nanti."

Kemudian di meeting berikutnya yang menghasilkan keputusan yang bermakna, isi satu entri bersama-sama. Lakukan secara publik, di depan tim, sehingga semua orang melihat betapa cepatnya. Tiga sampai lima menit. Itu saja yang diperlukan untuk memulai kebiasaan.

Setelah sebulan, tinjau log. Apakah Anda mendokumentasikan hal yang tepat? Apakah orang mereferensikannya? Apakah ada keputusan penting yang hilang? Sesuaikan dari sana.

Pelajari Lebih Lanjut