Ritual, Bukan Alat

OKR kami mati di dua alat berturut-turut. Catatan soal kenapa alat hanya hidup kalau ada ritual yang menempel, dan ritual mana yang paling cepat hilang ketika agen AI mengerjakan sebagian besar tiket.

· 7 menit baca

Pagi ini aku buka Operately, alat goal dan check-in yang kami pasang bulan ini. Isinya: 18 orang terdaftar, 0 goal, 0 check-in, 1 proyek. Refleks pertamaku, jujur saja, adalah mencari alat lain. Mungkin UI-nya kurang enak, mungkin notifikasinya tidak sampai.

Lalu aku ingat kami sudah pernah melakukan itu. Tanggal 25 Agustus tim memutuskan OKR pindah ke Multica. Di sana tercatat 13 objective, 39 KR, dan 36 check-in. Check-in terakhir tanggal 26 Agustus. Sesudahnya sepi.

Jadi OKR kami mati di dua alat. Kalau sesuatu mati di dua tempat berbeda dengan pola yang sama, tersangkanya bukan tempatnya.

Yang hidup dan yang mati di rumah yang sama

Multica sendiri tidak sepi. Dalam 30 hari terakhir ada 533 isu dibuat di sana, 29 agen bekerja, dan sekitar 300 run autopilot sebulan. Papan yang sama, login yang sama, orang yang sama.

Bedanya, pekerjaan harian memang mengalir lewat Multica. Tiket di-assign, agen mengambil tugas, status berubah karena kerjanya bergerak. Tidak ada yang perlu mengingat untuk membuka Multica, karena tanpa membukanya kerja tidak jalan. OKR tidak punya jalur seperti itu. Mengisi check-in adalah kerja tambahan yang tidak dibutuhkan oleh kerja apa pun.

Pola ini juga muncul di dalam Multica sendiri. Cycle 2 kami, “Analytics”, berjalan 12 September sampai 23 Oktober. Jumlah bet yang tercatat di modul cycle-nya: 0. Siklusnya jalan, modulnya kosong.

Contoh yang paling bikin aku diam agak lama adalah laporan kesehatan papan otomatis tanggal 14 September. Isinya tajam: batas WIP 2 per orang dilanggar, satu orang memegang 33 kartu, 81 kartu menunggu review lebih dari 3 hari, 60 kartu jalan tanpa PIC. Laporannya terbit rajin, tepat waktu. Tapi tidak ada satu orang pun yang wajib bertindak setelah membacanya. Per 25 September, isu di status in_review ada 156.

Laporan yang terbit tanpa pembaca adalah log file. Berguna untuk forensik, tidak mengubah apa-apa hari ini.

Anatomi ritual yang hidup

Kalau aku bongkar kenapa Multica hidup dan OKR mati, ketemu lima bagian. Ritual yang hidup punya kelimanya. Yang mati biasanya kehilangan satu, dan yang paling sering hilang adalah pembaca.

BagianPertanyaannyaKalau tidak ada
PemicuMenempel ke momen yang sudah terjadi?Butuh rapat baru, lalu rapatnya dibatalkan
PemilikAda satu nama?Semua orang, artinya tidak ada orang
PembacaSiapa yang wajib merespons?Laporan jadi log file
KonsekuensiDipakai untuk keputusan apa?Jadi teater
BiayaSelesai dalam 5 menit?Ditunda sampai hilang

Laporan kesehatan papan lolos di pemicu, pemilik, dan biaya, karena agen yang membuatnya. Ia gagal di pembaca dan konsekuensi. Check-in OKR gagal lebih awal: pemicunya tidak menempel ke apa pun, jadi dia harus diingat, dan sesuatu yang harus diingat akan dilupakan.

