Belajar dari Kesalahan agar Gak Terulang di Kerja

“Ever tried.

Agar Sulit Digantikan AI, Bangun 5 Kemampuan Ini

👤 Jurnalis Berita • 31/10/2026

Ever failed.

No matter.

Kombinasi Skill untuk Membangun Keunggulan Kerja

👤 Jurnalis Berita • 31/10/2026

Try again.

Fail again.

Fail better.” — Samuel Beckett

Rapat evaluasi proyek baru saja dimulai, tapi kamu sudah sibuk mencari alasan kenapa jadwalnya molor dan hasilnya tidak sesuai target.

Memetik pelajaran dari kegagalan sering hanya berhenti pada ucapan, “Lain kali harus lebih hati-hati,” padahal proyek berikutnya berpotensi mengulang masalah yang sama.

Saya pernah melihat tim mengulangi kesalahan yang sama karena evaluasi hanya mencari siapa yang bersalah, bukan apa yang perlu diperbaiki.

Kesalahan hanya menjadi pembelajaran ketika kamu mengubahnya menjadi tindakan yang bisa diuji pada proyek selanjutnya.

Memetik Pelajaran dari Kegagalan Dimulai dengan Berhenti Sejenak

Setelah proyek bermasalah, wajar kalau kamu ingin segera menjelaskan situasi atau langsung memperbaiki semuanya.

Namun, beri diri kamu waktu sejenak sebelum melakukan evaluasi, terutama ketika emosi masih tinggi dan semua orang sibuk membela diri.

Jeda bukan berarti menghindari, melainkan memberi ruang agar kamu bisa membedakan fakta dari rasa malu, kesal, atau takut disalahkan.

Cobalah mencatat tiga hal ketika kejadian masih segar: apa yang terjadi, kapan mulai menyimpang, dan dampak yang terlihat.

Contohnya, laporan terlambat dua hari karena data dari tim lain tiba setelah jadwal pengecekan terakhir.

Catatan seperti itu lebih berguna daripada menulis, “Tim kurang disiplin,” karena kalimat tersebut tidak menjelaskan penyebabnya.

Kamu juga tidak perlu mengubah evaluasi menjadi sidang panjang yang membuat orang takut berbicara jujur.

Mulai dengan pertanyaan sederhana, “Bagian mana yang berjalan sesuai rencana, dan kapan masalah pertama kali muncul?”

Jika jawabannya belum lengkap, tandai sebagai hal yang perlu diperiksa, bukan segera mengisi kekosongan dengan dugaan.

Pisahkan Fakta dari Narasi yang Mengada-ada dalam Pikiran

Setelah kejadian dicatat, pisahkan bukti yang bisa diverifikasi dari penilaian yang muncul otomatis dalam pikiran.

Fakta bisa berupa tanggal revisi, jumlah kesalahan data, durasi keterlambatan, atau pesan yang menunjukkan perubahan permintaan.

Sebaliknya, “klien selalu berubah pikiran” adalah tafsir yang mungkin tidak sesuai dengan urutan kejadian sebenarnya.

Misalnya, kampanye yang hasilnya jauh di bawah target, lalu periksa jumlah pengunjung, sumber trafik, waktu tayang, dan perubahan materi.

Mungkin masalahnya bukan promosi yang kurang menarik, tapi tautan pembayaran sempat rusak selama beberapa jam.

Jika tim langsung menyimpulkan ide kampanye buruk, energi perbaikan bisa diarahkan ke bagian yang salah.

Pertanyaan yang baik membantu kamu menguji asumsi, bukan hanya mencari bukti untuk mendukung kesimpulan awal.

Ini juga alasan kenapa catatan kejadian dan data kerja perlu dikumpulkan sebelum rapat evaluasi.

Seperti yang dibahas Amy C. Edmondson dalam artikel Harvard Business Review tentang belajar dari kegagalan, jenis kegagalan yang berbeda perlu ditanggapi dengan cara yang berbeda pula.

Kesalahan kecil yang bisa dicegah, hambatan dari proses yang rumit, dan percobaan baru tidak selalu punya akar masalah yang sama.

Jadi, tahan dulu kalimat, “Kita selalu begini,” lalu cari bukti yang mendukung atau membantahnya.

