Tahun lalu, kita dapat 12 laporan bug sama dari pelanggan berbeda dalam 14 hari. Bugnya sederhana: tombol export CSV tidak berfungsi untuk user dengan filter lebih dari 5 kategori. Yang bikin ngeselin, laporan pertama masuk dua minggu sebelumnya.
Satu pelanggan sampai mau putus langganan karena dia butuh laporan itu untuk presentasi ke investor, dan kita cuma bisa jawab "tim kita lagi cek ya" selama 10 hari berturut-turut. Total kerugian dari churn itu hampir 30 juta per tahun, belum lagi waktu yang terbuang buat tim support jawab pertanyaan sama 12 kali.
Apa yang salah saat itu?
Kita gak punya sistem yang nyambung antara tim support dan engineering. Semua laporan bug dari pelanggan disimpan tim support di Google Sheet terpisah. Setiap pagi, koor support kirim ringkasan laporan lewat WA grup tim engineering. Engineering cuma baca ringkasan itu, gak pernah buka sheet asli, gak ada akses ke percakapan penuh dengan pelanggan.
Sementara itu, support gak punya akses ke board task engineering. Mereka gak tau bug mana yang lagi diurus, mana yang pending, mana yang sudah selesai dikerjakan. Jadi setiap ada pelanggan tanya progress, mereka cuma bisa chat PM nanya, tunggu jawaban 1-2 jam, baru balas pelanggan.
Kita sempat berpikir ini masalah individu: support kurang rajin ngirim update, engineering kurang cepet respon laporan. Ternyata bukan. Semua orang kerja sesuai target masing-masing: support catat semua laporan tepat waktu, engineering selesaikan task sesuai deadline sprint. Cuma alur kerja kita yang bikin dua tim ini kerja di dunia terpisah.
Pada hari kita akhirnya sadar ada 12 laporan duplikat itu, kita audit dan menemukan ada 3 task terpisah di board engineering yang isinya bug sama, cuma dilaporkan oleh orang berbeda di channel berbeda. Tidak ada yang sadar itu bug yang sama sampai seorang engineer nyoba reproduce dan menemukan pola yang sama.
Hal yang kita salah paham sebelumnya
Sebelumnya kita berpikir pisah alur kerja antar divisi itu lebih efisien. Support urus pelanggan, engineering urus kode, jangan campur aduk supaya tidak ada noise di board task. Kita juga takut kalau support bisa langsung buat task di board engineering, nanti ada task yang tidak jelas, banyak laporan tidak penting yang masuk mengganggu prioritas sprint.
Ternyata semua asumsi itu salah. Noise yang kita takutkan jauh lebih kecil dibanding noise yang kita dapat dari chat bolak balik antar tim, laporan duplikat, dan waktu terbuang karena tidak ada informasi konteks lengkap di task engineering.
Satu lagi kesalahan umum: kita coba memperbaiki ini dulu dengan bikin grup WA khusus support dan engineering, berharap semua komunikasi ada disana. Itu malah bikin lebih berantakan. Laporan bug tenggelam di tengah chat tentang rilis baru, ada yang lupa di follow up, dan tidak ada catatan permanen status bug untuk dilihat semua orang nanti.
4 perubahan kecil yang bikin waktu resolve bug turun 70%
Kita tidak melakukan reorg tim, tidak menambah staff baru, tidak beli tool baru yang harganya jutaan per bulan. Semua perubahan ini cuma menyesuaikan alur kerja yang sudah ada, dan semuanya jalan dalam minggu pertama implementasi.
Pertama, kita hapus seluruh spreadsheet laporan bug sepenuhnya. Semua laporan dari pelanggan harus langsung masuk ke task board, tidak ada perantara sama sekali. Di SatuTim kita bikin template task khusus laporan bug, yang otomatis minta support isi semua informasi yang dibutuhkan: nama pelanggan, langkah reproduksi step by step, screenshot atau rekaman layar, dan tingkat dampak bug.
Tidak ada lagi laporan bug berisi "ada error dong" yang tidak jelas. Support cuma isi template itu, klik simpan, dan task langsung muncul di board engineering dengan label prioritas otomatis sesuai dampak yang dipilih. Tidak ada lagi ketik ulang laporan, tidak ada lagi lupa ngirim laporan ke tim engineering.
Kedua, kita bikin satu kolom status bug yang terlihat untuk semua tim, tanpa harus chat. Setiap engineering update status task: dari "belum diverifikasi" ke "sedang dikerjakan" ke "sudah diuji rilis", sistem otomatis kirim notifikasi ke channel support, bahkan memberikan template jawaban yang bisa langsung dikirim ke pelanggan.
Kita hapus seluruh meeting update bug rutin yang dulu diadakan setiap hari Senin 30 menit. Semua informasi yang dulu kita bahas di meeting itu sekarang sudah tersedia secara real time, kapanpun tim support butuh cek. Total waktu yang kita dapat balik dari meeting ini saja hampir 2,5 jam per minggu.
Ketiga, kita tetapkan satu orang engineering oncall setiap minggu, yang punya kewajiban cek semua laporan bug masuk maksimal 1 jam setelah laporan dibuat. Bukan untuk langsung memperbaiki, tapi cuma verifikasi apakah laporan itu valid, dan menetapkan prioritasnya: apakah ini critical yang harus dikerjakan hari itu, atau low priority yang masuk sprint dua minggu kemudian.
Kita juga kasih wewenang penuh ke tim support untuk menandai bug sebagai critical jika ada lebih dari 3 pelanggan yang melaporkan hal yang sama, tanpa harus minta approval PM dulu. Dulu laporan bug bisa ngendon 3 hari di spreadsheet sebelum ada yang lihat, sekarang rata-rata waktu verifikasi bug cuma 38 menit.
Keempat, kita buat async review bug setiap Jumat sore, totalnya cuma 10 menit per orang. Setiap minggu kita tarik semua laporan bug yang masuk minggu itu, lihat pola umum yang bisa dicegah di tahap testing selanjutnya. Tidak ada meeting, cuma daftar di fitur Discussions SatuTim, semua orang bisa komentar kalo ada saran perbaikan.
Misal bulan lalu kita menemukan ada 3 bug yang semuanya berhubungan dengan fitur payment, jadi kita menambahkan 1 test case khusus payment sebelum setiap rilis mingguan. Setelah itu, tidak ada lagi bug terkait payment yang lolos ke produksi.
Hasilnya setelah 3 bulan berjalan
Waktu rata-rata resolve bug critical yang dulu 54 jam, sekarang turun jadi 16 jam. Jumlah laporan bug duplikat turun 92%, dari rata-rata 8 per minggu jadi kurang dari 1 per minggu. Jumlah komplain pelanggan tentang "kapan bugnya selesai" turun 81%.
Yang paling mengejutkan, beban kerja kedua tim justru berkurang. Tim support tidak perlu lagi chat bolak balik nanya progress bug ke engineering, tim engineering tidak perlu lagi mencari konteks laporan bug dari chat grup yang tidak jelas. Semua informasi yang mereka butuhkan ada di satu tempat, tercatat dengan jelas.
Bulan setelah perubahan itu, ada bug lupa muat data di halaman laporan yang dilaporkan 3 orang pelanggan dalam 20 menit. Support langsung tag bug sebagai critical, oncall engineering cek dalam 40 menit, memperbaiki, dan mengirim update ke semua pelanggan sebelum ada yang komplain lagi. Total waktu dari laporan masuk sampai selesai dan terkirim update ke pelanggan cuma 2 jam. Yang dulu butuh minimal 3 hari.
Ada satu hal yang gak banyak orang bilang tentang silo lintas divisi: 90% kasus silo bukan masalah orang yang tidak mau kolaborasi. Itu masalah alur kerja yang kita buat sendiri. Kita juga dulu punya tim support yang super rajin, engineering yang kerja cepet, tapi karena kita bikin mereka berkomunikasi lewat perantara, semuanya jadi lambat dan tidak efisien.
Ini kontroversial tapi menurut pengalaman gw, gak butuh tool mahal atau reorg besar buat nyelesain masalah ini. Banyak tim yang beli platform manajemen proyek seharga jutaan per bulan, tapi masih nyimpen laporan bug di spreadsheet terpisah. Percuma aja.
Coba cek tim lo hari ini: ada berapa alat berbeda yang dipakai untuk nyimpen laporan pelanggan vs track progress engineering. Kalau ada lebih dari 1 tempat, itu tempat lo kehilangan waktu paling banyak tiap minggunya.
Kalau lo pengen coba template laporan bug yang kita pakai, ada di fitur Task template SatuTim yang bisa lo pakai langsung tanpa setup rumit.
Pertanyaannya: berapa banyak bug yang sudah ngendon di spreadsheet tim lo yang belum kelihat sama engineering sampe hari ini?