Belajar dari Kesalahan agar Gak Terulang di Kerja

“Ever tried.

Ever failed.

No matter.

Try again.

Fail again.

Fail better.” — Samuel Beckett

Rapat evaluasi proyek baru dimulai, tapi kamu udah sibuk menyusun alasan kenapa tenggatnya molor dan hasilnya meleset.

Belajar dari kesalahan sering berhenti di kalimat, “Lain kali harus lebih teliti,” padahal proyek berikutnya bisa mengulang masalah yang sama.

Kadika pernah melihat tim mengulang kekeliruan serupa karena evaluasi cuma mencari siapa yang salah, bukan apa yang perlu diperbaiki.

Kesalahan baru jadi pelajaran ketika kamu mengubahnya menjadi tindakan yang bisa diuji di pekerjaan berikutnya.

Belajar dari Kesalahan Dimulai dengan Jeda

Setelah proyek bermasalah, wajar kalau kamu ingin buru-buru menjelaskan keadaan atau langsung memperbaiki semuanya.

Tapi beri jeda sebentar sebelum evaluasi, terutama kalau emosi masih tinggi dan semua orang sibuk membela diri.

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

Coba catat tiga hal saat kejadian masih segar, yaitu apa yang terjadi, kapan mulai melenceng, dan dampak yang terlihat.

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

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

Kamu juga gak perlu mengubah evaluasi menjadi sidang panjang yang bikin orang takut bicara jujur.

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

Kalau jawabannya belum lengkap, tandai sebagai hal yang perlu dicek, bukan buru-buru mengisi kekosongan dengan dugaan.

Pisahkan Fakta dari Cerita di Kepala

Pekerja memeriksa catatan dan data proyek di laptop — Data yang jelas membantu memisahkan kejadian dari dugaan.

Setelah kejadian dicatat, pisahkan bukti yang bisa diperiksa dari penilaian yang muncul otomatis di kepala.

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

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

Ambil contoh kampanye yang hasilnya jauh di bawah target, lalu cek jumlah pengunjung, sumber trafik, waktu tayang, dan perubahan materi.

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

Kalau tim langsung menyimpulkan ide kampanye buruk, energi perbaikan bisa diarahkan ke bagian yang keliru.

Pertanyaan yang baik membantu kamu menguji asumsi, bukan sekadar menemukan bukti untuk mendukung kesimpulan awal.

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

Kayak 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, kendala dari proses yang rumit, dan percobaan baru gak selalu punya akar masalah yang sama.

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

Cari Akar Masalah Tanpa Menyalahkan Orang

Tim membahas urutan kejadian dalam evaluasi proyek — Pembahasan yang tenang membuka ruang untuk mencari penyebab.

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 bikin masalah makin besar.

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

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

Coba teknik bertanya “kenapa” beberapa kali, tapi jangan memperlakukannya kayak rumus ajaib yang pasti menemukan satu jawaban.

Jawaban pertama bisa jadi ada file yang kurang, lalu penyebab berikutnya adalah pemilik materi belum ditentukan dengan jelas.

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

Kalau 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 bikin lawan bicara sibuk membela diri.

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

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

Ubah Temuan Jadi Perbaikan Sistem Kerja

Kalau akar masalah udah terlihat, tentukan perubahan yang langsung menyentuh prosesnya, bukan cuma meminta semua orang lebih hati-hati.

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

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

Perubahan sistem gak 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, tapi cukup jelas untuk menunjukkan apakah masalahnya berkurang.

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

Tetapkan 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 tambahannya supaya solusi gak malah menciptakan hambatan baru di tahap pekerjaan lain.

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

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

Lakukan Evaluasi Setelah Proyek

Rekan kerja melakukan evaluasi proyek bersama — Evaluasi terarah membantu tim menyimpan pelajaran proyek.

Evaluasi setelah proyek akan lebih bermanfaat kalau 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 nunggu sampai seluruh detail terlupakan.

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

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

Pastikan pembicaraan gak cuma 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 pelajaran dalam dokumen yang bisa dicari, bukan hanya dalam notulen panjang yang gak pernah dibuka lagi.

Simpan keputusan, pemilik tindakan, dan tanggal untuk mengecek apakah perubahan udah berjalan.

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

Dengan begitu, evaluasi gak berubah jadi percakapan eksklusif yang mengabaikan orang yang memegang bagian penting pekerjaan.

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

Uji Perubahan dalam 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 udah kamu kumpulkan.

Kalau masalahnya laporan sering terlambat, amati apakah jadwal pengumpulan baru bikin bahan masuk lebih awal.

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

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

Tapi jangan juga mempertahankan langkah yang jelas gak membantu hanya karena kamu udah menghabiskan waktu untuk membuatnya.

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

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

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

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

Kalau Pola Terulang, Periksa Sistemnya

Profesional memeriksa ulang alur kerja dan daftar tugas — Pola yang terulang bisa menjadi tanda bahwa alur kerja perlu diperiksa.

Kesalahan yang terulang bukan bukti otomatis bahwa seseorang gak peduli atau gak 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 menyebalkan.

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.

Kalau kamu memimpin tim, tunjukkan bahwa menyampaikan masalah lebih awal gak otomatis berujung pada hukuman.

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

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

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

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

Pelajaran yang berguna bukan yang bikin kamu 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 membantumu melakukannya?

Gratis dibaca. Kalau kebantu, boleh traktir kopi.

Suka tulisan ini? Dapat yang berikutnya lewat email

Satu email seminggu. Isinya catatan yang gak aku taruh di blog.

Gak ada spam. Berhenti kapan saja.