Cari Penyebab Utama Masalah Tanpa Menuduh Seseorang

Begitu fakta terkumpul, susun urutan kejadian dari awal sampai dampaknya terasa oleh tim atau pelanggan.

Tanyakan apa yang berubah, informasi apa yang belum tersedia, dan keputusan apa yang membuat masalah semakin besar.

Misalnya, presentasi terlambat dikirim karena desain belum selesai, tetapi desainer baru menerima naskah setelah jadwal revisi.

Jika evaluasi berhenti pada, “Desainnya lambat,” kamu melewatkan alur kerja yang mengirim materi terlalu mepet.

Cobalah teknik bertanya “kenapa” beberapa kali, tetapi jangan menganggapnya sebagai rumus ajaib yang pasti menemukan satu jawaban.

Jawaban pertama mungkin karena file yang kurang, lalu penyebab berikutnya adalah pemilik materi belum ditentukan dengan jelas.

Terus gali sampai kamu menemukan faktor yang bisa ditangani, seperti aturan serah terima, jadwal, atau akses informasi.

Jika penyebabnya melibatkan kebiasaan seseorang, tetap bahas tindakannya dengan spesifik dan tenang, bukan menyerang sifatnya.

“File final dikirim setelah jam empat” lebih jelas daripada, “Kamu gak pernah bisa diandalkan.”

Kalimat pertama membuka ruang untuk mencari solusi, sedangkan kalimat kedua biasanya membuat lawan bicara sibuk membela diri.

Saya juga sering mengingatkan diri sendiri untuk memeriksa asumsi sebelum menunjuk penyebab, seperti yang dibahas dalam artikel Melawan Asumsi.

Kadang akar masalahnya bukan hal besar, melainkan kolom pemilik tugas yang kosong sejak awal.

Ubah Hasil Temuan menjadi Perbaikan Sistem Kerja

Jika akar masalah sudah terlihat, tentukan perubahan yang langsung menyentuh prosesnya, bukan hanya meminta semua orang lebih hati-hati.

Misalnya, kesalahan angka berulang karena file sumber tersebar di beberapa folder, buat satu lokasi dokumen resmi.

Tambahkan juga nama penanggung jawab dan tanggal pembaruan supaya tim tahu data mana yang paling baru.

Perubahan sistem tidak harus berupa perangkat lunak mahal atau rapat tambahan setiap minggu.

Kamu bisa mulai dari daftar pengecekan sebelum materi dikirim, format serah terima yang konsisten, atau satu tahap pemeriksaan angka.

Pilih perubahan yang cukup ringan untuk dicoba, tetapi cukup jelas untuk menunjukkan apakah masalahnya berkurang.

“Lebih teliti” bukan perbaikan yang bisa diperiksa, sedangkan “minta rekan memeriksa angka sebelum laporan dikirim” bisa diuji.

Tentukan siapa yang menjalankan perubahan, kapan perubahan dimulai, dan tanda apa yang dianggap sebagai kemajuan.

Contohnya, tim ingin mengurangi revisi akibat data keliru dari empat kali menjadi satu kali per laporan.

Catat juga beban tambahan supaya solusi tidak malah menciptakan hambatan baru di tahap pekerjaan lain.

Jika prosedur baru membuat pekerjaan rutin bertambah satu jam, cari cara menyederhanakan proses sambil mempertahankan pemeriksaan penting.

Tujuannya bukan membuat aturan sebanyak mungkin, tapi membuat kesalahan yang sama lebih sulit terjadi lagi.

Lakukan Evaluasi di Akhir Proyek untuk Mencatat Pembelajaran

Evaluasi setelah proyek akan lebih bermanfaat jika waktunya dekat dengan pekerjaan, saat detailnya masih mudah diingat.

Untuk proyek singkat, sisihkan sekitar tiga puluh menit setelah hasil utama selesai dan undang orang yang terlibat langsung.

Untuk proyek besar, kamu bisa mengevaluasi beberapa tahap penting, bukan menunggu sampai seluruh detail terlupakan.

Gunakan pertanyaan yang sama setiap kali agar pembahasan tetap terarah dan hasil evaluasinya mudah dibandingkan.