Multica pun tidak lolos sempurna. Mengerjakan tiket punya kelima bagian: pemicunya tiket di-assign, pemiliknya assignee, pembacanya orang yang menunggu hasil, konsekuensinya kerja berikutnya bisa jalan. Mereview tiket berbeda. Pemicunya ada, status berubah jadi in_review. Pembacanya tidak jelas, karena tidak ada satu nama yang wajib merespons dalam waktu tertentu. 156 isu yang menumpuk itu adalah ritual review yang kehilangan pembaca, di alat yang sama yang sedang ramai-ramainya.

Soal biaya, di sinilah agen benar-benar membantu. Agen bisa menyiapkan draf dari data isu, jadi yang tersisa untuk manusia cuma bagian yang memang butuh kepala manusia. Tahan dulu poin ini, nanti aku balik ke sini.

Shape Up tidak anti ritual

Ada salah paham yang sering aku dengar: Shape Up itu anti proses. Padahal Shape Up penuh ritual. Siklus, cooldown, betting table, pitch, hill chart. Yang dihindari Shape Up adalah laporan status, pertanyaan “sudah berapa persen?” yang dijawab untuk menenangkan atasan.

Di sini aku perlu mengaku. Di post kemarin aku menulis bahwa Operately adalah outer loop kami, lewat check-in Jumat dengan status on track, caution, atau off track. Itu usulanku. Setelah melihat angka nol di atas, aku sadar usulan itu bertabrakan dengan hill chart. Hill chart sudah menjawab pertanyaan “kerjaan ini di mana?”, dan menjawabnya lebih jujur, karena memisahkan fase masih mencari tahu dan fase tinggal mengerjakan. Check-in Jumat menanyakan hal yang sama dengan bahasa lain, di alat lain.

Dua ritual yang menanyakan hal sama saling bunuh. Orang mengisi satu, lalu yang lain terasa seperti kerja ganda, lalu dua-duanya ditinggal. Aturan yang sekarang aku pegang: satu pertanyaan, satu ritual, satu alat.

Tim kami pakai ritme 4 minggu build dan 2 minggu cooldown, dan cooldown itu kami anggap sakral. Metode lain juga paket ritual, cuma isinya beda:

MetodeRitual yang memaksa alat dibuka
ScrumSprint review, retro
KanbanBatas WIP
WaterfallGerbang fase
Shape UpBetting table, hill chart

Setiap SDLC pada dasarnya adalah paket ritual yang sudah dirakit. Jadi pertanyaan waktu memilih alat bukan “fiturnya lengkap atau tidak”. Pertanyaannya: alat ini menempel ke ritual mana, dan siapa yang membacanya?

Celah di setelah rilis

Shape Up kuat untuk membangun. Dari framing sampai ship, ritualnya lengkap. Yang tidak dia punya secara eksplisit adalah ritual untuk mengecek hasil setelah rilis. Idealnya cooldown dipakai untuk itu, tapi praktiknya cooldown sering habis untuk bug.

Pakai bahasa post kemarin: Shape Up menjaga inner loop dengan rapi. Bet di-shape, dibangun, lolos, rilis. Outer loop, yang bertanya “apakah ini benar di dunia nyata dan apa yang kita pelajari?”, tidak punya jadwal. Dan sesuatu yang tidak punya jadwal akan kalah oleh sesuatu yang punya.

Ritual yang paling cepat hilang

Minggu ini Karri Saarinen, CEO Linear, menulis Tools Are Getting Better. Are We? (25 September 2026). Argumennya: kerja produk menghasilkan dua hal, produknya dan pembelajaran dari membuatnya. Kita terobsesi pada yang pertama. Perusahaan yang hebat, katanya, “compound their understanding”, pemahaman mereka berlipat dari siklus ke siklus.

Dia juga cerita, saat dirinya menjauh dari tim produk, produknya terasa kabur. Jawabannya bukan menolak AI. Jawabannya memakai efisiensi agen untuk lebih banyak belajar tentang pelanggan. “Automate the known work”, otomatiskan kerja yang sudah dipahami, sementara manusia tetap dekat ke masalah pelanggan, discovery, penilaian, dan arah produk. Dan tentukan dengan sengaja di mana dan kapan belajar itu terjadi.

