Minggu lalu gw liat tiket Jira status 'Done', tapi client langsung nolak deliverable. Alasan? 'Ini gak sesuai flow user yang dibahas di minggu pertama.'
Gw panik buka sheet RACI kita. Di situ jelas tertulis: Product Owner = Accountable, Lead Dev = Responsible, UI/UX = Consulted. Semua centang hijau. Semuanya aman.
Tapi kenyataannya? Work-annya jeblok parah. Dan yang bikin kesal, bukan karena siapa yang culas atau malas. Masalahnya, 'Responsible' tadi beneran ngerjain sesuai brief yang dia baca, padahal context lengkapnya udah hilang di perjumpaan awal bersama client.
Kita ketemu titik nadir itu kira-kira 3 bulan lalu. Saat itu kolaborasi tim produk kita macet total. Silo antar divisi tebal banget. Dev ngerasa Product selalu berubah-ubah. Product ngerasa Design gak realistis. Design ngerasa Dev gak ngerti estetika. Dan kita semua sembunyi di balik RACI matrix sebagai tameng 'birokrasi aman'.
Putusan keraspun diambil: cabut RACI harian, ganti sistem.
RACI Itu Menipu — Kita Lagi Main Aman Palsu
Banyak founder dan PM senior percaya RACI itu solusi final buat clarifikasi peran. Gw dulu salah satu yang nge-gass soal ini.
RACI itu bagus buat audit HR, bagus buat compliance, bagus buat bikin manajemen merasa tenang karena ada kertas yang ditandatangani. Tapi di lapangan operasional startup atau agency mid-size, RACI justru membatalkan nuansa pekerjaan.
Masalah utamanya simpel: RACI mendorong mentalitas 'Not My Business Unless I'm 'A''.
Ketika seorang Senior Dev melihat tag 'Consulted' buat task tertentu, otaknya otomatis ngeblock attention. 'Ah, ini urusan PM. Aku cuma kasih input kalau ditanya.' Akibatnya, pertanyaan kritis gak dilontarkan duluan. Developer baru nyadar ada dependency yang kelupa-an tiga hari menjelang deadline. Nah, di situlah rework dimulai.
Kita pernah kena kasus beginian berulang kali. Brief berubah 4 kali, tapi karena si A marked 'Informed' dan gak follow-up agresif (padahal dia punya wewenang), dia baru tau update terbaru pas meeting review. Telat banget.
Kolaborasi tim produk emang butuh lebih dari sekadar tanda centang di spreadsheet. Kita butuh empati konteks, dan RACI gak bisa ngasih itu.
Masuk Ke Fase 'Handoff Buddy': Eksperimen Sialan (Yang Berhasil)
Gw mulai riset model kolaborasi alternatif yang bisa mendobrak silo tanpa bikin struktur organisasi ambruk. Gw nemu konsep dasar yang kemudian gw adaptasi jadi 'Handoff Buddy Method'.
Intinya gini: setiap sprint, satu orang dari Divisi A akan 'disandera' sementara ke Divisi B. Bukan dipindah tugas permanen, bukan promosi, tapi shadowing intensif selama satu siklus penuh.
Contoh konkretnya:
- 1 Person dari Tim Dev jadi Handoff Buddy buat Tim Product selama Sprint 1.
- 1 Person dari Tim Design ambil giliran jadi Handoff Buddy buat Tim Dev di Sprint 2.
- Rotasi terus berlanjut.
Si Handoff Buddy gak boleh cuma duduk manis. Lo harus:
- Hadir di semua standup dan planning meeting divisi tamu.
- Ikut melakukan review-an harian.
- Punya akses penuh ke channel komunikasi divisi tersebut.
- Wajib ngasih insight unik sebelum kembali ke divisi asal di akhir sprint.
Gw sempat takut bakal terjadi kekacauan. 'Lha kan capacity divisi asli berkurang?'
Jawabannya: Lo harus mengurangi scope tugas orang yang di-swapping sekitar 20-30%. Jangan coba-coba swap tanpa adjust workload. Gw dulu pernah coba swap PM tanpa kurangi beban administrasinya, hasilnya dia burnout berat dan malah bikin silo tambah parah karena stress.
Angka Ngomong Lebih Keras Daripada Opini
Biasanya gw skeptis sama klaim metrik. Tapi data dari eksperimen Handoff Buddy Method selama 3 bulan ini gak bisa dipungkiri.
Kita tracking dua KPI utama: jumlah missed requirement yang bocor sampai fase QA, dan jam kerja yang terbuang buat rework akibat misunderstand konteks.
Hasilnya?
Setelah 3 siklus (sekitar 6 minggu):
- Missed requirement turun 27%.
- Rework hour berkurang hampir 50%.
Penurunan 27% buat missed requirement itu angka yang nyata. Artinya, banyak detail kecil yang tadinya luput karena 'anggap remeh', sekarang tertangkap sejak dini oleh mata segar dari divisi lain.
Contoh kasus yang paling ngena di hati tim gw adalah soal fitur export report. PM bilang ini fitur low-hanging fruit. Dev bilang gampang, tinggal generate CSV. Design udah siapin template sederhana.
Nah, pas Sprint 3, ada Senior Backend Engineer yang jadi Handoff Buddy di Tim Product. Dia duduk bareng PM waktu wawancara user lanjutan. Eh, dia denger user ngeritilin ada constraint teknis soal validasi pajak regional yang beda-beda tiap tipe akun enterprise. Ini detail yang gak ada di PRD, tapi krusial banget.
Karena si Buddy kepo sejak awal, requirement ini langsung naik status jadi 'High Risk & Complex' di sprint berikutnya. Dev gak perlu nulis code ulang tiga kali. Time saving-nya gede banget.
Kalau sebelumnya dev baru nanya 'kenapa fitur ini perlu spesifik begitu?' pas mau coding, sekarang, si Buddy udah mencerna pertanyaan-pertanyaan itu sambil nemenin PM, jadi saat hand-off, tim teknis udah punya konteks yang jauh lebih matang.
Itulah perbaikan alur kerja lintas divisi sebenernya: transfer konteks, bukan cuma transfer file.
Kolaborasi Butuh Empati Konteks, Bukan Cuma Tanda Centang
Pelajaran terbesar setelah 3 bulan eksekusi Handoff Buddy Method? Kolaborasi bukan masalah proses, masalah persepsi.
Sebelum jadi buddy, kita sering ngerasa kerjaan tim sebelah 'santai aja kok'.
'Dev mah ngoding doang, gampang.'
'Designer mah drag-drop Figma, cepet banget.'
Pas lo masuk jadi Handoff Buddy, realita menghantam.
Lo sadar kalau kerjaan Dev bukan cuma ngetik kode di IDE. Lo lihat mereka harus dealin legacy code berantakan, menghadapi tekanan latency dari client, dan nego prioritas fitur sama stakeholder yang suka change of heart. Lo liat bagaimana mereka frustrasi pas ada requirement ambigu yang muncul mendadak.
Begitu juga sebaliknya. Lo yang jadi buddy di Tim Product, lo sadar PM bukan cuma 'pengurus Jira'. Lo lihat betapa melelahkannya harus manage ekspektasi client yang impossible, sambil tetap jaga morale tim, sekaligus nerima tekanan financial dari founder.
Empati ini lahir secara organik. Gak bisa dipaksa lewat workshop team building yang kaku. Empati muncul karena lo ngerasain pusingnya doi.
Akibatnya, pasca-sprint, interaksi di kantor berubah dramatis. Komunikasi jadi lebih pendek dan efektif. 'Hey, gw liat ticket ini agak risky loh,' lebih umum dibicarakan daripada diam-diam ngerajuk di Slack. Silo hancur karena masing-masing tim sekarang saling paham beban kerja lawan.
Cara Eksekusi Tanpa Ngeblock Kalender Lo
Bagaimana cara lo apply ini tanpa bikin jadwal lo meledak? Gw sharing praktik yang jalan di tim gw.
Pertama, jangan swap semua orang sekaligus. Pilih titik friksi. Kalau lo nemu dev dan product sering bentrok soal fitur, swap satu person dari masing-masing divisi itu saja. Fokus dulu ke masalah yang nyerempet dompet.
Kedua, gunakan tool yang tepat biar knowledge gak jatuh ke lantai. Di SatuTim, kami memanfaatkan fitur Brief untuk memastikan context yang ditangkap si buddy bisa ditarik ulang dengan mudah. Jadi waktu si buddy balik ke divisi lamanya, dia tinggal attach insight-nya langsung ke ticket PR-an terkait. Gak perlu meeting panjang lebar buat reporting.
Ketiga, beri ruang buat si buddy bertanya 'bodoh'. Seringkali, hal paling berharga datang dari pertanyaan yang terdengar konyol buat orang dalam, tapi sangat fundamental buat orang luar. Biasakan budaya bahwa 'bertanya itu wajib, bukan kelemahan'.
Keempat, buat ritual penutupan sprint yang singkat. Si buddy wajib narasummarikan '3 hal yang bikin gw salut' dan '2 hal yang bikin gw bingung' tentang kerjaan divisi baru. Ini bentuk feedback loop dua arah yang bikin divisi tamu juga evaluasi diri mereka sendiri.
Terakhir, ingat: ini bukan pelatihan cross-training jangka panjang. Tujuannya cuma membangun jembatan empati dan deteksi dini risiko alur kerja. Jangan paksa seseorang jadi full-stack dalam semalam.
Cek Silo Tim Lo Minggu Ini
Jadi, cek sheet RACI lo sekarang. Lo masih bergantung pada spreadsheet buat nyari tau siapa pegang apa? Atau kalian udah mulai saling nyalihin karena 'status-nya udah jelas' tapi hasilnya gak jalan?
Coba satu sprint nanti, swap satu orang antara Design dan Dev, atau Product dan Engineering. Kurangi beban kerjanya 20%. Biarkan dia duduk, denger, dan kepo.
Liatah setelah 2 minggu, seberapa cepat ticket berjalan tanpa perlu tanya-tanya mendasar lagi? Seberapa jarang request yang harus diulang?
Kalau lo berani keluar dari zona nyaman birokrasi, gw jamin pengalaman lo bakal ngasih return rate yang gak bakal lo harapkan. Soal kolaborasi, kadang lo gak butuh aturan baru, lo butuh kaki baru yang bisa jalan di ladang tetangga.
Gimana menurut lo? Apakah RACI masih jadi sandaran utama lo, atau lo sudah mulai rasa kurang puas sama hasil kolaborasi tim produk?