Tanyakan apa yang direncanakan, apa yang benar-benar terjadi, kenapa ada perbedaan, dan apa yang akan dicoba berikutnya.

Pastikan pembicaraan tidak hanya membahas hal buruk, karena praktik yang berhasil juga perlu dipahami dan dipertahankan.

Misalnya, tim berhasil menghindari revisi mendadak karena klien menyetujui contoh desain lebih awal.

Catat pembelajaran dalam dokumen yang bisa dicari, bukan hanya dalam notulen panjang yang tidak pernah dibuka lagi.

Simpan keputusan, pemilik tindakan, dan tanggal untuk memeriksa apakah perubahan sudah berjalan.

Jika ada anggota tim yang tidak bisa hadir, kirim catatan singkat dan beri kesempatan menambahkan konteks.

Dengan begitu, evaluasi tidak berubah menjadi percakapan eksklusif yang mengabaikan orang yang memegang bagian penting pekerjaan.

Ukur keberhasilan dari perubahan nyata, seperti waktu pengerjaan yang lebih stabil, koreksi yang berkurang, atau keluhan pelanggan yang menurun.

Uji Perubahan yang Diusulkan pada Pekerjaan Berikutnya

Sebuah ide perbaikan belum terbukti hanya karena semua orang setuju saat rapat evaluasi.

Uji perubahan pada proyek berikutnya, lalu bandingkan hasilnya dengan catatan awal yang sudah kamu kumpulkan.

Jika masalahnya laporan sering terlambat, amati apakah jadwal pengumpulan baru membuat bahan masuk lebih awal.

Jika keterlambatan tetap terjadi, cari tahu apakah jadwalnya tidak realistis atau ada hambatan lain yang belum terungkap.

Jangan terburu-buru menyimpulkan solusi gagal hanya karena satu percobaan belum sempurna.

Namun, jangan mempertahankan langkah yang jelas tidak membantu hanya karena kamu sudah menghabiskan waktu untuk membuatnya.

Mintalah tanggapan dari orang yang menggunakan proses itu setiap hari, karena mereka biasanya tahu bagian yang terasa merepotkan.

Misalnya, daftar pengecekan mungkin membantu menemukan kesalahan, tetapi urutannya perlu disesuaikan dengan cara kerja tim.

Uji perubahan dalam skala kecil jika dampaknya belum pasti, lalu perluas setelah hasilnya terasa berguna.

Perbaikan yang konsisten lahir dari siklus mencoba, melihat dampak, dan menyesuaikan langkah.

Jika Pola yang Sama Terjadi Lagi, Periksa Sistem yang Berjalan

Kesalahan yang berulang bukan bukti otomatis bahwa seseorang tidak peduli atau tidak mampu bekerja.

Bisa jadi tugasnya terlalu banyak, batas tanggung jawabnya kabur, atau proses penting hanya diketahui satu orang.

Coba lihat pola dari beberapa proyek, bukan hanya kejadian terakhir yang masih terasa menjengkelkan.

Jika kesalahan muncul saat serah terima, rapikan informasi yang wajib ikut berpindah bersama tugas.

Jika kesalahan muncul menjelang tenggat, periksa pembagian beban, tahap persetujuan, dan waktu yang tersedia.

Jika kamu memimpin tim, tunjukkan bahwa menyampaikan masalah lebih awal tidak otomatis berujung pada hukuman.

Tim yang merasa aman untuk bicara lebih mungkin mengangkat risiko sebelum dampaknya membesar.

Kamu tetap bisa meminta tanggung jawab, tetapi arahkan pembicaraan ke tindakan, dampak, and perubahan yang disepakati.

Jika kesalahan serupa masih muncul, anggap itu sinyal untuk memeriksa ulang penyebab dan merancang solusi, bukan alasan mengulang teguran yang sama.

Saya berharap, setelah membaca ini, kamu bisa memilih satu kejadian kerja yang masih mengganggu lalu menuliskan fakta dan satu perbaikan yang ingin diuji.

Pelajaran yang berguna bukan yang membuatmu terus menyalahkan diri, melainkan yang membantu pekerjaan berikutnya berjalan lebih baik.

Jadi, saat proyek berikutnya selesai, apa satu pola yang ingin kamu hentikan dan sistem apa yang bisa membantu kamu melakukannya?