Kalimat terakhir itu yang nyambung ke papan kami. Agen sudah mengambil alih sebagian besar ritual kerja: mengambil tiket, menulis kode, bahkan menulis laporan kesehatan papan. Ritual belajar tidak ikut pindah ke agen, karena memang tidak bisa. Dan karena tidak ada yang mengambilnya, ia hilang diam-diam. 533 isu sebulan, dan tidak ada satu tempat pun di mana tim duduk dan bertanya “apa yang kita pelajari dari yang sudah rilis?”

Usulan: dua ritual, satu pembagian alat

Yang berikut ini masih usulan. Belum dijalankan.

Siklus Shape Up tim kami dengan Multica dan Operately, termasuk dua ritual baru

Siklusnya dibaca searah jarum jam dari betting table. Kotak ungu putus-putus adalah dua ritual yang diusulkan; panah “wajib dikutip” dari Review Realita ke betting table adalah konsekuensinya.

1. Review Realita. Pemicunya minggu pertama cooldown, satu review per bet yang dirilis. Lima pertanyaan:

  1. Apa yang kita harapkan?
  2. Apa yang terjadi di dunia nyata? Data, tiket support, call pengguna.
  3. Kalau meleset, celahnya di mana: requirement, asumsi tes, kode, atau tesnya?
  4. Apa yang kita pelajari soal pelanggan atau sistem?
  5. Apa yang berubah untuk bet berikutnya?

Pemiliknya pemegang bet. Pembacanya betting table, dan di sinilah konsekuensinya: sebelum memilih bet baru, betting table wajib mengutip minimal satu pelajaran dari Review Realita.

Agen menyusun draf untuk pertanyaan 1 sampai 3 dari data. Pertanyaan 4 wajib ditulis manusia dengan kata sendiri. Alasannya sederhana: pelajaran yang ditulis agen tidak tinggal di kepala siapa pun. Dokumennya ada, pemahamannya tidak.

Kalau diuji pakai lima bagian tadi: pemicunya menumpang cooldown yang memang sudah ada, jadi tidak perlu rapat baru. Pemiliknya satu nama. Pembacanya betting table, yang toh akan bertemu. Konsekuensinya jelas, pelajaran yang tidak dikutip berarti bet baru belum boleh dipilih. Biayanya kecil, karena agen sudah mengerjakan bagian mengumpulkan data dan yang tersisa untuk manusia adalah bagian berpikir.

2. Jam Pelanggan. Setiap siklus, setiap product engineer ikut minimal satu call pengguna atau satu sesi support sebelum betting table. Tiga kalimat catatan masuk ke Review Realita. Ini yang mengisi pertanyaan nomor 2 dengan sesuatu selain angka.

Pembagian alat. Mengikuti aturan satu pertanyaan, satu alat:

AlatPerannya
MulticaInner loop, OKR, bet, hill chart. Tempat builder bekerja
OperatelyTempat bet dan pelajarannya dibaca seluruh perusahaan, bukan alat kerja tim produk

Operately dapat satu kesempatan dengan batas yang jelas. Kalau setelah 2 siklus tidak ada yang membaca di sana, bekukan dan pindahkan ke catatan tim. Aku tidak mau mengulang pola ganti alat untuk ketiga kalinya.

Uji pertamanya direncanakan di cooldown Cycle 2, sekitar pertengahan Oktober. Ukurannya dua: setiap bet yang dirilis punya Review Realita, dan betting table benar-benar mengutip pelajarannya. Kalau dua-duanya tidak terjadi, masalahnya ada di ritualnya, dan aku akan menulis soal itu juga.

Alat bisa diganti dalam sehari. Ritual yang tidak punya pembaca akan mati di alat mana pun.

Tulisan terkait